TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I'd listen to the writer. If, as he says, each screen/task set is accessed
from many different places, then the sequence in which steps are performed
(or whether some steps are skipped) may very well depend on where the user
came from. If that's the case, then numbered steps would misleadingly convey
a rigid sequence.
More relevantly, why, within a particular screen, do you think there must be
a prescribed sequence in which the user fills in/selects the paramters
values required to carry out an action?
In mostcases, the task sequence for an individual screen reduces to:
1. Fill in/select the required parameter values in any sequence that appeals
to you, just so long as you don't overlook any that are required, don't
enter any invalid values, and select the correct options for the action you
want to perform.
2. Click the Apply button
Adults do not like to see simple tasks (e.g., filling out a screen) reduced
to a rigid series of numbered steps. We don't think that way, because it's
not necessary or natural to think that way, and we don't want the
instructions in the manual to tell us to do something a particular way when
the "way" doesn't matter.
The fact is that, in many software products, most of the relevant task sets
are above the screen level (i.e., the task consists of accessing several
different screens in a particular sequence). In such "supertasks", the
actions the user performs in each screen depend upon the particular
supertask being performed.
In the early '90s, I developed a comprehensive hypertexted,
context-sensitive on-line help system (thousands of pages) for an extremely
complex mechanical engineering program that performed finite element
analysis of mechanical parts. The program had well over 1500 screens. Many
of those screens were designed to reflect the results of a rigorous human
engineering analysis. That analysis found that the Action-Object-Method
approach (hereafter called AOM) was best. That is, the engineer says to
him/her self: "I want to perform this action on that object, using this
method". Consequently, high-level screens had, at the top, three menu
buttons to select the desired AOM. After these selections were made, a
second-level screen appeared that showed the parameters that had to be
entered in order to carry out the selected AOM. In many cases, the same
second-level screen was used for two or more AOMs, but there would be subtle
differences depending on which AOM was being performed. These differences
might include different options available on some button menus, grayed-out
parameters, or parameters whose allowed value range changed. Documenting
each variation of such second-level screens was neither feasible nor
desirable. We found a solution that proved to be very successful. That
solution could not have been used if we had been told that all information
about a screen had to be reduced to a series of numbered steps.
==========================================================
At 08:06 AM 4/25/00 -0500, Stephen C. Gillespie wrote:
>Dear Techwrl'ers:
>
>I need your help to settle an argument with a writer in our group (yeah,
>I'm the editor!). The issue is with bullet lists (versus numbers) for
>all procedures in a software user guide.
>
>The manual is packed with discrete little tasks, each connected to a
>screen in the system. The problem (IMO) is that all steps are bulleted
>(vs. numbered).
>
>I maintain that each task MUST have (some kind of) sequence, i.e.
>proceed (usually) linearally to its end - the goal of the task (i.e. why
>the user wants to be there in the first place). Of course, I'm fully
>aware of the variety of style found in documenting complicated tasks:
>conditional action; also nonsequential action: continuous,
>time-dependent, and concurrent (see "Procedure Writing: principles &
>practices." Wieringa et al. Coloumbus: Battelle Press, 1993 for an
>excellent study).
>The writer, a long-time purveyor of the information set, argues that the
>information (specifically each screen & task set) may be accessed from
>'so many different places and points in the system,' that there's really
>NO SEQUENCE AT ALL.
====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory -at- primenet -dot- com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo -at- omsys -dot- com with "subscribe framers" (no quotes) in the body.
