MARGINALIA OF WEB DESIGN

This column has been touching on some pretty Big Issues lately, including disabled access, international usability, and site structure. This month, let's look at some details that may not be as profound but still matter for Web usability.

Page Titles

As part of the HTML standard, every Web page should have a <TITLE> defined in its header. Page titles are important for navigation support since they are normally the default way to refer to pages in various navigation support mechanisms such as bookmark lists, history lists, overview diagrams, etc. Titles are also often used as the best way of listing retrieved pages in search engines.

Many of these important uses of the page <TITLE> are taken out of context, and it is therefore important that the title has enough words to stand on its own and be meaningful when read in a menu or a search listing. On the other hand, overly long titles slow down users, so as a guideline aim at titles between four and ten words.

Different pages need different titles. It is very unpleasant to visit, say, seven pages with the same title and then try to go back to a specific page from the history list. Also, of course, bookmarking more than one page from such a site is a guaranteed usability problem, since the bookmark/favorites menu will contain several identical entries with different results.

A final point is to optimize titles for quick scanning. This implies moving information carrying terms toward the beginning of the title and preferably starting with a word that will match the user's needs when scanning down a menu or listing of titles. A classic mistake is to use a title like Welcome to MyCompany. It would be much better to call the page MyCompany - Home Page. Similarly, eliminate articles like The, A, and An from the beginning of the title. Doing so is particularly important because some title listings are alphabetized.

In addition to titles, other ways of referring to Web pages include verbal and visual summaries. Normally, such summaries are very difficult to produce algorithmically. The main exception is the miniature as shown by the illustration to the right. The figure shows a miniature of this page, generated by scaling it to 15 percent of full size. In general, page miniatures are only good as representations for highly graphic pages or pages with very characteristic layout.

Two of the better uses of miniatures are for building a site map and for the history list when navigating sites that focus on visual arts.

Text Size and Color

On the Web, blue text equals clickable text, so never make text blue if it is not clickable. It is also bad, though not quite as bad, to make text red or purple, since these two colors are often used to denote hypertext links that have already been visited.

Another commonly seen mistake in text design is the use of large or small font sizes as the body text of a page. Page designers sometimes think that the default text in their browser is wrong for the effect they want to achieve, and it is certainly acceptable to make a small percentage of the text on a given page large or small, as appropriate. It is not recommended to change the font size of all the text on a page since the user must be assumed to have set the default font size in his or her browser to exactly the size that is most comfortable for that user on his or her monitor. Any other font size is thus by definition suboptimal for reading body text.

Relevance-Enhanced Image Reduction: Better Thumbnails

It is quite common to use thumbnail versions to represent images that are too large to be downloaded without a specific user request. Thumbnails are smaller, meaning that more can fit on a page and that download times are minimized. Unfortunately, the two most common ways of reducing images, scaling and cropping, both result in thumbnails that can be hard to interpret, as shown in the figure.

Three different ways of making thumbnails.

Scaling reduces the image so much that pictures with extensive detail wash out and become too crowded to be meaningful. Cropping preserves those details that are within the new viewport, but at the cost of losing the context of the image as a whole. Our recommendation is to use a combination of cropping and scaling, resulting in a technique we call relevance-enhanced image reduction. For example, to get a thumbnail that is 10 percent of the original image, first crop the image to 32 percent of the original size and then scale the result to 32 percent. The final image will be 0.32 x 0.32 = 0.1 of the original.

As shown in the figure, relevance-enhanced image reduction results in a pleasant balance between presenting discernible detail and conserving context.

INTERNATIONAL WEB USABILITY

They don't call it the World Wide Web for nothing. A single click can take you to a site on another continent and a business can attract customers from hundreds of countries without ever going to a Frankfurt trade show where they book you into a hotel two hours down the autobahn.

The unprecedented international exposure afforded by the Web increases the designer's responsibility for ensuring international usability. International use is not a new phenomenon: most computer companies have half their sales overseas, and several books have been published with general advice for making user interfaces more international.

