Yes, rich (HTML/RTF/whatever this new crap Outlook 2007 is pulling is) email can be horribly messy. Yes, it is a requirement. Yes, if you think text-only is the way to go, you need to pull your head out of the sand. Welcome to the twenty-first century.

The closest I’ve come to someone who thought like that was a chap who was adamantly against the idea of content management systems. I jest not, but in my mind that’s less serious an offense than suggesting that all content on the web should consist solely of text and links, “because that’s the way it was designed”. That is, in essence, what these sysadmins (and some other open-source bigots — we should all use Mutt and Pine — who probably haven’t much experience with the creation or delivery of such things) are arguing.

“The four stripes down the left-hand side of each page of this site provide ambient temporal context to the item currently displayed—as does the brightness of the background color and overall contrast of the page you are viewing.”

A few months back I’m so sure I would have dismissed that as a fine load of waffle indeed. “Ambient temporal context”? Puh-leeaassee. But it does actually make sense. Almost in an Edward Tufte kind of way. It’s exciting and dynamic and automated and whatever else (presumably because of his brain being abnormally advanced and adept at ninja JavaScripting + less obvious backend things, etc.), but it actually does so to an end.

The visual representations are useful. One will discover chronology very rapidly, or perhaps simply understand with greater precision, the temporal nature of content featured. It feels on first glance wanky as the way that the word “symposium” is bandied around in academic-parlance when speaking of what normal people would term a conference, but it’s really not.

I think there’s something about geek culture that lets us be a little eclectic. A little ironic (socialist imagery for self gain?). There’s a difference, of course, between straight “geek culture” and IT culture — IT culture is people stuck in a cubicle writing code. Geek culture, as I define it (because I identify with it), is more about ridiculous manifestos and speculation about the next wave and pursuing possibly-never-eventuating ideas. Like Parakey, for example, which scares me (would scare me) if it ever got anywhere.

Yes, even the young and hip in our midst are afraid of change. Not that that would be me. I’ll take my free designer’s drinks where I can but at the end of the day (that is, in about an hour’s time) I’m still an ill-defined generalist. Which is a self-effacing way of saying strategist/integrator. Which is a pretentious way of saying broad knowledge of dubious depth.

Labels aside, it’s interesting to observe one thing that demarcates (in the view of a character I met today known as RLS) content management systems from blog platforms. I was stunned to hear a fairly serious web developer (even if we disagree on MVC and behaviour/content/presentation concepts) dismiss content management systems as “the worst thing that ever happened to the web”. A few horror stories about migration later (and a few “Josh, you really haven’t been around long enough to know” looks, no doubt) and it all started to make sense. The problem wasn’t migration or data (yes, even data) or closed/open source or any of the usual complaints, but users. And the flexibility that users demand and that content management systems have never willingly provided.

This is the second paragraph of the second big idea of this blog post: I have no way to distinguish and define this paragraph as belonging to the second big idea. I would love to be able to have been able to put the opening two words of the last paragraph (“Labels side”) in small capitals to demonstrate the start of a new section. I can’t. My software doesn’t let me do that — or, if it does, it does so in a way that isn’t scalable and semantically sound. Or, if it does let me do so in a way that is scalable and semantically virtuous (both in an internal data structure (relational DBs and so forth) and semantic markup (HTML, XML, XHTML) context) then it’s nigh on impossible to use and makes so much work it’s infinitely faster for me to write a Dreamweaver template, lock it, and create new pages manually based around this. Case in point, ezpublish. Full points for extensibility and flexibility, abstracted data structures, etcetera, but a big fat fail for making this practically useful. Having to reload the webpage or change views in order to put a photo into a document is not acceptable — media library is great, but not if it takes me away from my content for a moment.

The point is, tools get in the way often in ways completely foreign to hack-it-and-manage-it-yourself Frontpage-esque ways of thinking. According to RLS, this is particularly offensive in light of its similarities to bad management practice.

You don’t stand over your employees wielding a club in order to make them do things your way. You provide them with facilities to let them get the job done as best they can, and tools to enable them to innovate and improve your business processes, rather than playing the autocrat and creating automatons who don’t innovate and don’t think, either. As we can all imagine, non-thinking users are quite dangerous if you’ve got a hole anywhere for them to fall in to. (Unless you’re working in school IT, in which case thinking users are the infinitely greater risk!)

Therefore, content management systems are constrictive and evil. I went from a position of wanting to exclaim “what are you on, that’s completely insane, step away from that database!” to being convinced when he told me we were thinking along the same lines. So what’s my song that sounds so similar?

In a few points, something like this:

