James Wilding's Weblog

Go read A List Apart. This is one of the premier websites for informing, educating, and inspiring people who design and develop websites; its pages are full of articles on user science, usability, information architecture, accessibility — all things which, when done well, makes websites simpler and/or easier to use. This is a good thing.

I suspect that most people who love web standards and usability are probably geeks at heart: we like nice clean systems and we love it when things fit together in a clean, coherent whole. We don’t like mess, we don’t like complexity.

This is also a good thing.

Trouble is, we forget why we do this stuff. We forget that usability is about, you know, making things easier to use, and make it instead about following rules, evangelising, doing the “right thing”. We criticise websites which don’t properly use web standards without remembering why those standards are important — this isn’t a competition to see who can best conform to the HTML specs; it’s a chance to make sites which work better for normal people.

Yes, normal people. Because we’re not normal. In comparison to the majority of people who operate online, we are different, because we understand how the system works! If you’ve every watched your mother, or grandmother, use the web, you’ll know what I mean.

These — your mother, your grandmother, the non-techies — are the people who web standards, usability, and all those other disciplines are made to help. The most important thing is this: when used well, these disciplines should not be apparent to website users. Those users don’t care how good websites are implemented; they just care that they’re good.

Take a look at the progress of other technology: Apple’s iPhone is easy to use, intuitive, simple. Do normal users care that it’s running HTML5 with offline storage? Do they care that its browser is one of the most forward-thinking when it comes to web standards? Do they care that it uses a custom operating system? Of course not. These things are all great, but they’re great because they help make the iPhone easier to use.

When you get down to it, what is the web? It’s a way for humans to communicate. Whether you’re buying a book, booking a holiday, subscribing to a mailing list, or developing an application, the web should be made for human beings — it was created to help human communication and (unless we’re going to get all sci-fi) that’s what it will always be for.

Next time you’re knocking some poor young HTML student for using <b> instead of <strong>, or droning on about usability like everyone should give a damn, take some time to put things in perspective. Our primary aim on the web should be to help other humans; everything else is a waste of time.

I’ve been reading a lot recently about semantic markup: when to use it, why to use it, whether to use it at all. For many people, semantics in HTML is a holy cow — no matter what, the argument goes, you should never shirk your responsibility to use markup that adds meaning to your content.

This is something I broadly agree with, but: sometimes it’s OK to use ‘bad’ markup. If you’re just creating something for your own private use, or are prototyping some HTML that you’re going to flesh out later, then the semantics of what you’re writing really don’t matter. As long as you can come back later and use ‘better’ markup when it matters, it’s OK.

Note the ‘can’ in my last sentence. You need to know that you’re going to be able to replace your tag soup with something beautiful at a later date, before it matters; otherwise you’re creating a code debt that you won’t be able to replay. It’s like the difference between borrowing a little money which you can afford to pay back later, and borrowing too much.

So when does ‘bad’ code start to matter? For me, the answer to this question comes in two parts. First, bad code starts to matter when the code becomes a problem for your users — when it starts causing accessibility issues, for instance. Second, when bad code starts to create problems for you — maintenance problems for instance, or problems understanding your past intentions — then the code matters. This is when you should stop, and rewrite.

HTML is an easy language to learn, and a difficult one to master. Like Ruby, it gives you more than one way of doing things; this is both a blessing and a curse. Because HTML allows you to markup code ‘wrongly’, we should always be careful to manage our code debts and learn to respect our own limits. A little borrowing against future effort it OK; an unmanageable debt of badly written, meaningless code is not.