T + - - - - - - - - + 1
- _ |
- _ |
- _ |
- _ |
+ 2
Although this creates a triangle, topologists (unlike geometers)
don't care about the lengths of the links, or the angles between them...
only that there are three nodes, and that each is linked to each.In a hypertext, these three nodes will be documents, most likely a table of contents and two 'chapters'. In this simple case, the names for the links are fairly obvious (notice that they're different, depending on their direction):
<- [Up] or [TOC]
[Ch1] ->
TOC + - - - - - - - - + Ch1
- _ | ^
[Up] - _ | [Prev] or [Prior]
[TOC] - _ | [Next]
[Ch2] - _ | v
+ Ch2
Among these simple navigation buttons, the 'Previous' button is the
most problematic. Imagine that you started at TOC, but chose to read
Ch2 first, because its description interested you. When you were done
there, you might want to go back to TOC, which was the previous page
you'd been reading... but the Prev button will take you to Ch1 instead!
Mosaic and Netscape both offer a constant interface button that takes you back to the last document you viewed. The browser can do this conveniently, but (as far as I know) HTML will not allow you to create your own button that will do this. (You have to specify an HREF when you create the button, and HTML can't change it 'on the fly'...)
I'm experimenting with 'Prior' instead of 'Prev' because I think it might be slightly clearer wrt (with regard to) this ambiguity.
Another option is to allow the Next button at TOC to lead to Ch1, and the Prev button at Ch1 to lead back to TOC, since these are the likeliest interpretations. Similarly, Next at Ch2 could lead back to TOC (when there's just two chapters), though Prev at TOC should never lead to Ch2!
(Is it better to omit the Next button if there's no next, or is a No-Next button-- perhaps a greyed out Next button-- a better option?)
Jutta Degener (Germany) suggests Prev/Next/Up/etc buttons should normally include some additional description of where they'll lead you. This seems like a lot of work, but surely a helpful gesture...
TOC
From Ch1p1, you can offer both an Up that leads to Ch1, and a TOC (or Top) that leads to TOC. (The practice of separating the table of contents from another, title page seems undesirable to me, as a rule.) (Also, be careful with Top that it doesn't look like 'Top of this file/doc'. Don't put it at the bottom of the page, I guess...)
On the WWWeb, the convention is that the TOC of all TOCs is called 'Home'. Should every page then have a Home button as well? This could get excessive, so probably, in cases where you have entire subhierarchies under the home page, with their own TOCs, each page needs only to point to its own TOC, which should then point to Home.
(More confusions can be added on the WWWeb, when someone's link from outside drops readers deep into the subhierarchies of your trees.)
TOC1 JB bio
Maybe if readers become more sophisticated, generally, it might suffice to display some 'flag' when you've crossed into a different hierarchy. If they understand the flag, they could just be careful to use Back instead of Up.
As HTML evolves, we should expect that browsers will 'understand' these conflicts, and might 'grey out' buttons when their meaning has changed.
Here's a catalog of nice button-sets you can use on your own pages. Let me know if you've got a set to share.
The ultimate in chaotic linking on the Web is probably the HyperDiscoridan bible. There's a mechanically-generated map that gives a hint of its scope (notice that individual pages are multiply represented here, though.)
A few hours on the WWWeb should initiate almost everyone into the second generation, where it's recognized that minor links need to be incorporated into the text, 'in line', to avoid the water-torture fallacy.
For informational sites, I think two or three screenfuls of information is about optimal, if they're richly linked. Less linked material can be longer.
For long sequential presentations, the option of downloading the full text as a single file is highly desirable.