Whether you are a fan of the Mac OS or Windows, there is no denying that Apple know what they are doing when it comes to user experience design. There is a lot that can be learnt from them whether you are developing a piece of software or even a website.

This week I have come across two sites which perfectly demonstrates just how deep Apple’s knowledge of UI design goes. The first is Finer Things in Mac, which is a site dedicated to highlighting the small details in the mac OS UI which makes it shine. Examples include:

• The naming of buttons so they are more descriptive than “Okay” or “Cancel”
• The way Time machine changes the clock in the menu bar as you go back in time
• The accuracy of progress bars when compared to windows

The second area that demonstrates Apple’s expertise is in how they have chosen to tackle accessibility on the iPhone 3.1 interface. It is hard to imagine that a touchscreen device with only one physical button could ever be accessible to blind users. However, it would appear they have made it happen.

Marco, a totally blind user who works with Mozilla wrote in his post My first experience using an accessible touch screen device:

I must say this was an amazing experience! My fingers definitely need to get used to gestures such as flicking or tapping, or using a rotor. But having an iPod Nano 4th generation helped with that, since moving the finger over the screen like on a dialer felt most like tracking around the iPod’s click wheel. Even the sound the rotor makes is the same.

This amazing result is made possible by Apple’s VoiceOver technology which is extremely hard to describe. However Apple do provide a video that demonstrates the technology in action and I highly recommend you watch it.

Do you need cake if the icing is amazing?

On last week’s show I talked about 3 Ways to Stand Out From the Crowd. One of the things I mentioned as part of that post was Paul Annett’s talk at SXSW called Oh… that’s clever. In this talk he looked at ways to add design delights that excite and amuse users.

Although I am a massive fan of this approach, it can be taken too far. A Sitepoint article entitled: Do You Need Cake if the Icing is Amazing? looks at one example of where this happened.

The article is about the HEMA website where as the author describes it:

The site renders as what appears to be a garden-variety, IKEA-like online store: navigation tabs along the top and popular products displayed in a grid. Yawn. yawn.

That’s when reality seems to break, and strange and wonderful stuff start to happen.

It all begins when a plastic cup tumbles over, bumps the sticky tape, and a domino effect is set in motion. The tape then crashes onto the stapler before squishing the cake, noisily sliding down the xylophone, and knocking over the fluorescent pens like skittles.

This chain of slapstick events continues, drawing ironing boards, blenders, yo-yos, coat hangers, and kettles into the growing maelstrom before eventually breaking out into parts of the site navigation and text.

By the time this sequence of events has all played out, the tabs are torn and frayed, the navigation text has collapsed into a puddle, and confetti flutters about from above. Very, very cute.

The post is an interesting analysis of the pros and cons of this kind of approach. It concludes by saying:

But as sublimely clever as the animation is, I have to wonder if this project, and the buzz it created, has translated into anything particularly useful for the HEMA business.

What’s more, I wonder how many users have ended up feeling disappointed, frustrated, or confused by being unable to find some of the “bread and butter” basics like locating a store, giving feedback, or asking a question.

I have to say I agree. Although adding design delights and easter eggs is nice, it is easy to overstep the line and end up damaging usability and accessibility.

GIT: Your new best friend

If you develop websites as part of a team you probably use a version control system. We do at Headscape and it seems to be common practice. At the most basic level a version control system allows you to manage files, prevent overwriting by multiple contributors and allow rollback to previous versions of an entire site or a particular file.

The dominant player in this market is Subversion but there is a new kid on the block which seems to be getting a lot of press.

Git is a free & open source, distributed version control system designed to handle everything from small to very large projects. Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.

This distributed approach has a number of obvious benefits, but it would appear this is just the tip of the iceberg. Think Vitamin has published a post entitled “Why You Should Switch from Subversion to Git” which explains the advantages of Git in full.

There is also a detailed introduction to Git on Sitepoint entitled “Git: Your New Best Friend“.

I freely confess that I know nothing about version control systems (that is Dave and Craig’s areas of expertise). However, I have seen a lot of love for Git online and if you are a developer this is almost certainly worth checking out.

Project management and simplicity

Building and running a successful website is about a lot more than having a great design team. It is also about having a visionary website owner who can think creatively and manage projects successfully.

However, being able to manage projects and have time to think creatively about your site can be a challenging combination. Life is simply too hectic.

Fortunately there are two posts this week that might go someway to inspiring and organising you better.

