HCI Bibliography Home | HCI Conferences | DOC Archive | Detailed Records | RefWorks | EndNote | Hide Abstracts
DOC Tables of Contents: 828384858688899091929394959697

ACM Fifth International Conference on Systems Documentation

Fullname:Fifth International Conference on Systems Documentation
Editors:Virginia DeBuys
Location:Toronto, Ontario, Canada
Dates:1986-Jun-08 to 1986-Jun-10
Standard No:ACM DL: Table of Contents hcibib: DOC86; ISBN 0-89791-224-1; ACM Order Number 611860
Myths and realities of contract technical writing BIBAFull-Text 1-7
  Zelda Gifford
These ideas may provide one of the more meaningful sessions that you attend because we are going to be dealing with that thing of IDENTITY. The identity of the independent technical writer. Some of you will want to nod off and then there will be some who will be jumping off your seats. You may react, "No, it's not like that," or query "I've really got to know how your experience compares when it comes to ..." (whatever) and out comes a Niagara of questions: your experience, your thoughts, maybe even your outrage. Let me talk about some of the myths in contract writing and let me describe some realities as I've experienced them. Later we'll discuss their ramifications. To give you the context for these experiences, let me give the statistics that arise when I tally the projects listed on my resume. Starting in the late '60s, I did programming (three positions), followed by a marketing position where I sold time on an international time-sharing system. Then I made a shift into technical writing. For eight years, I labored as an employee, doing technical writing in a wide range of computer environments. For the last five years, I've been a freelance writer doing computer documentation in the computer industry in the San Francisco Bay Area. Here is a sample of the types of tasks I've been put to. I've written: manuals to support a product, in house technical notes where one programmer keeps another informed of progress, publicity pieces for trade magazines, a report from corporate management to their backers portraying the concepts and facilities of a proposed product, and several tutorials and quick reference cards. Not including the range of hardware and software involved, the statistics on these contract jobs may give you a sense of the variety of modes in this work. I've participated in 30 writing/editing jobs of which two were co-authoring, four were editing commercial books and one was a technical review of a commercial book. Of these 30 tasks, 10 were performed at the client's place of business and 20 at my Albany office. Incidentally, there were approximately five failures: false starts where the "client" wanted only an estimate or the company rebudgeted for various reasons. In these five years, I wrote 1054 pages of original material and revised 922 pages. In terms of size, 30% of my tasks were for big companies (more than a hundred warm bodies onsite); 50% of my tasks were for medium sized companies (10 to 100 people); and 20% of my tasks were for small operations (1 to 10 wizards). I began by touting myself as a "documentation consultant;" I settled later simply for "technical writer." That's a quick "statistical" look at my experience. But what is its soul? Sometimes contract technical writing is viewed as a top-notch rescue operation. What amount of that is myth and what amount is reality? Let's limit our grantedly breezy discussion to some myths clouding these few issues:
  • the experience you must bring to each task,
  • the image that you project and that the client buys,
  • the services that you really provide,
  • the standing you have within the company, and
  • what attitudes you need for survival and for obtaining nurturance from this
       line of work. When we're done, I hope we'll be better able to engender productive attitudes. Those of you who hire independent contractors will be better able to describe your needs and understand the fears and insecurities of the freelancer. Those of you who are freelancers will see the broader picture of where you fit and understand better how to serve.
  • Artificial intelligence and document processing BIBFull-Text 8-12
      Geoffrey James
    The responsibilities of an editor BIBAFull-Text 13-14
      Diana Patterson
    This paper presents observations and recommendations of a writer, editor, reviewer and publisher. It addresses the conventional publishing arrangements of academic presses and the emerging of corporate publishing, especially "desk-top publishing." This is not a discussion of technology but one of human responsibility toward people and the quality of information.
    Be your own publisher BIBAFull-Text 15-23
      Joan Janes; Marsha Snyder
    This paper is a composite of two talks at the conference and the discussion among the participants which followed.
    Automatic sense disambiguation using machine readable dictionaries: how to tell a pine cone from an ice cream cone BIBFull-Text 24-26
      Michael Lesk
    Generalized markup for literary analysis BIBAFull-Text 27-31
      Cheryl A. Fraser; David T. Barnard; George M. Logan
    Easy interchange of texts among humanistic scholars and development of standard analytical tools for these texts require a standard for marking features of documents for literary analysis. The Standard Generalized Markup Language has been used as a basis for a standard, and the results are compared against a set of requirements for such a tool.
    Adaptable and adaptive systems workshop BIBFull-Text 32-39
      Russell Borland
    Transparent network connection? (workshop): pretending to be almost another terminal BIBFull-Text 40-46
      Chris Hallgren
    Impact of graphics on end-users BIBAFull-Text 47-54
      Kathryn Davies
    Graphics in system documentation are important elements for ensuring that the end-user will actually turn pages and continue using the material that you have produced. Graphic design is a crucial factor for providing a document with eye-appeal and readability, and contributes significantly to the user's impression of the quality of the documentation. This paper will discuss the various types of graphics that CSG uses and our rationale for using particular graphics in certain situations. The focus will be on manuals and product descriptions.
    HOW can we HELP? BIBFull-Text 55-60
      Marjorie Kohli
    Usability testing of computer documentation BIBAFull-Text 61-65
      Mark Zirinsky
    In this talk, we will learn three things: A) Why we should test everything that we produce, B) how to conduct a test, and C) how to use test results. In any project, deadlines must be met. This is especially true when writing documentation for computer projects. Late technical changes, budget considerations, and other constraints make it difficult to meet deadlines. Why would we want to impose another deadline on ourselves?
    Language, art, and documentation: exploring the visual process for greater audience comprehension BIBAFull-Text 66-74
      James Hill
    Technical Writer -- Document -- Audience: The Technical Writer, ever-concerned with providing their audience with documents that will communicate ideas in as clear and concise a manner as possible, has relied all too heavily on the written word to accomplish this objective. This, however, is not enough and further investigation of the communication process is required. The Technical Writer, in order to create new ways to facilitate audience comprehension, must explore the visual process for more progressive alternatives. The result: fusing Language with the visual richness of Art.
    Whole brain computing BIBAFull-Text 75-79
      Bruce E. Rogers
    In our consulting work, we've run across four different types of people in corporations. Perhaps you've seen them around too. The first guy works in finance; we'll call him Walt. If Walt isn't in audit, he should be, since he displays a dazzling agility with figures. He reads balance sheets as a hobby, and he smells funny numbers three pages away. If you want to sell him, you better flood your presentation with data, because his thirst for facts is insatiable. And you don't bother offering Walt wine at a company party if you don't know its vintage. The second person we see holds a position such as Director of Personnel. Kathleen, we'll call her, is one of the best organized people you've ever met. She carries off an impossibly busy schedule with aplomb, gliding effortlessly from appointment to appointment on a steady stream of neatly printed lists. And you should see Kathleen throw a dinner party. Each course magically appears at the table on time, piping hot, and the seating plan bears striking resemblance to the organization chart. A glance at her bookshelf reveals a first edition copy of The One Minute Manager, and a record collection indexed in alphabetical order. Sandy holds a job such as marketing manager for one of the small, entrepreneurial business units. She's one of those people who's impossible to contact because no one knows where she is. In a meeting, plan on her being late, but also count on her having ten ideas to everyone else's two. Since she's rarely doing less than two things simultaneously, don't be upset if she's writing her management report during your dry-run sales presentation. Yet when you're through she'll be the only one who really understood the overall concept. If you root around her chaotic office, you will find a sign which says: "If you think my desk is cluttered, you should see my mind." You will find the fourth guy out in field sales. Everyone loves Bob. He's the kind of person you'd trust with your most intimate secrets because you know he'd never do anything to hurt your feelings. A good listener, and a good laugher, people instantly feel comfortable talking to him. However, don't bother asking him if he's free to work late. He belongs to four clubs, and coaches in three leagues. Do you recognize Walt, Kathleen, Sandy, and Bob? Do you have people like them in your group or business? They may also resemble customers or vendors. Who are you most like? Each of our four characters is emblematic of the four quadrants of the human brain, and the kinds of thinking each quadrant specializes in. The upper left quadrant is home for analytical and logical thinking. People who prefer to process information there tend to be mathematical and technical. They tend to have strong verbal skills, and given a choice, they prefer to deal with facts. Thinking in the lower left quadrant is oriented to the procedural, the precise, the practical, and the thorough. For the lower-left thinker, organization is a way of life. The upper right quadrant is the center for conceptual and imaginative thinking. It's where most of the artistic and holistic thinking takes place. And the lower right quadrant controls our emotional, responsive, empathetic, and interpersonal thinking. In general, the left side of the brain thinks sequentially, preferring to do things in order, one at a time, like working down a list; while the right side thinks simultaneously, juggling any number of tasks at once. Left brainers prefer to do things by the book, in order, and according to instructions. Right brainers wing it. Left brainers read the documentation before running the program; right brainers don't touch the documentation until they're hopelessly lost. Interestingly, just as people have dominate hands, feet, and eyes, they also tend to have one or two dominate thinking styles, like each of the people we described above. Yet even so, we actually have some of all four characters living within us. We all have a little bit of Walter the analyzer, Kathleen the implementor, Sandy the imaginator, and Bob the collaborator as part of the way we receive and process information. And all four styles are necessary for true, useful, creative work. But what does this have to do with computers? Everything. Let's take a look at the computing world from a left-brain -- right-brain perspective.
    Documentation and user interface planning for optical information systems BIBAFull-Text 80-86
      Stephanie Rosenbaum
    From one point of view, I should probably have waited to give this paper at next year's conference. Not many optical-based systems have reached the market yet. I've seen quite a few of the ones that have, and I've talked to some of their authors. But many more are still under development. Even so, I suggested talking about documentation and user-interface planning for optical systems, because I believe communicators can't wait for everyone else to blaze the trail. The products that optical system manufacturers will sell next year are under development now. If we delay planning how to describe them to their target audiences, we'll be playing the catch-up game we sometimes used to play when conventional software reached the marketplace with poor documentation. A paper like this is more useful while optical systems are on the drawing boards than it will be after their release.
    Effective user interfaces: some common sense guidelines BIBFull-Text 87-94
      Edward J. See; Douglas C. Woestendiek
    Literary expert systems BIBFull-Text 95-100
      Ian Lancashire
    ESTC -- a computer file for the scholarly community (title only) BIBAFull-Text 101
      M. J. Crump
    Because of the inability to resolve copyright permission with ACM, this article was published in the December, 1986 issue of Asterisk, the SIGDOC Newsletter. The author did not want to surrender copyright for this paper because the material was the property of the British Library. The Editor