Re: Problems Documenting An Application

["Dan Roberts" <droberts63 -at- earthlink -dot- net>]

to supplement John's statements, remember that the user objective is not to
see a screen, but to *do* something. The user could give a rat's
hindquarters about the name of the screen <panel? window? dialog?> that
opens next; they just wanna have fun--err, get a task accomplished (sorry,
flashback time). So if option 11 is the first thing they must do, put it
before option 1.

Honestly this is truth. I've got an app in which option 8 (or something)
comes early in the process of using the tool. The programmers just stuck it
in at the next available slot. And options 1 and 2 are stuffed in the back
of the book, cuz they're just customization stuff.

well, that advice and 0.50$ will get you a cup of coffee...

-----Original Message-----

>Screens and the screens that are spawned from screens
>can be arranged in an outline form.

stuff snipped...
>Since it was a windows application, I started with the
>first item on the screen menu (e.g., File, Edit, Go,
>Communicator, Help)


>Maybe instead of organizing the screens by the order
>they appear in the interface, you might consider
>ordering them by their functionality. However, one
>thing I always do is right in the beginning, explain
>how to get to that screen all the way from the
>"Primary" view of the application.


>--- pbw3172 -at- yahoo -dot- com wrote:
>> I have been tasked with documenting an entire
>> application by myself.
>>
>> My problem is that this application has SEVERAL
>> screens and I don't know
>> where to begin.
>> I figured that if I
>> divided the manual up by
>> task (screens) based on the main menu options, it
>> would be easier to
>> document.