Software Documentation© Janice Karin
- Lesson 3: The Importance of Word Choice and Consistent Writing
Lesson 5: Using Tables and Graphics
As a technical writer your job is to convey information to your readers. Sometimes the best way to do that is by writing long descriptive passages. Sometimes the best way to do that is by providing short, easy to use procedures detailing precisely how to perform important tasks. But sometimes you need to provide a screenshot or a graphical representation of an idea before it can really gel for your readers. Part of your job is judging when to rely solely on words and when to provide a graphical illustration of the information you need to impart to the reader.
Using tables
Many people today think of tables as layout tools, tools to help present information in pretty columns. Although tables are often misused in this fashion, they are not meant to be an underlying layout tool. Rather, their purpose is to present tabular data clearly and understandably. What is tabular data? Tabular data is any collection of data that most logically fits into a matrix. This is most often a series of elements which each have multiple properties. For instance, you could have a series of error codes and their corresponding text messages. You could present these as a list, but if you present them in a table you don't need as many descriptive words and the two parts of each error - the code and the message - are visually separated and easy to identify at a glance. To illustrate this example, let's display a list of errors and then a table containing the same information. First the list: - Error 190 occurs when you run out of memory
- Error 200 occurs when your input value falls out of the allowed range
- Error 300 occurs when you cannot connect to the database
And now the table: | Error Code | Error Message |
| 190 | Out of Memory |
| 200 | Out of Range |
| 300 | Connection Error |
As you can see the table is a lot easier to parse. Imagine if each of the elements in the collection had four or five different properties. In this example, the errors could also be categorized by error type and you could also note whether the error message can be localized. The list would get a lot more dense and convoluted, while the table would remain relatively easy to read: - Error 190 occurs when you run out of memory. It's a basic system error that can be localized.
- Error 200 occurs when your input value falls out of the allowed range. It's a parameter error that cannot be localized.
- Error 300 occurs when you cannot connect to the database. It's a basic system error that cannot be localized.
or within the table: | Error Code | Error Message | Error Group | Can Be Localized? |
| 190 | Out of Memory | System | Yes |
| 200 | Out of Range | Parameter | No |
| 300 | Connection Error | System | No |
As you can see, tables really do make a big different. Use them judiciously, but use them whenever you need to present a collection of tabular data.
1
2
3
4
5
6
Print this page
|