Table that spreads over multiple pages?

[Geoff Hart <ghart -at- videotron -dot- ca>]

Kimberly Thornton reports: <<I have inherited a military technical 
manual to update. I've come across a troubleshooting table that spreads 
across 33 pages!!!!! Just one table!>>

Why is this a bad thing? If a chapter can span 100 pages, why can't a 
table span a lesser range? I know nothing whatsoever about MILSPEC 
standards (not even if that's a correct acronym!), so one thing you 
need to do is confirm whether some obscure standard governs this 
format. If so, you can't mess around with it and must instead optimize 
the existing design to the extent allowed by that standard.

<<Its a three-column table that lists the Symptom, Probable Cause, and 
Corrective Action.>>

This is potentially a very clear and logical approach to presenting the 
information. The only part that seems to be missing is a description of 
how to tell whether the probably cause is the _actual_ cause. It seems 
inefficient and potentially dangerous to try taking corrective action 
before you're sure you've actually identified the real problem.

The first question to ask is whether the users find this approach 
effective. If they do, the solution is again to make the approach as 
clear as possible rather than changing the approach; for example, 
ensure that the column headers repeat on every page, and that the order 
of the topics is effective. For example, you said this is a military 
application, so the logical order might actually be something like 
"which problem could kill me fastest if I don't solve it immediately?" 
That suggests the order of topics should be designed to support the 
reader's survival.

<<Obviously this table needs to be broken up into something more sane. 
My first thought was to break up each Symptom into individual sections 
and create a table that just lists the causes and corrective actions. 
However, many of the Symptoms have multiple (five or more) Probable 
Causes and the Corrective Action for many of these causes have 
procedures with at least 10 steps.>>

On the limited evidence you've provided, I'm not convinced that the 
current design is a problem. However, the fact that symptoms have 
multiple potential causes suggests that the optimal design would be a 
decision tree or flowchart. That way, you present the symptom, followed 
by branches in response to questions that help the reader narrow down 
the potential causes. Truly efficient flowcharts can be difficult to 
create, but extremely effective if they're well-designed.

The final step in the chart leads to the actual procedure. Since a 
10-step procedure won't fit well in a small box in a flowchart, that 
final box should probably say something like "Install replacement 
battery (details on page 10)."

<<Has anyone else dealt with this type of issue? How did you handle 
it?>>

I handled it by creating a dichotomous key (one in which each decision 
point had only two possible branches), but I was working with 
biologists who were intimately familiar with this kind of 
decision-support tool. I'm not sure whether there's any usability 
advantage to a purely dichotomous key; on the face of it, it seems to 
me that branching to three or more points would be more efficient for 
the user, particularly if they must backtrack after choosing the wrong 
branch. This is one of those things that usability testing would 
demonstrate conclusively for your specific context.

<<It would probably take an act of God to get a new manual approved and 
I only have til September 12 to update the document.>>

That being the case, it probably makes more sense to stick with the 
current design and try to optimize it. Once that's done and you've met 
your deadline, propose a new design and ask for permission to test it 
with the actual users to see whether they prefer it to the old design 
(less important) and find it more effective (most important).

--Geoff Hart   ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl

WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l 

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.