Sunrise Family website
30 Jan 2006
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!