The first is “How Simplicity Can Help Creativity“. It looks at how simple changes to your routine can help grow your creativity. It contains good solid advice, although admittedly some of the suggestions are primarily aimed at writers.

The second is a Smashing Magazine article entitled “How to Find Time For Everything!” This is essentially a productivity post. However, it is particularly aimed at web workers. It covers everything from your working environment to prioritising and planning.

Both posts are worth a read if you find yourself constantly caught up in the day to day running of your website and never get the opportunity to think more strategically.

Back to top

Paul: So we are doing our first interview of the day at dConstruct, and joining us, of course, is Jeremy Keith – hello Jeremy.

Jeremy: Hello.

Marcus: Such a happy hello.

Paul: It is, he’s a happy, jolly person; well known for his jolliness.

Jeremy: It’s true.

Paul: So, HTML 5.

Jeremy: Yes.

Paul: There has been so much talk about HTML 5 recently, we thought, as we’re going to be seeing you, as we’re going to be at dConstruct, we ought to grab you and talk about the subject of HTML 5. Now, I haven’t thought through in a huge amount of depth want I want to cover…

Marcus: Surely Jeremy in cartoon form is want you want to cover?

Paul: Yes, that’s a really good point.

Jeremy: I was really shocked you haven’t prepared.

Paul: Yeah, but actually I managed to watch the cartoon, or read the cartoon.

Jeremy: So that was about you’re level.

Paul: That was about my level, yeah, I felt happy there. So maybe just run through this fundamental issue that XHTML 2 has gone away; HTML 5 seems to be the new thing that all the cool kids like, so what’s going on there?

Jeremy: Okay, well first of all HTML 5 has been around for quite a while; they’ve been working on this, so nothing has particularly changed. Well, Google had their IO Summit thing a few months back, and they came out and said, “We totally support HTML 5, and we think it’s the future”, and suddenly a lot of people got very interested in HTML 5 who hadn’t been paying attention, which is a bit weird. It’s like it’s been going on for ages, but as soon as Google says it’s interesting then people are interested. So that was one thing that kind of sparked a bit of interest in HTML 5 which is kind of good to see. But then the whole XHTML 2 thing was just really bizarre because I hadn’t realised the misconceptions that a lot of plain old working web developers were under about the format. Basically, XHTML 2 has been dead for years, and I thought everyone understood this.

Paul: No.

Jeremy: Okay, so HTML 4.01 was finalised around 2001, and after that W3C said okay, HTML is done, and we think the future is XML based… all these various XML based technologies, and amongst that is XHTML. Now, we all rated XHTML 1, but all that was, was just HTML 4, really. I mean all it is, is just an XML version of HTML. Nothing new was added, it’s all the same elements; everything works pretty much the same. So, really, XHTML 1 is just HTML, and most people used it that way, they would serve it as HTML. This upset a lot of people who thought, “Oh no, you’re serving XML as HTML and that’s bad,” but most of us didn’t care, you know. Browsers rendered it, we were able to validate against it, and that was good. I mean that’s why I use XHTML 1. I serve it as text/html, I don’t care that browsers then treat it as HTML, I get the validator telling me if I forget to close a paragraph, or if I forget to quote an attribute; that’s useful to me as a web developer. But it’s not a completely different format to HTML, it’s just HTML redefined as XML.

XHTML 2 is what the W3C started working on after HTML 4 was finished. XHTML 2 was going to be a complete break; an utterly new format. I mean things like you wouldn’t have an image element, you would have ‘object’ to cover any kind of thing you would put on a page. All sorts of things that really, theoretically, were wonderfully pure and abstract, but practically, just no way anybody’s ever going to use this, because it wasn’t backwards compatible with all the content on the web today.

So there was this kind of split in this W3C around 2004. There was this one particular meeting where the W3C really put their foot down and said, “The future is XML and particularly, XHTML 2. We know it’s not backwards compatible, we don’t care, we’re going to plough forward with this.” And some people in the W3C said “That’s it, we can’t deal with this”, and split off into this separate splinter group (this was Opera and Mozilla at this point), and they called themselves the ‘WHAT Working Group’. Web Hypertext Application something… I don’t know. It’s clearly a ‘back-ronym’ right? They came up with the word ‘what’ and figured out words to go around it.

So, they start work on this thing which they call HTML 5. That’s kind of this buzzword umbrella term to cover one, the next version of the mark-up language we know as HTML, two, XForms which is a good thing that the W3C have been working on to make life better for web developers, but mostly this idea of what they were calling web applications one, which was the idea that we’re moving from documents to web apps, and that’s what real people working on the web really need; fill in the gaps in HTML… We’re working with HTML now to kind of force things to act like applications, we don’t have native things to build applications like, let’s be able to make applications natively so that we don’t have to rely on a plug-in like Flash, or Silverlight, or any of these other non-open technologies.

