Chapter 7 and 8 Barker

This chapter was called Conducting Usability Tests. The chapter went over 3 basic types of tests:

1. tests for task performance (procedures)
2. tests for skill and understanding (tutorials)
3. tests for access to information (references)

- Hide quoted text -

The first step is deciding when to test. You can usually test at about 3 stages-- during design, during writing and development, and after the document set goes to the customer. Then you must select the test point. A test point is an issue or feature of a document that might interfere with the efficient and effective application of a program to a user's work activities. Then to select procedures for testing, you identify what issues you want to test by determining a point in your documentation where there is a chance for user error. To select design strategies for testing, look at terminology (language), an index (for consistency), cuing patterns, headlings/layout, navigation, and extraordinary document formats (special conditions). Next, you must choose the type of test to use. Relating to test points of tasks, terminology and document design strategies, you can use the Can They Do It Test, Can They Understand It Test, and the Can They Find It test. You may have to use more than one test.
Setting performance and learning objectives is important because you want the tests you perform to measure real behavior. Good performance does not necessarily mean getting something done in a short period of time. Kinds of performance objectives include


* time-related - time taken to perform a procedure
* error-related - Number of errors made during a procedure, number of times a passage gets reread before comprehending, and number of tries in the index.

Objectivity in testing means setting up the test in an unbiased way as to ensure the test does not just pass automatically to let you get on with the project. You cannot let personal bias to get into your test.
Selecting testers and evaluators is the next step. The tester is the person who administers the test: arranges the meeting with users, sets up the test situation, records the test activities, and so on. The evaluator is the person taking the usability test. Then, prepare test materials and know how you want to use them. There are many kinds of test materials, including:


* Evaluator Selection Survey - A brief list of questions that potential evaluators fill out to ensure they meet the profile as typical users.
* Instructions for Evaluators - A one-page list of instructions to help evaluators understand their role.
* Test Schedule - Schedule of testing times and locations for tester and evaluators to follow.
* Instructions for Testers - Set of instructions telling the test monitors how to conduct the test and how to record information.
* Test Lab Procedures - Set of instructions for operation the testing facility.
* Pilot Tests - Mock-up versions of test forms to try out as a way of determining how well the test works and the suitability of the performance objectives
* Test Forms - Actual tests written up as test scenarios, task descriptions, and/or procedures.
* Test Subject Materials - Actual copies of documentation that the test intends to evaluate
* Software Overviews - Marketing or overview information that informs evaluators or the main uses and features of the documentation they will use.

Kind of hardware and software test materials include a tape recorder, notebooks, camera, intercom, tables/chairs, and timing clock. All these items are used to test and simulate the actual working environment. Setting up the test environment can be a difficult task, as there is no perfect place to do this. The user's workplace, a lab, or a combination of the two. The latter two are the more expensive choices, but the user's workplace is intrusive.
Make sure information is recorded accurately. This way, you can evaluate and interpret the data to come out with a solution that best fits the user.

Chapter 7 - Writing Software Documentation - Barker



This chapter discusses getting useful reviews. To begin, Barker says a reviewer guidelines transmittal letter should accompany the document. This sheet gives document background, kind of information writer needs from reviewer, where to send mark-up copy, clear instructions for mark-up and encourages partnership with writer.



Barker details the following as guidelines for managing document reviews:

* Review the document objectives from the document plan.
* Determine the type of review needed.
* Establish a review schedule.
* Plan the review.
* Write a cover letter with questions for reviewer.
* Prepare feedback material for reviewer.



There are different types of reviews that require different people to be involved who will have different concerns regarding the review. For example, a managerial review involves managers, supervisors and team leaders who are concerned with staying budget, meeting objectives and quality control. All reviews can offer challenges and problems as all are not on-site and may not be familiar with the project. By establishing a review schedule, some problems may be eliminated.



Barker also discusses the advantages of sequential circulation verses simultaneous circulation. The writer would need to figure out which works best. The cover letter provides the following objectives and benefits to the reviewer: request for specific advice and comments, necessary background, tell reviewers how to mark or comment, give date and place for return, thank reviewers. The writer should also provide feedback materials.



