Building Usable Web Pages: An HCI Perspective

Tim Comber, Southern Cross University, NSW 2480, Australia, Phone:-+61 66 203117, Fax: +61 66 221724 Email: tcomber@scu.edu.au Home Page [HREF 1]

Keywords: usability, interface design, human factors, web pages

Introduction

New web pages are being added to the World Wide Web at a rapid rate. Consulting a list of new web pages such as Yahoo![HREF 2] on any day will show growth rates of up to hundreds of new pages a day. Most web page authors are experienced progammers or know how to program, Second WWW User Survey [HREF 3] and yet many web pages present usability problems despite the number of guides to writing html [HREF 4]. Each of these guides refers to some aspects of usability such as suggestions to date pages [HREF 5] and place the author's name [HREF 6] on the page but the articles mostly concentrate on the mechanics of marking-up documents. It is important to remember that "...there is a limit to how well users can adapt to a poorly designed interface" (Smith & Mosier 1986).

This paper offers specific guidelines to writing usable web pages by concentrating on those aspects of web page design that affect usability: learnability, efficiency, memorability, errors and satisfaction (Nielsen 1993, Lindgaard 1994). Guidelines are presented under the headings of information content, visual appearance, navigation and testing and a brief summary is given. References are made to HCI research where applicable.

A number of potential research questions are indicated:

What are the time limits before a reader will cancel a download?
Do users need verbal as well as visual cues to follow links?
What is the best way to provide navigation aids within a web system?
What are the best means for indicating the authority of the document?
How should icons be laid out?

A web page is defined as the information retrieved by invoking a single URL and is often referred to as a document. I prefer to call it a web page so as to highlight that a document published on the web is not the same as a paper document. A web system is defined as a collection of web pages that is controlled by one person or corporate identity.

Usability Guidelines

Content

The title [HREF 5] should be short as it is used by some browsers as a window title and may be stored as a bookmark label or as part of a history list. Every page should have a heading < H1> that describes the contents or purpose of the web page and it makes sense to use the same text as the title for the heading. The heading also helps the reader to locate the page in a web system (Smith & Mosier 1986).

Most guides to writing HTML suggest that web pages should be signed and dated. Dating allows the user to know how old the information is and when it was last updated. Pages should be signed so that readers can provide feedback and assess the status of the author. Signing and dating help the reader to assess the "goodness" of the information as there is little or no control of web pages.

Web documents should be short [HREF 5] (maximum of 2 to 3 screens) for a number of reasons:

Charging for access time.
Slow connections.
Reduce traffic on the net.
The user may only require sections of the document.
Problems with navigating a long hypertext document [HREF 7].

However it is a good idea to provide a single-document, printable version of manuals, research papers and similar lengthy documents. Research has shown that reading documents on line can be 20% to 30% slower than reading from hard copy (Smith & Mosier 1986).

Each page should establish the context [HREF 5] of the document (Smith & Mosier 1986), so that statements such as "The next thing to consider" are avoided making web documents more readable [HREF 8] . Users can enter a web system at any point and, even if following an author-determined path, can be easily confused by data that relies on reading prior pages.

Visual Appearance

Not all browsers allow for graphics [HREF 8] . Some people, particularly those with slow connections, set the browser to ignore inline graphics. A web page that depends totally on an image can be meaningless to these people. The solution is to use the ALT modifier tag to provide text instead of an image placeholder. Where an ISMAP is used as a graphical menu also provide a text option. Fixing the size of images with the WIDTH and HEIGHT tags can reduce waiting time for people using browsers such as Netscape. The Yale C/AIM WWW Style Manual [HREF 7] provides a good discussion of these issues.

Small pictures are quicker to retrieve than large pictures. Thumbnails give the reader an idea of a picture and can be linked to the full size picture. This allows the user to decide if the picture is worth retrieving without wasting time and bandwidth.

A single ISMAP containing buttons is quicker to retrieve than a number of individual buttons according to Nielsen [HREF 9] but consider placing the buttons in a logical pattern or metaphor. A good example is an interactive map of Australia [HREF 10] which provides a geographically sorted list of web sites.

