Long summary-visual presentation of information

[Norma Shulman <Norma_Shulman -at- BOSE -dot- COM>]

Date    6/29/94
Subject Long summary-visual present
From    Norma Shulman
To      techwr-l

 Subject:              Long summary-visual presentation of information
I asked these questions:

While writing manuals for consumer electronics products (of varying complexity)
, we are developing alternate approaches for presenting the installation and
operations instructions. Please help us expand our knowledge of the options
for presenting this information and methods for measuring our success or
failure.
Can you suggest any sources of data or references? We are interested in
references to books, articles, research, and examples of manuals. Do you have
any personal experience working in a visual format?

*************

Thanks to Tammy, John, John, Brad, and James for their informative replies!

*************

From: Tammy Williams, williams -at- oclc -dot- org
I don't have any experience with developing systems, but I have a  suggestion.
Contact Gateway 2000. I recently purchased a computer  from this company. The
computer arrived with a program that is a context sensitive help sytems that
describes the computer. The progam is divided into three parts. The first
describes the ports and slots as seen from the rear of the computer. The
second describes the buttons and lights located on the front of the computer.
The third describes the ships, slots, and other major parts of the motherboard.

Information for contacting Gateway:
Gateway 2000
610 Gateway Drive
PO BOX 2000
North Sioux City, SD 57049-9907

*************

From: john -at- atrium -dot- com (John Gough)

1. The DOD did a huge amount of research into this area (partially due to the
decreasing rate of literacy in recruits). I don't have any direct citations.
This would be a pretty major library project, but it's the way to go. I
believe I also heard that Caterpillar Inc. was producing visual instructions,
ostensibly to service their international market while minimizing the cost of
translations. You could try to find someone to talk to there.
You should try a university technical library; the public library probably won'
t yield much.

2. Methods for testing the usability of documentation?
Microsoft has a usability lab; maybe someone can connect you to someone there.
My own experiences have been in companies that like the idea but are unwilling
to fund it, so what I've done or supervised personally has been very ad hoc.


There are two really useful approaches:

1. USER PROTOCOLS
Assemble a set of test subjects that resemble your intended audience.
For each user:
Give the user a set of assigned tasks and the book. Sit in the room where they
do the tasks and observe their behavior. If they can be cued to talk about
what they're thinking, so much the better. Allow  them to ask questions only
if they cannot figure  out what to do.

The monitor keeps notes on every item that caused a user to reread, make a
mistake, or otherwise crinkle their brow.

At the end of the test, interview the user to get suggestions.

2. TIME TRIALS
This method consumes many more resources and can yield less interesting
information, but if it's combined with (1) you get some good hard data.

In addition to the qualitative recommendations.

1. Test a group of subjects on one or more discrete tasks. Time each task.
Use whatever qualitative information you can get from post-task debriefing to
improve the manuals.

2. Retest.

3. Use statistical analysis to determine if there has been significant
improvement or deterioration in task performance.

4. Repeat until the doc is good enough. You decide what is good enough.
Sometimes it comes from outside influences (e.g., "a user needs to be able to
clean and  reassemble a gadget in under 10 minutes"). Sometimes  it comes from
comparing similar task-completion times  to a competitive product (this is a
motivation in  user-interface design). Sometimes it comes from nothing more
than setting aside a fixed amount of time to do something to improve the
product.

A professor at University of Washington (Seattle) teaches seminars in
usability testing, but I don't have her materials handy. [see reference to
Judith Ramey below]
*******
Sender: "JPMartin1" <JPMartin1 -at- aol -dot- com>
Subject: Re: Visual Presentation of instr

1. Use of flow charts, charts of functions, icons, and other visual forms for
presenting installation and/or operations instructions for a general consumer
audience?

2. Methods for testing the usability of documentation?

Here are several excellent texts on these topics:
        The Visual Presentation of Information
        Designing the User Interface

Additionally, you might want to check with Prof. Judy Ramey (ramey -at- u -dot- 
washington.edu), an expert in usability testing. In fact, she's just been made
an STC Associate for her work.

*************

From: Brad Mehlenbacher

1. Use of flow charts, charts of functions, icons, and other visual forms for
presenting installation and/or operations instructions for a general consumer
audience?

I would strongly recommend getting a copy of the journal, _Technical
Communication_, 40 (4), November, 1993. It's a special issue on visual
communication and has articles on computer graphics, typography and  color,
video script design, and graphics use in computer documentation.  In
particular, I'd strongly recommend Bill Horton's "The Almost Universal
Language: Graphics for International Documents."

Horton is also the author of a popular textbook: Horton, W. (1991).  _
Illustrating Computer Documentation_. NY, NY: John Wiley & Sons.

And finally, a book that I've not yet read, but that received a good  review
in the STC journal is Wileman, R. E. (1993). _Visual  Communicating_.
Englewood Cliffs, NJ: Education Technology Publications.

2. Methods for testing the usability of documentation?