• Structured data is good.
• Interoperability is essential and good.
• Users are dumb.
• Users are smart enough to want good tools they can use, even if they don’t always have the language to describe what they want.
• Good tools let you structure data without thinking about it.
• Good tools take advantage of structuring data as a part of users existing workflow and business processes, and don’t increase administrative burdens.
• Good tools let you manipulate data and recycle it and re-envisage it in powerful, clear, and exciting contexts.

One of these things is not like the other one…

But most of it is. RLS emphasised the importance of flexibility. I do that, too. Only my flexibility is based around bending (or better, designing) the tool to make it accommodate user requirements properly, rather than dismissing the tool and returning to abstract semantics and poorly defined data structures (i.e. none except by HTML markup). Of course, I’m biased, and am possibly misrepresenting his thought.

In fact, there were several important qualifications to what he had said. This theory applies only to large bodies of text (in this case, recordings of semi-legal proceedings), not to other content types. For example, CRM tools are acceptable. Photo management, presumably, would also be acceptable. That all makes sense. Most curious was the idea that blogging utilities were acceptable, whilst content management systems were not.

Yes.

The theory is simple enough: blogs are something you give users and say “here, have this, work with it and manipulate it as you will”, whilst content management systems are something foisted upon users by middle-upper-management. Unfortunately, to me, this seems more like what I imagine an anti-uni-IT-service campaign run by Socialist Alliance would sound like. That is, not an objection to the tools themselves, but merely the bureaucracy behind these.

It’s not quite that simple, though.

Blog users do have a reputation for taking things in unusual directions. Think about categories. We kicked off with those and then grew out of them. So all of a sudden we had tags, instead. Then tag clouds. Then folksonomies. Sure, some of these things are gimmicks that are going to die off, but the point is there’s scope for innovation that traditional content management systems wouldn’t necessarily take kindly to. (Good ones would, but that’s besides the point, because I have a sneaking suspicion RLS hasn’t encountered any well-written, extensible, content management system). So blogs are quite different in that regard, and very much descriptivist with their content — that is, they take it and let it grow as it will, somewhat organically, and generally kick back and let users take their course. No prescriptivism here.

So there we go. Josh rolls elitist design/usability concepts, geek culture, labels, intergenerational conflict, a discussion of content management versus blogs, and linguistics all into one blog post. Now what category do I stick this in?

I tried Nvu ages back when it was still fairly new (but a while after the fork from Composer) and was pretty uninspired by the whole experience. Just recently I’ve been giving it a whirl for more complicated semantic markup (i.e. tables) and it’s performed admirably! You’ll note in the screenshot the HTML tag view gives you a pretty precise look at what’s going on. I managed things with regular tabbing between HTML tag and Source views (the Source syntax highlighting still isn’t realtime, which is a bit disappointing) — this is really helpful in reducing the time it takes to churn out good quality tables. You can also create unsemantic tables and whatever else with this, but it fixes things fairly readily and has “header” styles inbuilt for TH things, etc. The only thing it really doesn’t seem to want to do even manually is add thead elements, but if you edit them in yourself it won’t try and get rid of them.

Really good (free) tool for certain types of maintenance stuff. If it had a half-decent templating system (ala Dreamweaver Templates, which have got to be pretty simple to implement on top of an existing code base doing all the hard WYSIWYG work, etc.) I’d be seriously considering making more static page templates and handing administration over in a client-side sense using this program. Great stuff, and if you haven’t looked at it for a while/ever, worth considering.

Edit: Maybe it does have a half-decent templating system! I just saw the very prominent Insert → Templates → Insert Editable Area option. Doh, now I have to seriously think about such things. And, upon more serious reflection, the advantages afforded by web-based content management systems are generally too great to ignore. The only case it could be justified is where there’s no budget (or, in the case of volunteer work, no time), in which case chances are the website isn’t too likely to have dynamic requirements, anyway.

Launched very very quietly about a week ago. It’s hardly content-ready but that should hopefully come over the next week or two. We’re keeping busy and hopefully there’ll be blog thingies going eventually. It’s currently built around WordPress, which is a choice I made a few months ago [and now… you finish this sentence]. The content was taking ages to get perfect so our staff team decided it’d be best just to launch it and replace the old thing. So now we’ve got an incomplete new website! ;-) But it’s getting somewhere, praise God for the gifts of technology for communicating!

The upcoming events thing doesn’t have anything yet (and should), and will be incredibly interesting. I think the calendar system is probably still too counter-intuitive (it’s a WordPress plugin designed to link to blog entries) so I probably need to look at other options for that. There’s also a distinct lack of media library aspects that could mean more work when graphics or other documents need uploading, but we can address that in good time. By address, I mean change to a real content management system. Sigh, no-one but myself to blame, really.

