Re: How much is too much? (Long, as usual)

["Elna Tymes" <etymes -at- lts -dot- com>]

Kevin McLauchlan wrote:

> I heard/seen people claim that any more than 5 (or 9)
> numbered steps is too many, and the procedure should be
> broken down into smaller chunks.  Hoo-boy! I'm well into
> the twenties and still going, here.
>
> I've also heard that explanation has no business in the
> middle of a numbered list of steps.    Hmm.

<detailed explanation of the problem snipped>

Wow! You have yourself a difficult problem, and part of your problem is the
interface.

So first, is it possible to have the interface redesigned so that there are
some "safe" breakpoints?  What you're describing is a long process, possibly
several hours, that must be run correctly and without stopping and if not,
results in dire consequences.  That's just plain poor design. Normaly people
just can't do long processes without either breaks or opportunities to correct
mistakes.

That said, however, sometimes our task as writers is to write around/compensate
for poor GUI design. And that may be where you're stuck.  If so, here's what
I'd suggest:

You're smart to try to warn the reader about the need for care in executing the
steps, and for reading everything first. And you're right that most people will
ignore those warnings.  However, you can keep trying to warn the reader.
Something like a colored warning box every so often might get their attention.

Second, try to organize your procedures into manageable chunks, each with its
own introduction and ending.  And introduce the chunks with an overall
description of how things flow and where there can be deviations or variables.

Third, if there are things the reader has to think about before doing, try to
present that up front, in a kind of assembly-worksheet area, so that all that
pause-and-think activity has been done before starting any of the processes.
One example of a procedure like what I suspect your reader has to go through is
knowing the IP routing number, the type of connection, and other transmission
data that needs to be assembled before starting to configure a machine.  Most
good configuration guides have a worksheet area where that information is
assembled before starting the actual configuration process.

There is no hard-and-fast rule about the number of steps per chunk.  But a good
rule of thumb is no more than 10 per chunk.  And most places allow some
explanation in the steps themselves of what you're doing, although it's smart
to also do a lot of that explaining up front, before starting the procedure.
However if your reader doesn't have time to stop and read before the process
times out, then you'll have to deal with the explanations up front.

Probably most important of all is a good roadmap as to what your chunks do and
in what sequence and where there's variation.  It's a little like planning a
road trip - SOME of us anyway <g> like to consult a map before we start, so we
can figure out where we're going.

The program designers, however, really need to give the users some fail-safe
mechanisms, and it doesn't sound as if they have.  If there's any latitude at
all in their design, see if you can get them to provide some safe escape
routes.

Good luck - you're certainly going to be earning your keep on this one!

Elna Tymes
Los Trancos Systems