So that started in 2004. Meanwhile XHTML 2 is being developed at the W3C in the ivory tower where no-one is actually going to use it, and in 2006 Tim Berners Lee wrote a blog post and said, “Yeah we were wrong, we were wrong.”

Paul: Good for him.

Jeremy: Yeah he said, “Actually HTML is still good and is actually the future on the web,” and restarted a charter for the HTML working group. So in 2007, the W3C start work on HTML 5, as in the sequel to HTML 4.

Paul: Corr, this is complicated!

Jeremy: Working with the W… what, working with the WHAT working group?

Marcus: I need a coffee.

Jeremy: I know, I know.

So basically now you’ve got two groups working on this one spec. You’ve got the WHATWG which has a very open process, you’ve got the W3C which is generally more closed, although the HTML working group is more open than most W3C things. A lot of things with W3C happen behind closed doors. Actually with the HTML working group now, anybody can join; it’s a little bit convoluted how you join, but anybody can join.

Meanwhile XHTML 2 was still being developed, you know, down in the cellar they’re working on XHTML 2. But everyone knew, or I assume everyone knew, that it was like this kind of joke really – it wasn’t really intended for working web authors to use on the public web. So earlier this year, finally, 2009, W3C announced, “Oh buy the way, we’re not renewing the charter for XHTML 2″, and most of them went, yeah, no surprise there – really it’s been dead for years.

But a lot of people got really confused, “Oh no I have to change from XHTML to HTML now; I have to change all my mark-up back.” No, if you’re writing XHTML 1, that is basically HTML anyway, and HTML 4 and XHTML 1, those doctypes aren’t going anywhere, your documents are still perfectly good, you don’t have to change anything; everything’s absolutely fine. And what also happened was that some of these people, who were sort of traditionally, as I said, hated it when people like me would serve XHTML 1 as HTML, “Oh no the browser’s treated it as HTML”… They started gloating and saying, “Ah, this is great, this proves that the problem is XML and XHTML in particular, and everyone who ever used XHTML was a fool”, more or less… which really bugged, because like I said, Gareth Rushgrove write a great blog post about this. The reason I use XHTML is to make the validator more powerful, it catches those little things. Basically, it’s like a best practices coding style. So in the same way you’ve got things like JSLint that catches JavaScript coding practices, even if your JavaScript is perfectly valid and will execute, this thing will catch little things which aren’t best practices. That’s what I use the validator for when I write XHTML – it catches little things that wouldn’t be caught if I was writing HTML. So even though I think that’s the reason most developers use XHTML, these people who really looked down on XHTML from the start were like, “Hah-hah, we won!” and were gloating now, and that kicked off a whole shit storm. I’m sorry I shouldn’t say that!

Paul: That’s okay.

Marcus: You can say what you like!

Jeremy: Yeah, so that needed clearing up and a bunch of us were like, “Okay, this is the story and this is what it’s like with XHMTL 2. I know it sounds like XHTML 1, but actually they’re different as chalk and cheese.” I wrote a blog post, and that was okay, and this guy Brad turned it into a comic, and then everyone read it. Then they were, “Oh now I get it – cartoon Jeremy says it’s like cheese, so now I understand it.” No seriously, it did make a big difference, it was more accessible…

Marcus: You must have been happy with ham and hamster…

Jeremy: That I did like; that got quoted on Twitter a lot.

Marcus: Fantastic.

Paul: So this leaves you writing what now? Are you still writing XHTML?

Jeremy: Let’s take sites I’ve built already, so my own personal site, adactio.com, that’s XHTML 1, it has been since 2001, I’m not going to change that. Actually I’ve made a vow not to change my mark-up anyway. Because I kind of assume when people redesign their sites, they change their CSS and they change their mark-up, and I think…

Paul: That kind of destroys the whole point of it, yeah.

Jeremy: So whenever I do a redesign, what I actually do is I add sort of a skin on top. So I’ve got a bunch of skins to my site, I kind of made a vow to myself that even if I’m doing a redesign and think it’ll be really useful to change the mark-up here, but that’s just me personally. Actually at work, and on other projects, I do now use HTML 5.

Paul: Right. Now how does that work, because everybody says, “Well, HTML 5 isn’t supported.”