Speaking of church websites, I found one in the Sydney Anglican diocese that I actually like! Shock, horror! It belongs to St Peters Church Cooks River (located in St Peters the suburb, that is). I’d probably make the navigation square on the corners and if I were to use anti-aliased text make it something legible, or just plain HTML nav, but other than that I quite like the feel of the site. The less I say about markup the better, I think. It’s all done with Dreamweaver templates, which is an awesome option I’d be tempted to embrace but for the cost which we really can’t afford for the flexibility it doesn’t give compared to a multi-user CMS. One other new website of note is Moore College’s recent update. Semantically beautiful, solid design, okay CSS implementation (it… really doesn’t work too well at higher resolutions in Opera at least, I can’t be bothered opening another browser right now)

Anyway. Ours is good for the minute. It’s getting better, promise. And we’ll have half-decent creatives for it sometime in the hopefully-not-too-distant future once the one or two graphic designers in our midst are politely roped into creating such things :) I’d love to see more blog content, publication of more material we produce internally (most recently is the sheet on “How to choose a good church”, but there are plenty of others), a high-quality kid’s/youth ministry section (not just for youth — Dave Blowes is trying hard there with the JAM website — but for sharing what we’re doing with parents and childrens/youth programmes at other churches), greater multimedia stuff (mostly for those who aren’t regulars at Matthias and want to see what we’re doing, but also for archival purposes), electronic giving to make that easier, and online partner database that would effectively be a searchable church directory (secured, obviously).

I’m just praying we don’t slide down the slippery path into technology dependence along the way, because it scares me so much. I’m not afraid of us turning into a church that embraces technology and uses it effectively and extensively: I’m afraid we’re going to wake up one day and will be playing a video that’s all about a passage from scripture instead of actually reading the bible itself in a meeting. I’m not afraid of the power of media under God: I’m afraid we’ll see the power of media and slowly God could slip from the picture as we think we can evoke a response using it without turning to His word.

This is the single most difficult thing for me about being involved with technology implementation in an Evangelical church in Sydney. We’re new to this stuff. The difficult thing is that it hasn’t been done before (except in Pentacostal/‘charismatic’/AoG circles, which are slightly different — I won’t comment further for fear of saying anything divisive here), and even where it has been it’s not been done holistically. Approaching media is approaching the world’s way of communicating, which is so deceptive and shallow and often ill-informed. The challenges that face us are relatively new, though their essence is not. We must hold onto what we believe whilst trying to communicate those beliefs as clearly and effectively as possible — but our communication is nothing without the growth provided by God.

What then is Apollos? What is Paul? Servants through whom you believed, as the Lord assigned to each. I planted, Apollos watered, but God gave the growth. So neither he who plants nor he who waters is anything, but only God who gives the growth. He who plants and he who waters are one, and each will receive his wages according to his labor. For we are God’s fellow workers. You are God’s field, God’s building.

– 1 Corinthians 3:5–9

Planting and watering can take the form of a DVD or a website or a sermon in MP3 format as readily as it could a book or an evangelistic sermon: none of these things are anything without the growth provided by God.

josh@whisper:~/public_html/XX/db/migrate$ rake migrate
(in /home/josh/public_html/XX)
rake aborted!
You have an error in your SQL syntax.  Check the manual that corresponds
to your MySQL server version for the right syntax to use near
'desc varchar(255)) ENGINE=InnoDB' at line 1:
CREATE TABLE courses (id int(11) DEFAULT NULL auto_increment
PRIMARY KEY, name varchar(255), desc varchar(255)) ENGINE=InnoDB
./Rakefile:200

Nyaaaah. I think it’s coz I’m using the only version of Ruby that the Rails team don’t recommend:

We recommend Ruby 1.8.4 for use with Rails. Ruby 1.8.2 is fine too, but version 1.8.3 is not.

Hah. Yeah, I’m using 1.8.3. It’s Ubuntu’s fault! That’s just what happened to be sitting in stupid apt repositories. So now I need to add backports to an otherwise-clean computer. *shudders* Well, I guess the alternative is compiling and trying to stay on top of all that… *Josh is seen hurriedly running to add backports sources*

Well, maybe not tonight. *wanders off to post on τρανσλιτερατιον before sleeping*

The barcode reader automatically appends a return character to the end of the string it’s read… which would, in any normal circumstance, submit the form. Obviously problematic unless we split the form over several pages, which is just yuck.

If the barcode reader hadn’t returned character 13 (return/enter/whatever you’ll call it) at the end of the string, it’d be trivial to pick up a “maxlength=x then go to next field” script off the side of the road… they’re everywhere. Not so much the case with this exact problem, though, so I thought I’d share…

[source:str javascript]function catchEnter(e){
var characterCode
if(e && e.which){
e = e
characterCode = e.which
} else {
e = event
characterCode = e.keyCode
}
if(characterCode == 13){
document.getElementById(‘cardid’).focus();
return false
} else{
return true
}
}[/script]

Note we’re not using DOM methods here… there isn’t any equivalent to which or keyCode that I’m aware of (I looked enough). keycode is the important one… which is used by the likes of Netscape 4.x and other nasties… I don’t really want to know about it, but I stole the key trap code from somewhere (lost the site) and didn’t really have a reason to intentionally break the behaviour for those browsers!

So we use one of those (probably keycode) to set characterCode, which is a numeric value that corresponds to Unicode decimal values. 13 is carriage return. Then it needs to be compared to event (the character that triggered the onkeypress event), here used as e for convenience… and if this is true, then focus will go to the next field (in this case cardid) and the character will return false to prevent the form from submitting.

I’ve got a static demo here (don’t mind the message at the top, it was an HTML mockup)… try entering something into the first field and pressing return. Then press return again, and the form will submit.

Obviously this Javascript only works for a two-field case… but you could dynamically set the element for focus to follow to by parsing that through to the function onkeypress event. The only other thing I can think of is to getElementsByTagName every input field in the form and use the array to dynamically set the “next” field… but that would have been waaaay overkill for what I had to do.

This behaviour isn’t just useful for barcode scanners, by the way. Desktop applications often exhibit this kind of behaviour, and it also goes some way to ensuring all fields are filled without doing formal validation (either JavaScript on submit, or server-side).

Then I remembered wget (which I use all the time for grabbing big files, because I can just background the process and not think about it til I wonder “Hey, where’d this several-GB file on my desktop come from?”) had FTP capabilities and could spider websites. Recursive get shouldn’t be a problem!

And it wasn’t.

Just use wget -r ftp://login:password@example.org/public_html/ (or similar) and the server you’re on will happily leech from an older one! Good stuff.

• Font rendering. This is how ClearType should have worked years ago.
• Improved standards compliance. The Sunrise Family site (live) now works with IE7 near-perfectly (i.e. no more or less broken than most other browsers. On par with Firefox, worse than Opera and Safari.) Happy happy happy!
• Zoom. Note this is SEPARATE to font sizing. But it’s still a little broken.
• Homepage tab group isn’t an extension or extra software that needs to be added. Whenever you add a homepage, IE prompts you if you want to make this your ACTUAL homepage or add it to the opening group of tabs. Playing catch-up, sure, but a good feature nonetheless

Against:

• Font rendering. It’d be great if it could intelligently antialias only san-serif fonts, and not process fixed-width or serifed fonts, which it invariably makes “fuzzy” rather than clearer. Also, font rendering seems to be smaller by default, which is both a good thing — it’ll force designers to make their base font sizes bigger — and a bad thing — in that, obviously, those designers that don’t conform will be subjecting users to painfully small text :-(
• Interface. Kudos for thinking outside the square, or whatever, but I reckon people are going to struggle getting used to this. I know I will, but that’s probably because I switch between at least five different browsers daily and expect them to all behave about the same. I get confused when going between Mac and PC, mostly, because the keyboard shortcut bindings change from Apple/Start — I’m using a KVM — and control + [key] change, so Internet Explorer moving anything around is bad for me, unless everyone else follows suit.
• Broken zoom resizes images + elements in HTML fine, but on one of my sites struggles resizing the background on the body (or maybe html?) element. Also, it doesn’t keep (all) centered sites centered once you zoom. This will obviously have to be fixed for the final release, too. I searched their newsgroup and couldn’t find anything so I posted something about it quickly. Vote for it, please :-)

The site

This is the vaguely alluded to website of a few days ago, for Seven Network’s breakfast show (I refuse to describe any such commercial network drivel as “current affairs”!), Sunrise. The Sunrise Family is essentially an incentive/loyalty scheme vaguely akin to Triple M’s (recently-abandoned… doubtless to be re-released in nearly exactly the same form under a different brand) Freq Club and Entertainment Book–style discounts. There might be more later on, but that seems to be about it so far as what’s there right now. And, truth be told, I’m not really sure what else is coming… I’d love to replace Sunrise’s boring ROSwall form with something akin to the infamous Flash Just Letters interactive fridge thingo, though maybe in an add-only type way, which would link in to viewers’ existing Family login (i.e. so they don’t have to enter their name every time, etc.), but that’s just an idea of mine.