Barker distinguishes between reviewing, testing and editing. Reviews require comments from several people whereas testing concentrates on users and issues of accuracy and statistics, and editing comes from trained editors who perform various levels and types of editing to your document. Barker states that reviewing is critical throughout the documentation process stages; planning and design stage, user analysis stage, development and writing stage and the draft stage. It is important to remember that all the document changes should be negotiated diplomatically. The different cultures from within a company may bring different perspectives as to how the document should look.



To conclude, Barker suggests a user walkthrough in which you present the document from beginning to end and focus questions on the key issues of usability. This review will contribute the most to helping meet the task needs. During a user walkthrough the information illustrated can only come from actual users.

Examples of questions are:

* Does the document reflect recognizable workplace activities?
* What tasks does the document not focus on that users would find important?

Case/Pass
Barker ch 10

Barker discusses document design and its obstacles in chapter 10. He covers issues such as meeting user needs, how to accommodate specific user groups, as well as the different tools available for writers.

Fist we are given ‘Guidelines for Designing Documentation’

1. Create a table of contents
a. This can help a writer organize their document as well as assist the user in many ways
2. Match the user analysis with information design strategies
a. Design for different groups
b. Design for specific program issues
c. Meet user task needs
d. Meet user information needs
e. Match user computer experience
f. Enhance user’s subject-matter background
g. Leverage the user’s workplace
h. Meet the user’s learning preference
i. Meet the user’s usage pattern
3. Acknowledge production constraints in document design
a. This is where writers evaluate what the want versus what they can do
4. Test and review the design
a. This is best done with a form of usability testing
5. Follow a design process for online help
a. Online help uses topics
· About
· Module
· Action
· Problem
· Question
· Task
· Update
· User Group

The next part of chapter 10 deals with the Design Problem. In short, this is when the writer attempts to accommodate many users with one format. This is especially difficult in print because users’ search abilities are limited. To help remedy this problem the writer must first categorize his users. This can be done in multiple ways; two the book suggests are using computer experience or level of professional use. After the groups have been identified, the writer can then begin to analyze the users’ problem solving methods. Some points to keep in mind when doing so are:
1. No one reads carefully so keeps things short and accessible
2. Most users do not read the entire manual, instead they do specific searches when the run into problems.
3. Users wait until the have failed a task to look for help and are often impatient at this point.
4. Most readers do not bother reading introductions because they feel they are not related to user needs
5. Most users do not read any one section in its entirety; instead, they filter information while scanning.

After looking at the issues writers face when accommodating to their audience, Barker offers us an overview of the tools available to writers as well as a brief summary of how they are best used. Some of the design tools he referred to were
· Navigation
· Cross references
· Running headers and footers
· Layering
· Headings
· Advanced organizers
· Document overview
· Parallel structure
· Cuing
· Bookmarks
· Histories
· Pop-ups
· Links and jumps

Nelson and Haupt - Rockley Chapter 9: Metadata

Metadata is “data about data.” Any item of data is a description of something. Metadata is a type of data where the something being described is data. There are two types of unified content metadata: categorization and element. Users tend to use categorization to search for metadata, yet authors will most likely us an element search to find metadata.

An example of metadata would be to recognize a date on a photograph then when later searching for that practically photograph a user could search for the photograph by the date on it.

when compiling metadata it is important to understand who is going to retrieve the content, what tasks are they trying to accomplish with the content, and what terms will they use when retrieving the content. After understanding the first three steps in creating metadata it is important to create taxonomies. A taxonomy is the grouping of like or similar content together. After you have grouped your taxonomy you will want to test it. To test the taxonomy you will want to run a usability test on it.

When working with element metadata there are three main types: reuse, retrieval, and tracking metadata. Reuse is if data already exists in a data base then the metadata will recognize and ask the user if they would rather go back and reuse the data in it. Retrieval metadata is used to help authors retrieve content and information. Examples of information in a retrieval metadata would be the title/ subject, author, date, and keywords, and the security level. Metadata for tracking is used when showing workflow.

Metadata needs to be consistent to facilitate reuse, retrieval, and tracking. To keep metadata consistent it is best if a controlled vocabulary is created.

Rockley Chapter 9 - Designing Metadata (Peterson)

I apologize that I didn’t post this weekend. Totally misread the reading assignment chart.

Metadata can be looked at several ways. The short definition of metadata has often been described as “data about data.” Rockley expands that definition to include the importance of how data can be used for effective search and retrieval, reuse, and dynamic content delivery within an organization.

This chapter discussed the levels and different types of metadata that are needed for a successful content strategy. Rockley says that metadata enables:
• Effective retrieval
• Systematic reuse
• Automatic routing based on workflow status
• Tracking of status
• Reporting

This requires proper defining and categorizing of the types of metadata used.

Benefits of Metadata
• Reduction of redundant content
Consistent labeling of content enables authors to easily retrieve existing, reusable content. It also can identify situations where duplicate content might be created if multiple authors are involved.
• Improved workflow
Tagging content with metadata identifies its status and workflow automatically manages the content.
• Reduced costs
o If content already exists and can easily be retrieved, the work required to recreate it is eliminated.
o It can also help determine when source elements have changed. If set up properly, metadata can ensure that the changes are automatically populated everywhere it is used.

Types of Metadata
There are two types of metadata – categorization and element.
Categorization
Rockley described categorization metadata to be similar to the card catalogs and Dewey Decimal System used in libraries. Corporate information needs to be just as accessible as library materials. This is achieved with metadata hierarchies and metadata taxonomies. A hierarchy provides the content user with an understanding of how content is organized and the same content may be organized under more than one category. Metadata taxonomy is categorized in only one place.

Categorizing content can be difficult and time-consuming. It can initially involve a lot of manual work. Standards must be put in place. Some industries have developed vertical taxonomies that can be applied. Some vendor tools are being created to help with the process.

Rockley says that it is important to understand users when developing categorization:
• Who is going to retrieve the content?
• What tasks are they trying to accomplish with the content?
• What terms will they use when retrieving the content?

To create a taxonomy:
• Group or cluster related content
• Develop taxonomy – each term becomes metadata
• Test the taxonomy – ask users to perform a usability test

Element
Authors use elements to help manage content. There are three main types:
• Reuse metadata – identifies the components of content that can be reused in multiple areas
• Retrieval metadata – helps authors retrieve content and may include much or all of the reuse metadata, but it is more detailed
• Tracking (status) metadata – helps with implementing workflow.

Creating a Controlled Vocabulary
Consistency is critical for the successful use of metadata and a controlled vocabulary goes a long way to achieving this, especially if authors are creating their own metadata tags.

Ensuring Metadata Gets Used
Metadata is valuable only if it is used. Rockley suggests that an organization automate as much of the metadata application process as possible. That helps to ensure that metadata gets used and helps authors add metadata in the authorizing tool, rather than as it is checked back into the system.

Late Posting

Jaya and I have not yet posted Guidelines for Developing Instructions, Chapters 7 and 8. Our apologies. We will attempt to have this posted by Sunday evening.

Becky Guadagnoli

Barker Ch. 9 (Erik Sorensen & Emma Baumann)

Barker Chapter 9
Editing and Fine Tuning
Summary

By Erik Sorensen & Emma Baumann

This chapter is concerned with the editing and revision of projects as a management concern. The chapter offers guidelines to help develop a consistent and efficient style of editing.

1. Establish Project Guidelines
It is often important for the writer or writers of a document to be on the same understanding. This will help to ensure that goals and objectives of given documents are met. It is important in this step to identify your audience and make sure all editing is done with the audience in mind. Sometimes editing is done by other people and sometimes the creator of the document will edit it themselves. In each case it is important to be consistent and ensure attention is paid to detail. Barker introduces editing marks that seem to be universally understood so that editing can be done collaboratively.

2. Understand the Types of Editing

These are sometimes called levels of editing. There are four basic types of editing: Managerial, Substantive, Copy and Proofreading. Each one of these edits is unique in its intention.
Managerial editing concerns itself with the documents and their planning rather than the actual format and content. This type of edit will require comparison to other management materials. This edit will be done by managers and editors from a group working closely with the writers of the document.
Substantive editing involves editing language and information. This edit is done closely with the author and deals with the structure of the document. Substantive editing deals a vast amount the following are some examples:
Organization
Fluency
Parallelism in steps
Clarification
Omission
Copyediting will deal with grammar, mechanical style, and format. This editing will take place in the latter stages and most of the groundwork has already been laid. This would be like how we use to edit each others papers in high school. You will be looking closely for silly mistakes and final touches such as spelling, subject/verb agreement, acronyms, abbreviations and so forth.
Proofreading is the last stage. This will be an overall check of the document. You may catch mistakes that were previously undetected. This is the last opportunity to catch mistakes before printing takes place, so look closely!

3. Plan Your Editing Tasks
Planning your editing should take place at the very beginning stages of a project. This will allow for the best situation for proper editing to take place. Scheduling editing will budget the necessary time initially. However, there is no definite rule on how much time should be allotted for each step. Barker provides a rough guideline for each level of editing.

Managerial Editing: 10-15% of all activities
Substantive Editing: 6-8 hours per page
Copyediting: 1-3 hours per page
Proofreading: 5-10 pages per hour

Each level will require different tasks of the editor. For example, in a managerial edit you should plan on attending meetings and communication is the key on this level since you will be working closely with all aspects of the revision. Substantive editing will require you to look at each page of the document as its being created and closely keep in mind the readers needs. You will also be checking style and again, the meetings for comments and suggestions. Copyediting only requires one session per draft and will be done after the document is complete in draft form. Proofreading is just a matter of double checking things however; it can be extremely tedious so more than one person may be essential and beneficial.

4. Develop the Appropriate Editing Forms
Often times in order to save time and energy a company may have existing forms and procedures for editing. This can help regularize procedures and streamline the process. One of the most important forms, according to Barker, is a style sheet. A style sheet is a sort of way to keep track of the revisions as they happen. This is not to take place of a style guide but rather allows you to keep track of the small changes as they occur.
A style guide will contain all the rules and conventions for a specific project. This is a way to keep things uniform throughout a department or company and can also set a standard for future documents. A style guide does numerous other things and is essential for any project.

5. Conduct Editing Sessions
Different edits can occur at different levels of the document life cycle, however there some general rules that apply to each edit. Editing requires concentration so distractions are not encouraged. A checklist is also beneficial, especially if you are editing your own work in order to avoid ignoring our mistakes. There are a few other tips offered: edit with a partner, shorten editing sessions.

Managing Enterprise Content ch. 7 (Ahles/Hennis)

Chapter 7 continues Rockley’s idea of the unified content life cycle that was introduced in Chapter 5. Here though, Rockley talks about how the content life cycle can be put to better use in making a more efficient unified content strategy to aid your organization. Before you can begin your content strategy though, Rockley says that you must “identify organizational goals and issues, examine your current content life cycle, and analyze your existing and published content to determine potential reuse" (127). Doing all of these tasks will help you gain a better idea of how your content strategy can be improved on, and how these changes can be done through the proper utilization of a content life cycle.

Addressing Issues
At the beginning of the chapter, Rockley talks about the kinds of issues that need to be addressed with the content life cycle. Identifying these challenges should be the first step in your project and could be any number of things within your organization. The issues that Rockley gives fall into six categories:

• Content use
• Content authoring
• Translation
• Global requirements
• Review
• Publication and delivery

For each of these issues, Rockley gives required steps to addressing the issues, and which life cycle phase the issues can be resolved in. For example, the Content use issue of too much detail/too little detail should be dealt in the Create phase and can be resolved by re-evaluating the requirements and rewriting material accordingly along with providing content that is specific to the user’s needs.

Another example would be the issue of authors not being able to find the information that they need. An answer to this would be storing all content in a single repository, one place where the authors can find all the information that is available on a single product. Another response would be developing a better categorization method for the author to find the information. These solutions would need to be developed in the Manage and Create phases of the content life cycle.

