Howard - Who “Owns” Electronic Texts?

Who “Owns” Electronic Texts?

Tharon W. Howard

Introduction

In his article, “Who ‘Owns’ Electronic Texts?”, Tharon W. Howard explores intellectual property law from a historic and philosophical perspective to better understand how notions of copyright are being challenged by current advances in mass communication technologies. Most writers, he states, tend to believe that authors “own” their texts, and can assert control over how they are used. The trend toward collaborative writing processes and online distribution of texts has raised many intellectual property issues that writers are unprepared to deal with.

Howard then presents five potential scenarios illustrating the intellectual property dilemmas that modern writers face.

Scenario 1 involves a company that would like to incorporate a famous photograph located in a popular magazine into the cover of their annual report. How should the document designer proceed?

Scenario 2 imagines an individual being asked to install a piece of software on their work computer, even though it has already been installed elsewhere.

Scenario 3 questions if one can legally and ethically quote from an email message posted to a listserv in a scholarly article. Is this an obligation, and who controls such a text?

Scenario 4 explores whether a personal correspondence between individuals via a company email system should be considered private. The computers are owned by the company, but does that give other employees the right to monitor and reproduce such personal messages?

Scenario 5 describes a faculty member compiling a list of hyperlinks to potential employers’ job listings for job-seeking students. If these businesses are derived from a published book of business listings, does the creator have an obligation to pay royalties if their hyperlink system is published?

These scenarios, state Howard, reveal the way in which intellectual property issues are becoming an increasingly large concern in the workplace. In fact, an understanding of intellectual property and copyright in this environment could very well be considered a necessary component of electronic or computer literacy.

A Historical Overview

Unbeknownst to most people, copyright laws did not come about as a means to protect the “natural property rights” of authors. Rather, they represent a limited privilege that is granted to authors by the state for a variety of reasons. Following the invention of the printing press in the 15^th century, stiff competition between publishers established a need to protect their ability to profit from works they had purchased and printed. The easy mass-production of texts also took control of published works away from the Church and the government, allowing the dissemination of dissenting viewpoints. These developments led to the establishment of copyright laws, the purpose of which was to protect the financial interests of publishers and censor dissenting voices. England’s Statue of Anne, and the U.S. Constitution expand on these privileges, but remain grounded in the notion of copyright as “a privilege or license granted by the government for a limited period of time in order to promote not only the right of authors to profit from their labors, but also the enhancement of the public’s collective welfare.”

Major Principles of U.S. Copyright Law

The goal of U.S. copyright law is to strike a balance between the rights of an individual author and the good of the public. For this reason, the fundamental principle of “fair use” has existed throughout our history. In determining whether any particular case represents fair use, there are no black-and-white rules, rather there are a series of factors to take into consideration. Ideas themselves cannot be protected. One reason for this is that ideas are seen as universal truths that are accessible to all and cannot be owned by a single person. Also, because an individual’s ideas are dependent upon many ideas developed by others, an idea is a communal property. Copyright is only meant to protect an author’s specific expression in a fixed tangible form.

Copyrights in the Electronic Environment

Even when they are properly understood, these principles do not always yield clear answers when dealing with electronic texts. However, a broader understanding of copyright principles can still serve as a useful guide for professional communicators.

With this in mind, Howard now returns to his scenarios to see if this informed perspective sheds any light on the issues they embody.

Scenario 1

In the scenario involving the repurposing of a famous photograph, its inclusion on an annual report would likely fail the test of fair use. The document designer should seek to obtain permission and a copy of the original image from the original copyright holder.

Scenario 2

This scenario expresses a common misconception that an individual or company “owns” any software that they have purchased. What is actually purchased is a limited license to use the software in a certain way.

Scenario 3

In scenario 3, it would probably be legal for an individual to quote from an email, but the situation quickly becomes “clouded by the technology involved”. The author of the email may believe that copyright has been violated since she wasn’t able to publish her material through a more traditional means before it was copied, diminishing its value. However, the very act of sending this email to a discussion group would likely be considered a form of publication. Legalities aside, the most ethical course of action would likely be to procure permission from the author before quoting her.

Scenario 4

Usually, a company is the sole copyright holder of the texts produced by those in its employ. In some jurisdictions, there are laws which protect the privacy of personal communications between employees. Regardless, this scenario is less a question of copyright than it is of personal privacy.

Scenario 5

Determining whether the reorganization of data compiled in another source constitutes a copyright infringement is a tricky one, and cases have gone both ways. Howard predicts that this will become an increasingly prevalent issue with the advancement of computerized database systems in which information is automatically stored, manipulated, and accessed in a wide variety of ways. The most conservative course in this scenario, Howard concludes, would be to contact the publisher of the reference materials and attempt to work out a financial arrangement before publishing any repurposed material.

Conclusion

The advancement of electronic information technologies has created many challenges to our current model of intellectual property law. “It may well be,” states Howard, “future copyright laws will need to find radical new foundations.” Today more than ever, professional communicators need a more thorough understanding of the history and philosophy behind intellectual property law.

Barker Chapter 14

Designing Indexes

Manual Indexes:
The basic procedure for creating an index is:

1. Review the user analysis. This will refresh you memory about the main actions and activities in regards to the software and can be used as a reference when deciding on what terms are important.
2. Pick out terms or phrases that you want to index. Typically tables, figures; examples; definitions; acronyms; main topics; important concepts; main tasks; tool buttons; keyboard shortcuts; menu names.
3. Record the locations.
4. Alphabetize and edit the index.

Electronic Indexes

Advantages of using this method are:

• Automatic alphabetizing
• Automatic formatting
• Ease of revision

The process resembles manual indexing but differs in a few ways.

1. Review the user analysis.
2. Mark the index entries.
3. Build the index.
4. Edit the index.

What to Index

• Command and Functions. These include all of the terms that you find on menus, as well as control and Alt key functions.
• Concepts. The ideas related to the subject matter of the program.
• User Terms and Questions. Relating words to synonyms that a user might know, i.e. a user wants to "quit the program", your program calls it "exit".
• Glossary Terms
• Proper Names of Products and Companies
• Tasks and Procedures

Level of Detail

• A light index will have two to three items per page.
• A medium index will have five to seven items per page.
• A heavy index will have eight to nine items per page.

Phrasing and Format

• Primary locator numbers; the page number where the main information occurs. In some indexes this page number is in bold.
• Capitalize terms.
• Make entries sound like sentences.
• Special terms.

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.

Gender, Technology, and the History of Technical Communication

In her article “Gender, Technology, and the History of Technical Communication,” Katherine Durack examines the history of the female role in the technical communication field. She begins her discussion by noting the absence of women in the recorded disciplinary past. One possible reason is that “women have contributed only very rarely to technical and scientific work” (36). If this is true, and scientific inquiry and technological innovation have been primarily the work of men, then the contributions of women may have been consequently lost, subsumed, or overlooked. Another possibility is that the absence of women may have been due to historians and not actual historical reality.

A “Peculiar Set of Cultural Blinders”
Although those in the field of technical communication have yet to agree on a single definition, technical writing often contains either or both of two key characteristics: a close relationship to technology, and an understanding that technical writing is associated with work and workplace (36). It follows then that what is understood as technical writing comes from what is considered technology, work and workplace. The assumption is that these terms are gender-neutral, and that addressing the matter of gender and the history of technical communication is as easy as searching for women who have distinguished themselves in scientific, medical and technical fields (37). However, this view is often contested because of its simplistic view that inadequately addresses biases from our past and future.

