Registration opened a couple of days ago for the latest Clearleft event. UX London will be taking place from June 15th to 17th. This will be a very different event to dConstruct.
For a start, the format is based around workshops (although there will also be a day of presentations). Then there’s the timescale: UX London will last for three days. Finally, there’s the intimacy factor. Whereas the attendance for dConstruct is somewhere between 700 and 800 people, UX London will be deliberately limited to around 150.
Our motivation for putting together this event was partly to bring a kick-ass UX here in the UK for a change. But mostly we wanted to put together the kind of event that we wanted to attend. So we drew up our dream line-up and incredibly, we got everyone we wanted: Dan Saffer, Jared Spool, Jeff Veen …and Don fucking Norman (excuse my French but I find it very hard to say Don Norman will be speaking at UX London
without interjecting some indication of my excitement).
Andy has written more about the event on his blog which has, over the past week, arisen from its deep slumber.
The site itself launched right before Christmas. Natalie and I did the front-end build and I’m pretty damned pleased with how it turned out. Behold the liquidy goodness!
We used this as an opportunity to really push what Dan has been calling progressive enrichment
: sprinkling in some modern CSS declarations even if not every browser gets all of them—something that Malarkey has been banging on about for quite a while now.
So if you view the UX London site in IE6 it looks fine. Nothing special though. But if you view the site in a browser like Safari, a lot of little details shine through. The design is pretty much a test-case for the box-shadow property using RGBa. Depending on the browser width, multiple translucently shadowed elements can overlap and it’s interesting to see how browsers handle this (Safari’s additive approach seems correct to me).
On the markup side of things, we decided to write the site in HTML5. But wait! Isn’t HTML5 going to take another few decades before it’s finished?
Well, no. That little bit of bollocks was spread ‘round by people who misread the timeline, underestimating the importance of “working draft” and overestimating the importance of “proposed recommendation”. Admittedly, those are pretty confusing and unintuitive labels for it’s ready
and it’s been finished for ages and now it’s 100% supported in at least two implementations.
It turns out that when it comes to the markup, HTML5 isn’t all that different to what has come before. It’s all the DOM gubbins—which should allow a more declarative approach to building web apps—that is the real hard stuff that requires browser support in order to work. If you’re not interested in that side of things, much of the HTML5 spec won’t even be relevant to you. For your convenience, Michael Smith has put together a markup-only version of the spec.
From a semantic perspective, the most important additions to the markup language are the structural elements such as header, article, section and so on. Bruce Lawson has put together a test case to show that you can use these elements and still style them in most browsers. For pesky Internet Explorer, you can use a neat little JavaScript trick that John Resig discovered a while back. Alas, Camino still doesn’t play nice with styling the new elements. But that isn’t going to stop Bruce realigning his site to use HTML5’s new structural elements.
For the UX London site, we didn’t go quite that far. We stuck to using divs with class attributes for our structure. But we could still build on the work that has gone into the HTML5 structural elements. Rather than coming up with our own class names, we used the names proposed in the spec: article, section, aside, etc.
Now our document structure has pre-built documentation. Want to know what class="article" denotes? RTFM.
Using HTML5 elements as a basis for a naming convention isn’t a new idea. Malarkey has written about developing naming conventions from HTML5. Jon Tan also wrote about preparing for HTML5 with semantic class names. Oli Studholme put both of those articles together to create a handy little structural cheatsheet. Use microformat class names for the small stuff; use HTML5 class names for the bigger stuff.
Apart from providing easier documentation, there’s another good reason to take this approach: interoperability. Think about how much easier user styling would be if sites shared many of the same class names. Even if you don’t think that they are the best class names—I know, for instance, that Malarkey doesn’t like the presentational smell of footer—the benefits of an aggregate shared vocabulary could be very empowering. So if you do insist on creating a CSS framework that mandates using certain specific names (a concept I despise) please, please, please use those class names.
On the subject of user styling, there’s a site ID of uxlondon-com on the UX London site. Huffduffer, another HTML5 site, has an ID of huffduffer-com on every page. But rather putting these IDs on the body element, it seems more meaningful to me to add them on the html element itself.
A couple of weeks after the UX London site launched, another event site went live: the beautifully-redesigned An Event Apart. It’s also written in HTML5. Jeffrey has written about the design and Eric has written about the markup.
Huffduffer, UX London, An Event Apart and now The Watchmaker Project …there’s quite an exciting air of experimentation around using HTML5 right now. Personally, I’ve found it to be a fun way of breaking out and trying something new. I recommend giving it a whirl. Until recently you would have needed to use validator.nu to test your markup but now that’s been integrated into the W3C validator so all your old bookmarklets and tools will still work.
Even if you decide against writing in HTML5 itself, at least consider using those HTML5-inspired class names for your structural naming convention where appropriate.