Life Cycle Samples
The last half of the chapter gives two samples of how a unified content life cycle works for two companies: CreateSoft and Envigor. Both companies have issues with their produced content and decide to implement different strategies. Envigor decides to switch to XML for more control over their content and ensure a more consistent product. CreateSoft, though staying with their existing authoring tools, decide to try a new management system to manage and distribute their content. Rockley goes into each phase of the respective companies’ plans and talking about the differences between the two. For example, in the area of check-in content in the Review phase is handled differently. Envigor is automatically notifying a reviewer when content is ready for review while CreateSoft manually routes the content to reviewers.

Guidelines for Developing Instructions, Chapter 7 – Nelson and Haupt

The authors present a concise style guide in Chapter 7. Recognizing that there are many possible variations in style, Inaba, Parsons, and Smillie “suggest you use the specifications in a flexible manner and try not to adhere to them rigidly or unthinkingly.

The text offers guidelines for the use of Headings, Command Steps, Sequence of Tasks and Steps, Callouts in Text, Subprocedures (Procedures within Procedures), Table to Supplement Instructions, and Guidance and Routing Information (Notes)

The reference to ANSI standards on page 80 is particularly helpful. The two main ISO/quality organizations in the United States are ANSI and ASQC. The American National Standards Institute (ANSI) is the United States representative to the International Standards Organization (ISO). The American Society for Quality Control (ASQC) is an organization that develops, promotes, and applies quality-related information and technology for the private, government, and academic sectors.

Adherence to official and de facto standards is critical in technical communication. There are a multitude of national and international standards-setting bodies in addition to ANSI and ASQC. For example, The IEEE, a non-profit organization, is the world's leading professional association for the advancement of technology. The full name of the IEEE is the Institute of Electrical and Electronics Engineers, Inc. It is the IEEE that sets many of the standards that today’s computer systems utilize. For example: 802.3 (Ethernet), 802.5 (Token Ring), 802.11 (b) and (g) (Wireless Ethernet).

Due to the existence of numerous standards bodies and the potential for conflicting quality standards, the ISO created a set of five (9000-9004) standards developed to help harmonize the large number of national and international quality system standards. The ISO standards (conformance models) are themselves a subset (in the United States) of the Malcolm Baldridge National Quality Award Criteria. Gaining a working knowledge of standards applicable to the technologies you are working with is invaluable. As you gain an understanding of the standards, you will yourself become technical, and will be able to converse intelligently with the engineers involved in your documentation projects.

Following is a comprehensive listing of the rules Inaba, Parson, and Smillie suggest technical writers use when creating documentation:

• Use distinct, obvious headings to help the user quickly identify and locate the instructions, as well as all of the sections or parts of the instructions.


• Place headings that identify jobs or tasks flush with left margin.


• Place headings for Notes, Cautions, and Warnings in the center of the column


• Use consistent amount of space between heading and subsequent text (e.g. double space).


• Set all headings in bold with consistent use of upper and lower case.


• When instructions exceed one page, repeat task headings at the top of each page.


• To compose titles for tasks and task sequences (e.g., jobs) use the command form of an action verb or verbs followed by the name of the system, equipment, or other objects of the action.


• Use a simple, fixed syntax for command statements. Use a transitive verb (one taking an object) from the command verb list, followed by one or two objects.


• In necessary, modify verb or object with one or two prepositional phrases of a dependent clause. Place such phrases after the basic command.


• Use conditional phrases and clauses to tell how, when, or where to accomplish the work. Please such conditional phrases and clauses before the basic command.


• When the actions are identical for a number of clearly related items treat the entire set as a single action.


• Use fixed set of nomenclature for objects of action verbs.


• Use a maximum of three obviously related actions per step unless a fourth action is needed to bring the step to a close.


• If a single action produces a clear and specific result, and requires more than 30 seconds to perform, present it as a separate step.


• Limit the total number of words in a step to 25, except when additional words are presented in list form.


• Use only one command verb per sentence, unless two verbs are needed to express alternate actions or actions taken close together in time.


