Re: Using tables for content

["William Sherman" <bsherman77 -at- embarqmail -dot- com>]

This is a style that was once known as a Definition List. You wanted a clear 
cut view of Term - Definition or Task - Result and you wanted it neat with a 
clear straight line along the leading edge of the Definition / Result 
column.

Now a DL is not an option in most list formats. You could simply use a 
numbered list and format it with a tab at halfway across the page, but if 
either task or result is longer than half a page, the wrapping will mess up 
the look.

This style allows a person who knows little about the task to perform the 
task. There is a task. There is an expected result. How many times have you 
run a procedure and wondered if things were going smoothly as you had no 
idea if what was happening is what should be happening?

It also was used in ATPs, where you had a task and an expected result to 
confirm or a place to enter results of that test step.



I think the Mercedes example is a poor way to do it not because of using the 
table but rather the writing inside the table. I've read lots of service 
manuals and they are much easier to read than this even using a similar 
layout.





----- Original Message ----- 
From: "Slager Timothy J" <Timothy -dot- Slager -at- dematic -dot- com>
To: "Sean" <seanb_us -at- yahoo -dot- com>; <techwr-l -at- lists -dot- techwr-l -dot- com>
Sent: Friday, October 25, 2013 11:00 AM
Subject: RE: Using tables for content


The company that required us to put steps in a table also required that 
steps be broken down to their lowest level. Sean's example below would have 
been:
 1.   |    Click File.   |   A dialog box opens.
 2.   |   Click Open.   |   The file opens.

For every action, the expected result is listed. A bit wordy, but utterly 
unambiguous. In many (most?) cases the third column could be ignored, but 
it's there, just in case. I suspect the format also facilitated testing of 
the software.

------------------