Jeremy: It’s not ready yet.

Paul: No, exactly.

Jeremy: 2022…

Paul: Yeah, yeah – all of that kind of stuff.

Jeremy: Here’s the thing. If you want to write HTML 5, you take whatever doctype you’re using today, XHTML 1, HTML 4, HTML 3.2, and you change that doctype to ‘doctype HTML’, and there you go you’re writing HTML 5.

Paul: Okay!

Jeremy: So most of HTML 5 is HTML 4. The vast, vast majority of it is exactly the same language, and yet even that is really, really ambitious because one of the things they’re doing is they’re going to define error handling for HTML. Every version of HTML before this, 3.2, 4… All of these previous version, they just defined here’s what authors can do, you’ve got this element, you’ve got that element, boom – the end.

They never defined what happens when you do something wrong, or what a browser should do when it encounters mis-nested tags, things like that. So the browsers have had to kind of invent it, and what happens is that most browsers… Talk to a browser maker and they spend fifty percent of their time figuring out how does Internet Explorer handle this error, and recreating that. A huge amount of time is wasted on this. Or, whatever the leading browser maker is today, how does that browser handle errors? We need to copy that and reverse engineer it. The spec doesn’t tell them how to handle errors. So HTML 5, one of the ambitions is to take HTML 4 and define error handling for everything in it. That alone is massive; massively ambitious. And that alone would take a long time.

In addition, there’s new stuff. So you’ve got this web form stuff, you’ve got new types of inputs, user agents will be able to give us, you know, calendars and sliders and all this stuff, really cool. You’ve got some new structural elements, you’ve got some new rich media stuff like audio and video, you’ve got canvas… So that’s on top of the error handling. So, yes HTML 5 has a lot of new stuff that, frankly, you can’t use today, although a lot of it’s quite well supported, obviously not Internet Explorer, but in a lot browsers, you can use stuff like audio and video, and canvas and stuff like that.

You can’t use all of HTML 5 today, that’s true. But we probably don’t use all of HTML 4 today. For example, if you say, “I’m not going to use a mark-up spec if all of it isn’t implemented in the major browser vendor,” which would be like Internet Explorer, you say, “I’m not going to use a mark-up spec unless Internet Explorer fully implements it.” And yet you would have been using HTML 4 for years. Now, Internet Explorer didn’t fully implement HTML 4 until Internet Explorer 8 when they added support for the abbreviation element.

Paul: Right, okay.

Jeremy: Internet Explorer 7, Internet Explorer 6, Internet Explorer 5, didn’t support HTML 4, if you define support as every single thing in the spec. And you’ve been using CSS 2.1 for years. There isn’t a browser out there… Actually Internet Explorer is the first browser to fully support CSS 2.1, although you could quibble on some stuff, and yet we’ve been using it for years. Because if, ideally, you have to wait until something is fully support until you use it, it’s kind of silly, you just support features. You decide this feature is supported enough that I can use it. Enough browsers support video or canvas that I can use it today. So when people say, “I can’t use it because it’s not ready or it’s not support,” that’s too binary; it’s too simplistic a way of looking at it, because all the technologies we use today, CSS, HTML, are partially support in different browsers – that’s just the way it is.

Paul: Let’s talk about the new structural elements that have been added in to HTML 5. So you’ve got header and footer, and these various other things. I mean obviously you can’t use those as is at the moment because the support isn’t wide enough, is that correct or incorrect?

Jeremy: Well, support’s actually pretty wide in a lot of browsers. What a lot of browsers will do… It’s not so much that they’re supporting these elements, it’s just that they allow you to use arbitrary elements. So in Firefox and Safari, I could write a tag called ‘foo’, and in my style sheets I could say ‘foo, display block, colour red’ and it would work. So if you define working, or support as that, then actually yeah in Firefox and Safari and Opera you can use these new elements today.

Internet Explorer doesn’t have that, Internet Explorer doesn’t let you use arbitrary elements, but there’s a little JavaScript hack you can use to make Internet Explorer behave. In fact we’ve been using this for years with the abbreviation element. If I wanted to use abbreviation and style it in Internet Explorer, in JavaScript I would say ‘document.createElement(‘abbr’)', and suddenly I could style it. It doesn’t make any sense, but then again whatever does with Internet Explorer. So we use the same hack to say create all these new elements.

Paul: Okay, so are you using them at the moment?

