Navigational tools for websites

Published: Wednesday, 31. May 2000

A navigational tool is everything that offers a user help to navigate (beside of the URL input field and hyperlinks within a text – which usually are placed by the author manually). So there is a good chance that on dynamic web sites these tools are generated automatically by the system. Developers of content management systems should design their systems to offer easy ways to use these mechanisms. This article explains a number of common elements from a design perspective.

Some basics

As one can easily imagine, there are several ways to create order within changing content, so that a user may find his way.

Here is a very abstract list of the categories, in which information can be organized somewhere between the starting address of a web site and the actual parts provided by the writers:

by numbers (lists)
alphabets (lexica)
topology (encyclopedia)
geography (maps)
time (calendars and archives)
graphs and diagrams (combination of the above)

These categories derive from the inner structure of data itself – and thus are not invented for the web. But the specific issue for web content – of the kind described above – is that it is delimited by pages. Whenever you try to find navigational tools for this specific (but very common) kind of content, you are considering tools for jumping from one page to another.

All navigational aids should follow three principles:

1. they should provide information for orientation

2. they should be easily distinguished from actual content

3. their function and their role in the overall site content should easily be comprehensible

Of course pages is not the only concept for splitting content on the Internet – but for now, I am going to talk about just this kind.

These tools include:

pages as such (and how to split them)
in-page navigation
sequences of pages
tools to flipping pages in sequences
information about a page
chapters
overviews
related links
branches in a site hierarchy
main navigation
global functions

A page

Since the invention of frames it has already become hard to define what a page is. It may be an item which has content split into pieces, although the user may not consider what he sees as being split up. That basically is a real problem, because it is undermining the basic concept of the URL, which is supposed to be an unique locator for a resource. With frames, you can’t locate a resource with a single URL anymore. To solve this technically, a site developer could create an abstraction layer in between a URL to his/her server and a possible frame set. It is hard to maintain this – even with a CM system because of the fact, that usually the browser shall request and reload just parts of the frame set.

I’d like to go beyond that specific problem and talk about some conventional items, one can find on many web sites. These may have become a kind of standard by common use. In any case they may look very different, while they belong to the same class of navigational tools.

I want to reverse the order by not starting with the main navigation beginning of the starting page – a thing which is addressed by all CM systems – but with the navigational aids at the smallest piece, which is often needed and not addresses by many systems:

Navigation within a page

Many sites prefer longish pages. Sometimes a good reason for longer pages might be, that the author expects that users will print the information before reading. Each page consists of chunks, which are listed in a little table-of-contents (TOC). This in-page-TOC is often somewhere in the beginning of a page, so you can see, what the page is about and also may click on the TOC-items to instantly jump to that chunk without having to reload the page. The only possible problem here is, that this feature fails, if a page is not loaded completely yet or the user interrupted the loading process by hitting the stop button of the browser.

Some sites also provide little markers at each chunk, to scroll up and down to the next chunk with a click. While this somehow spoils the users expectations (clicking is definitely not considered as scrolling), a very common item is the “back to top”-link at the footer of a page. This is helpful, if other navigation options (like the main navigation) have vanished out of sight by scrolling down the page.

Splitting a story into pages

Many CM systems consider a story for the author as being a page for the user. This correspondence causes longish pages and sometimes problems in structuring the text into chapters, which can be read in a different order while there might be one order the author suggests. CM systems often do not have tools to define where a story could be split up into several pages. This would also automatically create the need of a system which maps the story in the database to several URLs – each reflecting one of the pages.

The main issue here is, that the author might want to edit the story as a whole, while the presentation of the story may deal with the loading time (relevant for the user) and also the possibility to jump into specific sections of the story or article.

A very good example of this feature are the articles in the Webmonkey.com magazine:

navigationaltool

I should say, that a very common reason for splitting a story is not convenience for the user but also the demand for placing as much banner ads as possible and for increasing the page views on a site.

