Why web pages cannot be designed like printed layouts

On this page: Why the web just isn't DTP. Lois reads lots of anguished messages from people trying, unsuccessfully, to emulate the printed page in their web sites. She considers how web authors can make their lives easier, and improve things for their site visitors at the same time.

Although the web has been around a fair while now, it still hasn't settled down into any fixed forms, and probably never will. By contrast, paper documents have a number of well-defined and usable forms (posters, catalogues, flyers and leaflets, encyclopaedias and dictionaries, novels, comics, children's story books etc.) We mostly know what to expect, and the designs, though all different, tend to follow hallowed typographical principles (or at least they did before DTP allowed anyone to have a go). Ignoring the worst home-grown efforts then, professionally-produced paper publications usually look OK, and are fit for their purpose.

If only we could say the same for web sites. Of course, the ease of web publishing means that anyone can do it – unfortunately, not everyone can do it well. It is a challenge to make a good site, because of all the technological and other constraints, in addition to the principles of good content and organisation that every content author (book or web site) needs to consider.

Pitfalls for the page designer

Some of the ways that technology can work against you are:

Extreme solutions

What can you do to avoid these pitfalls, as a page designer? There are two extreme approaches:

  1. Make plain vanilla pages that use the lowest common denominator. OK – everyone will see the same, but it will be pretty boring and unattractive to visitors. This may be OK for an academic archive, but probably not for most web sites.
  2. Assume one resolution and screen/browser configuration, and design just for that. Tie everything down to the last pixel by using very complex tables for layout. This is what I call the DTP approach – and believe me, it just isn't effective!

    With "WYSIWYG" web authoring packages (like Adobe GoLive or NetObjects Fusion for example), it's very easy to be tempted into believing that pixel precision is achievable. It might be OK on your monitor with your browser and work habits, but it almost certainly isn't for some poor sap working on an old laptop, an executive using her PDA on a plane, a potential consumer using his WebTV set, or a blind surfer listening to a screen reader.

Assuming that you care enough about both design and accessibility to reject both 1 and 2, what should you do? Read on to find out...

The middle way

I am going to suggest some simple principles that you could follow to make a usable but attractive site. This is a good English compromise, between the fusty and the bleeding edge, as you might expect from this wishy-washy liberal English writer <G>.

  1. Read the link to external site article I suggested above, and vow not to design for 800x600 only. Come up with a design that makes the most of the web's flexibility. Think of your page as a mould into which you can pour your content – but a mould whose dimensions and aspect ratio will change for every visitor.

    This is my main point about not trying to do DTP on the web. Don't think in terms of grids, fixed areas and aspect ratios, but of an elastic rectangle within which you can loosely arrange your content. Kalbach describes different ways of doing this – unfortunately, all the best are "complicated to implement", as he acknowledges, and may only work in later versions of certain browsers.

    You should ensure, especially on your home page, that all the essential information appears without scrolling for the average visitor. In newspaper terms - it needs to be "above the fold". On long inside pages, this may mean having a page summary and a navigation bar in the top 350 pixels, say.

  2. Use CSS style sheets to control the basic colours and fonts used in your page, and the spacing of individual elements like paragraphs and lists. (Read my article on using style sheets to find out more). As the article explains, you can design so that those visitors who can't see styles get a reasonable experience. Make sure you have a reasonable list of fonts to choose from: read my article on accessible fonts for more detail.
  3. Try to follow the KISS principle when laying out your pages. When I first wrote this in early 2001, I didn't recommend tackling the more difficult areas of CSS styles like absolute and relative positioning, because browser support was poor. Things are very much better now, but if you are not happy to take the time necessary to get CSS layouts working, you can use simple tables to position your elements.

    There are many resources for CSS design on the web; a good place to start is link to external site A List Apart's archive from Jeffrey Zeldman, which not only details the author's struggle to lose the design habits of a web lifetime, but also includes some useful hints on how to do it.

    Some hints on tables used for layout:

    • Consider the accessibility of your tables: blind people may 'see' the content sequentially, cell after cell, rather than being able to take in your carefully crafted design.
    • Long tables can take a while to display, unless the browser can calculate the space it needs to reserve at the outset, so it can start pouring text in immediately. A full consideration of this point is outside the scope of this page, but a good starter is to ensure that all your images in tables have height and width attributes.
    • You will often (but not always) get better results by allowing the browser to calculate cell widths according to the content, than by setting pixel/percentage widths.
    • If you need to specify cell widths, you may run into problems when you specify all but one cell, a mixture of pixels and percentages, or when the overall table width and the constituent cells don't add up to the same value. (I say "may", because there are no hard and fast rules – one table will work, and another almost the same won't, in the same browser.)
  4. Simple rollovers (beloved of DreamWeaver authors everywhere) are fine as an enhancement to the appearance of a page. But if they contribute to the content of the site (for example revealing a text description when you roll over part of a map or diagram, or drop-down menus), some of your visitors will lose out. Effects like this don't work in all browsers, and you probably need to provide down-market alternatives.
  5. Don't rely on Java applets or client-side JavaScript to provide essential content for your pages, as not everyone will be able to see it. The same is true of content that requires a plug-in to view. If you must use it, think about providing a text commentary or other alternative.

And finally ...

All I have to say in conclusion is, whatever your page design, if you are serious about your visitors' experience at your site, then please test it properly. Start by using a link checker for the mechanical errors, but then try it in as many browsers as you can, on as many platforms as you can. Putting a notice on the home page saying "this site works best in Netscape Navigator 7 at 1024x768" is no excuse not to test in others! Try it with scripting disabled, see if you can navigate to other pages with the keyboard, and see how easy it is to use with the monitor set to a lower resolution. (The list for a comprehensive test is a lot longer than this, but this is a good start.)