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.
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
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.)
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.
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!
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.
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).
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.
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!
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!