The technology

So, the deals.

The interface is using AJAX, presently with inline onClick triggers — because, unfortunately, I’m not quite good enough to make it pull the data from the ID… though, if you view source, I’ve setup the ID’s to have two pieces of data in there. If anyone can tell me how to write an event handler that converts an ID into a string which I can then feed to an onClick handler (and, server-side, explode() using PHP) I’m still very keen to fix that “properly”. The ID’s have two data elements because the Deals interface is designed to add support for multiple states (i.e. localised offers, etc.) in the future. And they’re prefixed by d_ because, obviously, valid identifiers can’t start with a number. D can stand for “deal” or “data”, whatever :-)

As for how the AJAX is pulling down data, I’m just using innerHTML, because it works in pretty much everything and is lots faster and lots simpler than “real” DOM methods, especially here. Observe the “Details” pane on the right of that page, and how there are different numbers of paragraphs of text, different types of data (lists, anchors, etc.), then consider how ridiculous it would be to use DOM scripting there. Euuuuccch. So, I’m not-quite standard but perfectly comfortable about that. I am, however, using HTML 4.01 as the doctype. There is no reason to use XHTML, and I’m not happy to use XHTML and not serve it properly. And, if I serve it properly, it’s too likely to break (parsers spit the dummy when encountering bad XHTML, because tolerance is zero) for a production site. Further, obviously, innerHTML doesn’t work when documents aren’t served/parsed as anything other than text/html.

I’d rather do absolutely awesome HTML 4.01 than valid but mediocre (and ultimately pointless, seeing as it’s not being parsed as XML even) XHTML.

In other nifty technology-related stuff, Yahoo!7’s partnership means (hopefully) that Seven will up the ante in terms of what technologies they’re unfurling. For us, this means taking a step forward and providing syndication services (both Atom and RSS formats) for the deals. For Seven as a whole? Well, maybe they’ll start to get rid of their once-ubiquitous table-based layouts, and (maybe) embrace more of an open broadcasting paradigm in line with their web strategy — assuming Yahoo! are directing that in any way, and/or that Seven’s online team have open minds — I don’t really know and haven’t personally dealt with anyone there, so I’ll just assume they must have a handful of cluey people on board!

The RSS and Atom feeds won’t be available if you’re checking it out on Monday, but it’ll likely be running by the end of the week. For Yahoo! users, this means they can add Sunrise Family Deals to their personalised page (but, seriously, who uses portals? I never understood that whole thing). For everyone else, you should be able to download a feed reader and add the feeds. I’d love to have a page telling people how to do this on the site, but imagine Yahoo! would object. So I’m saying it here: the people that matter know how to do it! (Though, I imagine, the “people that matter” — you, dear reader — aren’t particularly regular Sunrise viewers. Or, like me, never Sunrise viewers. Heh.)

We’ve also implemented a spot of JavaScript to fix text-selection in Internet Explorer. My layout is pretty insane in terms of the sheer quantity of absolutely positioned elements, which broke that functionality in Internet Explorer. One quick question to the WSG mailing list later, someone had provided a JavaScript fix (which we had to edit a little bit to make work properly, because we had problems with flickering elements even with cache enabled).

The eye-candy

I’ve implemented useless (but rather cool) eye-candy on the Deals page in the Details pane whenever a new deal is selected. A variation of the Fade Anything Technique, which is only meant to be pretty. No originality is claimed, we’ve had this technology all millennium.

Accessibility

Disable JavaScript and you lose the fades, and use a little more bandwidth as the entire page reloads for every item you click. In terms of non-visual user agents with JavaScript disabled, I’ve put the “Details” above the list of offers in source-order, and on every reload they only hear “Sunrise Family. Link: Skip to main content” (presuming they select the link) before getting to the actual details, so I’m fairly happy on that front.

Additionally, I’ve got the “header” from Yahoo!7 last in source-order, so anyone with assistive technologies don’t have to skip over that EVERY TIME they change the page. It was a little painful to figure out, not in the least because Yahoo’s supplied universal header isn’t at all nice for sites that are built properly — i.e. with web standards and accessibility in mind — but I much prefer it this way. This is also something we had to achieve silently and without complaining, because, whilst anyone who has a clue about web accessibility will immediately see this is a good idea, marketing people would conceivably think: “But we want people to see our search bar more often!”. Er, no, you don’t achieve anything by pissing off users. No matter, we pulled it off without making any noise about it!

