Why designers should care about HTML5

by .

After a while on the fringes of our collective consciousness, HTML5 is finally getting the attention it deserves. The development community (as typified by the SuperFriends) has come together to debate practical elements of the spec, argue over the inclusion of controversial elements, and assess the timeframe over which we can unleash HTML5 in the wild.

However those of us more accustomed to the world of Post-Its, sketches, and .psds – the designers – haven’t been so vocal. Perhaps we’ve been distracted by the bright lights of CSS3 and those surface thrills we’ve longed for. (Rounded corners! Gradients! Transparency!) Or, alternatively, we’ve been in the thrall of @font-face and looking forward to the coming age of passable web typography.

Understandable. But it’s time designers got excited about HTML5 too.

Partly, it’s just good practice. Whatever your flavour of design – visual, web, interaction, user experience – knowing the native technology makes you better at your job. Just as composers should understand the capabilities of the orchestra’s instruments, designers need to understand the language of the web.

But there’s more to HTML5 than simply keeping our skills sharp. It could make a big difference to the way we design for the web.

Semantic elements

Information architects (and, by extension, user experience designers) should be excited by the new HTML5 elements – <nav>, <header>, <aside> and so on. While they won’t immediately revolutionise today’s web, they’re an investment for the future. Doing useful stuff with information is the central theme of IA, and therefore its practitioners should be at the forefront of the new experiences that machine-readable semantics will offer. HTML5 allows us to mark text up in a more meaningful way than a sea of <div>s, meaning we’ll soon see applications appearing at a sub-page level. We’ve started to scratch the surface – think about the Operator toolbar or customisable UIs à la iGoogle – but we’ll need detailed design thinking to work out how to bring the benefits of semantic richness to the end user.

APIs and other extensions

While it’s clear that some of the HTML5 APIs are far from perfect right now, when they’re refined they will offer us intriguing new opportunities and challenges.

Designers of location-based services should of course find the geolocation API invaluable. The contentEditable attribute gives us further power to make the web truly read/write without resorting to JavaScript and custom interfaces. New input types (eg type="search") can provide extra visual cues about input function, although of course this depends on the solutions chosen by the browser manufacturers.

Until now, it’s been easy to consider our domain as bounded by the viewport and the web server. But HTML5 is another step toward seamlessness: the merging of desktop, offline and online. For instance, the drag and drop API could see the line between online and desktop experience blur further. Local storage could allow for a web-like experience in areas of poor connectivity. This convergence is clearly a good thing, but we must also design how to expose those hidden seams at the user’s request. Users should stay in control of how their locations are published and what data is synchronised to their machine.

<video>, <audio>, <canvas>

There is of course something of a reported schism between the standards world and the Flash world. Some see the advent of these new media elements (particularly <canvas>) as heralding the death of Adobe’s poster child.

I don’t think this is either likely or desirable. Neither technology is perfect. Flash is, of course, proprietary and thus subject to the whims of a third party that stands between browser and user. <canvas> has known accessibility problems. But the two can live in harmony, if we play to their respective strengths. Some current Flash applications might be better suited to <canvas>, particularly those based around dynamic visualisation: graphs, animations, infographics. Some applications will benefit from the powerful capabilities of Flash: games, heavily interactive widgets.

This aside, there’s clearly a user experience benefit in not having to rely on an external plugin to play rich media elements, and it will be interesting to see the uptake of the <video> and <audio> elements. Although it will initially be down to browser makers to define the interface elements involved, we will need to figure out how to integrate them into everyday web experiences. The good news is that they can be styled in the same way as any other HTML element. If your visual aesthetic relies on slanted images with box shadows, it’s trivial to apply this to video too.

That said, we can’t ignore the elephant in the room: the thorny codec issue. I’m sure we’d all agree that the sooner it’s resolved, the better.

What can designers do?

Only the most patient and detail-oriented designer will relish the idea of reading the spec in full and arguing the finer points on the WHATWG list. That’s just not the way designers roll.

But as a community it’s important that we start talking about HTML5. If you’re new to HTML, now’s a great time to learn. The articles on this site and A preview of HTML5 give useful guidance on the differences between HTML5 and its predecessors. Above all, designers should get chatting with their developer friends: there can’t be many left who no longer have an opinion on this technology. How do they see their practices changing? What can we do today to prepare our sites for the advent of HTML5? How can we build on its strong points to make the web a better place?

We don’t yet know what we’ll accomplish with HTML5, but then it’s not often that the vocabulary of the web changes this deeply. However, one thing is clear: if we prepare now, we have a great chance to bring innovation to our users’ online lives.

This article was jointly published on Ineffable, Cennydd’s personal website.