For a designer it is crucial here, that the user identifies the sequence as such and has a understanding about the length of that sequence. For that reason only putting a next/previous-flipper is by far not enough.

Flipping pages

Whether you have a way to automatically split stories into pages or wether you want to package a bunch of unsplit stories into a sequence, you will need a tool for the user to flip through that sequence.

There are several ways to do that. One is to provide next/previous links. Another possibility is to simply add a link to the next page at the end of a page. You can also provide a list of all pages within that sequence (you can see the latter two here). Some sites have a combination of a list with a next/previous-link, for example webreference.com uses it in it’s columns:

Per-page information

Whether or not you have a story split into pages as sequence, or you see a story on a single page, a page – by definition – has a title. In the case someone makes a bookmark or he wants to link the page, he/she should be able to name the destination of that link correctly. It would be perfect, if a user could have a chance to see, that he is sent into a sequence/chunk of a story, or to the story itself (associated with the first chunk of a sequence).

So the title is a very important piece of information and used for orientation – if it is intended by the author or not.

Because it is very difficult to name pages according to this requirement, pages often are accompanied by a subtitle – which may only be used on the page itself (and not on overview pages for instance).

Chapters

Chapters may be considered on different levels. The way it is meant here, it is addressing the possibility to group stories and articles together – wether those are split up into pages or not. A Chapter is something where the author may define such a group by editing the list and the order of stories which belong to it. The contained stories in a chapter may be written by different authors and as of this fact they can easily be distinguished from the order of chunks/pages within a story written by one author.

The title of a page is commonly placed in a kind of page header, which has then to be clearly identified as such. It should also be easy to distinguish the title from the name of a chapter the page might be in.

Overviews

Chapters often are reflected in a kind of overview pages, which provide a list of available stories within. Again webreference.com may serve as an example.

It is very important to mention, that overviews like these may be of two kinds: automatically generated and a written/authored overview – or a combination of it.

The issue here is that users should get information on any level of the site. For instance a chapter on cnet.com is not only providing a list of contained articles, but is also a place where specific information is presented, which is solely created or arranged for this kind of overview.

Overviews are also a common place to draw a users attention to another information, which he/she did not intended to look for. Because of the generalizing nature of overviews, it should be clear to the user which part of the overview represent a deeper navigation into the content (thus maybe following the direction of navigation he may already be in) and which links are just sideways or even jump-offs totally different places.

Breadcrumbs & hierarchy

I case a site is organized in a tree-like manner (and most sites are) the site structure may be several levels deep. A user needs to see the branch he is in.

It would be absolutely impossible to get an idea about the sites overall offerings on this page if there would not be a path on the page showing where in the site the user is currently in.

This specific example has absolutely no other helpful navigational tool related to the site structure that the branch path, because all other links are links related to the story or are dealing with the general offerings of CNET.com.

Such a branch (or breadcrumb trail) sometimes ends with the title of the current page (not clickable) and sometimes just with the parent item of the current page. In any case – clicking on the last hyperlinked item, should lead to a page that contains a prominent link to the current page – maybe in some kind of overview or list. As a matter of this concept, the amount of items in the branch may reflect the amount of clicks a user may have to perform to get to the page within the site tree.

While the branch navigation often is very subtle on the page, it’s permanent presence through the different chapters and levels throughout the site makes it a very important piece of both navigation and orientation. Users have a clear understanding, that a site is organized in an hierarchy, while it may well be, that clicking links could jump between brachnes without going up&down these branches all the time. That’s the nature of hypertext. But users can really profit from this concept if you add hierarchical means of orientation. Without these, users wouldn’t even know they jumped within your site!

Main navigation

Usually a main navigation is something which is rather stable within the site and so does not change. It offers a permanent link back to the homepage and it reflects the most important pieces of the site as a whole.

It should not be too detailed and should also not require more space as necessary, otherwise its formal importance conflicts with other navigational tools.

