The site

This is the vaguely alluded to web­site of a few days ago, for Seven Network’s break­fast show (I refuse to describe any such com­mer­cial net­work dri­vel as “cur­rent affairs”!), Sun­rise. The Sun­rise Fam­ily is essen­tially an incentive/loyalty scheme vaguely akin to Triple M’s (recently-abandoned… doubt­less to be re-released in nearly exactly the same form under a dif­fer­ent brand) Freq Club and Enter­tain­ment Book–style dis­counts. 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 com­ing… I’d love to replace Sunrise’s bor­ing ROSwall form with some­thing akin to the infa­mous Flash Just Let­ters inter­ac­tive fridge thingo, though maybe in an add-only type way, which would link in to view­ers’ exist­ing Fam­ily login (i.e. so they don’t have to enter their name every time, etc.), but that’s just an idea of mine.

The tech­nol­ogy

So, the deals.

The inter­face is using AJAX, presently with inline onClick trig­gers — because, unfor­tu­nately, 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 any­one can tell me how to write an event han­dler that con­verts an ID into a string which I can then feed to an onClick han­dler (and, server-side, explode() using PHP) I’m still very keen to fix that “prop­erly”. The ID’s have two data ele­ments because the Deals inter­face is designed to add sup­port for mul­ti­ple states (i.e. localised offers, etc.) in the future. And they’re pre­fixed by d_ because, obvi­ously, valid iden­ti­fiers can’t start with a num­ber. D can stand for “deal” or “data”, whatever :-)

As for how the AJAX is pulling down data, I’m just using inner­HTML, because it works in pretty much every­thing and is lots faster and lots sim­pler than “real” DOM meth­ods, espe­cially here. Observe the “Details” pane on the right of that page, and how there are dif­fer­ent num­bers of para­graphs of text, dif­fer­ent types of data (lists, anchors, etc.), then con­sider how ridicu­lous it would be to use DOM script­ing there. Euu­u­uc­cch. So, I’m not-quite stan­dard but per­fectly com­fort­able about that. I am, how­ever, using HTML 4.01 as the doc­type. There is no rea­son to use XHTML, and I’m not happy to use XHTML and not serve it prop­erly. And, if I serve it prop­erly, it’s too likely to break (parsers spit the dummy when encoun­ter­ing bad XHTML, because tol­er­ance is zero) for a pro­duc­tion site. Fur­ther, obvi­ously, inner­HTML doesn’t work when doc­u­ments aren’t served/parsed as any­thing other than text/html.

I’d rather do absolutely awe­some HTML 4.01 than valid but mediocre (and ulti­mately point­less, see­ing as it’s not being parsed as XML even) XHTML.

In other nifty technology-related stuff, Yahoo!7’s part­ner­ship means (hope­fully) that Seven will up the ante in terms of what tech­nolo­gies they’re unfurl­ing. For us, this means tak­ing a step for­ward and pro­vid­ing syn­di­ca­tion ser­vices (both Atom and RSS for­mats) for the deals. For Seven as a whole? Well, maybe they’ll start to get rid of their once-ubiquitous table-based lay­outs, and (maybe) embrace more of an open broad­cast­ing par­a­digm in line with their web strat­egy — assum­ing Yahoo! are direct­ing that in any way, and/or that Seven’s online team have open minds — I don’t really know and haven’t per­son­ally dealt with any­one there, so I’ll just assume they must have a hand­ful of cluey peo­ple on board!

The RSS and Atom feeds won’t be avail­able if you’re check­ing it out on Mon­day, but it’ll likely be run­ning by the end of the week. For Yahoo! users, this means they can add Sun­rise Fam­ily Deals to their per­son­alised page (but, seri­ously, who uses por­tals? I never under­stood that whole thing). For every­one else, you should be able to down­load a feed reader and add the feeds. I’d love to have a page telling peo­ple how to do this on the site, but imag­ine Yahoo! would object. So I’m say­ing it here: the peo­ple that mat­ter know how to do it! (Though, I imag­ine, the “peo­ple that matter” — you, dear reader — aren’t par­tic­u­larly reg­u­lar Sun­rise view­ers. Or, like me, never Sun­rise view­ers. Heh.)

We’ve also imple­mented a spot of JavaScript to fix text-selection in Inter­net Explorer. My lay­out is pretty insane in terms of the sheer quan­tity of absolutely posi­tioned ele­ments, which broke that func­tion­al­ity in Inter­net Explorer. One quick ques­tion to the WSG mail­ing list later, some­one had pro­vided a JavaScript fix (which we had to edit a lit­tle bit to make work prop­erly, because we had prob­lems with flick­er­ing ele­ments even with cache enabled).

The eye-candy

I’ve imple­mented use­less (but rather cool) eye-candy on the Deals page in the Details pane when­ever a new deal is selected. A vari­a­tion of the Fade Any­thing Tech­nique, which is only meant to be pretty. No orig­i­nal­ity is claimed, we’ve had this tech­nol­ogy all millennium.

Acces­si­bil­ity