We’re server-side sniffing for Firefox and handing it an “Add Yahoo!7 to the Firefox Search Box” link (which, incidentally, has particularly horrid inline JavaScript — but I don’t care because the only UA it’s being served to can do something useful with it), whilst IE users get a “Make this my homepage” link in its place. Yahoo’s version (which you can see on Seven’s — pure Flash, *obligatory shudder* — Australian Open website, though I think that version (of the header, not the website) might now be deprecated) uses JavaScript for that, but it was fairly obtrusive and, seeing as we have the ability to do that server-side, I’d much rather reduce page weight.

In terms of accessibility generally speaking, I’ve bundled in all the usual goodies such as a skip to main content link, as well as skip to login on the front page, base font size of 100.01%, and relative font sizing throughout… but extensive image replacement techniques mean that the headers are probably sub-optimal in terms of visibility. This one is out of my control, and everyone else in the workplace seems to love small text (even Lyn, who seems to often put on glasses to read things on a screen… go figure!) so I wasn’t going to fight too hard about it. All other text will scale pretty well, with the exception of the deals — because the layout is so tight, it’s only really possible to go up one, maybe two size steps in most browsers.

We’re lacking any explicit accessibility statement, and we’re also lacking access keys. Mostly because I’m convinced access keys are practically useless, and rarely bother to implement them. (On forms, there are never enough buttons for access keys and/or there’s no logical combination available, and everywhere else it sort of seems a bit pointless unless everything has an access key. Where do you draw the line?)

This site is interesting to me because, even though it’s a television audience, I still can’t make assumptions about how people will be browsing. PDA devices, for example, would struggle with our built-for-1024 layout had we done it with tables. For this site, PDA/mobile users are realistic: for example, if someone incidentally is near a Wendy’s store and remembers they might’ve seen something on the Sunrise website but can’t remember the details, they can quickly and painlessly look it up.

Further, the site also has to cater for people with cognitive or motor disabilities. For cognitive disabilities, one thing in our favour is that we’ve provided a short summary of each deal before a more heavy-duty fulltext item. For users with motor disabilities, the entire website should be accessible via tabbing — including the JavaScript-enabled Deals page.

I lost an argument regarding target=“_blank”, but will eventually win this point. A handful of advertisements — including those for intra-network links, such as for the Seven Store — open in new windows, which I am most certainly not a fan of. All external links, however, should have the rel attribute set to external. There is unfortunately no visual cue associated with this. Links I count as my biggest area of defeat in this website, which is pretty good (as in, I’d rather it just be that than something more significant such as iframe usage, enormous usability problem though new windows may present).

Inline JavaScript is completely unrelated to accessibility in light of the way this has been implemented. Admittedly, it would be advantageous to use event handlers in place of inline JavaScript (and we will be thinking that to ourselves as we look at the traffic statistics), but from an accessibility perspective it has very little impact. Standard HREF’s are defined, and caught with Javascript using return false; No functionality is lost. I much prefer this method to scattering iframes throughout the site! At any rate, I’m still trying to resolve this one, accessibility related or not. It’s a matter of personal pride, I suppose.

The Styles and Bugs

The entire design (done in-house by Dacien) is awesome (in my opinion — if I didn’t think it was, I just would have kept quiet about it), but very tight.

So tight, in fact, that I had to set outline:0; on some links to stop Firefox from breaking the layout (1 pixel difference) when a link was active (as they are when you click a deal and it’s caught by JavaScript rather than actually reloading the page — the link remains active), adding a 1 pixel dotted border. Cross browser support is pretty awesome — it should be good in IE back to 5 — Opera, Safari, Konqueror, and even (mostly) IE 5.2 Mac are happy. Firefox deserves special mention: it has so many little (big for this site) things wrong with it that it’s often rather painful to make work properly. In fact, of all browsers mentioned, Firefox 1.0.x (on non-Windows platforms) is the only one whose behaviour I’m definitely not happy with (mostly because I expect better from it, but also because it gets some things horribly wrong).

Such as, for example, the “Meet the Family” page. It works perfectly or near-perfectly in every other browser, but certain Firefox variants on certain platforms render only the first two items in the “Sunrise Team” list(/right column, if you’ll excuse my presentational-speak) on first load… and then renders perfectly if you refresh the page. This is what I meant by my “predictable inadequacy” post of a few days ago. I’m fairly certain it’s something to do with floated list items, but possibly not.

Another bug is (also in Firefox — noticing a trend, anyone? No, I didn’t build for IE. I wrote about 90% of the stylesheet sitting in Firefox 1.5.x using Chris Pederick’s Web Dev extension, and both that browser and Opera operate near-perfectly) Firefox 1.0.x’s penchant for adding scrollbars where they’re not required with overflow:auto (see front page on non-Windows platforms, and the Deals page — lots of style overlap/common classes there, so this is to be expected).

