Reprocessed, by Matt Patterson

Something approaching a weblog

Web design tools are skeuomorphs of print design tools, and this is a bad thing.

I've recently been re-reading (actually, reading from start to finish for the first time) Philip 'Vermeer's Camera' Steadman's The Evolution of Designs. The book is about biological analogy in design, focussing on architecture and industrial design. At work I've been gazing into the content production and management abyss, and I've been doing more thinking about web design. This post is the collision between those things, and some of the earlier thinking I did for my dissertation (which I'll try to get around to properly putting up on the site, with its images).

The book introduced me to the term skeuomorph. A skeuomorph is, essentially, a decorative feature which is derived from an earlier structural feature. A good example is to be found in classical stone architecture: guttae, the line of protruding cubes which runs underneath a pediment, are decoration derived from the roof joists of the wooden temples which preceded the classical stone temples.

A more modern, and more extreme, example is found in mid twentieth-century British railway locomotive design. When steam trains were still predominant there were experiments with new kinds of engine technology, one of which was with gas turbines. Steam locos (particularly the big express train locos) had a characteristic shape, with the boiler occupying the majority of the front of the train with a cabin for the driver and engineer at the rear, then a tender (a separate truck) for coal and often water. The arrangement means that the forward windows for the train crew to see out of are tiny - people need to lean out of the cabin to get a good view. Most modern european locos ditched this arrangement when they moved away from steam, because there was no requirement for the front of the loco to be occupied by a boiler any more, and put the crew cabin at the very front with a nice big windscreen.

The experimental gas turbine loco didn't change things, though. It looked almost exactly like a steam loco, with a tiny-windowed cabin at the back, the exhaust from the turbine on the top and near the front (where the chimney would be). It even had a separate tender with fuel in it: A skeuomorph. It's shape had absolutely nothing to do with the underlying technology, and everything to do with following established norms of locomotive form. (As an aside, they ditched that gas turbine design -- it kept setting fire to the wooden foot bridges it passed under.)

When we start to look at the tools available to web designers which specifically claim to be design tools, rather than text editors, we can see something funny is going on.

If you were to characterise the history of visual web design tools in a single sentence it would be that they, more or less, look and act like page layout tools. All the major visual web tools use 'pages' as the thing that you build. In fact, one of the biggest differences between GoLive and InDesign, both Adobe products is that InDesign has a 'pages' palette, listing pages in order, while GoLive has a site view, listing pages organised according to a tree-like structure which may (or may not) accurately reflect the macro-structure of a site. Going back to the history of the tools, I'm sure that a fair few of you remember the period in the mid-nineties when the page layout tool vendors (Quark, Adobe) and their raft of plugin manufacturers tried to turn the Quark and PageMaker into Web-design tools. More recently Softpress's Freeway is a web-only tool which tries to act as much like Quark as it can, to the point that you can't always tell if text on the page would be generated as HTML text or as an image: the app decided for you in many circumstances.

These tools have two main obsessions. The first is an obsession with producing whole pages, and the second is in providing a 'WYSIWYG' editing and creating experience. My problem with the tools stems from these two points, which are hang-overs from their page layout tool ancestors. Much like the gas turbine locomotive, these tools have their cabin in the wrong place, tiny windows, and they keep burning the bridges they pass.

Both 'pages', as a be all and end all, and WYSIWYG are hang overs from print design, or from strange assertions and assumptions about print design. Precisely why this should be is a subject too large to adequately address in this post, but I'll try and quickly paint in some detail (broad brush-strokes). Pages, firstly, are an obvious tool inheritance from page layout. 'But', I hear you cry, 'what about web pages, surely pages are what the web's about'. While it's certainly true the 'original' web was heavily based around what it called pages, there are several fairly serious factors which support me. The same holds true for the strange WYSIWYG construction.

Web pages are not print pages (and they never were)

Although print pages and web pages seem similar on the surface, there are significant differences between them, which quickly become apparent. In essence, print pages are arbitrary units of manufacturing convenience, while web pages are semantic units of editorial intention. Print pages are there because you have to split a document up into chunks to manufacture it sensibly, they aren't actually intrinsic to the document. Web pages are semantic units, which is to say that their content is not an arbitrary chunk of a document. Instead, their content is a whole document.

This is a fundamental difference between the two concepts. The design tools which supported page layout and have been adapted or had their tenets reused for web design are lumbered with the problem of emphasis on a physical unit, which generally happens to be roughly the size of a screen. Anecdotal evidence suggests that one of the defining differences between 'web-native' design and print-designer-turned-web-designer design is the latter's instinctive tendency to design and build things approximately the size of a screen.

Print design need for physical accuracy doesn't help either. Since a print page is of fixed physical dimensions and the only device which has to deal with your design is the film or plate setter at the printer's then it's necessary to focus on exactly where things are placed, and how big they are. Also, since every printed page looks the same, and looks (more or less) exactly like the design on screen there's an inherited assumption that a design should look the same on all browsers everywhere, for moral/aesthetic reasons, so that if a design doesn't look the same everywhere then it's wrong. The reasons why this particular fallacy is so dangerous has been talked about in many places, and I won't rehash things here, but the key point is that visual web design tools explicitly support, and by extension help perpetuate, this view (see WSYIWYG is not true now, and never was below).

In short, Web 'pages' are not print 'pages' now, they never were, and they're drifting further and further away from each other. Anything, and especially a 'design' tool, which doesn't recognise this is doing web design harm.

One of the most interesting areas where visual design tools for the web have real problems because of their print assumptions is when the web diverges most completely from the print page analogy, with dynamic content. When the same 'page' is different, for different people, and at different times of day, then you know you're not in Kansas anymore. It's a shame no-one told the tool makers.

