This page explains what a forward index needs in order to be useful for visitors.
See also: RoadMap explains why starting with a forward index might be a good idea if something is on your mind but you don’t yet know how to start writing.
Casual visitors to the site don’t know what the site has to offer. When visitors arrive on the front page, they need to know what the site is about, and they need to see a few interesting links to follow. When visitors arrive on any other page, they want to explore by following links. Since the visitors are new, they will get lost.
Therefore, visitors need navigational aids.
At the same time, wikis should be simple to edit. We want a low barrier-to-entry. A complicated edit page with a large number of fields to complete is daunting. A simple edit page does not offer sophisticated ways of entering metadata to organize the site.
Using metadata to organize the site introduces “black magic” as the structure changes indirectly depending on the metadata you provide on the various pages. Experienced users are used to this, but new contributors are confused.
Maintain the site structure manually by building the forward indexes on the front page and the category pages carefully.
Use descriptions in addition to page names in these indexes so that visitors have enough information to choose which link to follow. As they follow links from the front page to a category page to an ordinary page, they are gradually narrowing in on their target page. As they read what the site has to offer at every step, they can make meaningful choices and appreciate the existing content.
A search box would have been far more frustrating in this situation, since visitors knows neither what the site has to offer, nor do they usually know what they might be interested in.
Since the main purpose of a forward index is to offer meaningful choice to a reader at every level, be careful not to list too many items. If you have more than ten items, try to find whether you can group them. If you have several groups already, move some of the groups to a new page: Start a subcategory.
A TableOfContents in a book or at the top of a page is forward index.
Maintaining a forward index is sometimes considered a chore. See AutomaticForwardIndex for some thoughts about maintaining such a forward index automatically.
The discussion of whether a forward index is a good idea for category pages is happening over on CategoryCategory.
PeriPeri’s implementation of DublinCore-with-implications (see PeriPeri:FacetWiki+PeriPeri:RdfForWikis) creates an automatic TableOfContents with the Abstract of each page. An author can also supplement this with an explicit ForwardIndex TableOfContents, which will have any missing links appended.
I’m wondering if calling pages CategoryThis and CategoryThat is really a good idea. I’ve often times wanted to link to a list of related ideas, and internally thought “That’s ugly” as I try to work the word “Category” into the page name. The trade-off is that you lose the quick identification- “This is a category page.” – LionKimbro
I think you are right; the “Category” prefix is not mandatory. The naming convention just helps us differentiate between “content” pages and “helper” pages – namely category pages without any content acting as a “canned searches” via their page title. When we use category pages with a forward index and short summaries, however, there is no need to mark the page as “helper” page; the forward index makes the page a “content” page in its own right; the importance of the canned search is diminished, and rightly so. – AlexSchroeder
Since adding the DublinCore MetaData pattern to PeriPeri, I’ve found myself dropping the “Category” prefixes as I rework the site. It’s interesting that PageClusters aren’t prefixed by “Cluster” on this site, either. It seems the visible indication of “meta” information is all that’s wanted. – ChrisPurcell
Good point. Then let it be thus: No more Category prefix. – AlexSchroeder
The Category prefix may have been a case of premature optimization.
However, I believe we have here a case of FeatureCreep, of the perfect being the enemy of the good, and perhaps not too little of technocratic hubris. The wiki concept transcends any single implementation of the idea in any single WikiEngine. Backlinks are an essential element to the implementation of the wiki concept. Their use in implementing indices via the category mechanism is cheap and robust both in terms of code implementation, learning curve for new users and for non-software-expert content maintainers. It is portable from WikiInstance to WikiInstance, from WikiEngine to WikiEngine. Idiosyncratic implementations of a ForwardIndex are not, either in terms of the underlying technology nor of the social understanding necessary to implement them.
On the other hand, I never used backlinks as a wiki newbie. These days, I just use them when I want to fix typos or do other maintenance work. Using a search is just not useful enough without good ranking.
I don’t use back-links either, here or on Meatball. Again, from my PeriPeri experience, once things get a little more integrated - one visible link away, not two subtle ones - maintaining indexes becomes more natural. After all, they’re always visible.
However, I suspect a side-effect will be my maintaining much smaller indexes, and increasing both width (more top-level indexes) and depth (more intermediate indexes). This may be a benefit or a curse - depending on how it works out.
Maybe I am in the minority, but I actually do find myself using the “backlinks” in wiki, when I am in a “reading” mode, anyway. I still think it’s useful to have some form of way to “tie” related pages together, although I don’t know what the “best” solution is (liek “category” or some other method). After experimenting with RdfForWikis a bit, I have to say that I really like the “annotation” approach,and I like the exportability, but I realize that is maybe a minority viewpoint.