Dis­able JavaScript and you lose the fades, and use a lit­tle more band­width as the entire page reloads for every item you click. In terms of non-visual user agents with JavaScript dis­abled, I’ve put the “Details” above the list of offers in source-order, and on every reload they only hear “Sun­rise Fam­ily. Link: Skip to main con­tent” (pre­sum­ing they select the link) before get­ting to the actual details, so I’m fairly happy on that front.

Addi­tion­ally, I’ve got the “header” from Yahoo!7 last in source-order, so any­one with assis­tive tech­nolo­gies don’t have to skip over that EVERY TIME they change the page. It was a lit­tle painful to fig­ure out, not in the least because Yahoo’s sup­plied uni­ver­sal header isn’t at all nice for sites that are built prop­erly — i.e. with web stan­dards and acces­si­bil­ity in mind — but I much pre­fer it this way. This is also some­thing we had to achieve silently and with­out com­plain­ing, because, whilst any­one who has a clue about web acces­si­bil­ity will imme­di­ately see this is a good idea, mar­ket­ing peo­ple would con­ceiv­ably think: “But we want peo­ple to see our search bar more often!”. Er, no, you don’t achieve any­thing by piss­ing off users. No mat­ter, we pulled it off with­out mak­ing any noise about it!

We’re server-side sniff­ing for Fire­fox and hand­ing it an “Add Yahoo!7 to the Fire­fox Search Box” link (which, inci­den­tally, has par­tic­u­larly hor­rid inline JavaScript — but I don’t care because the only UA it’s being served to can do some­thing use­ful with it), whilst IE users get a “Make this my home­page” link in its place. Yahoo’s ver­sion (which you can see on Seven’s — pure Flash, *oblig­a­tory shud­der* — Aus­tralian Open web­site, though I think that ver­sion (of the header, not the web­site) might now be dep­re­cated) uses JavaScript for that, but it was fairly obtru­sive and, see­ing as we have the abil­ity to do that server-side, I’d much rather reduce page weight.

In terms of acces­si­bil­ity gen­er­ally speak­ing, I’ve bun­dled in all the usual good­ies such as a skip to main con­tent link, as well as skip to login on the front page, base font size of 100.01%, and rel­a­tive font siz­ing through­out… but exten­sive image replace­ment tech­niques mean that the head­ers are prob­a­bly sub-optimal in terms of vis­i­bil­ity. This one is out of my con­trol, and every­one else in the work­place seems to love small text (even Lyn, who seems to often put on glasses to read things on a screen… go fig­ure!) so I wasn’t going to fight too hard about it. All other text will scale pretty well, with the excep­tion of the deals — because the lay­out is so tight, it’s only really pos­si­ble to go up one, maybe two size steps in most browsers.

We’re lack­ing any explicit acces­si­bil­ity state­ment, and we’re also lack­ing access keys. Mostly because I’m con­vinced access keys are prac­ti­cally use­less, and rarely bother to imple­ment them. (On forms, there are never enough but­tons for access keys and/or there’s no log­i­cal com­bi­na­tion avail­able, and every­where else it sort of seems a bit point­less unless every­thing has an access key. Where do you draw the line?)

This site is inter­est­ing to me because, even though it’s a tele­vi­sion audi­ence, I still can’t make assump­tions about how peo­ple will be brows­ing. PDA devices, for exam­ple, would strug­gle with our built-for-1024 lay­out had we done it with tables. For this site, PDA/mobile users are real­is­tic: for exam­ple, if some­one inci­den­tally is near a Wendy’s store and remem­bers they might’ve seen some­thing on the Sun­rise web­site but can’t remem­ber the details, they can quickly and pain­lessly look it up.

Fur­ther, the site also has to cater for peo­ple with cog­ni­tive or motor dis­abil­i­ties. For cog­ni­tive dis­abil­i­ties, one thing in our favour is that we’ve pro­vided a short sum­mary of each deal before a more heavy-duty full­text item. For users with motor dis­abil­i­ties, the entire web­site should be acces­si­ble via tab­bing — includ­ing the JavaScript-enabled Deals page.

I lost an argu­ment regard­ing target=“_blank”, but will even­tu­ally win this point. A hand­ful of adver­tise­ments — includ­ing those for intra-network links, such as for the Seven Store — open in new win­dows, which I am most cer­tainly not a fan of. All exter­nal links, how­ever, should have the rel attribute set to exter­nal. There is unfor­tu­nately no visual cue asso­ci­ated with this. Links I count as my biggest area of defeat in this web­site, which is pretty good (as in, I’d rather it just be that than some­thing more sig­nif­i­cant such as iframe usage, enor­mous usabil­ity prob­lem though new win­dows may present).

Inline JavaScript is com­pletely unre­lated to acces­si­bil­ity in light of the way this has been imple­mented. Admit­tedly, it would be advan­ta­geous to use event han­dlers in place of inline JavaScript (and we will be think­ing that to our­selves as we look at the traf­fic sta­tis­tics), but from an acces­si­bil­ity per­spec­tive it has very lit­tle impact. Stan­dard HREF’s are defined, and caught with Javascript using return false; No func­tion­al­ity is lost. I much pre­fer this method to scat­ter­ing iframes through­out the site! At any rate, I’m still try­ing to resolve this one, acces­si­bil­ity related or not. It’s a mat­ter of per­sonal pride, I suppose.