Jeremy: No. What I’m doing is, I’m trying to get my head around how these structural concepts work, but I’m not ready to make the move to new elements, and I’m not ready to do client side work that relies on JavaScript, which is what I’d be doing if I used this JavaScript hack. So what I do is, I take the concept, I take the names – header, footer, section – and I use them as my class names. So I’ll have div class equals section, div class equals header, div class equals footer, and it’s partly so I can get my head round how these things work together, and also, it allows me to basically have self documenting code in that when I’m handing it off to developers that are back end developers who are building a system, I often give templates – HTML templates. And I would usually have to write out this is how this class works, and I’d have to comment everything and say the class of ‘foobar’ is used for this kind of content. And now I can kind of say, just link to the HTML 5 spec; header is for this, footer is for that, section is for this, and okay I’m using classes not elements, but the definitions…

Paul: Are the same.

Jeremy: Are the same. So there’s benefit for me getting my head round this new stuff and sort of getting a jump up on what we’re going to be using in the future, and it’s a benefit for documentation because it’s a great big spec documenting all this stuff. So I’m using them but not really in day to day work.

Paul: Because there’s some debate, is there not, about these pre-defined elements, you know, things like footer I mean. I was reading Zeldman about, well footer isn’t what you expect it to be. So potentially, as this is still in draft, you might be using footer in what will ultimately end up being the wrong way because they might change the way footer works and then you’re going to be out of sync with things.

Jeremy: Yeah, but it’s by using these things that you get to know these problems, and flag them up and bring them to the working group. In Zeldman’s thing, he said… So Zeldman asked a bunch of us to get together with him in New York about two weeks ago, because basically we’re all working web developers, we’re all interested in HTML 5, but we’re kind of sceptical of it, so like we’d be hearing conflicting things people say, there’s a lot of rumours going round, we don’t know what to believe, let’s all get together in one room and go through the spec.

We spent two days literally just going through the spec, and figured out how it affects us. And we’re not interested in the browser features, and the DOM stuff and the APIs, we’re interested in the structural stuff; we spent most of the time talking about this and the semantic meanings of these new elements, and that’s where we came against these issues. Like, wait a minute, the content model for what they call footer is totally different from what any working web developer would call a footer. So in our element, footer, you can’t put a nav element, and you can’t use headings, you can’t use H1s or H2s. But you ask a working web developer what footer is, and they point you to Flickr, or their blog they have, you know, “Oh a footer’s where I pull in my pictures from Flickr, and I have other navigation, and stuff like that.” So instead you have a flat footer which has kind of got a bit more popular in the last few years. So there’s a clash there in the semantic meaning of footer in English for most working web developers, and the semantic meaning of footer the element, and that’s something that came out of that meeting, we realised okay, this is an issue. That’s one of the things that we flagged up.

And there’s a few things like that, that when you really sit down and look you realise hang on, these two elements sound really, really similar, why are there two of them? So there’s a section and an article… For historical reasons I can see why they’re different, but they’ve actually evolved over time now to converge and get really similar. So we found a bunch of these things as authors we realised there were issues with, and we’re bringing them to the working group, we’re flagging them up, we’re publishing them, we’re blogging about it. And I think the reason this hasn’t really come to light before, is that most of the people on the list, and in IRC and the WHAT Working Group, they’re kind of hard core developers making web apps. These are the people building Google Wave, and building these big, big apps, and they’re not really thinking so much about the semantic meaning of documents. And also, there’s the browser makers, which is good – you want browser makers involved in the spec so that you know this stuff’s going to be implemented…

Paul: Yeah, of course.

Jeremy: As Hicksy keeps saying, you know, if one browser maker says I won’t implement this feature, that feature comes out of the spec, because otherwise the spec is just fiction, and it wants to be practical. And of course, that means the spec won’t be the best possible spec it could be, but it will be the best possible spec it can be and be implemented…

Paul: …Realistically.

Jeremy: Exactly, realistically. So, there hasn’t been enough working web developers involved in the process, in my opinion. There’s a lot of programmers, a lot of browser makers, not enough just, you know, working web developers. So, recently, Zeldman made this effort, let’s all get together. I’d been researching it a lot, and so I was explaining stuff to them, they were telling me about how they felt about this stuff, there was Eric Meyer there who’s got a lot of history with working with specs, and Tantek was there and he knows about how to read these kind of specs. So together we had a really good group of people, and we were able to come to the consensus that we can all… I mean, we disagreed on some stuff, I’d like to have this feature, and I don’t care about that feature, but there was a core set of stuff we all agreed on that was in the spec: this was confusing, that needs to either change, be dropped, stuff like that, and that would be our concerns. And what I what I’ve been encouraging people to do on my blog, which has kind of turned into an HTML 5 blog…

