In facing the challenge of efficiently communicating with a large number of microcomputer users, there are a number of possibilities. Some of these involve the very technology that is being discussed. A computer bulletin board, for example, lets microcomputer users with the right equipment call up over regular telephone lines to connect to another computer. This allows the users to log on and read news bulletins and other information, share ideas and send messages to fellow computer users, and even copy programs and other files from the bulletin board computer to their own computer. The problem with this at Shippensburg University was that most offices do not have the necessary technology (including a modem and communications software to make the telephone connection) to accomplish this. In addition, administering a computer bulletin board can be very time-consuming.
Another solution is the development of a computer magazine on a floppy disk. This involves a program that would display information on the computer screen, demonstrate sample programs, and perform other functions. This method is sometimes used by software companies to communicate with registered owners of their products, and there are also some commercially distributed magazines (such as Big Blue Disk) in this format. The problem with this solution is the amount of time involved in preparing it, plus the cost and trouble of distributing these disks to hundreds of computer users on campus.
A more practical solution is to develop some kind of traditional publication, such as a newsletter, that could be distributed to interested individuals. While preparing a publication can take some time, it is still less involved than running a computer bulletin board or creating a magazine on disk. In addition, microcomputer tools such as desktop publishing software and laser printers make it easier for individuals without a publications background to prepare high-quality documents. Because of the widespread presence of microcomputers not only at work but also at home and in schools, such a publication can be of interest to a large number of people.
In planning the types of support services my office would provide, I decided that some sort of publication could be an efficient way to convey information to a large number of people. The university's Public Relations Office distributed a newsletter called Fact to all staff and faculty every other week during the academic year. Fact contained news of interest to the campus community, including a schedule of upcoming events, notes about professional activities and accomplishments, and other types of news items. If a computer newsletter were included with Fact, there was the chance to reach this wide audience with news, tips, answers to computer questions, and other information that could help increase computer literacy.
In late 1987, I began discussions with the publications staff about developing a newsletter for microcomputer users. There were some questions to be answered before starting such a project. The first was: is this sort of thing too specialized for a general audience? We considered the growth in the number of microcomputers on campus, which provided a large audience with an interest in the subject. In addition, the growing use of computers in elementary, secondary, and higher education made the subject important both to faculty using computers in their courses and to staff who had children in school. As a general matter, the increasing use of computers in other areas of society, including at home, made the subject of interest to staff who did not already work with computers.
Once it was decided that the subject was of interest, the next question was what format to use. If it was included as a regular part of Fact, even on a separate page, it might be overlooked. We decided to make it a special insert, a two-sided single sheet that could be removed and saved. The schedule would be to have it appear in every other edition or roughly once a month.
It terms of the style of the publication, it would have to appeal to as many microcomputer users as possible by covering subjects of general interest. The material would have to be presented in a way that would not intimidate beginners, but would still be of interest to those who had developed their computer skills. The writing style would need to be clear, concise and understandable to an audience that was not technically sophisticated.
One concern I had was how the publication would be produced. If I provided copy to the publications staff, I was afraid that they would be unable to edit it properly because of their lack of knowledge of the subject matter. In addition, I felt that the way the material was presented would be very important as to how it was understood. For example, the use of boldface type or italics could help clarify the meaning by setting certain words or phrases apart from the main text. After discussing the matter, they agreed that I could provide them with camera ready copy. The graphic style and the content would be up to me, although it would be subject to review.
Once these issues were resolved, I began work on developing the publication. My goal was to have the first issue ready at the beginning of the 1988 spring semester.
The first step in developing the publication was to narrow the focus of the subjects covered. Since the primary goal was to communicate with microcomputer users on campus, I decided to concentrate on the hardware and software most commonly used in university offices. Although there were no standards dictated, the configuration adopted for academic department offices was widely used by other areas. The hardware included an IBM PC-compatible Zenith microcomputer with a hard disk and an Epson letter-quality dot matrix printer. Software used included WordStar Professional Release IV for word processing, Lotus 1-2-3 Release 2.01 (a spreadsheet package), and dBASE III Plus for data management. WordStar was used on almost every microcomputer on campus at the time. Lotus was less widespread, but still used in a number of departments. Because of its complexity, dBASE was far less common, but it was used by those who needed to manage large amounts of data.
The next step was to decide on a name. After considering some obvious candidates (Computer Notes, Micro News), I decided on PC Notebook. I used PC since the focus was on the IBM PC-compatible microcomputers that were used in most offices. Right away, however, I had an example of the type of problem I was facing. In the industry, PC was generally understood to refer to any of the many computers that used the MS-DOS operating system and were compatible with the IBM Personal Computer (or IBM PC). For most people, however, PC appeared to be an acronym for the term "personal computer," a more generic category that included Apple II, Apple Macintosh, Commodore and other types of systems. I tried to clarify this distinction in the first issue, but I was never totally successful. With the second part of the name, "Notebook," I tried to give it a somewhat friendly, non-technical and non- threatening sound. I also hoped to imply that these issues could be collected in a notebook for future reference.
The third step in refining the concept was to decide on the layout of the publication. Using the title as a guide, I decided to try to make it look like a notebook page. I used a box around the page with rounded corners similar to a piece of notebook paper, and I placed three shaded circles where holes might be punched to place it in a three ring binder. Besides reinforcing the notebook theme, this format would also make it stand out in Fact.
To avoid clashing too much, the rest of the layout was somewhat similar to Fact. The text was arranged in a three column newsletter format. The main body used a Times Roman 10 point font, which was a fairly common text typeface. The columns were justified and the first line of each paragraph was indented. Main headings used a slightly larger Times Roman bold, while subheadings were in Helvetica bold.
The final step in refining the concept was to choose an appropriate writing style for the publication. In order to encourage readers who were not technically proficient or who were intimidated by the technology, I felt it was important to have a non-threatening tone and a friendly voice. Using the second person to address the reader personally seemed to be an effective way to get information across. This also provided a way to avoid using the passive voice; instead of saying "if a file name was not provided when the copy command was given," for example, I would write "if you did not provide a file name when you gave the copy command."
I also made an effort to avoid jargon and to explain technical terms whenever possible. This was often difficult, since the development of microcomputers has not only brought new technology to society but new language as well. Besides terms like word processing, spreadsheets, and booting up, the language of microcomputers includes an array of acronyms such as CPU, RAM, ROM, KB, MB, CGA, EGA and VGA. As I wrote, I tried to keep in mind that not all of this language was clear to my readers.
In preparing PC Notebook, I generally relied on my instincts to develop a writing style. Subsequent research has shown me that most of my choices were appropriate for the type of writing I was doing. Much of the literature on technical writing about computers before the mid-1980s focused on documentation and manuals for mainframe systems. Those books that dealt with microcomputers also concentrated on preparing a manual that could instruct readers on the use of a commercial or customized software package. Many of the suggestions and guidelines in these books, while not specifically about preparing a newsletter, were applicable to my attempt to communicate with microcomputer users.
For example, in a guide on preparing documentation for mainframe data processing systems, William L. Harper identifies a central challenge:
One of the most difficult problems of technical writing is trying to write like someone else thinks. Do not try to copy someone else's style of writing. Be yourself. Use simple, everyday language, and straightforward writing. Write the way you talk-- almost. (245)
His book is addressed to data processing professionals who are responsible for developing documentation. He states that "the technical writer's purpose is to write a clear, brief, and technically correct DP document, rather than prose to persuade or convince" (247). To achieve this goal, he gives suggestions for an appropriate writing style:
DP technical writing should contain short sentences and common everyday words. The sentence length and word difficulty are the most important factors in measuring readability. Words that the reader can easily understand should be put in short and uncomplicated sentences. Technical writing that is easy to read is usually easy to understand. (258)
Harper points out that the technical writer does not need to be overly concerned with the rules of grammar. He suggests that basic rules be followed, but that the writer concentrate on a clear and simple explanation of the subject. He summarizes his advice by stating:
DP documentation should be written in simple English for practical purposes--to convey exact meaning and aid rapid reading. Writing is readable if it easily communicates thoughts to the reader. To do this, the writing must be clear, concise, complete and simply written. Simplicity is the key to technical writing. (270)
In another "how-to" book on creating user documentation for mainframe systems, Emanuel Katzin also stresses the need for a writing style that is clear, simple and concise. "Simplicity and directness are prime virtues for informational and instructional writing," he notes. "They save time and prevent confusion" (19). One of the most important attributes of a good user's manual is readability. Unless the intended audience is actually reading the documentation, the information is not getting across. This readability can be achieved with the proper writing style:
Readability insists that writing be simple, direct, and crisp--so that any reader, regardless of education or training, can understand. Writing should be straightaway, without backing into phrasing. (11)
Although these guidelines should be applied to all technical writing, Katzin stresses the importance of targeting the writing for the audience:
Knowing the professional background of the User is virtually a necessity for deciding the level of sophistication the writing style must have. Different qualifications require different communicating techniques. (9)
This does not mean that the technical writer should ignore the goal of simple and direct writing. It is possible, with a more sophisticated audience, to leave out certain explanations or to use technical terms that the readers will understand.
With PC Notebook, the intended audience had a range of technical skills. I hoped to reach clerical staff with limited exposure to microcomputer equipment and technology, as well as faculty and administrative/professional staff who were eagerly exploring the possibilities of this technology. In order to avoid losing some of the advanced readers, I did not include those who knew absolutely nothing about microcomputers. By assuming a basic level of familiarity with the PC, I could avoid explaining every single term. I also tried to build on the topics that were presented in each issue, so that the users would develop their skills as we went along.
Susan Grimm, in a guide on writing computer documentation published in 1987, deals with manuals prepared for microcomputer users as well as for individuals working with mainframe systems. She notes the growth of microcomputers and their use by non- technical people in offices and homes:
These new users, especially, require excellent and thorough documentation. They are often working alone with their microcomputers. Because they are new and have no one readily available to help them, microcomputer users will be less tolerant of inadequate documentation. (2)
Grimm recognizes that writing about microcomputers is particularly challenging because the audience does not have experience working with such technology. "The prevalence of microcomputers in offices," she notes, "means that many users who are very knowledgeable about their own job responsibilities but have never seen a computer before are technically unsophisticated" (30).
One of the most important qualities in writing for this audience is understanding the reader, and Grimm suggests that "writers without a technical background have an advantage in this area. It's easy to understand the users' frustration with computer terms and their bewilderment about what the computer really does" (28). Like Katzin, she stresses the importance of shaping the writing style to the abilities of the intended audience:
The users and their needs determine the kind of language you will use. Obviously, you would use different kinds of words if you were writing for executives with advanced degrees than you would if you were writing for clerical people who have recently completed high school. (34)
The problem for PC Notebook, of course, was that the audience included clerical staff as well as faculty members with doctoral degrees.
As do other authors on technical writing, Grimm proposes a writing style that is conversational in tone. "Address your writing to the reader as if you were engaged in conversation," she suggests. "Besides being more personal, calling the reader 'you' helps avoid a sticky problem for writers--sexist personal pronouns" (80). She warns, however, that a conversational writing style has to be a bit more formal than everyday speech:
We can get away with sentence fragments and incorrect noun/verb agreement when we talk but not when we write. No one talks with visible punctuation marks. If our writing is to be understood, though, we must write with correct punctuation. (79)
Basic grammar rules should be followed, but other archaic rules that don't contribute to effective communication should be discarded (such as not ending a sentence with a preposition).
Vocabulary is extremely important for the writing style: "Usually, words that lead to understanding are simple, everyday words" (77). For example, "use" is better than "utilize," and "start" should be used instead of "initiate." Computer jargon should also be avoided whenever possible. When technical terms must be used, they should be defined for the reader.
Grimm also notes the importance of using language consistently. "Don't call something a 'command' one time, a 'function' another time, and an 'instruction' a third time," she warns. "The reader may think you mean three different things" (81). The writer should also be consistent when using simple words:
Inconsistent word usage that can be understood still can be annoying. For example, you can do many things on a terminal keyboard. You can hit, press, tap, strike, type, and depress the keys to enter, type, or input the data. Decide that users should press the keys to enter data (or whatever combination you prefer), and use those words throughout the manual. (81)
This advice can sometimes be difficult to follow. Using certain words consistently can lead to a monotonous writing style. I tried to use variety in my choice of words without creating any confusion for the reader.
Although PC Notebook was not going to be a computer manual or technical documentation, much of the above-cited advice about preparing such publications was applicable. In approaching the writing, I attempted to have a well-written conversational style, addressing the reader directly rather than having a stilted or passive voice. I tried to achieve a clear, simple writing style that would convey the information clearly and avoid any complex technical jargon. In order to explain procedures properly, I tried to envision the reader as an "average" PC user. After experimenting by writing some sample articles and getting some feedback from microcomputer users, I started to produce the monthly newsletter.