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.
This makes sense, but why not use a numbered procedural table without a
header, rather than a numbered procedural list? Don't you agree that
that procedural layout separates the information better for the reader
than a numbered procedural list?
Best regards,
Mats Broberg
Technical Documentation Manager
From: Yves Barbion [mailto:YBarbion -at- uni-learning -dot- com]
Sent: den 2 september 2005 11:04
To: Broberg, Mats; TECHWR-L
Subject: RE: Procedural layots
Hello Mats,
this is a nice coincidence, I had a chat with a colleague about
this this morning.
I'm in favour of simple numbered lists (1, 2, 3, ...).
Various reasons:
- We, the tech writers, indeed have to make a distinction
between procedures and processes as infotypes (and change our style of
writing accordingly). We cannot expect from the reader that he/she
should make the same distinction. To him/her, it's just a sequence.
- The only visual difference between a step/action table and a
stage/description table as defined by Information Mapping (IMAP) is the
text in the cell heading (apart from the style of writing). Again, the
reader just sees a sequence of events, he/she doesn't care whether they
are steps (in a procedure) or stages (in a process).
- Localization: the terms "step", "action", "stage",
"description" have to be translated as well and inconsistencies may
appear (in spite of translation memory systems).
- Tables are helpful to present very structured information, but
sometimes, they can be very complex to present something very simple
(like a procedure). For example, If/Then tables embedded in Step/Action
tables. And this complexity can present problems when doing the layout
or when publishing your documentation to various media (HTML, XML,
online help, ...). If you're developing templates or designing an
information model for a DTD or Schema, you'll have a lot more work for
the different types of tables. If you don't use step/action or
stage/description tables, you could simply do with <list> and
<listitem>.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 converts RoboHelp files with one click. Author with Word or any HTML editor. Visit our site to see a conversion demo movie and learn more. http://www.componentone.com/TECHWRL/DocToHelp2005
---
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- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