Most of the guidelines remain the same: don't use icons that give your users the finger (or the foot, or other gestures that are offensive in their culture), don't use visual puns (e.g., a picture of a dining table as the icon for a table of numbers), don't use baseball metaphors (except, obviously, at baseball sites), translate fully if you do translate, and so on. This column looks at some of the issues that are specific to the Web.

A major problem is the fact that Web sites attract many international customers. We should all have this problem,you may say, but some companies are not interested in overseas business. Make it clear up front if you are only interested in serving a local market to avoid wasting both parties' time. Also, many companies have significantly different product offerings across countries, and it can be quite confusing for a customer to access, for example, Mercedes-Benz' main site only to discover that some of the models are not for sale outside Germany. Always make it clear if different models, prices, or procedures apply in different countries.

The Web and the Internet allow real-time interactions, with celebrity chat sessions and with Olympic or World Cup results posted as the events happen. In announcing any real time event, you cannot simply say that it will happen from 2:30-4:00. First, is it 2:30 in the morning or the afternoon, and, second, what does that translate to in my own time zone anyway? It may be obvious to you that nobody would put on an event at 2:30 in the morning, but if that happens to correspond to 11:30 AM in my country. Any times listed on a web page should always at a minimum make it clear whether they are given in the AM/PM system or the 24-hour system (and if AM/PM, then these suffixes should be given) and which time zone they refer to. Time zone abbreviations (e.g, EDT) are not universally understood, so supplement them with an indication of the difference to GMT. Many users don't understand GMT either, so optimal usability would involve translating the time into local times in a few major locations (e.g., "the press conference starts 1:00 PM in New York (GMT -5), corresponding to 19:00 in Paris and 3:00 the next day in Tokyo").

International Usability Testing

Because of the myriad of issues in international usabilitywe recommend doing international usability testing with users from a few countries in different parts of the world. No guidelines yet published are sufficiently complete to guarantee perfect international usability, so an empirical reality check is always preferred. Luckily, the Web makes international usability testing relatively easy.

It is possible to test Web designs internationally without ever leaving home. Since users can access the Web from everywhere, they can access your site without you having to go to their country to set up the test. One option is to place telephone calls to the users and ask them to think aloud as they navigate the site. Assuming that you can identify users in other countries who speak your language well enough for a telephone interview, this is a very easy way to conduct international testing.

The two downsides are the need to get up early in the morning and the difficulty in following the user's navigation from a purely verbal description.

A good alternative is to have staff from your local offices in various countries conduct the test themselves, even though they are not user interface specialists.

The best choice, though, is to travel to the foreign country yourself. Of course, this is expensive, but again the nature of the Web comes to the rescue. It is possible to conduct informal tests during trips that are planned for other purposes since you can pull up a Web page any place you can get to a computer. One of the results was that people didn't understand the difference between the Information button and the Documentation button. As shown by the example, international usability testing often reveals problems that could well exist for domestic users also. Other problems related to recognizing the espresso machine, though most people understood the general cafe concept which had been one of my main worries.

Language Choice

In many ways, the ideal international user interface is one that is available in the user's preferred language. Eventually, language choice will be handled by content negotiation between the user's client and your server so that the user will only need to specify a list of preferred languages once and for all as a client setting. At the moment, content negotiation is not sufficiently widely used to be a reliable solution, so many websites use manual options for language selection.

To choose between a small number of languages, we recommend listing the name of each language as a word, using each language's own name for itself. For example: English - Français. Lists of more than 7 foreign words are hard to scan, so for lists of between 8 and 21 languages, we recommend using visual symbols to supplement the names. For lists of 22 languages or more, scanning is hopeless, and the only solution is a long alphabetical list (in which case non-Latin languages should be listed twice: once in Latin characters in the proper alphabetical order and once in the true character set at the end of the list). The best visual symbol for a language is probably a flag. Icons playing on national stereotypes are possible and can be fun, but risk being offensive (not all Americans wear cowboy hats).

If language choice is supported by a site, we recommend providing a link to the choice on every single page since users often go directly to pages from search services or bookmarks without passing through the home page. Some sites put up a language choice page before the user can reach the home page, but we recommend against this if it is possible to determine a default language that will be used by a very large proportion of the users (the Louvre Museum in Paris is a good example: fair enough to start in French). Clicks and download time can be saved by going straight to a page for the main language as long as the home page has a very prominent (and internationally understood) entry for language change. Also, the pages for the various languages should have their own URLs so that users can bookmark the proper entry point and bypass language choice if they visit again.

Multi-Lingual Search

A special problem is the search of multi-lingual information spaces. If all of the information has been replicated in every language, then there is no need to search more than one language. In this case, the search interface should know of the user's preferred language and only display hits in that language.

Unfortunately, it is often not possible to translate all documents, so many sites require searches of several languages if the user needs complete coverage of the available information. Currently, multi-lingual search requires the user to manually enter synonyms of the desired search terms in all the requested languages. This is obviously an unpleasant task, and users often forget to search for translated terms, even if they understand several languages. It would be better to have the computer automatically perform multi-lingual searches by understanding the meaning of the search terms in several languages. Doing so is easier than the general problem of natural language translation (for example, the term "rock" would not normally refer to music if used on a geology site) and there are some research systems that have performed reasonably well on multi-lingual searches.

Printing

For rich or large hyperspaces, we recommend providing a special version that can be downloaded and printed as a single document. Any file that is intended for printing must be able to accommodate the two most common page formats: A4 and 8.5x11 (U.S. Letter). To do so, the width of the page must fit on an A4 sheet and the height of the page must fit on an 8.5x11 sheet, since A4 is the narrowest format and 8.5x11 is the shortest format. It is recommended to leave a margin of at least half an inch (13 mm) for all four sides of the page to ensure that it will print on all printers and to facilitate photocopying. With half-inch margins, the printable area is 7 1/4 inches (18.5 cm) wide by 10 inches (25.4 cm) tall; with one-inch margins (preferred), the printable area would be 6 1/4 inches (15.9 cm) by 9 inches (22.9 cm).

DESIGN GUIDELINES

The Rise of the Sub-Site

Web users need structure to make sense of the many and varied information spaces they navigate. The fundamental nature of the Web does not support any structure beyond the individual page which is the only recognized unit of information.

Single pages are obviously not sufficient as a structuring mechanism, and from the early days of the Web, we have advocated an emphasis on the site as an additional fundamental stucturing unit. Since a single click can take the user to the other end of the world, every page needs to provide users with a sense of place and tell them where they have landed. A recommended standard is to put a corporate or organizational logo in the upper left corner of the screen (upper right corner in countries using a right-to-left language). When clicked, this logo should take the user to the main home page for the site.

Explicit recognition of the site as a structuring mechanism is important for Web usability, but most websites are much too large for the site level to provide the only structure. Much information can be hierarchically organized, and an explicit representation of the hierarchy can be added to the top of the page to provide additional context and navigation options. For example, the intranet for the hypothetical BigCo company might have the following list of the nested hierarchy leading to the home page for the Stockholm office:

BigCoWeb -> Sales -> European Region -> Sweden -> Stockholm Office

Each of the elements in the hierarchy list should be made a hyperlink to the appropriate top page for that level of the hierarchy. Note that the name of the lowest level of the hierarchy (here, "Stockholm Office") should not be a link when displayed on the top page for that level. Even the lowest-level name should be made active when displayed on a leaf page on that level.

For information spaces that cannot easily be hierarchically structured, the sub-site can be used as a helpful additional structuring mechanism. Sub-sites can also be used in hierarchical information spaces to give particular prominence to a certain level of the hierarchy which is used as the sub-site designator.

By "sub-site", simply means a collection of Web pages within a larger site that have been given a common style and a shared navigation mechanism. This collection of pages can be a flat space or it can have some internal structure, but in any case it should probably have a single page that can be designated the home page of the sub-site. Each of the pages within the sub-site should have a link pointing back to the sub-site home page as well as a link to the home page for the entire site. Also, the sub-site should have global navigation options (e.g., to the site home page and to a site-wide search) in addition to its local navigation.

Sub-sites are a way of handling the complexity of large websites with thousands or even hundred of thousands of pages: By giving a more local structure to a corner of the information space, a sub-site can help users feel welcome in the part of a site that is of most importance to them. Also, a large site will often contain heterogeneous information that cannot all be squeezed into a single standard structure, so the ability to have sub-sites with somewhat different look-and-feel can provide an improved user experience. A sub-site is a home environment for a specific class of users or a specific type of usage within a larger and more general site.

There is a tension between the desire of the sub-site designer to optimize fully for the specific needs of local information versus the need for consistency across the entire site. Sub-sites should definitely not aspire to become independent sites with no relation to the parent site of which they are part and which should provide them with context and richness. In my opinion, IBM's new AlphaWorks sub-site is an example of what not to do: IBM has maintained a strong site identity across all their other sub-sites with a logo in the upper left corner and a tilted sub-site image in the upper right, but AlphaWorks hides the logo at the lower left and has an inconsistent style. It's almost as if AlphaWorks was ashamed of its parent site.

A good example of a sub-site done right is ZD Net's AnchorDesk. AnchorDesk provides a platform for the respected computer industry commentator Jesse Berst to discuss current events in computing and pull together recommended links to additional information from across the rest of the Ziff-Davis site. The AnchorDesk sub-site uses human editing as a guide to an otherwise overwhelming information space and has value-added use of hyperlinks to provide the foundation for the commentary.

In Defense of Print

As an online publishing enthusiast, I sometimes get ridiculed for having written a traditional printed book about hypertext and the Internet. It is an unfortunate fact that current computer screens lead to a reading speed that is approximately 25% slower than reading from paper. We have invented better screens and it is just a matter of time before reading from computers is as good as reading from paper, but for the time being we have to design our information for the actual screens in use around the world.

The reduced reading speed on computers can be compensated by good hypertext design that allows the user to read less information and to find it faster. A typical example is online help and documentation: because the information is right there on the computer, there is no need to spend time finding the hardcopy manual, and because of good search tools and hypertext links between related information, users can go directly to the one or two sections that contain the answer to their problem. After all, Nielsen's first law of computer documentation is that users don't read it. The second law is that if they read it anyway, it's because they are in deep trouble and need the answer to a specific problem. Thus, somebody reading a manual won't really read it cover-to-cover, so online presentation makes perfect sense.

Other types of information do require the user to read large amounts of text. A typical example would be the instructional materials to teach a programmer a new programming language. Users typically want to spend an extended period of time reading long texts and they prefer not having to sit at their screen while doing so. Thus, even when the reading speed problem gets solved, we may still find that people decide to print out long texts rather than read them on the screen.

In any case, our surveys have shown over and over again that users do like the ability to get long documents in hardcopy, which is why even online publishing systems need a print feature. The implication for web design is to provide printable versions of any long documents. Web browsers are slowly gaining decent print functionality, but one cannot rely on browser companies to produce well-crafted printouts since their main interest is online information. For example, Netscape and Internet Explorer both use the same typeface and font size for online viewing and printing, even though it is known to all typography specialists that the two media require different type.

My recommendation is to generate two version of all long web documents: one that is optimized for online viewing (is chunked appropriately into many files and has plenty of hypertext links) and one that is optimized for printing (has good layout and is in one piece). The print file should probably be in formats like PostScript or PDF. It is extremely important to denote any such files as being for printouts only and always supplement them with links to the same content in HTML for online viewing by users who want to browse or search a small part of the document.

PostScript and Acrobat files should never be read online. PostScript viewers are fine for checking out the structure of a document in order to determine whether to print it, but users should not be tricked into the painful experience of actually spending an extended period of time with online PostScript. We learned this lesson the hard way in one of my projects: The current release of Sun's AnswerBook documentation viewer displays PostScript windows of the same pages that are used in our printed manuals. The next version of the product will use an SGML-based content structure that allows for much nicer information presentation and searching. All our user tests of the pre-release version show tremendously enhanced user performance and satisfaction with the new product, so you have something to look forward to if you are a Sun customer.