Re: HELP! Guidelines/methodology for documenting GUI software needed

["Parks, Beverly L." <parksb -at- HUACHUCA-EMH7 -dot- ARMY -dot- MIL>]

Robert Tennant asked about ways to approach the documentation of a system
with very busy screens. He says,
>>
The approach I've taken is to put a screen shot into the manual and then
to
carve it up into "fields," describing each field in detail. I've done
this for
each screen, but I know there must be a better way; it just seems that
having
to describe a screen "geographically" is not the most efficient way.

Unfortunately, the system is not structured in a way that easily lends
itself
to documenting simple functional tasks (like How to Open Your File, How
to Do
Thus and So, How to Print Your Data, etc.). However, the whole system is
driven by screens containing buttons that the operator clicks, drop-down
menus
that contain secondary cascading menus, etc., etc.,etc.
<<

Hi, Bob.

I'm in the midst of documenting a similar-sounding system, though my
screens may not be quite as busy as yours. While I do address some
high-level, basic tasks using a functional approach, I'm documenting the
majority of the screens pretty much as you described. I call it a
menu-based approach because I address each option on the main menu bar
one at a time, from left to right; and each submenu from top to bottom
within each.

My busy screens consist of a couple of tables, some dropdown lists, some
text boxes and check boxes. As complicated as the screens look, there is
usually a standard path or approach to take to work your way through
them. I let the tab key guide me as far as what order to use to address
the different fields. Of course if it doesn't "look right" (the tab key
jumps me from a field in the top right to a field in the lower left,
skipping a bunch in between) I query the developers.

Luckily, I don't have to go into a great deal of depth about each and
every field, short of how to navigate to it and what to do with it once
you're there, because the target user set for this system is very limited
and experienced in the disciplines the software addresses (project
management and resource management).

Sorry. You asked for help and all I can say is that I'm in the same boat
with you. I'll be eager to see what other replies you get. (Though I'm
too far along in my project to change my approach, any suggestions would
sure be helpful for the next time!)

Bev Parks
parksb -at- huachuca-emh7 -dot- army -dot- mil

     Searchable archives located at http://www.documentation.com/
           ALL questions or problems concerning the list
      should go to the listowner, Eric Ray at ejray -at- ionet -dot- net -dot-