• When a command sentence requires more than two objects, present the objects in list form following a colon. If the list is greater than four, partition the list into groups with no more than four objects in a group.


• Assign an Arabic number to each step. Assign 1 to the first step in each task and assign numbers in proper counting sequence to the subsequent steps.


• Arrange tasks and steps in a task in the most likely order of occurrence.


• Incorporate instructions for the use of special tools or test equipment in the sequence if the use occurs only once or twice throughout the entire set of instructions, and no special skill is required to use them.


• When extensive routing is involved within a task (e.g., from two or more steps), provide a routing page that serves as a road map for the user and supplements or is supplemented by the detailed instructions.


• Place the appropriate callout number in parentheses immediately following the name of the equipment.


• When there are two or more like items on the graphic, use two or more callout numbers with a single noun.


• As an option use a subprocedure when a short sequence has a clear and specific result, is needed as part of different tasks, but is not long enough to merit being treated as a task. Compose the title as a step, add “as follows:” and list the action.


• Use tables in combination with command steps when they help clarify instructions. Tables are useful when combinations of events or equipment are involved.


• When using a table for routing purposes, insert the table immediately after the step and on the same page (or facing page) as the step.


• When a large table is needed to support steps on several pages provide the fable on a foldout page that the user can pull out and use together with the instructional pages.


• Assign numbers to tables when two or more tables appear on a page or on facing pages.


• When using a table with a graphic to show the location and function of a number of similar items such as fuses and circuit breakers use callout number to link the items in the table to the graphic.


• Use Notes to provide guidance information and to route the user to the appropriate instructions.


• Always precede safety information with a Caution, Warning, or Danger heading, preceded by the safety alert symbol. Use multiple paragraphs if information exceeds 25 words or covers different subjects.


• Place safety information entirely on the same page as the command step to which it applies. If this is not possible due to the length of the safety information or the length of the step, place the safety information on a separate page preceding the command step.\


• Always place a safety alert symbol and a signal word immediately before the command step to which it applies.


• If Danger or Warning and caution apply to the same step, present the Danger or Warning before the Caution. If a Note is needed, place the Note after the Caution or Warning.


• Use the same style of heading as the style chosen for the planning page. Place the heading in the center of the column.


• Provide explanations for the Warning or Caution, after the primary safety sentence.


• For Cautions and Warnings, use strong terms.


• Whenever a serious situation is implied write the primary safety sentence in command language.


• When a Caution or Warning applies to two or more steps start the statement with a phrase to that effect.


• Always place guidance Notes before the command steps to which they apply.


• Present the routing information as a separate paragraph, separated from the preceding step by an empty space and with each alternate route in a separate paragraph.


• Whenever possible shorten the description of the second alternative when it is the direct opposite of the first.


• To help alert the user, include a phrase in the routing statement to describe the work to be done.


• When directing the user to a step preceded by a Warning, Caution, or Danger signal word, or a Note, instruct the user to read the applicable information.


• If the same obvious alternative applies to a series of steps place the routing statement before the applicable step.

Writing Software Documentation - Chapter 6

Writing Software Documentation

Chapter 6

This chapter was involved with planning and writing documentation. This process has been divided into nine steps.

1) Start The Project – In the old days, one writer could sit down with a program and figure it out for himself. This is no longer the case, and most documentation is done in teams. A Development Team is composed of the programmers who created the software, while a Writing Team is made up of just writers.

2) Perform User Analysis – In any situation with giving directions, it is good to know how much your audience already knows. The purpose of this step is to ascertain that.

3) Design Documents – Form a template for how the help system will look and work. Do this for a tutorial, procedure, and reference in mind.

4) Plan the Documentation Project – Form a timeline for who does what and when.

5) Write the Alpha Draft – This is a preliminary version of the documentation.

6) Conduct Reviews and Tests – Make sure your documentation is on target.

7) Revise and Edit – Standard writing procedure.

8) Write a Final Draft – Again, standard writing procedure.

9) Conduct a Field Evaluation – This is when you go out and make sure Johnny Enduser is able to use your documentation effectively.

