People who want to learn more about computer technology and solve
problems they encounter on their systems currently have a wealth of
forums to turn to: mailing lists and newsgroups, official and
unofficial documentation (which may be distributed on the Web, on
their systems, or in printed form) and the more collaborative media of
IRC channels, wikis, and virtual worlds.
Why tamper with this set of resources? Because they are not as easy to
find or to use as they should be. Each medium was invented for
purposes other than the specific task of educating computer users, and
have never been tailored to the tasks of generating and searching for
information about computer systems. If relevant material was served
through more specialized and helpful tools, people might create better
information and it might be used more.
In a recent
blog on the Radar site,
I suggested two tools that could help improve the quality and
findability of information. In this blog I’ll expand my view a bit and
suggest a whole new information-sharing environment.
Let’s fantasize about a new system that combines the best features of
a wiki, a FAQ, a mailing list, an interactive tutorial, and
stand-alone documents in order to provide special features that
enhance users’ ability to find answers to their questions.
Start with a wiki organized hierarchically by topic and containing a
series of FAQs. As with a newsgroup or mailing list, anyone could add
a question to the FAQ. Others could then fill in answers using the
wiki software.
Questions often duplicate earlier questions. For instance, suppose
someone asks how to add an icon to a desktop. Someone later asks how
to start an application from the desktop, without realizing that this
is essentially the same question as the one asked earlier. The tool
should make it easy to combine the two questions, and to subdivide a
question into constituent parts.
Each question can have a unique ID, so that answers can be linked and
viewed together. The ID also makes it easier for questions to refer to
other questions, which is often necessary because users need to put
more basic changes in place before fixing the symptom that led them to
the site.
For instance, the answer to “How do I filter out redirect requests on
my router?” might be start, “First, refer to the question on how to
filter ICMP traffic,” which in turn might start, “First, refer to the
question on how to set up a new filter chain.” If a question is a
common one, obviously, it would be someone’s time to string these
answers together and integrate them into a single coherent document.
The tool should be organized as a set of APIs that could be embedded
in other tools. Users would have access to all its features through
any entry point of their choice: from a web browser, from a
stand-alone program on a desktop system, from any IDE whose developers
chose to provide an interface, even from Emacs. It should also be easy
to print sets of content; sites could then offer to sell
print-on-demand copies.
Now imagine an API that made it easy to offer specialized windows with
different purposes related to community education. Often, a person
posting a question has several parts to the question: the text of the
question, some sample source code or a part of a configuration file,
output or error messages, and so on. It should be easy to put these in
separate windows that were linked so that the question could be viewed
as a whole, but with easy comparisons. For instance, particularly
lines of code or configuration directives cause certain output to
appear; links between these should be easy to draw. Links to bug
reports should also be easy to insert.
Authors who notice widespread interest in a certain topic can extract
the answers and make stand-alone web pages that are maintained within
the wiki.
Using one of the tools I have
already proposed,
users can suggest pathways through the documentation–this is,
different documents that people with particular needs can read in
order. For instance, users could be advised to read a background
document or guide to configuring the system before tackling one of the
utilities that depend on this background and configuration.
The “push” feature that many people like about email is reproduced by
wiki watchlists; users should be able to learn within minutes of
changes via email, IRC, or RSS. A source control system could preserve
all versions of the wiki material for historical purposes.
We should aim this tool at developers as well as users, particularly
because users sometimes turn into developers. They may submit bug
reports, contribute to the core technology, or create new tools at a
higher layer. Databases of bug reports, bug fixes, and feature
requests could be linked in. When someone asks “Does the program do
XYZ?” it could either be answered by a “Yes, here’s how” or be
reclassified as a feature request. A question that can be solved
through a cumbersome procedure could also generate a feature request.
Wikis tend to disguise the contributors. But one of the most powerful
motivations for contributing documentation is recognition. People want
to be known for their documentation so they can compete better for
jobs and contracts, gain readers’ trust for their pronouncements, and
just enjoy basking in praise. So it would be worthwhile to try to
label a document with metainformation indicating the percentage
contributed by each author. This is hard to automate, unfortunately.
Limited recognition should be given for changes that look extensive
but come down just to fixing grammar and misspelled words. And it’s
complicated to determine how much credit to give someone who restores
information that was removed or incorrectly edited by someone else.
To summarize, a community education environment should include:
-
Easy access for adding questions and editing both questions and
answers -
A suitable division of material into different types
-
Extensive linking that not only helps people find information, but
shows them a variety of pathways through related documents -
Support for combining questions, dividing questions into subquestions,
and extracting material to make stand-alone pages -
Recognition of authorship
-
An API that can be incorporated into tools of the users’ choice
-
Push technology for people who want it
-
Source control
-
Integration with bug reports and feature requests
-
Print-on-demand
Done well, this system would make it fun and rewarding to
contribute information to user communities. People searching for
answers would be more likely to find and understand them, reducing the
need for the time-consuming hand-holding that takes place on
forums. When novices do need help, they’d encounter a structured site
that’s well suited to submitting their questions, and the answers
could quickly be generalized into resources of value to others.
In fields as fast-moving as modern computing environments, we need
tools like these in order to free up developers for the work of
development. The result will also enhance a key goal of all projects:
to recruit new users and make them comfortable using the system.