TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
On Wed, 12 Jun 1996 Tim Altom <taltom -at- IQUEST -dot- NET> wrote
> We've often had occasion in software documentation to describe
> tasks that weren't linear...that is, there are several possible
> paths the user can take, depending on the data he enters and
> conditional branching that such data can force. For example, a
> user might start with a preliminary entry screen and type
> "medical student." Since medical students need a whole different
> set of fields than law students, a Medical Student window opens.
> There, the user enters "first year medical student." Yet another
> branching occurs. And so on and so forth.
> Now, we've solved the problem of describing branches in two
> basic ways: with a diagram, and with an if/then table. The first
> works for all users except those who are diagrammatically
> impaired (and there are many such). The second works for almost
> everyone, except that it requires more thought and isn't as
> amenable to simple recognition.
> Does anyone out there have other clever ways to lead the user
> through functional branching? I've sought better ways in the
> Journal and in textbooks, but we've yet to find anything that
> isn't just a refinement of these two basic approaches.
Of cause there are other ways, it depends on what your problem really
is!? As technical writers we very often tends to focus on "how",
instead of starting with "why" and then through "what" go to "how".
Why at all *describe* if the way through the software is self
explaining? That is documentation for the cause of documentation,
not to help the reader, because the reader don't need help, and is
more likely to be confused than helped. If you get a good market
research questionnaire, you don't need a manual for how to fill it
in with a diagram of all the branches. You might need some
explanations for the single question, and that is preferably placed
with the question. If it is a large text, it could be referred to
e.g. an appendix.
So what is the user's problem here?
1. I want to find my way through the menu tree to the order "xxx".
Solution: index to a page reference or the menu path itself.
2. I need an explanation of a function.
Solution: index to a page reference.
3. ???- I really can't imagine more basic user problem types - please
help me!
"Index" can be a sort of diagram (preferably with page references),
an if/then table, or an ordinary alphabethic index.
If the manual is on-lne the references should of cause include the
possibility to jump to the reference.
You are welcome to write me directly on the specific problem.
Greetings from Denmark
Peter Ring
PRC - specialist in user friendly manuals and quality measurements on
manuals.
prc -at- pip -dot- dknet -dot- dk http://www.pip.dknet.dk/~pip323/index.htm
- homepage on user friendly instruction manuals with tips for
instruction manual writers.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net
