Get back
I’ve already spoken at some length about links and the use of images as icons. That’s because navigation is crucially important to whether or not your site works. Most of the time, links need to be clear about where they lead for users to find their way around the site.
One shibboleth I’ve come across frequently is that “users need to know where they are”. I think that the truth of that depends on what you mean. Users don’t always need to know precisely where they are in the entire structure of a site. What they do need to know is where they are in relation to what they want to find, and possibly in relation to the point they entered the site.
Sometimes even that can be quite a complex matter. Some sites, but not many, are linear — that is, arranged first page, second page, and so on until the last page. When you are in the middle of the sequence, the only way you can move is “forward” or “back”.
Most sites are more complex, ranging from linear with links between non-adjacent pages through hierarchically structured sites to full-blown webs with every page connected to every other. Sometimes sites are mainly hierarchical or web in nature with a section — a gallery, perhaps — which is linear.
Users don’t need to know the precise details of where they are in relation to every file in the site (and an attempt to do that would probably be overwhelming). The things they need to know are: What are the main options from here? Where is what I want likely to be? How do I get back here if I want to?
One answer to that last question is to use the back button. That assumes a back button is present, which might not necessarily be the case. An instruction to use the back button looks amateurish. Often a web designer will want to provide a button which will take the user to the “previous” page — even with a back button, this might be more convenient.
What, though, was the “previous” page?
That question is at the root of why links labelled “back” or “return” or “previous page” or whatever are a bête noir for many Web gurus: maybe the user did not come from the page you expect.
The nature of the Internet means that users can arrive on a site at any page. You may design a site with a clear logical sequence, but that doesn’t mean users have to follow it. The criticism of “return” links makes sense: you can’t return to somewhere you haven’t been before.
Of course, Web users aren’t stupid, and I doubt many assume a page exists in vacuo with no logical connection to another page. I don’t think I ever had any problems with a search engine putting me on a page where the “go back” link sent me to a page I hadn’t seen — I immediately recognised it as something akin to “see previous page” in a book.
On the other hand, clarity of labelling always helps the user, so why not use something like “first part of this article” or something similar? If using images as links, a left-pointing arrow tends to suggest “go back” without too much ambiguity.
Supposing, though, you are not sure which page the user might want to return to. Perhaps you have an example or illustration which is referred to by several pages. One answer, of course, is to provide links to each of those possible pages. This does mean extra work in adding a link every time a new reference to the page is created; and it is always possible the user might not be clear about which link is the relevant one.
Even if you make the links very clear, the user may have gone to that page looking for a specific item and not paid too much attention to details like the page title. Faced with several links, they may not know which refers to the page they were on. (Remember, not all systems can display visited and unvisited links differently.) Sooner or later, the idea occurs: Can I make a link which does the same as the back button?
This is possible — in fact, easy — but is generally frowned upon for the good reason that this is not what users expect from a link. Think of the confusion if someone has just arrived in your site, clicks such a link and is returned to the search engine!
However, in a very few instances, such as that mentioned above, you might think the technique worth using. One avantage of the technique over using a link to the page in question is that the user will be returned to the point they left that document rather than the top of the page — this is more convenient.
A disadvantage is that the technique is dependant on JavaScript working: if the user has disabled it, it won’t work.
The answer to this is not to call the JavaScript link from the href attribute, but use an onClick event handler, before the href attribute, which will activate when the mouse button is clicked on the link.
If JavaScript is not available, then the href attribute will send the user to a page of your choice. This is something you don’t want happening if JavaScript is available, so the onClick event attribute is placed before the href attribute, and, after the parent.history.back() instruction, return false is used to stop the execution of any further commands from that tag:
<a onClick="parent.history.back();return false" href="firstpage.html">[back]</a>
Most of the time, this is not something I would recommend, but very occasionally it would be useful. It is a good idea if you do use it to provide ordinary links to either the page(s) in question or to the site’s home page or the top page in that section of the site. That way, if the link sends the user back to a search engine, they can still find their way to the rest of the site.
© DC 2000, 2001. All rights reserved.