Changes to the main navigation

To a certain extend the main navigation may change. CNN.com has a main navigation to the left, which changes only once it is clicked (don’t look at the rest of the navigational tools there yet please!).

The left column changes a second time if you select a subcategory (e.g. world > europe) but then stays in that condition as long as you are not leaving that section.

A rather bad example of a changing main navigation is scripting.com. This site actually has no main navigation at all – but the user does not know that unless he is a regular visitor of the site. The links to the left are a kind of “related links” referring to other sites with similar editorial approaches. The actual “main” navigation is the calendar on the right side, because scripting.com is a daily diary of a single person – and so the content is just ordered on a timeline. Users may consider the column beneath (named “UserLand”) as the main navigation, but clicking that leads to different sites, which have a invisible relation to scripting.com – one has to know that the author of scripting.com is the president of UserLand Inc. to understand why this box is there.

Global functions

While all the navigational tools (except the main navigation in my view) may only present on specific pages of a site, some “functions” should be available anywhere, because they are not directly related to the structure:

1. Search

In the case the user may perform a full text search on the site (which he should be able to), it has to be clear a) what options he has to refine the search and b) what the scope of the search is, if there is any.

2. Index

Indexes are usually very hard to do. Mostly because they represent a intellectually selected and constantly refined list of words, which may be of a specific relevance to the visitor because they deal with the particular content of a site.

3. Site maps

Site maps often provide a visual overview about the site. Like the other text based overviews above there are mainly two groups of site maps: automatically generated site maps and manually designed maps.

While the automatic version deal with change very easily, they may not be very good representations of specific meanings within the structure. Manually drawn maps usually consider the users pre-knowledge about the site and find a optimal representation. Usually manually crafted maps demand much effort and so many sites avoid this special kind of map.

Very often site outlines are called site maps as well, but they reflect the site tree as a list and often look more like indexes than maps.

4. Language change

Many sites provide content in different languages. I propose, that in very few cases – even on the worldwide big corporate sites – the content is 1:1 the same in all languages.

One of the very few examples I found which has a 1:1 translation in all languages is Inter Nationes – an institution communicating cultural information about germany. In this very specific case it makes sense to provide language changes on all pages.

Commonly a user decides the language by going to the specific top-level domain (e.g. http://www.apple.com vs. http://www.apple.de) or he can decide upon language on one of the starting pages.

Very few sites offer a context based change, where language options are available in the case translations are there. Usually the problem here is that according to the level of difference between the languages, the overall site structure may be very different as well.

5. Print version

A printer-friendly version of an article is not a navigational tool per-se, but it is related to the way an author may want to split an article into pages.

As already said above, some sites make longish pages in order to make printing of a single article easier – one might be able to print a complete article by a single print command.

This conflicts with the need to have rather short fragments for navigation in a hypertextual manner. Therefore many sites provide printer friendly versions, which contain the article in a way specifically designed to be printed on paper. These versions often do not include the navigational tools anymore, but may add some easy-to-read information for finding the electronic version in the web later on (such as an human readable URL, which is rather easy to type).

If there is a printer-friendly version, the question of splitting pages or not can be freely considered as a question of best display on-screen.

Conclusion

Many content management systems do not offer a full set of components to provide the tools explained above. If they do, these components often have very few options for applying designs and style to them. From this perspective, software developers who create such content management systems should consider the above tools as relevant for the system as a good control over the text itself might be.

Surveys have shown, that many users directly head for the site search feature or even go to a big search engine and limit the search to the site they want to get information from. This seems to be more productive than navigating the site with the provided navigational aids.

This behavior – in my opinion – is provocated by a general lack of navigational tools in websites. If there would be a technically more sophistacated approach to provide these without hassle users would potentially find their way through a site if not the “overall style” makes it impossible to clearly identify the navigation aids.

Prof. Dipl.-Des. Oliver Wrede