Formatting can be used to highlight text items. Special formatting features such as blinking should be reserved for occasions that are truly important to the user. If you feel that the reader's attention must be drawn to something then consider using a symbol with the special formatting (Smith & Mosier 1986). A blinking asterisk * still grabs attention but does not interfere with reading the text. It is better to use logical formatting [HREF 11] eg < CITE> < /CITE>, rather than fixed formatting such as < I> < /I> because browsers may ignore fixed formatting or treat it in an unexpected manner.

Miller's "plus or minus seven" rule is often quoted as a guide to the number of objects that can be displayed at once but remember that grouped objects count as one (Miller 1956). For instance do not place more than seven icons on a page without grouping. Likewise if you have a long list break it into sub-categories and offer links to the sub-categories.

Navigation

A web system should be designed so that a reader can form a useful mental model [HREF 12] of the system. One technique is to give readers a predictable location for information and controls throughout the web system eg Sun Microsystems [HREF 9] . Buttons or hot links can be provided to enable a user to move both forward and back through the system as direct manipulation (Shneiderman 1982) is better than users entering an actual URL. The navigation system adopted should aim to minimise cognitive effort by following a pattern that users understand (Hutchins 1985). A common design format for a web system that would be printed as one document consists of a link to the table of contents, a link to the previous page and a link to the next page in the series. The alternative design for non-linear web system is to offer a link to the home page, a link to a feedback page and optionally links to important pages.

Use the same icons or tags for the same job through every document and consider using a labelled blank or a logo rather than leaving an item out (Smith & Mosier 1986). Not only does this reduce the memory load and make it easier for the user to learn how to use your web system but browsers cache graphics. This means that icons do not have to be retrieved again once they have been downloaded.

The size and type [HREF 12] of files offered for downloading should be indicated. If the size of the file is known in advance, the user can make a decision as to when and whether to download. Keep in mind that users prefer and expect computer response times in seconds (Smith & Mosier 1986) though they will tolerate longer times according to the importance of the information. The other issue is knowing the type of the file. If the user can not deal with the data then there is no sense in downloading it, see User Interfaces for Public Information and Scientific Research [HREF 13] for a discussion of the importance of data exchange standards.

Meaningless links eg click here for more information, are considered a problem by some authors eg [HREF 12]. There are 2 problems with meaningless links:

If the user does not have or use a mouse then how can the action be achieved?
Only necessary data should be displayed (Smith & Mosier 1986). Browsers always highlight links in some fashion so that an anchor should be associated with the word that best describes the link.

Testing

Usability testing can be an expensive exercise requiring sophisticated techniques (Nielsen 1993) such as laboratories to video tape users with a new system. I would suggest that it would be a good idea to at least stand and watch someone using your web system even if you do not have access to a usability laboratory. It can be surprising how things that you consider obvious may be confusing to a new user.

It is important to test your web system with as many different browsers [HREF 5] as you can access, as different browsers have different display capabilities.

It is important to check links regularly. A link that has deceased is totally unusable. Your web system may work perfectly when you first publish it but over time links may become out-dated. This reflects on the professionalism of the web author. For instance, while writing this I havebeing trying to ftp files from the CERN site but none of the ftp links at the WWW Project work. At present, politeness suggests that if you change or expire a web site you should leave a message indicating the fate of the site.

If you offer a service make sure it works as any reasonable user would expect. A good example of a service failure is the University of New South Wales home page where a link offers to find the email address of people at that campus. However the search only succeeds with exact spelling and capitalisation and does not return the full address.

Examine server log files [HREF 5] to determine whether certain pages are being read. Users may be ignoring pages because of a lack of interest in the content but it is also possible that you have used the wrong words to describe the link. A simple example is my own link to rock [HREF 14] information. As I have just expressed it, the link is ambiguous and most users would expect a link to rock music not gems and minerals.

Checklist

Content
Short title.
Meaningful headings.
Sign and date pages.
Short documents (around 2 screens).
Provide a printable version of lengthy documents.
Each page should "stand-alone".
Visual Appearance
Provide text alternatives to images using ALT.
Specify the size of images with WIDTH and HEIGHT.
Use thumbnails instead of large graphics.
A logically designed ISMAP is better than separate buttons.
If blinking is necessary, blink a character such as * rather than the text.
Use logical formatting.
Keep in mind the "plus or minus seven rule" (Miller 1956) for graphics, lists and headings.
Aim for consistency of design.
Navigation
Provide links on each page to other relevant pages.
Re-use icons where possible.
Tell the user how big and what type of files that are offered for download.
Avoid meaningless links.
Testing
Check links on a regular basis.
Test the usability of your web system.
Make sure that services offered work correctly.
Check log files to gauge user acceptance of your system.

Discussion

The World Wide Web provides a unique opportunity for people to publish documents with little or no cost to themselves on an international platform. It is very easy to create simple documents that seem to work and look reasonable but it is very easy to make usability mistakes. And by the very nature of the publishing medium, mistakes are very visible to many people. Problems with usability usually occur with navigation, screen design and layout, terminology, consistency and match with user's tasks (Lindgaard 1994). Therefore it is important to plan and test your web system carefully.

The visual appearance of a graphical interface can be very attractive but response time is an issue (Smith & Mosier 1986). Most people are used to very rapid response times from computers but response times can be much slower over the Internet. Research is required to determine how long a person will wait and what categories of information influence waiting periods. In the meantime it is safe to say that it is important to minimise the time a person has to wait for information.

Another issue is the consistency of the web system design. A web system should be consistent (Smith & Mosier 1986) but keep in mind that a thing is consistent if users think it is consistent and use it consistently (Nelson 1980, p104). Users are not usually interested in how you have designed your pages but in completing a task. An inconsistent design necessitates the user wasting time adapting to changes instead of getting on with the job.

Web documents can be accessed by many different browsers working on many different operating systems unlike, for instance, a Windows help file which is only meant to be read by the Windows help program running under Microsoft Windows. The author of a web page has no control over the browser that will be used by the reader. Most computer systems deliver information in seconds but the web is often much slower because of distance and the amount of traffic on the net.

Further Research

There seems to be very little HCI research done on interface design and the WWW. The only reference I could find after searching Perlman's bibliography [HREF 15] and the WWW using different search engines was Jakob Nielsen's paper on the design of internal web pages for Sun Microsystems [HREF 9] .

Areas that seem to me to require particular attention are:

Determining thresholds for user tolerances of slow downloads. Will a user abandon the document retrieval if it takes too long? Just how long is too long and does the importance of the information affect this time? The browser can partially solve the problem by downloading information gradually rather than waiting until it is all received but it is still up to the web system designer to minimise the time. What is needed are specific time limits so that a person authoring web pages can know in advance that a certain percentage of users will not download that page unless it is made quicker to download.
Web browsers aid the user by allowing navigation of documents that have been read. However this may not be the navigation that the author of the web system would wish the reader to use. For instance, if a reader follows a link to a page in the middle of your web system, how does he read the rest of the pages unless there is a navigation system built into the web pages? Given , then, that these internal links are necessary what is the best way to indicate the links and where is the best place to put them. Should there be a button bar at the top of the page, at the bottom of the page, or both top and bottom? The answers to these questions should be determined empirically.
How important are meaningless links? Many authors suggest that they should not be used but some users like to be told what to do and find the instruction to "click here" appealing.
It may not be necessary to layout icons in a neat, ordered fashion. Previous research has shown that people believe that complicated interfaces are good designs (Comber & Maltby 1994). Compare Sun Microsystem's home page [HREF 16] where the icons are laid out in a strict grid with Next Online's home page [HREF 17] where the icons are random sizes and random positions.

One of the most awkward questions facing anybody reading a WWW document is determining the authority for what is being viewed. Is it the rambling of an unimportant nobody or the revelations of a mighty guru? The options as an author are to have enlightening content, establish who has written the document and under whose authority and date the document. Is this enough for people reading web documents?

Conclusions

This paper has presented a collection of guidelines that should aid authors to design web pages that are usable ie: meet user goals quickly and easily, be easy to learn, work under many different systems and for many different people, and be enjoyable to use. However these guidelines are mostly based on experience and intuition as there is little empirical research. Investigations are required into:

