Re: Branching...Results

[Tim Altom <taltom -at- IQUEST -dot- NET>]

At 08:28 AM 6/20/96 -0700, you wrote:
>I seem to have missed this thread, but here's my two cents worth.

>I think the only good solution to the complexity problem for paper manuals
>is to make the user documentation entirely task oriented. There is usually a
>reasonably small set of tasks to describe. For each task there is probably a
>simple path or set of paths through the maze of menus and options.

>For this to work there should be good context sensitive online documentation.

>A good example of this approach is Microsoft's user documentation for
>Access. It's about 200 pages and covers all the bases. They have other
>manuals for application developers. They wrote those in a more traditional
>style.  ...RM

>Richard Mateosian                                Freelance Technical Writer

We entirely agree with the task approach, and that's what creates the
branching problem. If we were willing to adopt the old screen-by-screen and
field-by-field approach, we wouldn't have to branch at all. It's the flow
that creates the splits. One of our jobs is to reduce the number of branches
by detecting new tasks in the multiple branchings and breaking them out, so
an average task flow will have a minimal number of branches. Still, much
software isn't thought out well enough to permit the user only two or three
real decisions during a task. Often it's more, and it's the app's fault for
having functions, fields or information on scattered screens that appear in
order of some programmer's opinion, not in order of use by the user.

Our dilemma is that any branch, no matter how infrequent, is a serious speed
bump. Our goal during task breakdown is to make it as no-brain as possible
for the user...1, 2, 3, etc. At some point we have to heave a sigh and
reconcile ourselves to the inevitability of user decision-making, but we
want to make the speed bump as low as we can. Hence my question.

Our typical branch is tabular, although it doesn't LOOK like a table:

5. Press Enter.
6.   IF the tiger is behind the door
     THEN open the other door.

But that often necessitates yet another choice to close the possibilities loop:

     IF the tiger is NOT behind the door
     THEN open the first door.

Software folks will recognize the form, an IF-THEN loop. But they'll also
recognize the potential catastrophe if one condition is forgotten or
overlooked. Thus, one two-option choice produces at least two branching
decisions in the matrix. Three options produce a three-axis matrix...and so
on. If there are many choices, we may construct an actual table, or we may
create a flow chart. In any case, though, even with IF-THENs cut to a
minimum, the user will experience some small amount of drawback and
frustration. At that point, we try to point this out to the programmers.
Sometimes they even listen to us.

Tim Altom
Vice President, Simply Written, Inc.
317.899.5882 (voice) 317.899.5987 (fax)
FrameMaker support  ForeHelp support

Makers of DuoFrame, giving you online help and paper
documentation from a single parent FrameMaker document.

http://www.iquest.net/simply/simplywritten

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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