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:

• Your visitors will have a variety of screen resolutions, so you can't predict how much screen real estate you have to work with. A web page doesn't have a fixed size like paper – so any complex layout you do will probably fall over for at least some of your visitors. At low resolution, they may need to scroll sideways (a real no-no!), and at high resolution, they may see either very long lines of text, or acres of white space.
• Your visitors don't all have the same page display area inside their browsers. They may not run them full-screen; even if they do, they may have task/Office bars in different configurations; and finally they may have different buttons, toolbars and sidebars in the browser itself. So you really can't predict, even for a given resolution, what the 'paper size' will be.

   The Myth of 800x600 by James Kalbach is an excellent summary of page size design considerations.

• You can't tell what fonts your visitors will have installed on their computers. Unless you use font embedding technology (which can be slow and doesn't work for everyone), you can only guess at common fonts and hope for the best. (If you decide to get around this by having all your content in graphics of your chosen font, you are creating a whole new set of accessibility problems!)
• For Windows users, you can't tell if they are using a small or large font display setting. This can make a difference to what they see.
• Visitors will have a variety of browsers. Each browser interprets your page slightly differently, and even the simplest page will look subtly different in every browser. In the worst case, a complex page may be unusable in some older browsers. You can get round this to a degree by browser detection – but this often involves using scripting (so see the next point).
• Some visitors will turn off scripting, cookies and Java applets (or have them turned off/filtered out by company policy). So, you can't rely on any effects or content that need these to work.
• If your content isn't standard web fare (in practice, this means plain text or HTML files, and JPEG, PNG or GIF images), some visitors won't have the necessary plug-ins or programs installed to see it. This applies typically to Microsoft Office documents, Adobe Acrobat files, Flash movies, and various audio, video and VRML formats.

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  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  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.)

© L Wakeman 2018 email +44 (0)1297 444707 | technical writing | web design | photos | pottery | about | help