The Web Just Isn't DTP
By Lois Wakeman
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 while now, it still hasn't
settled down into any agreed 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 homegrown 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" (http://webreview.com/2001/03_16/webauthors/index01.shtml)
by James Kalbach is an excellent summary of page size design
- 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 fonts or large fonts 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
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 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.
What can you do to avoid these pitfalls, as a page designer?
There are two extreme approaches:
With web authoring packages like Adobe GoLive, Macromedia DreamWeaver
and Microsoft FrontPage, 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 palmtop on a plane, a potential consumer using his WebTV
set, or a partially sighted surfer listening to a screen reader.
- 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.
- 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
Assuming that you care enough about both design and accessibility
to reject both 1 and 2, what should you do? Read on to find
The middle way
I am going to suggest five 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
Some hints on tables used for layout:
- 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. On long inside
pages, this may mean having a page summary and a navigation
bar in the top 350 pixels, say.
- 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
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 (http://lois.co.uk/web/articles/font-access.shtml)
for more detail.
- Try to follow the KISS principle (Keep It Simple, Stupid)
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 (see below for a few hints).
- There are many resources for CSS design on the web. A
good place to start is A List Apart's archive (http://www.alistapart.com/stories/)
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.
- 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. DHTML effects like this don't work in all
browsers, and you probably need to provide down-market alternatives.
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.
- 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
as a coherent whole.
- 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 in text immediately. A full consideration
of this point is outside the scope of this article, 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.)
- Tables with complex row and/or column spans can display
very poorly in Netscape 4, especially if a style sheet is
associated with the page.
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. (The list for a comprehensive
test is a lot longer than this, but the points here are a good
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 VGA resolution.
Lois Wakeman is an experienced technical author and the principal
of Communication Arts (http://communicationarts.co.uk),
and a web site designer specialising in accessibility and usability
Resident in the UK, she currently works for European and North
American clients. You can read more of her web design articles
at http://www.lois.co.uk, or contact her on firstname.lastname@example.org.