Paul: Yeah it has, I’ve noticed this!

Jeremy: …Is to get you, the kind of people who would read my blog, to get involved in the process, to get involved in the WHAT WG, and I’ve seen it happening, it’s great. I’ve seen web developers going on the IRC channel asking really basic questions like, “I’m confused by this element, how am I supposed to use it?” And then these people who are writing the spec, having to explain in normal words how it’s supposed to work, and then realising hang on this might be a problem, if I can’t explain it well then maybe this element is going to be an issue, and things like footer are obviously a problem; it’s got to change.

Paul: I read some article which seemed very left field, which was basically saying why is the W3C actually defining things like nav, and footer, and article, and section and all the rest of it? Why can’t we make up our own tags? Which kind of almost brings you back to XML I guess.

Jeremy: Yeah, the idea of extensibility. I think it’s probably John Allsopp’s List-A-Part article you talking about.

Paul: It wasn’t actually, but yeah I was aware of that one as well.

Jeremy: So there’s basically two schools of thought. What you need to provide is a mechanism for extensibility that allows anybody to extend it, and this kind of is the W3C idea of RDF and RDFA, that potentially you could encode any data in the universe, it’s infinitely extendable, and any author can define a vocabulary. And then there’s the other school of thought which is you keep the extensibility deliberately limited, and deliberately centralised to a community, and that people have to cooperate to decide what extensibility is to be used. Now that basically comes from the micro-format school of thought, where you don’t try and encode everything in the universe. You look for what’s the most common use cases, what’s the minimum you need to allow people to encode those cases, and you quantify that. You say we’ll create an element for that because eighty percent of people are publishing it, but we’re not going to create an element for something that’s really fringe, and sort of left field.

And that’s the way the HTML 5 group have gone, it’s like we’re going to keep things scarce and controlled, and if we create a new element it’s for a really good reason; we’ve thought about it, and it’s actually going to help web developers. And if anything, I think they might have created too many, not too few, and it’s only a handful, there’s maybe like ten new elements, you know structural elements, and if anything I think so of them could go.

So there’s these two very different schools of thought, and I was reading a blog post from 2006, nothing to do with HTML 5, it was to do with this idea of namespaces in HTML, which is what you get in XML – allows namespaces to allow you to create your vocabulary, you can put anything in there. It said if namespaces had been allowed in HTML then during the browser wars in the late nineties when this browser was inventing this tag, and that browser was inventing that tag, and it was just this mess of stuff, if there was a way to infinitely extend HTML, it would have legitimised that. They would have been okay with that, and we couldn’t have complained. As it was, they had to sit down in the end and sit around the table and hash this stuff out, because we complained and said, “It’s a messed up landscape and you’ve got some browsers supporting some stuff and some browsers support another thing.”

So, because HTML is limited, you have a certain amount of interoperability, and so I’ve come around to that point of view. That actually I can see the case for extending HTML and we have some mechanisms, we have the class attribute, a fairly limited extensibility thing, and I can see why for your own personal needs you might want to extend HTML, but I do actually think there’s a benefit to having a community deciding what’s the best elements, as long as that community is listening to all concerns, and that includes authors. My concern is that the community isn’t getting enough input from working web developers, but I see that changing. So I’m actually pretty reassured.

Paul: Okay, that makes a lot more sense. There’s one other question that I want to ask before we wrap things up, which is this canvas element. There seems to be a lot of excitement about canvas, but very little descriptions about what it does and why it’s exciting that is accessible to a lot of people, and understandable by a lot of people. Can you kind of summarise the canvas?

Jeremy: The canvas is a dynamic image.

Paul: Right.

Jeremy: The image element is static, and the canvas element is dynamic over time, and it can be interactive. So basically I believe you can have interactive graphs, you can have moving things like animation, you can draw on it and define movements… So it can do a lot of stuff that say, you know, Flash 1 could do, all this basic sort of stuff, and it is very exciting that where you would have needed a plug-in, you can now write an element and write some script, and you don’t need a powerful piece of software to write this stuff, you just need a text editor and everything’s cool.

So that’s good, and it’s already implemented in a lot of browsers; Safari, Firefox – they’ve got canvas, and people have already done really exciting things. John Resic has ported the processing language into JavaScript, processing.js, that uses canvas; it’s amazing. You’ve got this ball bouncing, and lines going, and generative art; all this amazing stuff – no plug-in required, it’s all native to the browser. That’s great. So the spec that defines canvas is for interactive or dynamic images. It is not for text. The spec doesn’t ever say… in fact it will forbid you from using text. But because it can, people have started putting text in there and then dynamically…

