I looked at the page on the dynamic help for WF5, et al.
One of the difficulties with dynamic help systems is difficult in
finding what you are not looking for and don't already know. By
definition, there is no static structure to work with.
Because it is dynamic, previously viewed items are indistinguishable
from new or altered items.
Also, because it is dynamic, there is no stopping-off point, so no maps
of explored regions are possible.
This makes it unlikely new features or functions will be found.
It is better to have a static document core with time-noted/time
search-able links to dynamic content. The static part presents topics
according to how the software was intended to be used, with the links to
changes and additions. Being time search-able is a key element, so that
one can easily see items added or altered after the last visit.
While I understand costs are involved in creating a usable manual, it is
costly to software users if they don't have a place they can find
information that is new to them. With books, there are bookmarks; one
can skim chapters that are presently useless, but may find application
in the future; one can add meaningful annotation.
Dynamic documents can be a good reference, but they are not as good a
way to communicate what must have gone through selection committees,
design concept reviews, code reviews, software and user lab testing on
the way to the end user. At some time there were presentations that
showed what function they wanted to do and how it was to be done. A copy
of those, together with an index, would be a good document basis.
Another difficulty with dynamic help? How do you learn in advance of
installing it how to use the software?
The opposing case is that few users read the manuals anyway; choosing
hunting and pecking to figure out how to use the software, and losing
design time.
Dave S.