The Styles and Bugs

The entire design (done in-house by Dacien) is awe­some (in my opin­ion — 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 Fire­fox from break­ing the lay­out (1 pixel dif­fer­ence) when a link was active (as they are when you click a deal and it’s caught by JavaScript rather than actu­ally reload­ing the page — the link remains active), adding a 1 pixel dot­ted bor­der. Cross browser sup­port is pretty awe­some — it should be good in IE back to 5 — Opera, Safari, Kon­queror, and even (mostly) IE 5.2 Mac are happy. Fire­fox deserves spe­cial men­tion: it has so many lit­tle (big for this site) things wrong with it that it’s often rather painful to make work prop­erly. In fact, of all browsers men­tioned, Fire­fox 1.0.x (on non-Windows plat­forms) is the only one whose behav­iour I’m def­i­nitely not happy with (mostly because I expect bet­ter from it, but also because it gets some things hor­ri­bly wrong).

Such as, for exam­ple, the “Meet the Fam­ily” page. It works per­fectly or near-perfectly in every other browser, but cer­tain Fire­fox vari­ants on cer­tain plat­forms ren­der only the first two items in the “Sun­rise Team” list(/right col­umn, if you’ll excuse my presentational-speak) on first load… and then ren­ders per­fectly if you refresh the page. This is what I meant by my “pre­dictable inad­e­quacy” post of a few days ago. I’m fairly cer­tain it’s some­thing to do with floated list items, but pos­si­bly not.

Another bug is (also in Fire­fox — notic­ing a trend, any­one? No, I didn’t build for IE. I wrote about 90% of the stylesheet sit­ting in Fire­fox 1.5.x using Chris Pederick’s Web Dev exten­sion, and both that browser and Opera oper­ate near-perfectly) Fire­fox 1.0.x’s pen­chant for adding scroll­bars where they’re not required with overflow:auto (see front page on non-Windows plat­forms, and the Deals page — lots of style overlap/common classes there, so this is to be expected).

By far the most inter­est­ing ren­der­ing dif­fer­ence I encoun­tered build­ing a lay­out this tight was between Inter­net Explorer/Windows XP with and with­out Win­dows Themes enabled. Yes, it does make a dif­fer­ence. Inter­face wid­gets shouldn’t really inter­fere with styles at all, IMO, but they did here. The solu­tion basi­cally entailed shav­ing off a cou­ple of pix­els where required, so I didn’t come up with some­thing par­tic­u­larly inno­v­a­tive for it!

Sum­mary

In all, I’m pretty happy with the site. Seven’s inter­nal Online team appar­ently noticed/complimented our team on the absence of lay­out tables, which I (per­haps arro­gantly) take with some degree of indif­fer­ence: peo­ple shouldn’t be build­ing sites with tables for that pur­pose any­way. If we are to be com­ple­mented, then it should be on the design (and, as part of that, achiev­ing a design this ‘tight’ with CSS), or on the usabil­ity ben­e­fits realised by intel­li­gent inte­gra­tion of AJAX, or the devel­op­ment pace (again, par­tially because of the flex­i­bil­ity CSS gives us), or maybe on light­weight, seman­tic code as a cost-saving mechanism.

Truth be told, I now believe we may have even gone a lit­tle over­board with the tables elim­i­na­tion. If I could do it all again, the Deals page would fea­ture a table instead of a list, and I’d use DOM script­ing to insert/delete records rather than replace the “state” part with inner­HTML. The markup might gain a (very) lit­tle bit of weight, but it’d be worth it. It would, of course, remain seman­ti­cally sen­si­ble and com­pletely acces­si­ble. It’d prob­a­bly be more seman­ti­cally sen­si­ble, actu­ally. I realised a table would work great about two days after I’d fin­ished 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 build­ing a “pseudo table” with­out real­is­ing. At least it wasn’t that complex!

Any­way, I’m really inter­ested to hear what peo­ple have to say about the site. We’re being plugged every half hour on Sun­rise tomor­row morn­ing from 6am, and will be anx­iously watch­ing the server to see what, exactly, the effect of pro­mo­tion on a show with 4 mil­lion view­ers daily has on band­width, etc. I’ve also installed an AWstats tracker to col­lect aggre­gate data (as on this site) which we’ll parse later on (assum­ing the hor­ri­ble mon­ster that it’s run­ning on, Zeus, out­puts normal-ish log files for me! Oh, and it doesn’t sup­port mod_rewrite, but instead has some retarded alter­na­tive that seems like a cross between VBA and Apple­Script — and fails as much as the lat­ter did in terms of actual ease of use, despite try­ing to use human lan­guage. It’s very dumb.) to fig­ure out how Aus­tralia is doing in terms of browsers, oper­at­ing sys­tems, screen res­o­lu­tions, JavaScript sup­port, and the like. Should be incred­i­bly inter­est­ing stuff, and I can’t wait!