The Technical Writer as Software Evaluator

Home / Archives / Back Issues 1992 /

The Role of a Software Evaluator

The role of the technical writer is expanding; the days of sitting at a computer and writing for forty hours, week in and week out, are fading into past. Technical writers are taking on more responsibilities. More and more, writers are being asked to participate in the design and review of a new product, or to help organize the efforts of a product team.

Recently I had the opportunity to take on the role of a software evaluator. With this opportunity comes a responsibility to the customer, fellow writers and the corporation to recommend a product that will get the job done effectively and efficiently. How does one go about evaluating software? What are the important considerations? This article attempts to outline the basic evaluation process.

Before you even begin evaluating software, resolve the following points in your own mind: Performing a comprehensive evaluation of a piece of software takes time, and chances are that no one product has all the capabilities you would like it to have, so be prepared to make concessions.

Ample Time

The process of assessing a software package's full range of capabilities takes more than a couple of hours. It could easily take one week to review a package the size of Microsoft's Word for Windows, Xerox's Ventura Publisher, Windows Edition or Lotus Development Corp.'s AmiPro; a smaller package might take less time. The important thing to remember is not to rush the evaluation process.

At the outset of the evaluation, it is essential that you know what you'd like the product to do. For example, is it important that numbers in figure captions be updated automatically? If your document contains a lot of graphics and it would be time-consuming to manually alter the captions if figures were added or deleted, then an automatic updating feature might be necessary.

However, if the package has all the other capabilities that you need except for automatic figure caption updating, keep an open mind. Remember, no one product probably has all the features that you're looking for. It wasn't that long ago that we updated captions manually.

If the package saves time in all other respects, it's probably best to bite the bullet and update the captions by hand. If you find you must have the lacking feature, contact the software company and ask them to consider adding the feature to the next release of the software.

Develop a Checklist

Prior to conducting an evaluation, you may want to develop a checklist of requisite features and capabilities. This approach is particularly useful if you are evaluating more than one product of the same type, such as a desktop publishing package. Keeping a checklist will ensure that all products are evaluated consistently.

It's up to you to decide how the checklist should be setup. If you're evaluating one package, your evaluation form might consist of a list of features that can be answered simply with a "yes" or "no," followed by a comment If you are evaluating two or more products, you may want to develop a list where you assign numbers to indicate how well the product performs in each category (see Figure 1).

Important Components

When I evaluate a desktop publishing package, I usually look first at individual components -- the same components that I identified as requisite features/capabilities in the checklist. In addition to assessing the software's ability to work with captions, I investigate how it handles graphics, headers and footers, tags and tables.

Graphics

Because packages manage graphics in many different ways, I begin the evaluation process by importing an image, and noting the ease by which this is accomplished. Once the graphic is in the document, I ask the following questions:

• Can I place the graphic wherever I want?
• How does the graphic look when printed?
• Is it possible to annotate the graphic?
• What kind of annotation tools are available, and are they sufficient?

In Word for Windows, 2.0, for example, Microsoft doesn't offer arrow as a line style You may be able to work around this by using another color to highlight the lines, but then you'll need to determine if there is enough money in the budget for a second color. With the push on for developers to create graphical user interface (GUI) applications, it's important that you, as an evaluator, recommend a package that handles graphics well.

Headers and Footers

Headers and footers can be particularly tricky if your standards call for right-page headers to match the current A-level head in a section. Ventura 3.0 for Windows, for example, makes this task easy; all you need to do is to go to the Headers and Footers dialog box, click on 1st Match, and type in the appropriate tag name (A-head). The current A-head is automatically placed in the right-page header.

Word for Windows 2.0 requires a little more work. Each time you want to change the right-page header, you must begin a new section and then enter the text for the new header either in Normal or Page Layout mode. While you're in the Header/Footer dialog box, you must click on the Page Numbers button to specify whether to restart page numbering or to continue it from a previous section.

In addition to modifying headers and footers frequently, you may also want to investigate the product's ability to:

• Add a line, also known as a rule in some packages, to the header or footer.
• Set up the headers and footers so that they are automatically updated if you add or delete a page. Like the automatic updating of figure caption numbers, this can be a time-saver.

Tags

