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

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

Web resources

index page