Andy Roberts posted some questions about designing Frequently Asked Questions (FAQ) pages to a couple mailing lists and to his blog, multiple page FAQs. Specifically, he was looking for advice on structuring long FAQ's:
I’m thinking about FAQ documents, and how to structure them when they
start to get large and unwieldy. The use of wiki technology can allow
this to happen sooner than it used to.The problem I first identified is to do with the trade-off between
individual page size and excessive navigation, which seemed at first like a web development problem. But there’s also the knowledge related problem
of not wanting to set up overly rigid categories by defining the
individual pages, which would then tend to become fixed.
He is specifically thinking of doing this in a wiki (MediaWiki), but the larger question of how to structure these things is important to consider as well.
FAQ's originated from discussion groups, both mailing lists and Usenet. As a community became established and new members would arrive, they would have very similar questions over time. As with anyone else who gets tired of answering the same questions over and over, a community would decide to put together a list of frequently asked questions to assist both the new members and those who were looking for quick answers to a question. One of the beauties of a FAQ is that they are browsable, so if I don't know how to word my specific question, I can punt and browse through questions that seem to be related. There are many other aspects to FAQ's, but they have continued being a helpful aspect of knowledge sharing in communities.
But how to structure them? As Andy Roberts says in his post, there is the simplest method of creating one, long document with each entry being listed down the page as they come. At some point, the community adds more structure to the list by grouping related topics and, at some point, adding a table of contents. At some point, the FAQ document gets too long for comfort and the community struggles on a mechanism or structure to split the FAQ into reasonably-sized chunks that aren't too big and aren't too small. But with splitting the FAQ comes the issues of where does a specific entry end up, and the guaranteed added complexity of maintaining more than one "thing" that comprises the document. There are plenty of useful tools to make this easier, but the concern still remains. Andy Roberts is tackling the problem before it strikes, which is probably the best time to do it.
Here's one mechanism that appeals to the engineer in me, assuming the technology is available and the community is amenable. The basic description follows the tenets of content management: separate the content from the display of the content.
Each FAQ entry (each Question-Answer pair) should be an individual "thing" somewhere (a database entry, a file, a wiki entry, an XML pair, etc.). At the most basic, there is just the Question and the Answer for each entry. But one quickly sees the need to help with organizing the content, so additional metadata should be applied. This can be done by applying a category or taxonomy to the entry, or by allowing more free-form tags, or a combination. Depending on the community and the type of knowledge being archived in the FAQ, the entries may explicitly fall into multiple categories. In an electronic universe, this should be no problem. For more complexity the community might want to know when this particular entry was last updated, by whom or even its history. (This starts sounding like a Wiki or other content management systems.)
Once you have the information in the form of these entries, it is then up to the tool to manage how the entries appear for reading and browsing. It should be able to pull up all entries, or all entries in a given topic area (category / tag). Even better would be tools that automatically provide a list of entries just by their "question," which in this application is the title of the entry. And these question lists should be refinable by topic as well. One could imagine requests for "most recently updated" or "most popular" all fitting within the responsibility of the display end of the application. (That assumes "popularity" information is stored somewhere, of course.)
In the end, however, it all depends on the community. Do they have a complex enough set of questions and answers that it demands more flexibility? Do they think the FAQ will continue growing? And most importantly, are there people in the community who are willing to do the work, either on a long document or the kind of approach (and tool) I suggest?
UPDATE: Fixed url for "content management."