Web pages are not necessarily static

When a web 'page' isn't simply a static chunk is when the cracks in visual design tools really start to show. The primary problem is that if your underlying analogy is to page-layout, where every unit -- every page -- is one thing which has a canonical appearance, then how are you supposed to handle the creation of something which has many permutations of its final appearance?

It's very difficult to do, because what you're designing, by and large, is a series of components, each of which can have several visual states, and contain different amounts and kinds of content, then you need a tool whose size of component is much finer grained than the whole-page level of the visual web design tools, and if you're on the fallacy-of-fidelity, pixel-perfect tip then the tool you're likely to jump for is an image editor, like Photoshop. Let's dwell on this for a moment. Photoshop, which provides layers and all sorts of cleverness, can be harnessed for dealing with the complexity problem by using all those clever compositing tools.

This has its own consequences. It encourages the separation of visual design from technical and markup design, it allows for a situation where designers who can't code, and so have no real understanding of the feel of the medium, the way that the web actually works, can lay claim to being web designers. This is nothing new. DTP raised a generation of designers who could (and would) design things which couldn't be printed (in as much as they couldn't be made to look like they did on screen), but would still call themselves print designers. This is all a bit of a digression from my main point, so I'll leave it for a later post.

Of course, there are other approaches, notably interleaving the dynamic aspects with the HTML in tools like Dreamweaver, which is the approach used by Zope's ZPT system, where the instructions to the templating system are hidden from the visual design tool by using XML namespaces and namespaced attributes to hold all the dynamic bits. This is a nice idea, but it still falls far short of the ideal: For starters, you can't edit any of the templating commands within Dreamweaver, you need to use an external editor, and you can easily clobber what's already there. It's a fragile system.

WYSIWYG is not true now, and never was

One of the biggest problems that borrowing the tools and inheriting the assumptions of print design has caused is that of the fallacy of fidelity, that WYSIWYG editing really is true to what will be seen in browsers everywhere, and that, by extension, WYSIWYG is the right and proper thing. I'll deal with these points separately.

That WYSIWYG and the web don't mix becomes apparent to most people who get involved with the web pretty quickly. The promise of WYSIWYG is a false promise, for many reasons. The single biggest reason is that browser software is a moving target and, unlike print, there is no such thing as a canonical visual representation: Each browser -- each instance of each brand of browser on each different platform, with each different screen size and colour handling -- makes their own. WYSIWYG on the web is true to the letter, not the spirit: What you see (in your editor) is what you get (in your editor, but nowhere else).

What's interesting to note is that WYSIWYG isn't true anywhere else either, it's just that the holes are subtler and people have had more time to paper over them. In PageMaker, the first DTP app, linebreaks on screen were decided by PageMaker, and line breaks in the printed output were decided by the printer, with the result that the two didn't always match up. Even now, screen representation is so coarse compared to print that the two never exactly match, it's just that the differences are subtler not as glaring as they used to be.

Of course, we're forgetting the next biggest boundary to a pixel-perfect cross-browser dream state: The user. Ah, the humble user, much maligned by the web design community who are stuck with the inherited notion that the user gets what they're given.

This is the biggest issue facing web design as it begins to mature. With print design, the user gets what they're given, literally, in the form of pieces of paper with ink on them. On the web there's no such look for the poor designer. Since each user's browser performs the final render of a page, interpreting the HTML, CSS, and Javascript sent to it, the user has the final say over how the page looks.

How many of us have heard people moaning about people who set their default text size too high, or switch javascript off. Those bloody users, always breaking our designs. Let's say that again, shall we: Breaking Our Designs. Web designers say that a lot, and it's so far from the truth it's laughable. Take a deep breath everyone, because when you use text sized in pixels, or images for headings, or whatever, and a user somewhere complains that your site is broken, and it's because they've got their text size set differently, then they're right: You broke their browsing experience. You broke it, not them.

The concept of user agency is alien to print design, but is at the absolute core of the web. While you can, and should, use your design expertise to craft sites which are beautiful and functional, not to mention accessible and standards-based, you need to do so with some flexibility, because if your site depends on the user's browser (or computer, especially with regard to display size) behaving in a certain way then you're betting on a dead donkey.

It's possible (hell, it's easy) to design sites so that when the user takes matters into their own hands, like when they can't see very well and need that text to be bigger, your design responds graciously, and allows them to do that without breaking their experience. And when the users push things beyond the bounds of of what you might consider graciousness (For example, I have a colleague who essentially has a black-and-white computer because of his vision requirements) then graciousness needs to extend further, and allow them their control without complaining, and without obscuring things.

When we have inherited standards of good design from print, carried down in no small part because of the contribution of visual web design tools, which are corrosive to the core of the way the web works then we need to get new standards, frankly. There are many other factors at work here, and I'll hopefully have time to deal with them in a later post.

We have a situation where many of our tools and techniques are inherited from the tools and techniques print design. The example of the gas-turbine locomotive is an example of a thing evolving technologically but retaining a shell essentially decorative in function. While visual web design tools are a technological evolution of print design tools and are skeuomorphs of those print tools, they're more pernicious than that. The gas-turbine locomotive and the steam locomotive are both railway vehicles doing the same job on the same tracks.

Visual web design tools and print design tools are both 'design tools', but at the level of infrastructure -- the tracks -- the two things are not the same. Visual web design tools are skeuomorphs of print design tools, but they are orthogonal to web design itself, running off on their dangerous tangent and causing more problems than they'll ever solve.

Not forgetting:

This page is: