menu bars and site maps

general points about menus

I have always believed that links are the second most important bit of a web site. (The most important is, and will always be, the actual text.) Links are the one unique aspect of the communications medium that is the WWW. They are what turn your disconnected pages into a site, and they are what turn all the disconnected sites out there into the truly worldwide web of interconnected information. As described in the printed booklet for Web Design, they're far from a perfect implementation of the idea of hypertext - but they're a start, and therefore, they should be concentrated on by all web designers.

The question is, how should links best be presented? In the ideal hypertext document, they would appear dotted through the text, where ideas presented on other pages were being referenced. But there is a lot to be said for collecting links in one place as well. (These are not mutually-exclusive alternatives - you can easily do both in the same site.)

A site with a lot of external links would benefit from bringing them together on a "links page". This makes things easier for the user - it also makes things easier for you, the author. External links need maintenance, as other pages often go out of commission. If your links are all in one place, that task is made easier.

But it is also helpful to have internal links collected together for each particular page on your site. As described in the printed booklet, the structure of your site is an important factor in its usability. Deciding which page links to which, and why, can make the difference between a helpful site and a confusing one. Here is where the menu bar comes into its own. Menu bars make it clear to the reader where they can go from any given page. They guide the user, and do so subtly as well. And there are many different ways to create menu bars, with each having the potential to attract the reader's attention. You saw a menu bar at the top of this page: another, similar mode of presentation would be to use a list, like this:

• general points
• using forms
• site maps

This might all seem a bit unexciting, but don't underestimate it. The advantage of retaining text-based menu bars as opposed to image-based ones is that you know these will still be visible under text-only conditions. So for all it might seem tempting to craft lovely graphic buttons or rollover images to highlight your links, this can often be the safest method. And much of the most famous graphic design (such as the Bauhaus) was far more interested in text, symbols, lines and layout than pretty pictures. Think about it...

Of course, many sites do have menus created from images: the front page of the Leeds Uni site being an example (the "About" and "For" menus). You may, or may not, decide to include rollovers in such a menu. The ultimate determinant of whether you do this or not should come down to the issue of usability. When designing your image-based links and menu bars, always ask yourself, does this make my site easier and friendlier to use?. Visual impact does matter - image-based links stand out from surrounding text. They therefore add emphasis to that most unique characteristic of the Web, the document's links to other points in cyberspace. But as always, if used gratutiously or without thought for the end user, they will more likely obscure and confuse. Tempting though it is to start spreading buttons and other image-links all over your sites, do always sit and think about these issues beforehand.

Back to the top

using forms

Form buttons and drop-down menus (selection boxes) can both be exploited to vary your presentation of links. With buttons, What we want to do is add an onclick event which causes the browser to load another page. Add the event as shown underneath to each button (only one button shown for clarity), and bingo, you've done it. These are actually more robust than image links, as you don't actually need to download an image to make them work; no need to worry about those browsing with images turned off, then. The main disadvantage is that, as you can see, it's quite hard to control the size of the buttons with any precision, and therefore to get a tidy-looking page.

<form action="">
  <input type="button" value="Multiple windows"
  onclick="window.self.location='subj_newwindows.html'">
</form>

Drop-down menus are a little more complex, but not that bad. However, they do make the link unusable by anyone using a keyboard to browse; in other words, to those who cannot use a mouse for whatever reason. You must supply other means of reaching the content if using this method.

The code for that menu is as follows. Note that the "onChange" JavaScript event in the long second tag should not be broken between two lines like this but should be entered in a continuous string of characters. I had to break it below to make this page fit on the screen, but ensure you glue the line back together in your code.

<form action="">
  <SELECT name="jumpto"
    onChange='window.location.href=this.form.jumpto.options
    [this.form.jumpto.selectedIndex].value'>
  <option selected="selected">Link Menu...</option>
  <option value="subj_newwindows.html">Multiple windows</option>
  <option value="subj_frameset.html">The frameset document</option>
  <option value="subj_noframes_tag.html">The <noframes> tag</option>
  <option value="subj_framelink.html">Links in frames</option>
  <option value="subj_iframe.html">Inline frames</option>
