Re: Context-sensitive Help (a little long!)

[Laurie Rubin <lmr -at- SYL -dot- NJ -dot- NEC -dot- COM>]

First of all, if your users liked the help design and it was approved by them,
this is what they will be expecting, no less!  You may need to convince the
developers that the whole point here is to give the users what they want or
expect (duh!!). What's the whole point in usability testing/demoing, if not
this!!?? In fact, your user feedhback is definitely one big way how you learn
what they want or need!

Secondly, no matter how familiar a user may be with the software, there are
always new people or experienced users who may be unfamiliar with any or all
of a window's functionality.

Thirdly, I agree that you will catch up with development, or only lag behind
at tops a couple of weeks.

One previous project experience:  I was initially told that I was going
to write a windows level (primarily field-level) description (brief description
of the window, the command buttons and field (element) description). I found
that at the initial demo of the software, the users had a hard time figuring
out how to use many of the window functions.  Just giving them the field
(element) descriptions would not be enough!
So, for first round, I, too, had a window description section and "how to"
jumps
at the end of each window section. I added only a few window captures to check
user interest. During the initial usability testing, my PARTICULAR users found
it too confusing to have the pictures of the windows in Help next to the
actual windows.  They loved having the "how to" sections.
The alternative was:  I had a section for window elements in the window
description that listed only the label names for all of a particular window's
elements (field-level description).  Each name was a popup (created via the
glossary, and included description, valid length, characters, etc.).
Of course, I definitely left in the how to's. The first reference of a field
(element) in the procedures was also was a popup that displayed the glossary
description.

BOTTOM LINE, no windows, field desription popups, and how to's,  made less
confusion for my PARTICULAR users, and was easy for them to understand the
functionality of a window as well as locate a specific label name and
description.

Laurie
lmr -at- syl -dot- nj -dot- nec -dot- com

> We are creating help for a Windows application being developed
> with PowerBuilder.  We are writing the help using Robohelp.  The
> help files include How Tos (not tied into context sensitive help)
> and help on the menus and windows in the program (tied into context
> sensitive help).  The menu/window level help shows a picture of
> the application menu or window.  On the window pictures, the user
> can get field-level help in popups.
> Our developers feel that our help systems are lagging in delivery
> behind their applications.  They believe that the time it takes
> to recapture the windows pictures and tie in the field topics
> is what makes us unable to complete the help system at the same
> time they complete the application.
> Their solution is to write field-level help and tie that in.
> We tech writers do not believe that this will solve the problem.
> We believe there will still be a lag time.  We think that the
> lag time will decrease as the product stabilizes.  We also
> do not think that the users will find field level help "helpful"
> without windows-level help.  We think the developers want us
> to write database descriptions of the fields on the screen,
> rather than supplying true process help.  (BTW, you can jump
> from the window level to the how to topics related to that window.)
> Our help design was user-approved and developers also approved
> it before we started writing.