There are two primary development plans:

1) The Waterfall Method – One stage comes after another, and one cannot begin until the previous one has been completed. The easiest method to start up, it is also the least efficient.

2) The Rapid-Development Method – Writing and planning happen independently of each other; one portion of the team focuses on user needs and proper format, while the other focuses on the raw text required. Once a format is decided upon, the text is absorbed into it. Far faster to implement than Waterfall Method, Rapid-Development also calls for a higher team-work capability.

Summary - Guidelines for Developing Instructions

Team 3 - Bynum & Peterson

Chapter 6 covers the use of both command and non-command verbs in a set of instructions, as well as nomenclature, nouns, pronouns, and the other parts of speech, including punctuation and symbols. Inaba also adds a list of command verb followed by a list of their definitions. Throughout the chapter, Inaba states rules, such as a topic sentence for the following paragraph. These rules cover everything from use in one statement to use in the whole document. Most of the rules are followed by a paragraph, and sometimes an example, which further explains the rule. Most of the rules in the chapter revolve around one basic principle, keep it simple.

Most of this chapter was already common knowledge to myself but I wish I had read it before doing the Quick Start Guide because I'm sure that the guide could have been done better.

(Since I still don't have the textbook, Matt took on the responsibility for writing the entire summary for this week's chapter. - Anne)

CHapter 6 Rockley

Managing Enterprise Content, Chapter 6: Performing a Content Audit
(Case/Pass)

In this chapter, Rockley discusses a strategy for performing a content audit. Rockley defines a content audit as “an accounting of the information in your organization,” though the process could be described more specifically as an analysis and categorization of all the content present in your organization. Rockley identifies several steps in the process of a content audit, which include:

Identify the scope of the audit
Select representative materials
Analyze the content
Build a reuse map
Identify opportunities for reuse
Summarize your findings and document recommendations

Identifying the scope of the audit
The first step of a content audit is to decide what to audit. Most technical publication groups start with their content, and discover in the process that much of their content resembles what marketing or PR is producing. This will drive them to expand the audit out into other departments or groups to improve consistency. Rockley advises us it isn’t necessary to start big and analyze every department we can, but by starting too small, a decision could be made to use small or inflexible technology choices that won’t translate over if the decision is made to do a large-scale audit.

Selecting representative materials
This step is similar to taking a core sample of a group; it asks us to select several pieces of content from within our scope to represent the whole. Because a content audit is a comparative exercise, content that spans across the entire scope of our audit should be selected

Analyzing the content
Rockley recommends a method of breaking down each document into ‘pieces’ and observing where pieces of different documents are very similar or identical. Rockley splits this step into two parts: the top-level analysis and the in-depth analysis

A top-level analysis involves a scanning of the content for pieces of information that might be similar. Look for headings, sections, tables, graphics, product descriptions, introductory information, procedures, etc. Scanning the table of contents (if there is one) can be helpful in finding where information might repeat.

An in-depth analysis involves delving into the pieces of information that you identified as similar during the top-level analysis. During the in-depth analysis, we should identify which parts of the content are similar, which are different, which parts can be changed to become similar, and which parts could be standardized for reuse. Be sure to create some sort of system for yourself to track which pieces you identify as reusable, such as a table or a highlighting/marking system.

Building a reuse map
After performing an audit, it’s a good idea to map out findings. A reuse map is a matrix chart that identifies what content is reusable, where the content is reusable, and what type of reuse should be made. You can build a reuse map by assembling a table with your representative materials in columns and the content pieces you identified in rows. Where the pieces match up with their representative materials, you can place an identifying symbol for which type of reuse can be made.

Summarize your findings/document recommendations
Since single-sourcing could be a costly and time-consuming project, it is a good idea to write up a summary and recommendation report, because you may be pitching your ideas to higher-ups to get approval to go ahead.

Usability issues
In addition to saving time and money, a content audit might have secondary benefits as well. As you are scanning through your content, you might come across problems or inconsistencies that hurt usability and create confusion (for example, two identical procedures with different steps for completion). Content reuse is one method of eliminating those problems by making everything unified.