The book metaphor is a good structuring device for things that will eventually be printed such as manuals. It is also a nice metaphor to use for a small web site because people know how to navigate a book: Check the TableOfContents, check the index, page forward, page back.
The EmacsWiki had a script that allowed you to download the entire (UseMod) database as a texinfo file, which can then be compiled into GnuInfo (or into a DVI). It no longer works because of BitRot?.
The book metaphor in hypertext is one of those paradigm crossing phenomena. People wrote hypertext in a book format because it was a familiar structure to them. However, now that the dust has settled, it's pretty clear that the book metaphor is one of the best ways to structure hypertext. It presents the information in a logical, linear flow. People like reading things in a linear flow. In fact, one of the biggest complaints with hypertext is that it isn't linear.
Hypertext adds to the traditional book the concept of "active references." That is, instead of saying "Eggs work really good in cake as well. (See Chapter 12. Cake.)" you can now say "
<A HREF="Cake.html">Eggs work really good in cake as well.
</a>". Even this is aggravating because it doesn't explain to the reader where the link is going. It's even better to say "Eggs work really good in cake as well. (See
<A HREF="Cake.html">Chapter 12. Cake
</a>.)" -- SunirShah
This "See ref" format suggests that some page names should look like chapter titles rather than phrases you might use in normal text. -- DaveHarris
If you want to know what someone thought it looks like in VirtualReality, read the [WebBook project] from '96. Bizarre stuff.
The benefit, therefore, is the increased usability for end consumers. It's easier to read for them. That tells us something about the end users, not about the content. Just because it is easy to consume doesn't mean that the form is more appropriate. Is it imaginable that the 14000 WikiWiki pages are presented in one book? Even if printed, 14000 pages will not be printed in one book. They will be spread over 30 books at 500 pages or less. The 30 books will then be available at a library. Each book will focus on a particular topic or subtopic. The BookMetaphor is only useful for book sized things.
There is support for it in the AntiMacInterface:
For large collections of pages, the connected graph continues to be the only metaphor available to us. However, the BookMetaphor can be used to structure local space in a connected graph. The OtherHypermedia page seems like a good example. It structures the page space in a star shaped pattern. Hypermedia pages cluster around it. It's not a book, yet. But given a proper introduction and a proper discussion, it might. See ForwardIndex.
Good point. The automatic TOC generation will fail when there is content redundancy, when summary pages are missing, when introduction and discussion sections are missing. Maybe all we need to improve usability for a Wiki, is a script to detect these weaknesses? That would mean that generating a TOC is not really necessary. Checking wether all the information for a potential TOC is available, however, would be nice:
A way to cluster related pages and determine whether one the pages might serve as a summary page. Check whether the summary page actually offers anything beyond a list of links (assume the extra text to be a discussion of the links). Find pages with similar content and suggest mergers.
That still doesn't tell us whether using the BookMetaphor for something like the SoftSecurity page is appropriate and/or desirable at all.
The elements of SoftSecurity are independent of each other, yet they are connected. It has a nice TOC. There is no keyword index, however. The subsections do not connect in a linear fashion using previous and next links. The pages linked do not themselves contain further subsubsections.
Let me ask another question, then: Should we use the BookMetaphor to structure pages on a Wiki? Would usability improve?
Based on a Table Of Contents it would be possible to link all the pages with next, previous and up links, it would be possible to provide chapters, sections, subsections. I still don't know whether this makes something like MeatBall or WikiWiki better in terms of usability for end consumers.
The BookMetaphor is the best way to build a book because a book is essentially linear. Having links in a book (table of contents entry/index entry --> page number) is handy to navigate the stream. However, hypermedia can be more fluid. Especially when it isn't static content, like a wiki. And as you know, it's hard to maintain a table of contents for a wiki (ala StartingPoints). -- SunirShah
On the EmacsWiki this was easy, because StartingPoints is the same as CategoryCategory. As long as the category pages list some of their children in order, the children can be ordered that way. It is only the children belonging to the category but with no link from the category page (the ones getting "adopted" in automatic TOC generation) that cannot be ordered.
Striving to maintain these page lists manually is good because it facilitates navigation for other users. Searching for back links is slow, while reading a menu on the category page is fast. The menu on the category page can also offer a few additional words about the page being linked to.
Having automatic TOC generation might motivate some users to actually add the meta information required: Add a category tag to new pages, and add a link to the new page from the category. If their new pages do not make it into the TOC, they get listed as "not included"...
Anybody interested in writing a script that scans through a HyperText and tries to write a Table-Of-Contents as if it were a book?
Some people seem to be working on this.
TableOfContents uses a manually created outline (Feb 2001):
StrikiWiki tries to structure pages (Feb 2001):
This is not what I was thinking about, however. I'd like a TOC generated for the entire Wiki, automatically. I think it should be possible to create the TOC automatically using some heuristics or other.
Here is how the EmacsWiki works. Note that the EmacsWiki was created long after using Categories as a tool was invented, so for the EmacsWiki, StartingPoints and CategoryCategory are the same. Furthermore, the EmacsWiki category pages usually have a small introduction, and they list many (certainly not all) of the pages in that category in a simple unnumbered list.
Here is an older suggestion:
For an example on trying to find page clusters, see the IndexingScheme list. The AccumulatedRandomWalk seems particularly interesting.
Well, maybe WikiExport?. I've worked out how to pull wiki pages into IFRAME components, cross-server even. That only whetted my appetite. Now I'd like to do a search (Category search works nicely), select the list of hits, paste that into a magic box, and click a link and get all the selected wiki pages concatenated into an HTML file. Or select just one wiki TOC page, and have all the child pages built into a big HTML file (few problems with link translations), something like the Print Book option in Amaya. I crafted a Perl script to do that with a directory of HTML files, to pull the files together into one that can be opened in Word for printing, but I can't figure the wiki way of doing it. Maybe I should concentrate more on daydreaming and less on programming, since I am clearly much better at the former than at the latter. -- JerryMuelver
While manually maintaining the list of contained pages on the Category's mainpage, it takes discipline not to miss one of the subpages. Therefore combine the manually created and annotated list of pages with a list of pages which link back to the Category index but are not listed in the manual part. This "list of unlisted pages" can then be used to fold additions back into the manual part and annotate them. To improve incentives to do the actual folding, the list can be reduced to "Currently X unannotated pages in this category" with a link to the listing.