The patience threshold of users when downloading documents.
Verbal cues to links.
Methods for internal navigation within web systems.
Layout of icons and buttons.
Reader's perception of the authority of WWW documents.

Publishing on the WWW is proving to be a popular and easy way to communicate to an international audience for a low cost. Increasingly that audience will consist of people who want to use the web to get their work done. Web documents have the capacity to be "living" documents, unlike printed material. They can grow, shrink, react to criticism, change over time, and, if ignored, die. Sometimes they can become virulent and attempt to kill the host eg Delft University's 17th Floor picture archive! Web authors have a responsibility to design web systems so that it is easier and more pleasant for people to complete their tasks but also they need to keep their documents alive.

References

Comber, T., & Maltby, J. R. (1994). 'Screen complexity and user design preferences in windows applications'. In OZCHI'94, Melbourne, Australia.
Hutchins, E. L., Hollan, J. D., & Norman, D. A. . 'Direct manipulation interfaces'. Human- Computer Interaction, 1, 1985, 311-338.
Lindgaard, G. (1994) Usability Testing and System Evaluation. London: Chapman & Hall.
Miller, G. . 'The magical number seven, plus or minus two: Some limits on our capacity for processing information'. The Psychological Review, 63, 2, 1956, 81-97.
Nelson, T. . 'Interactive systems and the design of virtuality'. Creative Computing, 6, 12, 1980, 94ff.
Nielsen, J. (1993) Usability Engineering. San Diego: Academic Press, Inc, .
Shneiderman, B. . 'The future of interactive systems and the emergence of direct manipulation'. Behaviour and Information Technology, 1, 3, 1982, 237-256.
Smith, S. L., & Mosier, J. N. (1986). Guidelines for Designing User Interface Software No. ESD- TR-86-278). The MITRE Corporation. (Online copy 790KB, text)

Hypertext References

HREF 1: http://www.scu.edu.au/buscomp/compmaths/tcomber.html
HREF 2: http://akebono.stanford.edu/yahoo/new.html listing of new web pages and links to similar lists.
HREF 3: http://www.cc.gatech.edu/gvu/user_surveys/User_Survey_Home.html- survey of the www user population.
HREF 4: http://info.med.yale.edu/caim/M_Resources.HTML very recent guide to designing web pages.
HREF 5: http://www.w3.org/hypertext/WWW/Provider/Style/ Tim Berners-Lee's guide to writing HTML.
HREF 6: http://www.willamette.edu/html-composition/strict-html-gp.html#sigs - sign html pages.
HREF 7: http://info.med.yale.edu/caim/M_II_3.HTML Yale C/AIM WWW Style Manual: Document Design, Page Length.
HREF 8: http://heasarc.gsfc.nasa.gov/0/docs/heasarc/Style_Guide/styleguide.html another style guide
HREF 9: http://www.sun.com/technology-research/sun.design/sunweb.html presents the methods used to design the user interface and overall structure of the internal web pages for Sun Microsystems.
HREF 10: http://www.csu.edu.au/links/ozmap.html - map of Australia where clicking returns regional servers
HREF 11: http://www.utirc.utoronto.ca/HTMLdocs/NewHTML/htmlindex.html HTML Documentation Table of Contents
HREF 12: http://www.csi.uottawa.ca/~dduchier/misc/hypertext_review/
HREF 13: http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/HCI/register/register.html
HREF 14: http://www.scu.edu.au/buscomp/compmaths/misc/rocks.html
HREF 15: http://hyperg.tu-graz.ac.at:80/B10A350F/CHCIbib - a searchable index to Perlman's HCI bibliography
HREF 16: http://www.sun.com/index.html Sun's home page.
HREF 17: http://www.next.com.au/ Commercial web site for music and computer games.

Copyright

© Southern Cross University, 1995. Permission is hereby granted to use this document for personal use and in courses of instruction at educational institutions provided that the article is used in full and this copyright statement is reproduced. Permission is also given to mirror this document on WorldWideWeb servers. Any other usage is expressly prohibited without the express permission of Southern Cross University.

Return to the AusWeb95 Table of Contents

AusWeb95 The First Australian WorldWideWeb Conference