Designing a Help System

Question

I'm implementing a help system for a desktop app (Win32) and am looking for how to go about designing it.

What kind of structure should a help system have, what's actually helpful for the user? e.g. Should the help system be a big list of FAQ's (office 2010 help seems to be like this)? or should it be a Feature list documenting and describing what everything does (This is probably only helpful if the user is not sure how a feature they already know about works)

What kind of knowledge should I expect the end-user to have? It's probably slightly demeaning to write into the help file that File -> Open Project Closes the current project (if present) and Opens an existing project.

What I'm looking for here is some guidence, a set of features any good help system should have and a method of organising the topics in a way that users can find them.

Answer 1

"Open project" can also be a good place to put a reference to the definition of a project, and other more general descriptions and procedures relating to opening of projects.

In general CHM help is accessed either via context sensitive help (which is the typical for the file->open case) and via the general table of contents, fulltext search and indexes. Most recent apps seem to only create one help page per container (a dialogue, or pullodwn menu), where they list all the items on that screen (e.g. by annotated screenshot) and not a lemma for each item (checkbox, menu entry) in the GUI. Less clutter and navigation, and many points only need a fairly short description

Besides context sensitive help, one can also browse the help via the help system.

A CHM is pretty much a bit like an e-book, with a table of contents (TOC), index and optionally support for fulltext search.

The index and fulltext search are ways for the user to search for content. The main difference is that the index is more under your control, and the fulltext search is largely automatic when enabled.

The TOC is a treeview of nodes that act like the TOC in a book, and should fixate the general structure of the "ebook". FAQs are typically an appendix in this TOC.

Besides this, there is a default "entry" page, which is like the homepage of a website. It should navigate users to the most commonly searched topics.

Be careful by comparing to Microsoft products. They sometimes use systems that are not available for end-users/developers yet.

Good help uses all these elements.

Answer 2

There are broadly two styles of help: reference-based (i.e. what does this checkbox mean?) and task-based (how do I achieve XYZ?).

You're probably best off creating a task-based tutorial first, backed up by a FAQ if necessary.