[Home]BookMetaphor

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Hypertext written using the book metaphor has a table of contents, an index, a hierarchical structure with chapters, sections, subsections. GnuInfo is such a hypertext medium.

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?.

What does it look like?

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.

thanks for the link, I thought the WebBook? idea was neat. I especially liked that part where they took all the pages in the book and displayed them on one screen. I wonder if something similar could be implemented within TouchGraphWikiBrowser. Also, I agreed with the WebBook? folks that it is good to see animations of the pages which you flip past as you flip through. This helps keep a sense of place (in real books, at least). By the way, I don't think a sense of place is necessary just to prevent a feeling of confusion, but I do think it helps people connect ideas. It is easier to have a few things in front of you and to flip back and forth than to try to really hold both of them in your mind at once. -- BayleShanks

Size Limits?

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 example, we are as guilty as anybody for using the tired book metaphor: When we recently designed the user interface to 300MB worth of Sun's online documentation, we used a book metaphor to unify the icons, the vocabulary, and the hierarchical structure of the user's navigation. Our excuse was that the interface will display information originally written as separate printed manuals and that it would have been confusing to use a free-form hyperspace model to represent this text. There is no doubt, however, that the book metaphor prevented us from introducing desirable features like the ability to reorder the chapters according to their relevance scores after a search.

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.

If the 14000 WikiWiki pages were linearised into book form, much of the content would need to be rewritten/deleted. I suspect that would improve it. The pseudo-linear form exposes a lot of redundancy and illogic.

A good book-like organisation adds value because it presents the content in a more understandable way. I suspect "Automatic TOC Generation" tools would not add that value. It needs a human editor. A tool can merely do the grunt-work. Which is useful, of course, and might lead to more editors willing to take on the job. Just don't mistake the form for the content. -- DaveHarris

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.

Is this something we should strive for?

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.

Arguably this stuff is relative. In other words, if the same page appears into two different TOCs, it would need two sets of next/previous links.

Personally, even when reading a site that has those links I rarely use them. I use shallow HubAndSpoke navigation instead. -- DaveHarris

I think SectionedPage would be a useful framework for hiding multiple sets of next/previous links. -- BayleShanks

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"...

Automatic TOC Generation

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):

What I've done is to create two "reports" that use an outline file to then generate a "table of contents" and a "BookView?" that have the assigned section numbers.

StrikiWiki tries to structure pages (Feb 2001):

The basic idea was to add a template functionality. Every page as a form associated with it. This form describes what sections this page has. A form is just another page. As a form is basically just a list of sections everybody can make a new form.

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.

Serialization

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

On the manual maintenance of Category pages

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.

CategoryMetaphor CategoryNavigation

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: