History, Rhetoric, and Humanism

In his article “History, Rhetoric, and Humanism,” Russell Rutter looks at a more comprehensive way to define technical communication. He begins his piece by discussing that technical writing is more than just writing proficiency; it also involves problem solving skills and the ability to work with other people (21). Technical communication, Rutter feels, needs to associate itself more with rhetoric and humane learning. Also, technical communicators need to go beyond just being users of systems; they need to be educated human beings.

Being and Knowing Before Doing and Writing: Technical Communication and the Liberal Arts Tradition
The tradition of technical communication asserts the primacy of knowing and being over willing and doing (22). According to this tradition, the person thinking is more important than the tools or systems being used. Rutter goes on to provide research of this tradition, which emphasizes the classical period, the Renaissance, and the nineteenth century. After these three periods, even more perspectives of technical communication were formed.

Scientific Progress Through Crisis and Its Implications for Technical Communication
Science and technology are often viewed as rigid subjects, and therefore most think that when writing about them, the language should also be rigid. However, this is not the case, and this thought needs to be brought into the open. The importance of the scientific method is often exaggerated, and the scientific and technological progress through spasmodic change, serendipitous discovery, and imaginative flexibility are often forgotten (26). Rigid procedures have not always brought about scientific advancement so it is hard to see how they would ensure the advancement of technical communication. Therefore, as technical communicators, if we must mimic science, we should also mimic the imaginative side as well.

The Evolution of Science and Technology and the Reductionism of Technical Communication Theory
As late as the seventeenth century, what passed as science was based on the authority of the ancients rather than experimentation (26). Technology wasn’t even really considered because it rested in the hands of guilds, artisans, and the illiterate. Rutter then goes on to describe more about the history of scientific advancement. Most of the great scientific advancements of the time came from just a few scientists. He notes that professors at Oxford were laid off because they couldn’t fill their science courses. It wasn’t until the Technical Instruction Act of 1881 that it became possible for Britons to study technical education (27). In the United States, the Morrill Act of 1862 brought about technical education by endowing what we now know as land grant colleges (27). With the increased enrollment in technology and science came a need for courses designed to teach about how to write about technology and science. However, these emphasized that the scientists provided the content, and the actual writing was just “frosting” (28). This form of rhetoric emphasized technical writing as a means to fitting facts into content outlines developed long ago. Rutter notes that by providing this history, we should be equipped with the knowledge needed to shape current practice (28).

Technical Communicators as Rhetoricians
“To understand the dynamic nature of science and technology and to discover that the supposed gods of objectivity and pragmatism are just the illegitimate offspring of expediency and misunderstanding is to realize that technical communication is rhetorical above all else (28). Rutter notes that if technical communicators aim to create versions of reality instead of serving as windows to reality, then technical communication must be fundamentally rhetorical. This is valuable in the workplace because communication should be seen as an open system, which is often not. Technical communication has to be rhetorical because its task is not to serve technology abstractly conceived but rather to produce “writing that accommodates technology to the user” (29). “Technical communicators, because they depend on both ‘knowledge and practice,’ because they rely on learning as guide to experience, and because they need to bring eloquence, empathy, and imagination to the world of work are—and should be expected to be—rhetoricians” (29).

The Values and Limitations of Research on the Culture of the Workplace
Rutter writes that the research for redefining technical communication defines a problem that it cannot be expected to solve. Through his reaserach, Rutter has found that technical communicators must do more than write. They must also possess the ability to function productively in the collaborative context of the workplace (30). Writers must be able to focus on the culture as an entity in which they must fit themselves. However, Rutter finds this similar to fitting content into pre-existent content outlines, which will not produce a result of progress (30).

Conclusion
Rutter concludes by stating that he wants to avoid negativism, and that he is not trying to deprecate the efforts of those who have devoted productive lives to writing well and teaching others to write well (31). However, he writes that the best way to advance would be to eliminate the biases against such subjects as rhetoric, literary criticism, and the history of science and technology, and to include teaching training. He notes that if as much effort is put into this as has been for cooperative education, then we will surely succeed in broadening the base of technical communication.

Understanding the Writing Context in Organizations

Linda Driskill

Linda Driskill discusses the importance of communication in written documents, she explains different situations and how communication was handled.


The Importance of the Writing Context

Driskill first talks about a marketing team and the concept they created for their direct mail piece for the National Association of Securities Dealers (NASD). The direct mail piece was catchy and to the point, however, as procedure they had their lawyer overlook the document and it failed to be approved because of legalities with the wording. She explains how the writers on the marketing did their job, but were not equipped with the legal expertise to successfully create a direct mail piece.


Why Current Models Neglect Context

The next section Driskill discusses in the problem with courses on communication. She states that the courses focus on the means for expressing meaning, no the meanings themselves (p.57).

One of the approaches to organizational communication is structural-functionalism which requires the focus to be on the mechanisms of the organization. This theory which is influenced by the Shannon-Weaver Theory is based on reducing noise in the system and creating a flow rate to channel information. Shannon-Weaver Theory was not concerned with people or why they needed to communicate. Schramm revised the Shannon-Weaver model it was more focused on the environment were communication took place and recognized that people were involved and that feedback is part of communication.


External Sources of Meaning: Mutual Funds Industry Example

Driskill explains external sources of meaning to be influences on the writers they are not absolute some examples of external sources of meaning are money supply and credit availability. Basically the factors that directly affect the business at hand but are not factored into the work are external sources of meaning.


Internal Sources of Meaning: The Challenger Accident Example

The structure, size, and technology of the organization will affect the role people play and the way rhetorical situations are defined (p. 63). Some of the factors of internal sources of meaning are: corporate culture, individuals, and situations. Internal factors deal greatly with people and their perceptions at work and how they communicate and how people receive the communication.


Organizational Situations and Rhetorical Situations

This addresses knowing your audience and knowing that not one particular type of audience is reading your information. Driskill refers back to the example of the marketing team for NASD. Knowing that not such a simple audience will be reading you document, a person who looks deeper into the meaning might be upset with the word choices and deem them unfair or illegal.


Implications for Teaching

Driskill talks about identifying the different situations that occur and how information and communication was handled is the best way to learn for the future and to correct any communication flaws. It is important to recognize the internal and external sources of meaning with teaching communication models.

Barker - Chapter 13 - Using Graphics Effectively

Writing Software Documentation: A Task-Oriented Approach

Thomas T. Barker

Chapter 13 – Using Graphics Effectively

In this chapter, Barker explores on the use of illustrations in manuals and online help. He offers examines the role that images play in informing users, and presents guidelines for their effective use. This chapter also discusses the different types of graphical elements available and how they function.

Barker begins by presenting an example from a printed document and an online help screen that make use different types of graphics to deliver information.

Guidelines

Barker presents 4 guidelines for using graphics effectively.

1. Identify Needs for Graphics by Your Users

Barker asserts that graphics should serve to support two user questions: “How can I use the program easily?” and “How can I put the program to work?” That is to say, the graphics should help the user locate and act in order to efficiently operate the program, and they should also help the user understand, providing education, guidance, and support for workplace tasks. Graphics are not to be used as decoration, but as a way to explain concepts and illustrate examples. Revisit your user analysis, and think of ways in which graphics can help in meeting user needs.

Where Is It?

Graphics can serve to help users locate information in a number of ways. This includes:

• Show the user where to look to perform tasks
• Show concrete versions of abstract things
• Make visuals clear

What Is It?

Graphics can be used in various ways to help define concepts unfamiliar to the user. Users often require subject-matter knowledge or background information about a program or idea. Graphics can help provide this understanding through examples and metaphors.

Examples can show things like documents, reports, or printouts. This could also include showing sample data, all of which helps users identify the various aspects of a procedure. These often benefit from labels and explanatory text.

Metaphors involve illustrating an abstract concept by relating it to something the user already knows. Metaphors can help users to quickly grasp an idea without having to learn it from scratch. A prime example of this is the desktop metaphor used by many operating systems.

How Do I Do It?

Graphics can also be used to effectively demonstrate and support sequential actions. Graphics answer the question of “how?” by giving a visual overview of step-by-step procedures. A flowchart is a good example of this type of graphic. These help users to form a mental model of a process that they need to perform.

What’s the Big Picture?

Graphics can also be used to give users a broader understanding of a concept or process. Barker lists four forms that these illustrations may take:

• Overall Program Diagrams
• Menu Maps
• Conceptual Overviews
• How to Use the Manual

2. Set Graphics Styles

Just as you set styles for text, you should also use consistent styles when incorporating graphics into your document sets. Some of these stylistic elements include boxes and frames. These styles should be established early in the project, communicated to team members, and recorded in the documentation plan.

Barker lists several style elements that are of particular importance for graphics:

• Lines
• Fonts
• Arrow Styles
• Box Styles
• Frame Styles

In designing graphics, it’s also important to consider the degree of realism that you will utilize. All of these styles should be carefully documented in a table.

3. Revise and Edit

Once you have established standards, you should revise your illustrations based on those standards, in addition to overall correctness and consistency. Barker presents several points to keep in mind when revising graphics. “Graphics,” he states, “present the user with the thing itself rather than the word for the thing.” For this reason, graphics must be designed with a clear purpose. At the same time, it is important to recognize the value that words have in helping users to internalize a concept or process. This means that it is important to strike a balance between words and graphics when designing documents. Barker lists and discusses various aspects of documents that can incorporate or be augmented by graphics. These include:

• Titles
• Labels
• Placement
• Rules and Lines
• Size
• Colors

4. Revise for Typography

Typography refers to the arrangement of images based on a logical structure. Guidelines that can assist in achieving this are as follows:

• Make important things larger
• Make important things darker
• Make important things central
• Make important things sharper
• Align related things
• Put first things left, later things right

Discussion

“If a documenter has done the job well,” states Barker, “the user will not just press the correct key or button but do so in the context of meaningful work.” Graphics can help users to make clear connections between software operations and workplace actions by describing operations in meaningful ways.

Showing How Tools Apply to the Workplace

Illustrating the use of tools is directly related to the concept of task orientation. In some ways, it is the simplest form of instruction. You can support operation of interface elements (the “tools” of the program) by using images of the actions taking place, or illustrated tables of commands.

Show Results of Software Operations

Showing results occurs on all three levels of task orientation—teaching, guidance, and reference. An illustration of a tool combined with an illustration of the result of it’s use, work together to support the operation/result model of instruction.

Keys to Usability

Additional ways that illustrations can be used to support task oriented usability include:

• Presenting overviews to integrate software with workplace activities
• Suggesting functions and uses
• Making abstract concepts concrete through metaphors

Barker concludes with a glossary and checklist for incorporating and evaluating the use of graphics in a project.

Selfe & Selfe - The Politics of the Interface

The Politics of the Interface

Cynthia L. Selfe and Richard J. Selfe, Jr.

Introduction

The authors begin their article by recounting a story that was told to them by a colleague. Upon returning from a trip to Mexico, an Indian-born resident alien professor was detained at the border and eventually fined, since he did not have the required documentation to enter the country. The authors view this incident as an example of imperialism and unjustness, and use it as an analogy for the politics of computer interfaces. “It is at the geopolitical borders of countries,” state the authors, “that the formations of social power, normally hidden, are laid embarrassingly bare—where power in its rawest form is exercised.” They go on to state that teachers who use computers to teach English often contribute to the establishment and maintenance of these sorts of borders in their own classrooms, characterizing this activity as “the systematic domination and marginalization of…women, non-whites, and individuals who speak languages other than English.” In their article, the authors hope to describe the political and ideological boundaries associated with computer interfaces, ways in which these boundaries are constructed along ideological axes, how borders in computer interfaces can be mapped as complex political landscapes, ways in which borders can prevent the circulation of individuals for political purposes, ways in which students and teachers can learn to see and alter these borders in productive ways, and tactics that teachers can use to enact a radical pedagogy of electronic borders.

Computers as Learning Environments: History and Motivation

In this section, the authors begin by discussing the increase of computer technology within the field of English composition instruction. Computer-supported learning environments have generally been viewed optimistically by teachers, as “places within which teachers and students can try to enact educational practices that are more democratic and less systematically oppressive.” The authors quote research, however, that demonstrates that minority students and those of lower socioeconomic status remain a “technological underclass”, and are the least likely to gain computer skills during their public schooling. In order to face this reality, instructors are encouraged to become both technology users and technology critics, reflecting on the cultural and ideological characteristics of their technology.

Mapping the Interface of Computers as Educational Space

The authors acknowledge the ambitiousness of such a project, and declare that they will focus specifically on computer interfaces. They go on to describe interfaces as “cultural maps” of computer systems, maps that have ideological underpinnings. Like all maps, they reflect the historical and social values of the culture that produced them. “Primary computer interfaces,” they state, “do not…provide direct evidence of different cultures and races that make up the American social complex, nor do they show much evidence of different linguistic groups or groups of differing economic status.” Instead, the authors argue that these interfaces tend to exhibit the “monoculturalism, capitalism, and phallologic thinking” of “male, white, middle-class, professional cultures associated with the military-industrial complex.”

Interfaces as Maps of Capitalism and Class Privilege

The authors present examples of how these maps are exclusive, in that they based on a world that middle- and upper-class users know and are comfortable within. This includes using analogies such as the desktop, folders, files, documents, telephones, fax machines, clocks, watches, and calendars. They suggest that alternative icons could be used to represent different worlds, such as a kitchen countertop, a mechanic’s workbench, or a fast-food restaurant. They describe the white pointer hand in the Macintosh interface as a semiotic message about race. They also identify clipart collections as including images that are predominantly white, professional, and office-oriented. The authors also an association between computer use and capitalism, as more and more people are subscribing to internet service providers in order to access online information.

Interfaces as Maps of Discursive Privilege

Primary interfaces, the authors assert, tend to reproduce the privileged position of standard English as the default language of choice. Computer users must often pay extra to purchase versions of software that have been produced in other languages. Using English versions of software forces students from other races and cultures to “submit to the colonial power of language and adopt English.” The authors go on to describe the fundamental level at which many computer systems are based on English, so that even non-English speakers much make use of English symbols, such as those contained in the American Standard Code for Information Interchange (ASCII) character library.

Interfaces as Maps of Rationalism and Logocentric Privilege

In addition to the previously mentioned interface associations, the authors also believe these interfaces to be aligned with “values of rationality, hierarchy, and logocentrism characteristic of Western patriarchal cultures.” These values inform how information is represented and limit alternative possibilities. The article goes on to describe ways in which this hierarchical framework is actually limiting computer development. By incorporating methods of data representation such as “bricolage”, which refers to the construction of meaning through the arrangement and rearrangement of concrete materials in an intuitive rather than logical manner, the authors look forward to interfaces that exhibit the “epistemological pluralism” proposed by Turkle and Papert. Taken together, these interfaces “do violence to” minorities, imposing “a master narrative that resonates…with modern myths of technological progress.”

What to Do?

To respond to this phenomenon, the authors recommend that educators begin by locating themselves in relation to the map. Are we the cartographers creating the map, or the members of a dominant group that profits from it? We can then attempt to view the map from other vantage points to get a broader perspective. In this way, educators are better equipped to teach students how to view the interface “as an interested and partial map of our culture and as a linguistic contact zone that reveals power differentials.” Educators can also work with students and computer specialists to reimagine and redesign interfaces such that they avoid “disabling and devaluing” minorities. The article presents several tactics for accomplishing this.

Becoming Technology Critics as Well as Users

One tactic proposed for addressing this issue involves working to encourage a general level of critical awareness about technology issues among current teachers, and those planning to teach. As technological literacy and training is promoted within academia, it is important to also teach technological criticism, so that instructors think carefully about the implications of using technology in their classrooms.

Contributing to Technology Design

Humanist scholars and teachers should be involved in the practice of interface design. In some cases, this involvement can occur directly. However, since most instructors will not be directly involved in designing computer interfaces, they can influence the process by promoting collective professional action aimed at general technology design efforts. Online discussion forums can also be utilized in promoting this aim.

Reconceiving the Map of the Interface

Another strategy would be to involve composition teachers and students in a project to revise interfaces as texts. These projects can involve reconceiving interfaces according to a broad range of perspectives. New ideas for interfaces based on a range of “cultural, linguistic, and ideological perspectives” can be designed and expressed through either prose descriptions, drawings, or computer illustrations. This process could also include assembling libraries of icons and images that represent a diverse range of cultural values.

Toward a Critical Reading of Interfaces

The goal of eliminating oppression in our society represents a broad, ongoing challenge involving every aspect of life. For this reason, English teachers must work to bring these issues to light as they relate to computer interfaces. The article concludes with a quote from Winograd and Flores, who state that, having identified the ideological boundaries inherent in computer interfaces, we have a responsibility to “work towards unconcealment…and let our awareness guide our actions in creating and applying technology”.

Barker - Chapter 11 - Laying Out Pages and Screens

Writing Software Documentation: A Task-Oriented Approach

Thomas T. Barker

Chapter 11 – Laying Out Pages and Screens

This chapter describes two main elements of document design: the design of the screens and pages and the design of type. Barker begins by presenting several graphics illustrating major trends in page and screen design.

Guidelines

Barker’s 6 Guidelines for designing pages and screens proceed as follows:

1. Review the User Analysis

The goals of layout resemble those of document design in general. First, it’s designed to meet dynamic needs with a static document. Second, it should support overall task orientation. And third, it should accommodate the visual needs of the user, the need to learn and do through images rather than words.

2. Create Page Grids

Page grids define communication spaces by drawing invisible “fences” around areas of a page. They act like a scaffold or framework onto which text and graphics can be anchored.

These can incorporate design elements such as:

• Grid lines
• Margins
• Columns
• Gutters
• White space
• Baseline

3. Define the Page Grid Using Styles

The page grid defined in the last step should provide a road map for almost all your pages. At this point, you should define the styles that you want to use to set up the pages. This includes page elements such as margins, gutters, line spacing, the size and font of text, and so forth. Special concerns when designing for the screen include elements such as column spacing, arrangement of headings, and how hyperlinks are indicated.

4. Draw Thumbnail Sketches

A thumbnail sketch uses lines and spaces to show how pages should be organized. One method for producing these involves folding a piece of paper in half multiple times to produce a grid. At this point, you may draw in margins, columns, and page features. It helps to model your page design on a design you have seen that seems particularly suited to your project.

5. Set up Pages and Styles in Your Word Processor

Using a word processor or desktop publishing program, you can establish specifications for pages by defining both styles for text and page setup parameters. There are two very important reasons for using styles. These include:

• The styles can be changed later at a global level
• The styles ensure consistency across a document set

6. Determine the Layout of Help Documents

Screens offer an array of features you can use to create a usable and intuitive design. These include frames, narration strategies, hypertext links, and image maps. Remember that users search for information differently on a screen than on a page. It is important to understand the constraints of page and screen design, and how they differ. Barker presents a table listing some of the differences between page and screen layout elements.

Discussion

Designing Communication Spaces

There are two important aspects to any document that need to be decided:

• The degree of modularity pages and screens need
• The degree of structure pages and screens need

Modularity means breaking the information into chunks of text and graphic units to make them easier for the user to digest. Ask yourself if your page design contains all of the information needed by users to perform and fully understand the task. Barker quotes Edmond Weiss’ assertions that modules should be functional, independent, and small, providing greater ease of access that unlocks information. Online help documents can segment information more easily through the use of pop-up windows, expandable text, and rollovers.

Structure refers to the arrangement of information according to patterns. This requires defining spatial relationships between chunks of information. Research into how people process information has shown that individuals locate information in documents by remembering the physical location of information on the page. Elements that contribute to structure in a document include:

• Rules
• White space
• Bullets
• Chunks

Common Page Designs

In this section, Barker lists some common page designs. These include:

Two-Column Format: Allows the user to easily distinguish between guidance information and support information, and works best with procedures and step-by-step instruction. It is not as dense as a one-column format.

One-Column Format: This format keeps task information together in a linear form, and can be a good way to present long sections of prose.

The Elements of Page Design

In this section, Barker lists and discusses various elements that the document designer must consider in order to produce an effective document.

• The Left Margin
• Columns
• Headers and Footers
• Icons and Diagrams
• Screen Shots
• Rules
• Pagination

Barker concludes with examples of common page and screen designs, a glossary, and a document layout checklist.

Barker Chapter 12 - Getting the Language Right

In this chapter, Barker discusses the role language plays in helping the manual and help system attain the goal of supporting information-oriented work. He begins this discussion my noting the ways we process information and that there are two central difficulties that many problems in the language of software documentation revolve around: failure to write so that the user can perform the task easily, and failure to write as if we were speaking to real human beings.

Next, Barker provides a list of guidelines for ensuring that your style is oriented to users’ needs.

Write About Actions Rather Than Functions
Instead of simply giving a definition of the function, you should answer the question of “Why would I want to perform this function?” If you identify the object and tell the read what to do with the object, you are creating a set of tools to help the user do their work.

Revise for the Active Voice
Passive voice makes a passage seem impersonal, which will make the reader feel manipulated uncaringly. Active voice is more personal and direct, which makes the reader feel empowered.

Revise to Keep Writing Simple
You don’t want your reader to waste time rereading sentences, so try to make passages simple. Simplicity helps every aspect of software manual writing and you should strive for simplicity in each sentence.

Revise to Build Parallel Structures
Parallel items acknowledge the similarities between concepts and express that similarity in matching grammatical structures. This is one of the best solutions to the problem of using the user’s short-term memory effectively by helping readers remember even though they may not recognize the pattern.

Add Operational Overviews
Because users often read for meaning, you should provide prose passages containing clear overviews of concepts as well as straight procedures; users appreciated learning the conceptual model of the program and how the program does its processing (389).

Barker then begins a discussion about language, learning, and how to effectively present information in software documentation.

How Do We Process Language?
Barker writes that to set goals of language use to support task orientation, you must first look at how readers process language. He notes that the act of reading requires that the concept in the reader’s mind bond with words on the page and that the words register as significant, which is meaning. The words don’t convey meaning to the reader, but the reader brings meaning to the words. The more clearly writers can anticipate that task the more task-oriented the manual.

Performance-Oriented Language
Performance oriented software documentation is when there are clear explanations of how to perform using the software. Using the active voice, using the ‘you’ pronoun, and using the imperative verb add to the performance orientation of the style. You should write to an actual human being, which will make the documentation less stuffy, formal and robot-like.

How Do We Remember and Learn?
After finding the right answer, users must remember the idea until they get back to work. This means that the writer must rely on both short and long-term memory. You should strive for a style of writing that has words that connect to the users’ mind, which will make it easier to remember. To do this, you must structure the sentences carefully using the following sentences: patterned, highly parallel, balanced, and sentences that end in three rhythmic clauses.

Style Problems in Software Documentation
Barker writes that problems with style in software documentation relate directly to your overall goal of making software easy to use. He then provides some of the problems associated with writing in software documentation.

• Acronyms: Users can often understand common acronyms such as DOS and RAM, but the difficulty comes when some of the terms constructed as part of the computer program or system appear in the document. You can’t always avoid acronyms and abbreviations, but try to use a few of them in a sentence at a time.

• Synonyms: You should use these consistently and accurately as to not confuse the user. You should also try to use the terms that users will most likely recognize and build in crossover techniques, such as synonyms in parentheses.

• Paragraphs and Sentences Too Long: Paragraphs should focus on explanations, not performance, and not on steps telling the reader what to do. It is best if the writer can forget about paragraphs and just think in terms of lists and chunks of no more than three sentences.

• Emphasizing the Computer Instead of the Program: A writer must remember that a computer doesn’t perform tasks, the program does. When writing software documentation, you must think about the program performing the functions, which will also help promote the program.

• No Connection between the Heading and the Topic: Often, in a manual, headings are following by paragraphs explaining a program. However, the information in these passages doesn’t always match the heading. Instead, the writer has included one or two relevant details about the program, which get presented in a highly technical language.

• Too Formal Tone: Software documentation is intended for real people, so it shouldn’t be too formal. According to Barker, speaking in a informal tone—without being overly familiar or presumptuous—makes contact more quickly and evokes the user’s desire to do well on the job. You can incorporate an informal tone into your writing by using the following characteristics: use of contractions, reference to other users, and humorous aside.

• When to Use Humor: Barker writes that humor sparks as much controversy as it does good feeling in manual writing. Bad humor can cause a user to reject a manual. Common sense tells us that humor will not work in all kinds of documentation, especially sections where the user simply looks up information. You should always test humor before the final draft.

• Ambiguous Task Names: In task-oriented documentation you should name tasks clearly, with a sense of planning for the user’s new vocabulary. Don’t fall into the tendency of referring to tasks vaguely because this leaves the user with more questions.

• Step Not a Step: The step constitutes the basic element of human-computer interaction, so you should make sure that each step is actually a step and not just a guide or information about the previous/next step.

• Omitted Articles: Barker ends the chapter by discussing the tendency for software documentation to fall into the telegram style of writing. We don’t have to pay for words anymore, and such attempts to leave out articles to sound official fall flat. Since you are communicating with real people, you should use real language.

We're Thinking About Going On-Line

Campbell Chapter 12

In this chapter Campbell discusses putting policies and procedures online. She mentions that going online doesn’t change your policies or procedures it simply creates another method of communication beside written or verbal. She mentions the advantages and disadvantages of going online.

Advantages:

• Faster retrieval and faster circulation
• No paper revisions
• Easy storage
• Can link related facts or documents together in a way that gives users faster access.
• Easy access to the manual
• Fewer deadlines
  

Disadvantages:

• May intimidate users who are not computer literate
• Could by costly (software, hardware, etc.)
• Need for training
• Format limitations
• Lower readability
• Some users may not have access to retrieve document from a computer
• Reading from a screen is not always preferred
  

Campbell mentions that there are certain questions the writer should ask about the user:

• How experienced and comfortable are users with computers?
• What kind of equipment do they have?
• What kind of software do they have?
• Do they have read access to a terminal
• What format are they used to working with and do they prefer?
• What’s their environment like?
• Are their organizations supportive
• Will they really check the system regularly for updates?
• How can they be made to acknowledge receipt?
  

Designing an On-Line System

In this section Campbell discusses being aware of the limitation online documentation creates. Knowing what the user is reading from meaning what kind of computer screen they have and that it is harder to read on screen than on paper. She mentions four factors to keep in mind while designing:

1. Visual simplicity
2. Ease of use
3. Clear operating instructions
4. Adequate conversion of elements such as acknowledgements and revisions

Finally Campbell talks about making sure the users know when the document has been released and when revisions have been made. Most importantly she mentions to make sure the user receives and uses the online policies and procedures.