You might to check out something that I presented last year and that  received
a fair amount of positive feedback (and received 'most innovative' of the
conference's refereed materials--forgive the obvious pride). The citation and
a brief abstract are listed below:

Mehlenbacher, B. (1993). Software Usability: Choosing Appropriate Methods for
Evaluating Online Systems and Documentation. SIGDOC'93: The 11th Annual
International Conference Proceedings. NY, NY: The Association for Computing
Machinery (ACM), Special Interest Group on Documentation, 209-222.

Article copies can be obtained from the Association for Computing Machinery (
ACM) Order Department, P.O. Box 64145, Baltimore, MD 21264.

ABSTRACT: The objective of this paper is to bring users to the foreground of
on-going system and documentation development efforts by doing five things: (1)
 outlining nine methods to elicit user reactions to software;(2) describing
how to design informal usability tests employing each method; (3) discussing
the strengths and weaknesses of each method given the time and resource
constraints facing technical communicators and software designers; (4)
recommending times during the software development cycle, when certain methods
are particularly fruitful in providing valuable design feedback, and; (5)
providing an extensive bibliography on usability testing methods (66
references).

Brad Mehlenbacher        Phone: (919) 515-4138
Assistant Professor      Fax: (919) 515-1836
Technical Communication E-mail: brad_m -at- unity -dot- ncsu -dot- edu
English Department       Fortunately, your NEW BABY is a fully
NC State University      lap-size model (Martin Baxendale, 1989,
Raleigh, NC 27695-8105
****
From: James Brandal <jb -at- VINGMED -dot- NO>
Subject: Alternative way to do paper manuals.
Traditionally, manuals had text only. Even today, some still have this.Reading
this mailing list tells me that many of you have changed this slightly. You
have text and graphic inserts I assume.
We document ultrasound scanner systems and in our company we have five years
experience with another method. Our manuals are loaded with pictures, screen
captures and drawings with short instructive text inserts that portray the
exact way to use our systems.

If anyone would like to know more about how we do this, and what our
experiences are, please feel free to reply and I will do my best to answer you.


From: jb -at- vingmed -dot- no (James Brandal)
Subject: RE: alt. way to do manuals

The main positive effects we have logged after changing from the traditional
method to our new method are:
- Users are reading our manuals, they did not do it before.
- Users have obtained a high level of correct system use knowledge very fast .

- Manuals have played a decisive role in system sales.
- Customer support on system use has dropped to nearly zero.
- Because users know our systems well the on-flow of implimentable system
improvement suggestions has increased vastly.

As mentioned previously our products are basically Ultrasound scanners. In
addition to these we develop and produce Diagnostic application programs that
can be run on Mac's and PC's, which communicate with our scanners.

We work on Mac's and have an own developed tool which allows us to connect a
cable between a composite video output in the scanners and an interface in our
Mac's and allows us to display what we are doing on the scanner screen on our
Mac  screen where we can screen capture stepwise scanner operation with a tool
called Snapjot  (have you heard of it, it is very good).

Our application programs run on Mac's  and PC's and we can also stepwise
capture picture from these as we use them.  To capture elements such as
keyboard and control panel use, we take pictures with a camera or video camera.
 Camera pictures are scanned to files on a HP document scanner and with video
film we can also stepwise capture the handling.

All pictures that we take are automatically named and stored on our hard disk.
These picture are put through Adobe photoshop to a fileformat and size, that
can be used in our manuals, by a macro, developed with a program called Quick-
keys. We often start the macro when we leave work to go home for the evening
and in the morning when we return the pictures are ready to be moved to a
large 1GB network disk where we have all our manuals and pictures.

All our manuals are Framemaker books with eight main sections. Each section
has a number duplex 10-page files (max size datawise for spooling area on our
network when printing). Some sections are common to many books and we have
only one storage of it controlled by conditional settings in 46ramemaker.Our
Page Format is A4 (21cm wide x 29.7cm high). The files a re a basic designed
templates where the pages have odd margines, header and footer areas, heading
area and an information area which we turn gray. Onto each page we normally
import by reference 2 pictures, the start of or part of a procedure. We create
a title which defines uniquely what is happening on this page. We look at the
pictures once and determine what we need to add to the pictures to make the
user do this step correctly. This is the text part.

To do the text part, we first of all insert a number of white bubble frames
with a black edges. Onto these we insert text frames, reset their font size (
in our case helvetica, 14pt., bold, to be viewed at 2 meters distance) work
out short, concise and easy read instructions (many of our users have english
as their third or fourth language). To eliminate any doubt ot what is to be
done at this stage we e add heavy black arrows with white edges from each
bubble to the exact place on the picture we are talking about with the text.


With thee automation in framemaker each page title is included in an
automatically generated table of contents. Thanks to contributions on this
list, from experts on the subject, we have been able to automaticaly create
professional indexes, after manual marking, where each page can be found in
minimum three different ways. The structure of information in each book, is
based on knowledge of user variations, and how our users should, and would,
use our systems and applications.

In short we have structured the book in a way that portrays their normal way
of use. We print our manuals on a QMS 2000 printer in the network which also
serves everyone else in the company. We update them, picture and text wise
each time changes are made to the user interface. To translate these manuals
to french and german I cooperated with two friends at distributers in France
and Germany who had sound knowledge of our products but no knowledge of Frame
or Mac. To make it possible, I made a"how to use frame on Mac and traslate our
manuals" manual. To illustrate effectiveness of this method,the French friend
translated our largest manual in his spare time and got it back to me in
Norway in less than 4 weeks. The cost side of this should be visible from the
above but I am open for more questions on the subject.