Another feature of a desktop publishing package that you should evaluate is its ability to assign tags. A tag consists of font, size, style and spacing information for a specific component of a document, such as a Chapter Name. Once a tag is defined, it can be applied throughout the entire document. While most packages have this capability, you should verify how easy it is to assign a new tag-otherwise known as defining a new style.

My suggestion is to try assigning four tags, perhaps Chapter Name, Chapter Number, A-head and body. Usually, you are provided with templates or style sheets in the software, so try adding styles based on ones that are already defined. Once you have added the four tags, exit the document and return to make sure the new styles have been maintained. You can finish assigning tags when you create your sample document If you like, you can then save the collection of tags as a style sheet, and apply it to any other document that you develop.

Tables

Because its easier 10 scan a table for information rather than a body of text, it's a good idea to look at a package's ability to create, move and edit a table. In both Word for Windows and Ventura, it's easy to create a table; simply place the insertion point where you want to locate the table, select the Table command, and insert the number of rows and columns that you'd like the table to contain.

Once you've created the table, try moving it. Next try editing it by adding, deleting and merging cells. The task that might prove tricky is breaking a table so that it continues on the next page; this can be particularly challenging if you want to add the word "continued" at the bottom of the table on one page, and then repeat the title and column heads in the table on the next page. With some packages, this process may take more work, such as adding spaces to cells, as well as adding at cell at the bottom of the page to contain the word "continued." Therefore it may not be a bad idea to write down how you accomplished the task for future reference.

Sample Document

Once you have evaluated individual components of a package, try creating a sample document. You may choose to develop a document within the application, or import and convert at file from another application. To test the package thoroughly, be sure that the document is at least 10 pages long. You should incorporate all the features that you included in the checklist. You may even want to create a small table of contents and index to note the package's ability to generate both of these components.

Documentation Evaluation

The documentation that accompanies the software is at very important part of the package. It too should be scrutized. As you assess individual features of the software, you'll soon learn how helpful both the hard copy and online documentation are.

In the case of Word for Windows, there was no direct explanation in the manual to automatically number figure captions that consisted of a chapter and sequence identifier (e.g., 4.1). After going back and forth in the manual and noting that a sample table of contents had been generated in at chapter number/figure number format, I deduced that the capability had to be there, even though it might not be spelled out. After additional research, I found some material about numbering headers and footers that proved helpful. . Armed with information from three separate sections in the user's guide, I was able to put together field codes that help me to create chapter/ figure number captions that could be automatically updated.

Be certain to also look at the software's online help. Online help can sometimes offer new insights into a concept or a task. At other times, it's useless.

In addition to the hard-copy documentation and online help, you may also want to look at the product's tutorial. It, too, can provide valuable information not presented in the other pieces of the documentation.

Assessing Customer Support

You should investigate at firm's customer support policy when buying any computer equipment. If you have difficulty performing at task, you shouldn't hesitate to call the software firm's customer support center. To get the most out of the call, it's a good idea to research the problem so that you can explain it in detail to the representative. I have had very good response from Microsoft on my questions. They are knowledgeable and will recreate your problem on their system not merely refer you to the user's guide. This type of support holsters confidence.

Cost Considerations

While it may not be your decision to purchase a product, you can provide important feedback to your manager on the benefits and drawbacks of each package. Ask yourself, "Would I buy this product?"

The checklists and samples will go a long way in helping to make that decision. Tell your manager whether you like or dislike the way a product per forms. After all, you're going to be the one using it. And remember a higher priced product doesn't always mean its better. If you can recommend a product that meets all your needs, minus the fancy bells and whistles, the company saves money, and your credibility as an evaluator increases.

Personal Recommendation

Your evaluation and ultimate recommendation of a software package impacts customers, fellow writers, the company and yourself. A thorough assessment of the software means that:

• Customers will receive documentation that, from a compositional point of view, presents the product that your company is selling in the best light.
• Fellow writers can rest assured that someone whom they know has taken the time to look at the package in-depth, and that the software has been selected with care not just thrust upon them. In addition, they will feel comfortable knowing that there is an in house resource familiar with the package when questions arise.
• The company is probably more willing to make an investment in the software because it has been evaluated by an experienced user in a methodical manner and has been judged to be the tool best suited for the job.

Finally, you can be satisfied knowing that you've done your best to help produce a high quality document.

Cyndee Milley is a technical writer at Information Resources, where she develops end-user documentation for business applications.