16 Responses on the article “Why designers should care about HTML5”

  • […] This post was mentioned on Twitter by Rich_Clark, html5doctor. html5doctor said: Why designers should care about #html5 – http://bit.ly/3wYy4Y from guest author @cennydd […]

  • simong says:

    Great article.

    Being a web designer and developer myself, I think all designers should start focusing about the new APIs and HTML5.

    New APIs + being able to style them = more creative websites.

  • […] Read the original post: Why designers should care about HTML5 | HTML5 Doctor […]

  • Paolo says:

    Actually, every web designers should care about code and markup and, yes, HTML5 is another chance for them to take control of the whole web experience. Sadly, after all this standardistas years there is people who still think that ‘visualization’ is the only matter.

  • I applaud all of the folks who are working to make HTML5 a superior standard. That said, when I read lines such as “there can’t be many [designers] left who no longer have an opinion on [html5]” I feel like there is a good bit of disconnect between those writing the specs and those using them.

    Maybe it’s just that everyone’s opinion is “I’ll figure it out when I have to but today I have work to do”.

  • Gonzalo says:

    @simong: I think you’re a little confused about what an API is.

  • stelt says:

    you forgot SVG

  • MzGray says:

    I’m interested in learning more about HTML 5. The new features seem cool. And since I’m new to coding the timing to learn it is perfect, IMHO. One thing about this site intrigues me…

    The tagline states: “Helping you implement HTML5 today”. How can you make that assertion when this site does not validate???

  • Rich says:

    @MzGray

    Which validator are you using? The only error I’m getting is caused by the sociable plugin which is out of our control.

    In addition, as Bruce pointed out recently our use of section is incorrect and as such we’ll be updating our theme accordingly. You have to bear in mind that the spec is changing regularly and sometimes it is difficult for us to keep up (and reflect that in our markup). You also have to bear in mind that the validator isn’t always up to date because of the changing spec.

    Hope that clears things up a little.

    Rich

  • MzGray says:

    The validator I know and trust exclusively is from the W3C and it gave your site 1 error, 2 warnings. By your response I surmised there is more than one validator out there. First, I googled html validator; several of them rendered many errors that were too many to count. Then, I searched for html 5 validator. After plugging in your web address to the handful listed at the top of the search page, they gave a minimum of 1-2 errors each.

    Bottom line: I still believe passing validation with flying colors is the way to go. But in my research and reading expert opinions about the subject, I’ve found its not worth the hassle to sweat 1 or 2 validation errors. I recently found out Google uses HTML 5 and their validation rate is abysmal, IMHO. If they aren’t sweating 41 errors, and 2 warning via the W3C validator, then I guess it’s just a matter of preference. Besides they get millions of hits every day and those errors definitely has not hurt their bottom line.

    Cheers!

  • I’ve been using HTML5 (just the simple stuff, like in my last two sites. I’m liking it. And you’re right, as a designer, the bright lights of CSS3 are really what’s attractive!

    Since I’m using both, ‘validation’ is a game I play. ;-)

    I’m also using the H5 WordPress theme (unstyled, but HTML5 setup) by Chris Coyier & Jeff Starr. Lovin’ it!

  • Ryansway says:

    We keep several different machines here, pc’s and mac’s, for testing client code on different platforms and browsers to ensure code renders correctly.

    Most of our client’s are blue chip organizations with alexa ranks under 100k and PR beyond 5, so we’ve continued to make the investment in different machines so that we can absolutely guarantee our code has been tested on all browsers and platforms in use.

    The machine I’m using right now is an imac with osx 10.3.9 and FF 2.0.0.12 (not pre 1.9b5). FF can’t upgrade to FF 3 on this machine without upgrading to Tiger, which is fine because we use this machine to check code rendering in FF2.

    I just checked out html5gallery, and none of the sites rendered correctly. In fact, all the sites looked darn awful – including this site which looks completely broken. I’m surprised that some developers appear to be marching ahead with html5 while not all browsers support it, and while it’s still in development. I’m even more surprised that html5 sites aren’t detecting browsers and providing an alternative code which is tested to work in the browsers that don’t support html5, which is just as bad as ignoring the needs of IE6 and providing browser specific style sheets for tweaking rendering issues.

    We’re as excited as the next person about html5, but, we’re not going to “go there” until the standard is officially finalized and browser support doesn’t present as many issues. I believe even IE needs a chrome window for html5 video to work, and not many consumers are going to know about that. If any of the html5gallery sites had detected the browser I was using, then they certainly did nothing to address FF2’s lack of html5 support, or whatever they did do, didn’t make a difference.

    Perhaps there needs to be a greater emphasis on the importance of providing alternative code for browsers which don’t support html5? It’s frightening to see site after site looking like they were coded incorrectly by amateurs.

  • Dan says:

    If you’re a HTML author and just want to know about the available tags in HTML and when / where / how to use them, there’s a much shorter document at the W3C just for that particular purpose: http://dev.w3.org/html5/markup/

  • […] Why designers should care about H… […]

  • Leave a Reply to Dan

    Some HTML is ok

    You can use these tags:
    <a href="" title="">
    <abbr title="">
    <b>
    <blockquote cite="">
    <cite>
    <del datetime="">
    <em>
    <i>
    <q cite="">
    <strong>

    You can also use <code>, and remember to use &lt; and &gt; for brackets.