Some principles for html web page design
Keynote:
A usable web page is one which gives as soon as possible
the information needed to know whether to read on,
go "Back" or go onwards to a more relevant linked page.
The principles
Navigability
| Timeliness
| Reversibility
| Escapability
| Context links
| Minimal work
| Granularity
| Maintainability
| Responsibility
| Consistency
| Development methodology
-
Navigability
-
People do a lot of browsing and navigating on the web.
Even where a particular page answers someone's need, it
is rarely possible to find it at the first attempt.
This means that making navigation easy is one of the prime
functions of a web page, and the popularity of lists of
links reflects this.
Navigation differs from reading a page of interest,
and needs to be more immediate, to help people find the page,
or information, they want as quickly and easily as possible.
Here, first are principles for design independent of time,
while the particular issues related to the dimension of time
are in the following heading.
- Every page needs to be considered from the point of view
of navigation.
- It will often make sense to provide many pages which are
optimised for navigation only, separately from
the pages which deliver the message or content desired.
- Dedicated navigation pages need to give the right
amount of information for choosing the next link to follow.
This means giving self-explanatory names, or phrases of
explanation, for the contents of any pages linked to.
Too little information, and the user will make more 'wrong'
choices which are immediately cancelled. Too much information
will clutter the page and make the decision process longer.
- For pages that provide the main content, it needs to be
clear from the start what that content is. Providing
helpful titles, short abstracts or summaries can help,
as can a list of internal content links (as on this page).
The other principles below add more particular detail to this.
- Timeliness
-
These are issues that depend on the technology, that are
currently very salient, but may change with time.
Graphics take a relatively long time to download
(though there are
ways
of saving bytes in images)
and so having a large graphic at the beginning of a page
can seriously obstruct its usability for navigation purposes.
-
The first thing we need to see on a page is the information
that will help us to know whether we want to read the rest
of the page, whatever it is. With current
technology, it makes most sense to present this as text.
-
For navigation pages, the next things that need to be
presented are the links to other pages.
-
For long 'content' pages, it may be useful
to have internal links to parts that may be referenced separately.
In any case, it makes sense to ensure that there is sufficient
text visible to occupy the user usefully while the browser
program displays graphics.
-
The right place for graphics (currently) is after the
vital navigational information has been given textually.
- Reversibility
- At the top of each page, (and perhaps the bottom) put a link
back to all main pages from where there are links to that page.
This is a navigation aid that allows exploration without
penalisation. There are two reasons for this: firstly because
the `back' button of the browser does not say what it goes
back to, and secondly to provide an indication of, and link to,
context, as discussed below.
- Escapability
- At the top of each page, and possibly the bottom, put a link
to the main likely starting point, home page, index, or whatever.
This should be designed as far as possible to fit in with the user's
likely concept of the browsing activity. One should enable escapes to
the starting points of the activity that remains in mind as the
current one even when the user gets lost.
This may be further than (as with reversability)
simply going one level up in
the hierarchy (humans don't keep mental track of hierarchies very
well), but going back to an early beginning might be too far back.
An easily-recognisable icon, or a textual label,
for each major level, at the top of the page,
would be one good way of fulfilling this principle
(see also context below).
- Context links
-
The above two principles are combined in a discussion of context.
Web pages usually have some context,
which gives the background that enables the page to be
understood properly. Since one can never give all the
context of anything, and since pages may have multiple contexts,
it is a good idea to indicate possible contexts explicitly,
for example, by putting links to other pages giving the context
for a given page at the top of that page.
What pages could be linked like this?
One obvious answer is the pages which have links to
the page. To illustrate this,
at the top of this page, I have a
link back to my home page, which is the most
obvious place from which there is a link to this page.
I could also provide context links to lists of html
style guides, but I haven't, partly because I haven't
arranged for this page to have a link from any of the
more obvious pages on html style. Would you like to
tell me in what context this page would fit in nicely?
A context link may also serve as a reverse link (see above,
"Reversibility").
This illustrates the method of having small
icons or text labels at the top of a page
(above the main page title),
which are anchors for returning to the higher level of context,
while also giving context information simply by being present.
If you consider more than one level of context (both the immediate
context, and also wider contexts) one can get a series of icons
or text labels, which give a very useful multi-level view of the
context of a page, and also provide escapability.
Textual context links could either be done as a table
(as I do in
my thesis),
or even more simply as a column (or row) of textual links,
separated by some punctuation (not included in the anchor text),
to clarify the boundaries of each separate link.
I do this in the
Quaker
FWCC pages
that I have prepared for the widest audience possible.
Context links are even more important now that search engines like
AltaVista are very likely to take someone directly into any of your
pages. Context links allow them to back out gradually.
But calling this kind of link "Back to" somewhere is increasingly
confusing, because the person browsing may not have come from there.
Much better simply to give the context name.
It makes sense to give the context links from largest
(furthest) to smallest (narrowest) at the beginning of the page,
and, of long pages, in the reverse order at
the end of the page. This is easily comprehensible,
as it maps readily onto the idea of nesting boxes.
- Minimal work
- For related pages where access to one page is likely to be
followed by access to another, put a direct link to the likely
following page or pages at the bottom of, and possibly the top of,
each page.
Wherever the user's attention is likely to be captured, provide a
direct link to the place of related interest. This principle is
fairly obvious for any hypertext format, but needs a clear idea of the
user's possible motivation or possible tasks or goals if any.
- Granularity
- Due to the principles on which html and html browsers are based,
it is impossible to define in advance how large one screen will be.
In general, one page (or node) should contain the amount of
information that a user is likely to want together in one unit.
For navigation pages,
following the principles of navigability and minimal work,
it is a good idea for a page to fit on one screen, because
it saves the mousework of scrolling down. The two principles may
occasionally be in conflict, however, and clear, consistent navigation
logic should not be sacrificed for the possibility of
fitting on one screen.
For the leaf pages that present the bulk of the information,
one has to guess how much a reader will wish to see at once.
Thinking about this, and making a guess, is better than
not thinking about it at all.
There should be a good reason if a number of sections are to
be put together in one file, with internal links at the top.
For instance, in this file, the guidelines are interdependent and are
best read together. In other cases, it may often be better to split
the file into self-contained units, particularly where the sections are
not clearly related, or where it is likely that only one will be
wanted at once.
- Maintainability
- Put at least the email address (as a "mailto" for most
browsers) of the person who maintains the page on that page.
Also, keep a last revision date visible on all documents, to help
others to know when it has been revised.
- Responsibility
- Make it clear, or make the information clearly available, who the
author is and who owns the intellectual property. In particular,
point out any significant copyright.
- Consistency (a very general principle)
-
In similar situations, corresponding things should be similar.
Ensure that there is a good reason for any differences.
If there is no good reason, make it the same, or do it in the same
way. This is a general principle that helps to minimise the effort of
learning or becoming familiar with anything.
To fulfil this principle successfully, one has to think quite
carefully what the probable users or readers of one's material are
likely to think of as similar situations and corresponding things.
- Development methodology
-
These principles are, necessarily, sometimes quite abstract.
This is because one cannot generally specify how to implement
consistency, for example. In practice, it is suggested that a
developer chooses the principles that appear to apply to the case of
the development that is under consideration, and that the generalities
are specified progressively as the development progresses.
During development of pages, the guideline on maintainability should be
emphasised.
For example, the consideration of the needs of various classes of user
may lead to a set of functions that should be implemented. Further
specification of the principle of consistency would lead to design
decisions about how to implement each aspect of the functionality
chosen.
These principles are given as suggestions,
and make no claim to completeness, optimality or originality.
They are partly derived from commonly-discussed HCI guidelines.
Please tell me
if there is something that I have left out or that I could
express more clearly.
I have made a more straightforward
version of this guide. This one is written in an
rather more academic style, the other version less so.
There used to be a good, comprehensive selection of web design guidelines,
on Keith Instone's
http://www.acm.org/sigchi/webhci/ site.
Alas, no more. Try the Internet Archive.
My own pages attempt to illustrate the principles I suggest.
Where they fail, please feel free to tell me,
and say whether it is the page or the principle at fault.
Revised 2000-03-21