By far the most interesting rendering difference I encountered building a layout this tight was between Internet Explorer/Windows XP with and without Windows Themes enabled. Yes, it does make a difference. Interface widgets shouldn’t really interfere with styles at all, IMO, but they did here. The solution basically entailed shaving off a couple of pixels where required, so I didn’t come up with something particularly innovative for it!

Summary

In all, I’m pretty happy with the site. Seven’s internal Online team apparently noticed/complimented our team on the absence of layout tables, which I (perhaps arrogantly) take with some degree of indifference: people shouldn’t be building sites with tables for that purpose anyway. If we are to be complemented, then it should be on the design (and, as part of that, achieving a design this ‘tight’ with CSS), or on the usability benefits realised by intelligent integration of AJAX, or the development pace (again, partially because of the flexibility CSS gives us), or maybe on lightweight, semantic code as a cost-saving mechanism.

Truth be told, I now believe we may have even gone a little overboard with the tables elimination. If I could do it all again, the Deals page would feature a table instead of a list, and I’d use DOM scripting to insert/delete records rather than replace the “state” part with innerHTML. The markup might gain a (very) little bit of weight, but it’d be worth it. It would, of course, remain semantically sensible and completely accessible. It’d probably be more semantically sensible, actually. I realised a table would work great about two days after I’d finished styling the list, and thought “I’ve put way too much effort into this to pull it now”, but felt like Dave Shea must have after building a “pseudo table” without realising. At least it wasn’t that complex!

Anyway, I’m really interested to hear what people have to say about the site. We’re being plugged every half hour on Sunrise tomorrow morning from 6am, and will be anxiously watching the server to see what, exactly, the effect of promotion on a show with 4 million viewers daily has on bandwidth, etc. I’ve also installed an AWstats tracker to collect aggregate data (as on this site) which we’ll parse later on (assuming the horrible monster that it’s running on, Zeus, outputs normal-ish log files for me! Oh, and it doesn’t support mod_rewrite, but instead has some retarded alternative that seems like a cross between VBA and AppleScript — and fails as much as the latter did in terms of actual ease of use, despite trying to use human language. It’s very dumb.) to figure out how Australia is doing in terms of browsers, operating systems, screen resolutions, JavaScript support, and the like. Should be incredibly interesting stuff, and I can’t wait!

At first it was thought this was just because of a dud character in a file, but then we tried using PHP to echo \n\r, \n, and \r in the place of a manually entered return: all of which resulted in the bug persisting. The only fix I’ve got is to use an HTML comment between lines

</element><!--
--><another element='element'>

Like that. Anything else, and we get a blanking character in there. Bizarre!

It doesn’t occur anywhere else on the site in question, and I’m not going to waste hours trying to build another un-branded test case which may or may not work! The problem affects IE only (though we didn’t do version testing), and only when traffic is going through (some) proxy servers. And only that one character.

It’s not an encoding problem per-se, though is obviously related to that in some sense. This is still internal-only, and it’s not being dished up with proper content-types defined in HTTP headers (because I’m still liable to change my mind as to how that should be done, and I’m not calling it until the site is about to launch/what is/isn’t required in terms of content-type–affected things is abundantly clear!), but seeing as it only has an impact when using through a proxy it’s pretty obvious it’s not JUST here. Shrug. I reluctantly deleted the linebreak and the box went away.

Such pages, however, tended toward dullness and infrequent updating.

Or, to put it another way: Such pages tended to fulfill the original vision of the Web, which was to allow absolutely anyone to publish information that might otherwise be lost to the public, in a way that allows it to be searched, indexed, bookmarked, and linked to related information. And accessed by absolutely anybody who’s looking for it.

As opposed to today’s “dynamic” Web, where you need a broadband connection, an industrial-grade graphics workstation, and more plug-ins than a Roman orgy just to look up the atomic weight of molybdenum. Which you can’t bookmark because the URL is a dynamically-generated conglomeration of the hostname, your session ID, the phase of the moon, and the bra size of the webmaster’s current girlfriend, that doesn’t point to a page that’s actually stored on disk somewhere.

As nifty as it is that people have found new ways to make use of HTTP and HTML, we seem to be slowly losing the very concept of “publishing” as “preserving a record of today for future recall”. Instead of being the equivalent of an “address” where one can “go” to retrieve information, the URL has become a “magic incantation” that instructs a distant server to perform some action that may or may not produce the same results as the last time it was used.