Paul: Because doesn’t Google Wave use it?

Jeremy: Err, I’m not sure about Google Wave, I haven’t really checked that out…

Paul: Perhaps I’m getting confused…

Jeremy: But Google is certainly experimenting with canvas with some things. But there’re things like… Have you seen Bespin? It’s this Mozilla project which is basically a text editor in your browser, or a code editor in your browser, and it’s all built using canvas. It’s incredibly powerful, it’s really impressive. But, those bits of text that are in canvas are just shapes to the DOM, there is no DOM saying this is a string, this is an element, it’s just there are some vector shapes, because canvas is just vector. So any piece of assistive technology just sees a bunch of… like there’s an image here of some kind. And you can find some fallback to describe the image, this is a chart showing blah blah blah, but if you’re putting a text editor in there, there’s no way they can interact with it, it’s just impossible.

Now, you could say, “But that’s not the point,” and the spec should maybe say you don’t use it for this, but people are going to use it for that because you can. So you say, okay, then the challenge is, if people are going to use it for that, even if they should be using a different technology like SVG or Flash, if people are going to do that how do we make it accessible, and that’s where there’s a lot of work going on. There’s people at Apple working on this, James Craig, who’s a really smart guy, he’s working on this idea of a shadow DOM that’s in canvas, so there is work on that. I personally think it’s such a big issue, it’s such a big thing, it’s such a powerful thing, I think it might benefit from being split off into its own spec.

Paul: Oh, okay.

Jeremy: Which has already happened with some HTML 5 stuff. Things like storage and client-side database, there’s all this powerful stuff. A lot of that ends up being spun off into a separate spec because it’s like it’s getting too unwieldy for the mark-ups.

Paul: Yeah, yeah.

Jeremy: And I kind of have this suspicion that this might be the case with canvas, because otherwise it may hold up the rest of the spec, and we’ve seen this happen with CSS 3. There were certain parts of the modules that were really important to solve for internationalisation reasons like text modules, but because that one part of CSS 3 was hard to solve it held up all this other stuff like multiple background images and border radius, and it held the hold thing back, and I would rather see things split off and worked on separately than be part of a spec and holding it back. So we’ll see; canvas is a big, big issue.

Paul: So you wouldn’t be doing a huge amount yourself in Clear Left, doing huge amount with canvas at the moment?

Jeremy: No, but that’s not the kind of work we do, it doesn’t really require…

Paul: But then the kind of work you do is the kind of work that a lot of the people listening to this will be doing. Rather than big fancy web apps.

Jeremy: Yeah, what we tend to do is documents that have interactive elements to them rather than applications that sometimes have document-like parts, and I think most people working on the web are like that, you know documents… Some things you want to be more interactive. So there’s other things in HTML 5 I would use, but that wouldn’t be one of them.

I’ll use some of the new input types already, because the default behaviour, if you say input type equals foo, the browser doesn’t know what foo is, it will just display a text input. That’s the default fallback behaviour for every browser. So if you try one of these new things like input type equals search, well in Safari will get this nice search field the same way you get in the Google search part of Safari; you get this nice styled thing with a little ‘x’ in the corner. Every other browser just gets a text input, which is what you would have got anyway. And there’s a few things like that I use today, because there’s no harm and because there is that kind of degradation that works well. But it’s the little things I use.

Paul: So, let’s finish things by saying okay, there’s some people that have listened to this and thought, “Yeah, really cool. I want to be doing some of that kind of stuff that you’ve just mentioned.” Where do they go to learn that stuff? And don’t say the spec!

Marcus: Where do normal people go?

Jeremy: The full spec has got loads of stuff for browser makers; we don’t care about that – we’re not browser makers. Michael Smith at W3C has actually spun off… Parse the spec, take out all the stuff for browser makers, and that just leaves the stuff for authors.

Paul: See, now didn’t that… That was like today that came out wasn’t it?

Jeremy: No, no, it’s been out for a while, but I pointed Zeldman to it and he blogged about it.

Paul: Ah, that’s where I read about it. There we go.

Jeremy: Yeah, because we’ve got this basecamp going for our HTML 5 super-friends group, and err…

Paul: You’re a super-friend!

Jeremy: Yeah, with unicorns.

Paul: Okay, that’s good!