History and Women’s Work
History, including the history of technical communication, primarily focuses on the works of great men and the great works of men (37). In both of these cases, there is a need to establish significance, which usually involves prerequisite location in the public sphere. This public sphere is male dominated, while the private sphere is generally the realm of women. The activities of women have typically been omitted because history focuses on public and political activities and innovations. To include women’s work in the history of technical communication, “we [must] contest two assumptions that lead to their exclusion from our disciplinary story: First, (the assumption of agency) that women are not significant originators of technical, scientific, or medical achievement; second, (the assumption of technological significance) that women’s tools are not sufficiently technical, nor their work sufficiently important, to warrant study of their supporting texts” (37).

Women as Significant Contributors to Science and Technology
To overcome the first assumption, women need to be identified who have contributed significantly to science, technology and medicine. Then, their written works must be fit into technical communication history. The main difficulty facing the historian is the apparent lack of women’s contribution to these fields. Women, like men have undoubtedly sought means for improving their work processes, but their significance may be obscured by having been misclassified, trivialized, or attributed to men (37). Women’s inventions may have been under-reported because they weren’t ‘real’ inventions of technology such as weapons and machines.
Often, when women did invent ‘real’ inventions, they were left off the patent record. Some reasons for this include: women’s lack of disposable income and time, married women in the United States and Britain could not own their inventions or patents until the Married Women’s Property Acts passed, the necessary technical and mathematical training necessary to build models of inventions and patent them was not available to women, cultural stereotypes discouraged women from taking credit for their achievements, and these same stereotypes encouraged women to be generous, thus sharing ideas instead of profiting from them (38). Technologies that pertain specifically to women’s biological functions and social roles, including the baby bottle and sewing machine, have essentially been ignored by historians (38).

Women as Significant Users of Technology
Addressing the second assumption involves a different strategy: departing from conventional history to challenge existing definition, seeking a “a new narrative” that focuses “on the casual role played by women in their history and on the qualities of women’s experience (39). The industrial revolution brought about great technological innovation and increasing differences about appropriate work roles for men and women. Women are often seen running machinery, but it is rare to see them actually knowing what goes on inside the machine. During World War II, women were expected to help out, but as soon as the men came home, they needed to return to their homes. Even when a woman is skilled at a job, such as sewing, they are often underpaid because it is a ‘woman’s job.’ Men remain predominantly the makers, repairers, designers, and uses of what we typically consider technology, while women hold household jobs, which are unrecognized and generally unpaid (39).

“The periodic submittal (and rejection) of texts such as cookbooks to the Society of Technical Communication’s annual publications competition demonstrates the difficulty we have with considering as ‘work’ a productive activity that is typically assigned to women and accomplished within individual households without benefit of financial compensation” (40). Durack adds that when a man tinkers in his garage it is considered a significant invention, but when a kitchen doubles as a chemistry lab it is often discounted as technological.

The Household as a Setting of Consequence
The current focus of workplace writing as a definition of technical writing fails to recognize the household as either a workplace or a setting of consequence. Writers in organizations are more easily studied and compared, therefore individual household are often excluded. However, there are significant instances of technical writing and use of technical documentation that occur in the household since many products are geared toward home use (40). These include computer hardware, lawn mowers, blenders and credit card agreements. There are many instances in which private individuals must interact by text with organizations (41). Also, many people are starting to move the traditional workplace into their household.

Toward Inclusive Definitions
Durack concludes by writing that “if we are to include the accomplishments of women in the history of technical communication, we must first challenge the dualistic thinking that serves public and private, household and industry, and masculine and feminine labor” (41). She notes that she doesn’t know if it is possible to construct a single definition of technical communication that can accommodate both past and future changes in the meaning and significance of work, workplace and technology, but she offers the following observations.

• Technical writing exists within government and industry, as well as in the intersection between private and public spheres.
• Technical writing has a close relationship to technology.
  
• Technical writing often seeks to make tacit knowledge explicit.
  

She concludes her essay by stating “as we construct the history, a major challenge will be to examine why we deem certain artifacts technology, their attendant activities work, their place of conduct the workplace, and therefore find reason to include associated writings within the corpus history of technical writing” (42).