In some ways, that’s good: it’s nice to be able to use the same mechanism to say “Bring up the latest edition of Dan’s blog”, “Show me the current pressure and temperature readings of Injection Molder #7″, and “Display page 7 from our company’s 2003 annual report”.

But there’s some very scary Orwellian potential here, as well as the risk of exacerbating the Digital Divide by constantly ramping up the minimal platform needed to access much of the web. Those librarians Dan mentioned lately shouldn’t be the only ones worried about making sure that a large percentage of online content remains “dull” and “static”.

I think the “Orwellian potential” bit is a load of scare-mongering crap (in relation to the other concerns posed in the article, at any rate), but everything else rings true.

I am, at present, working on the first large-scale project I’ve been involved in where <a href=“http://en.wikipedia.org/wiki/AJAX/ title=“Asynchronous JavaScript and XML”>AJAX is being utilised. In this instance, yes, it was my call: yes, I do feel it’s justified (reasons include traffic, and the advantage of not having to reload an entire page — yes, it’s large scale enough for that to be significant — and simple usability, because the architecture is such that users will desire to move quickly between elements of content, and AJAX facilitates that. More details post-release). We’ve been very careful to preserve functionality in non-XMLHttpRequest enabled UA environments, but it’s still not perfect — bookmarking is one (minor, given the nature of the content) problem that still requires rectification: that’s one thing I’m hoping to resolve tomorrow (along with general CSS compatability back to IE 5, possibly 4 — but that’s not particularly relevant). The Javascript is not particularly “unobtrusive” (still using inline onclick), which I’m hoping to similarly resolve prior to launch, but it’s not of any particularly great consequence.

This is not a site to be archived, as the author of the comment above laments. But he shouldn’t. That wasn’t ever this site’s purpose, so I’m not particularly concerned if the markup isn’t prestine. Yes, there will be RSS/Atom syndication. It’s a fairly Web 2.0 buzzword-compliant site, though (I hope) not particularly unneccessarily adoptive of such technologies. We’ll see.

On a small-ish site, even a minor change becomes hellish — someone asked me to change the font size down a bit, which of course involved going to TOO MANY BLOODY LAYERS and manually adjusting the font size. And don’t even ask about form controls… Mocking that up involves layers, placement… but none of it synced to the font size. So when I change the font size, the forms of course are all out of position.

CSS… I change two digits and the entire site changes along with them. Magic.

p.s. Oh, yeah, and how the hell do you markup a TABLE in Photoshop? Dumb dumb dumb!

At any rate, good luck to anyone who feels like trying to memorise any substantialish chunk of this by tomorrow…

Without further ado, quotes in PDF format. (53.1KB)

If you want fulltext, Project Gutenberg has a nice HTML version (better than plain text because it’s not scattered with stupid linebreaks).

Clearing this up right now: it’s not, either in HTML 4 or XHTML (which retains much of the semantics of HTML 4, except where explicitly contradicted — “The semantics of the elements and their attributes are defined in the W3C Recommendation for HTML 4. These semantics provide the foundation for future extensibility of XHTML.”). Section 3 of the HTML specification states:

By default, SGML requires that all attribute values be delimited using either double quotation marks (ASCII decimal 34) or single quotation marks (ASCII decimal 39). Single quote marks can be included within the attribute value when the value is delimited by double quote marks, and vice versa. Authors may also use numeric character references to represent double quotes (&#34;) and single quotes (&#39;). For double quotes authors can also use the character entity reference &quot;.

Ben didn’t quite get the “Single quote marks can be included within the attribute value when the value is delimited by double quote marks, and vice versa.” bit, so here’s a quick example of both:

<img alt="If you can see this, the image isn't working" />
<img alt='You can probably see this because the "src" attribute is not defined' />

Both are valid and should work fine (with the exception of the lack of src, obviously). Feel free to use single or double quote marks, safe in the knowledge neither is better than the other.

Nevertheless, impressive considering the limitations of the medium. I used it to download Breezy from iiNet’s FTP (because ISP.net.au still doesn’t have the ISOs), and averaged about 750KB/s — which is about a third again of what I was getting from ISP.net.au, so I think I’ll change the sources.list to that. It’s a shame Telstra’s files.bigpond.com is so useless/HTTP-only/slow to respond to new releases, because I’d love — and I’m sure they’d save some bandwidth/peering expenditure — to be able to get quota-free downloads of this stuff. I probably could have got Breezy from there, albeit via HTTP, albeit in a few days time whenever they get stuff up there (haven’t checked, might be there already, but generally they’re pretty sluggish), but it’s just so much easier this way.

Anyway, I’ve burnt it to CD now (no, Elinks doesn’t do that too) and will hopefully be up and running again soon.

Posted from Elinks