</select>
</form>

A few observations, which may be obvious but I'll make them anyway - first note that you can use this for any type of link: internal, external, anchor or whatever. Secondly, note that you can change the link showing in the "window" when the menu is first seen by moving the "selected" attribute in that list of <option> tags. The first, "dummy" option does not have to be there either, but is easy to remove (or indeed put back in). Make sure your readers know that the menu is a list of links. As links are not often presented like this they may not realise, so be very clear about it.

Quite a few sites these days are starting to use drop-down menus to present links, but these are usually programmed with Java (a fully-fledged Web programming language of which JavaScript is a relative). The disadvantages of Java are that, first, it's difficult, and second, not all browsers are set up to view it. This method isn't so sophisticated, and its appearance can't be tailored so easily. But it's pretty simple, and even quite antiquated browsers should be able to cope with it. However, as noted, there is always the problem of keyboard-only browsing which must be accounted for.

Back to the top

site maps

This is very much a section under development. What I mean by that is that I've not really investigated this topic thoroughly, and nor do I think that it's discussed in any systematic way in the web design literature. I'm therefore open to suggestions here and/or knowing about any useful examples you might have seen yourself.

When you play an adventure game, no matter whether it's computer-based (Half-Life has to be the all-time classic here) or something like Dungeons and Dragons, exploring the "labyrinth" is part of the fun. On the other hand, being lost in a big, unfamiliar city is no fun at all. In each case, a map will help your wanderings enormously - as of course will big signs saying "This Way To The Dragon's Lair!" (or similar).

A good menu, and clear and helpful links, should act as the "signposts" of a web site. But there's no reason why you can't provide visitors with a map of the whole terrain as well. In effect, that's what the Subject Index and A-Z Index on this site are - particularly the latter. A site map shows the whole site at once, so people know what's there before they start browsing.

This idea may strike you as rather pointless, for two reasons, both of them quite valid:

• "My site's only got half-a-dozen pages!" In that case all you need is a well-crafted menu. A site map would only seem necessary on large sites where a single menu would be too unwieldy.
• "If I'm going to all the bother of following your three-click rules and thinking about my site's structure in such detail why should people need a map?" Another good point. But sometimes people arrive at a site wanting very specific information. Your site's particular structure may just not quite match their needs. For example, this site is basically designed to be read in order from lecture 1 to lecture 10. But if someone arrives wanting a little bit of information on, say, the <area> tag but isn't familiar enough with the site (or indeed the tag) to know straight away that it's on lesson 7, they might rather have a different index - a map, in effect - that tells them how to get straight there. And that's why the A-Z Index exists. What a nice guy I am.

As to how you might best provide such a map - well, I'm open to suggestions. The worst way to do it would be to use a graphics package to draw a fantastically complex diagram of all the pages and links and then simply plonk that somewhere on your site: a classic case of "information as an image". At the very least you need to make the map active, that is, allow people to use it to jump straight to a given page.

Here's an example, for instance: a map to a small fan site devoted to a random celebrity (note that not only is the celebrity purely hypothetical, so's the site: these are "real" links, but they won't go anywhere):

Doing a map like this, incidentally, might not be a bad idea for you as a designer... it could show you when your structure is illogical, and get you thinking about your site in systematic terms. It might also serve as a useful list of all the pages, so when you come to do updates, you remember them all.

Google has quite a good site map at http://www.google.co.uk/sitemap.html - this will open in the second browser window. Google also offers another possibility here, the site search facility, but I must admit that despite trying for a while I have never been able to get this to work. Reports welcome: perhaps I am missing something obvious.

Back to the top

Back to the menu for lesson 10