Mindless screen shots

[Richard Mateosian <srm -at- C2 -dot- ORG>]

>Guess what, guys! The students who got the doc *with* the screen
>shots took longer to perform the tasks and retained less information
>than the other two groups of students did!

I don't know why this surprises anyone.

Screen shots have become the new passive voice. They take up too much room,
convey information inefficiently, and often mask the fact that the writer
doesn't have a coherent mental picture of what the software does.

Some managers like them because they provide a metric for the writer's
performance. Count the number of screens the user can get to. Assign a
standard number of pages of description to each one. Voila, a yardstick.

"How are you doing, Rich?"

"I've finished 187 screens."

"Great. We're 50.68% done, and we're averaging 2.88 screens/day. If you can
keep up that pace, we'll bring this one in a day and a half early--pretty
good result for a 750-page manual."

A good software manual should explain the underlying metaphors of the
software's operation and its user interface. This could easily entail using
a few carefully annotated screen shots. Once the user understands the
"physics" of the artificial world created by the user interface metaphors,
screens should require no further description. The remainder of the manual
should focus on the tasks the user needs to accomplish and the support the
software provides for those tasks.

Of course this is an idealized picture, and it assumes an excellent user
interface. However, by focusing effort on understanding and documenting the
user interface metaphors, rather than on mindlessly and repetitively
describing elements of screen after screen, the writer can find and help to
correct potential usability problems.  ...RM

Richard Mateosian    Technical Writer in Berkeley CA     srm -at- c2 -dot- org