Jeremy: And Eric was saying, “We should create a version for the spec that’s just the author’s stuff without the browser stuff,” and I was like actually that exists and it’s over here and then Zeldman linked to it. If you look at Zeldman, he’s linked to it; I’ve linked to it in my blog a few times as well. So there’s that, that’s really useful for just getting the semantics. Going to the IRC channel and the chat there, there’s also sites like html5doctor.com, that’s people like Bruce Lawson, and Remi Sharp, and these people. You have a question, you write to them, they answer the question.

Paul: Brilliant.

Jeremy: They also get questions from people with genuine medical problems, because they give out good Google juice for the word ‘doctor’.

So that’s very useful for web developers who say, “How do I do this? I don’t understand this element.” Yeah, start using it. I would say you’ve basically got three options today. You can just swap out your doctype to ‘doctype html’ and stop there, and just carry on doing what you’re doing – that’s one way. You can swap out your doctype and start using the class names that are taken from these structural elements, that’s what I’m doing, that’s another way. Or you can be hardcore. Swap out your doctype and start actually using these new elements, and use this JavaScript hack for IE.

So you’ve got these three levels of how far you want to go. I mean, on your personal site you could use that third option, push the boat out and go for it. I wouldn’t really do it on a client’s site yet. So you’ve got those things, there’s a validator, html5.validator.nu, and actually the W3C validator uses that, so you can validate HTML 5 today, and that means you can use Aria roles in HTML 5, which you can’t do in HTML 4 or XHTML and validate at the same time. So that’s really, really useful having Aria and HTML together. So you can do it today, keep up with HTML 5 Doctor, hang out in the RSD channel, and if you’re up to it, join the mailing list, although there’s a lot of talk from browsers makers. It goes way over my head.

Paul: Okay, thank you so much Jeremy, that was really useful. I think that has certainly clarified a lot for me, and I’m sure for a lot of people listening too.

Jeremy: I sew clarity.

Paul: Yes, thank you for passing your wisdom on to us.

Jeremy: Any time Paul.

Paul: Okay thanks.

Thanks goes to Gareth James for transcribing this interview.

Back to top

Hey everyone, I’m Ryan Carson, founder of Carsonified.com, the makers of Think Vitamin, DropSend and the events Future of Web Apps and Future of Web Design.

We’ve both failed and succeeded in building web apps so I’m going to share a few tips that we learned the hard way. Hope you find them useful!

1. Measure marketing success. As developers and designers, we often shy away from marketing as it’s perceived as dirty. This will absolutely kill your web app. So make sure every time you place an ad, send out an email newsletter or ask someone to link to you, use the Google URL Builder and track the results as a campaign in Google Analytics.
2. Write out the signup steps for your app. Before you even begin wireframing, spend a day jotting down the rough steps that the user will go through to sign up for an account. This helps you spot potential areas for improving the user experience. Make sure to pay special attention to which form fields should be required and what kind of help text you’ll write to accompany the page.
3. Give away free-upgrade coupons. When we were running DropSend.com, we placed a simple status message at the top of every page of the app. We changed it weekly to make sure people noticed it and we also made it really noticeable with colour. We regularly offered a coupon code which allowed users to upgrade for free for the month and it worked surprisingly well. I think this is because it removes the risk of trying out the more expensive plan. I’d definitely recommend it.
4. Create content for your potential users. One of the most powerful ways to do marketing for your product is to offer valuable content to your potential customers. This is expensive and time consuming but it’s highly effective. For example, if you’re building a todo list web app, write a blog that offers a free daily productivity tip or GTD hack. Make sure to offer a weekly newsletter – they’re very effective if they’re based on good content (and not cheesy sales offers).
5. Get your hosting and deployment nailed down. The thing that will haunt you forever is poor hosting and deployment methods. I’d highly recommend that you make a 1-button deployment system that quickly deploys from a development environment to a staging environment and then to a production server. Make sure the database on the staging environment is identical to production, as this will help you spot bugs. I can’t tell you how many times we’ve had trouble because no one except the developer new how to deploy the site. It needs to be easy, bullet-proof, and reversible if things go wrong.

That’s it – hope everyone found those simple tips useful.

By the way, we’ll be discussing other important web app topics at The Future of Web Apps on Sep 30 – Oct 2nd in London. Speakers include Twitter, Facebook, Mozilla, Gary Vaynerchuk, Kevin Rose of digg, Mike Arrington of TechCrunch and more. Feel free to stop by the site at http://bit.ly/fowa-london-09

Back to top