While visiting the Invisible City weblog, I came across an article about the conflict between design and usability involved in making web sites. The central question the article asks is whether a web page should be designed to look nice and create a mood and so forth, making it different from any other page of the same type, or whether all pages of the same type should resemble each other so that people aren’t constantly trying to re-learn how to do things.
My gut instinct is to go with the usability people, but that’s mostly because I tend to see designers as the Enemy, the people who Broke the Web. That’s not at all fair—designers like Jeffrey Zeldman helped create the Web Standards Project, after all—but there is some small element of truth to it. But before I can explain why I feel that way, and why it isn’t really fair, I’ll need to explain why the shift towards presentational markup makes more sophisticated use of the web impossible, and to explain that it’s probably a good idea to look at control and abstraction.
Control vs abstraction
When the Macintosh first shipped, it came with two graphics applications: MacPaint and MacDraw. MacPaint was a bitmap editor; you got a bunch of tools like paint brushes, pencils, erasers, and paint buckets, and you used them to draw on an initially-blank screen. What the “bitmap” part means is that your drawing consisted of a rectangular grid of pixels, and each pixel was either white or black. When you drew a line with the pencil, each pixel the pencil moved over changed from white to black. The eraser reversed this process, turning black pixels white. It’s a very simple tool to create, and it allows the user to create any arbitrary pattern of pixels, which the eye would interpret as a black and white image.
MacDraw, on the other hand, was a vector graphics editor. While MacPaint worked at the level of the pixel, MacDraw dealt with objects like lines, squares, arcs, circles, and text. Where MacPaint let you draw any arbitrary squiggle, MacDraw would make you construct it from short arc segments. It’s a much more complicated tool to create, and requires more initial effort to use.
As you’ve probably guessed, there is an advantage to MacDraw to make up for its lack of flexibility: it’s really easy to make changes. If you draw a square in MacPaint, all it does is change the pattern of pixels. If you decide to resize it, you have to erase the old one and draw a new one. If the square was drawn over a complex background, then the background needs to be recreated, because MacPaint forgot about it when you drew the square over it.
MacDraw knows that the square is a square, and gives you square-related editing tools. Furthermore, it knows what the objects behind the square are, so it can redraw them if you move the square somewhere else. The downside is that you’re limited to the shapes that MacDraw is designed to work with. MacPaint would let you write a text label and flip it vertically—easy to do, since it just involves moving pixels around—but MacDraw would not, since it doesn’t know how to draw the text upside-down while retaining its “text-ness”.
Thus, MacPaint gives you control: Anything that you can draw using a grid of pixels, you can create in MacPaint. MacDraw works at a more abstract level, squares and lines instead of pixels, which makes it easier to work with but less flexible.
Structural vs presentational markup
This distinction applies to word processing as well, at a different level. The basic unit for word processors is the character (letters, numbers, spaces, paragraph breaks, etc.), and each character can be presented with different fonts, text styles, colors, and so forth. (The codes used to identify these styles are called “markup”.) By and large, word processors work at that level, potentially letting you create documents where every character has a different font, size, or color.
This has its uses—especially for writing ransom notes—but there are advantages to working at higher levels. If our word processor lets us mark some text as section headings instead of just “18 points, bold”, then it can also do useful things with that information, like create an overview of the document or a live table of contents. (iCab, for example, has an Overview menu that takes advantage of HTML’s headings.)
Thus, we come to the question of whether web pages should be presentational (describing how to display their contents) or structural (describing what their contents mean, and leaving the presentation up to the reader’s software). The problem is that HTML, the language used to define web pages, has both structural and presentational aspects. Text can be marked as a heading, or as emphasized, but it can also be made large or italic.
There’s no question that structural markup requires more effort to start working with, requires more complicated tools to use, and doesn’t provide the flexibility of presentational markup. The advantage is that it allows you to work at a much higher level of abstraction. With web publishing in particular, it allows you to leave some presentational aspects up to the reader, which is important since you can’t predict how the user is viewing your page. Are they using a graphical computer that can see color and fonts? Are they using a text terminal that can only turn underlines on or off? Are they running the page through a text-to-speech engine?
If you’ve designed your page so that it marks the title as a level-one heading, than all three users can have it presented in a manner appropriate to their system. On the other hand, if you’ve marked the title as being large and bold, then the latter two are out of luck.
What you see is what you get
The problem is that HTML was intended as a structural language, but had
only a limited vocabulary in the beginning. Worse, there was no way to
specify the presentational aspects, so everyone’s pages looked roughly
the same. The design community hated that, so Netscape added extra
presentational elements to its browser (FONT being the big one). Web
designers, free to specify font sizes and colors arbitrarily, quickly
abandoned the structural aspects of the language. (I’m generalizing
here. Obviously, not everyone did.)
Books started coming out, describing how you could abuse tables and the height and width parameters on images to lay out pages to pixel-level accuracy. Adobe and Macromedia created software to automatically use these techniques to let you design pages in a visual environment.
The problem is that these pages only look good on graphical web browsers. Text- and audio-based browsers will at best be able to see the text with a few hints about structure (some headings, a random emphasized word). At worst, they’ll get an incomprehensible mess. (We’ll just ignore the people who achieve absolute control over layout by putting all their text in images. Welcome back to MacPaint.)
Worse yet, these pages aren’t guaranteed to look good even on graphical computers, where readers are free to use older software, disable images, or restrict the font list. Tools like Dreamweaver and GoLive are lying or deluded if they claim to create web pages that look a certain way, because there is no intrinsic “look” for a given web page. You may be seeing what you get, but there’s no guarantee that anyone else will see it the same way.
Whose fault is it?
This is turning out a lot longer than I expected, so I’m going to leave some aspects for later and skip ahead to the assignment of blame. As I said before, I tend to view the design community with suspicion, mostly because they created the most hideously-coded pages, but that’s unfair. Yes, the designers created the clamor for presentational control that derailed HTML’s path towards structural markup, but what of the browser makers that still haven’t produced a browser than can fully parse HTML or the makers of the so-called WYSIWYG HTML editors? What of the W3C, which took its sweet time coming up with a style sheet specification, thereby creating the demand for other ways to specify presentation?
I don’t think it matters. While some claim that all presentational details should be left to the reader, this is neither a desireable nor a practical solution. Ideally, usability and design would exist on different levels, and have no cause to compete. This isn’t practical on the web today, and may never be, but that’s no reason for antagonism.