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

ACM Sixth International Conference on Systems Documentation

Fullname:Sixth International Conference on Systems Documentation
Location:Ann Arbor, Michigan
Dates:1988-Oct-16 to 1988-Oct-18
Publisher:ACM
Standard No:ACM DL: Table of Contents hcibib: DOC88; ISBN 0-89791-336-1; ACM Order Number 613880
Papers:18
Pages:151
Ban the Book? Interactive Documentation and the Writer's Responsibility for the Human/Machine Interface BIBA 5-12
  Liora Alschuler; Debra Schneider
To answer our own question: no -- but, ...
   Hardcopy will continue to be important, but it will be only one feature of an integrated documentation delivery system as the document blends into the machine. Today's user documentation is an interference. It is the paper that comes with the disk; the book that comes with the machine. It stands between the machine and the user. Ideally, user documentation should be transparent, should bring the user to the machine, then tactfully withdraw.
   System and programmer documentation is always out of date and does not provide a good return on investment. The more we rely on software, the more critical it is for us to understand how it is put together. And despite all the promises of new languages, there is no such thing as self-documenting code. Ideally, programmer documentation should be an integrated part of the system.
   Problems on the human/machine interface must overcome the barrier between humanism and technology that divides our culture. The way through this barrier is paved with interactive, graphic, smart documentation that looks more like video games than like school textbooks.
   Our analysis grew out of our experience selling, using and producing documentation in situations where documentation is under-funded, unappreciated and generally the object of scorn. We formulated a theory of what documentation should look like and with this theory as our guide, began to look around at what was available. We saw that many of the promising new technologies were adding problems as well as solving them.
Bridging the Moat: Helping Training and Documentation to Work Together BIBA 13-18
  R. Dennis Walters
You're in Corporate Training, and you're returning from a meeting about a joint project with Documentation to support users on the new system. The meeting upset you, because you and Documentation couldn't agree on what users need to know about the system. If only the two departments weren't so -- antagonistic!
   As you walk down the hall toward your office, you seem to see looming ahead the walls of a fortress with battlements. The name of your department stands out in sharp relief, like an inscription chiseled on a granite arch over the drawbridge. Disturbed, you look behind you. At the other end of the hallway, rising as if out of a mist, appears a second castle, inscribed "Documentation".
   Even more disturbing, you notice for the first time that a moat separates the two castles. It has no bridge.
Case Study: Reorganizing the Document Production Unit BIBA 19-24
  Gerald McCartney
A rapidly growing user base, a perception of declining service, and low morale forced the User Services Group in the Computing Center at the University of Notre Dame to review its procedures and service posture. The production of documentation, the newsletter, and the provisions of training courses were ripe for reorganization because for a long time they been performed on an ad-hoc basis with little forward planning or revisions in the light of experience. The staff involved were dealing with apparently unceasing demand, low budgets and little apparent control of the problem. This paper deals with the task of reorganizing these three allied functions into one and the consequent enhancements that each aspect of the service enjoyed.
Communicating with Icons as Computer Commands BIBA 25-33
  Philip Rubens; Robert Krull
If one attempts to define the salient features of a conventional sign system, one could suggest that it will have three aspects: leveling, sharpening, and assimilation [1]. Leveling simply means that extraneous detail and objects have been delete. Sharpening involves making the remaining detail stand-out from the background. Finally, assimilation means that exaggeration and other deformation techniques are used to interpolate from mimetic, or real, to imaginative, or metaphoric, detail. Techniques of this variety allow developers of icons to represent fairly complex environments with relatively simple graphics. Since computer screens and memory both have their own varieties of limitations, employing techniques such as these help information developers create useful iconic representations within a limited operating framework.
Documentation Project Management (from Both Sides) BIBA 35-39
  Alice Powers McElhone
The subject of this article is not how to convince your management you need staff or how to train that staff -- there is far too much information on that subject as it is. Instructional design and that whole mystique is also omitted (I don't have a new lock on how to make people learn; clear and simple works for me). Instead, the focus here is on some ideas that helped me get some very big jobs done against very big odds. We'll take a look at the parts we can control: How to organize our own responsibilities and how to get cooperation from the people who can hold us up -- in short, Project Management: PLANNING, PROCESS and CONTROL.
   As the song goes, "I've looked at life from both sides now" -- then, as manager of a high tech vendor's publications department and now, as manager of an independent publications company, selling a service I used to buy. The similarities are more striking than the differences. On both sides of the bargaining table, it takes negotiating skills, planning skills, team-building, quality control.
Documentation -- The Good, the Bad, and the Ugly BIBA 41-46
  John Minor Ross
Most people would agree that it is eager to criticize user documentation than to come up with solutions. This explains the plight of the microcomputer community...no shortage of critics for a seemingly never-ending flow of documentation. This is a review of some of the problems facing the PC industry today. It also touches on how educators may attempt to equip students with a perspective to improve the documentation that will be shipped with tomorrow's products. While the theme herein is perhaps somewhat amusing, its value is nevertheless intended to be significant. It may help you to form your own answers to such questions as:
  • Does documentation have to be so boring?
  • Why do manuals always seem to be oriented towards someone else?
  • Why is what you don't know so hard to find?
  • Why is there always too little or too much detail about what you need to
       know?
  • Expectations and Experiences with Hypercard: A Pilot Study BIBA 47-56
      Ted Smith; Steve Bernhardt
    As interested and moderately sophisticated users of computer software, and as teachers of writing in university and corporate settings, we were naturally intrigued by the concept of hypertext and by the hype over HyperCard as a hypertext tool. Our research interests in text creation and reception, in intertextual and intratextual relations, in computer applications of these interests -- all these made us eager to try out this new tool.
       We initially conceived of a project in which students in a writing class would be required to enter material for a research project into a common HyperCard database and then individually create links between pieces of information in the database. Our goal was to explore the types of linking relations each student established, as well as to see to what relational links the students created in common.
       It soon became clear that, given the time frame for completing the project (a short summer school term), we would have to abbreviate our research design. So we began with a public domain HyperCard database called "The AIDS Stack" and assigned students the task of adding a few cards to the stack. They were then to use the stack as background material for developing a set of policy and information materials on AIDS for a fictitious company.
       In the next two sections we describe and critique the AIDS Stack as an information database; then we describe the students' use of the stack. We believe that the students' use of HyperCard is instructive for 1) characterizing the reactions of naive users to a hyperdocument and a hypertext tool, and 2) identifying some limitations of HyperCard in its present form. Both kinds of information ought to be valuable to teachers and hypertext developers. Thus, in Section 4, The Ideal HyperTool, we offer some suggestions for an improved version of HyperCard based on our students' experience with it.
    Guesswork and Common Sense: The Alphabetic Reference Design Process for Microsoft Works BIBA 57-61
      Rick Grimm
    A successful reference is one whose organization is readily comprehended very soon after the book is first opened. This usually isn't a problem for alphabetic references with a broad focus. People have learned their ABCs and easily grasped the organization of encyclopedias, dictionaries, and atlases for centuries. However, creating an alphabetic reference that focused on four software applications for the novice computer user proved to be a challenge.
    An Integrated Approach to Documentation Retrieval Using a SPIRES Database BIBA 63-68
      Suzanne Schluederberg
    The University of Michigan Computing Center is committed to providing greater and easier access to its documentation. We want to publish materials that users can locate themselves, and to provide exactly the kind of information they need. To this end, a committee was formed in October 1986 to review all documentation currently produced and to offer recommendations for improvement. Three especially important recommendations from the committee are being implemented. They are:
  • 1. Reduce the number of types of documentation from six to three, categorized
        by function rather than size.
  • 2. Design a searchable document retrieval database to replace the current
        online documentation facility.
  • 3. Centralize all input and output document files on one Computing Center ID. This paper will summarize progress to date on these projects, especially the development of the new database. It will highlight features already incorporated into the database structure, as well as those that will be future design enhancements.
  • Is Universal Document Exchange in Our Future? BIBA 69-73
      Louis M. Gomez; Donald F. Pratt; Mark R. Buckley
    Will there come a day when we will all work in a common document production environment so that if you gave me a file or I gave you one, either of us could print it immediately, using the equipment we have, or edit it immediately, using a markup language that is straightforward, easy to use, and familiar to both of us? That summarizes the goal we've labeled universal document interchange.
       We do not see that day coming. Although much effort is being put toward the goal of universal exchange, it appears to us that it can go only so far. What we do expect to happen is a flourishing of translation products and services as the interchange problems become more manageable but do not go away. From now on for as far as we can see, editors are going to be tinkering with different varieties of markup to accomplish the wide variety of tasks associated with technical documentation.
    Justifying the Cost of New Computers for Documentation BIBA 75-79
      Donald F. Pratt
    Corporate accounting practices sometimes make it very difficult to justify the cost of new computer equipment, for documentation or any other purpose. These practices, however, tend to keep us from understanding the costs and overestimating the immediate benefits of new systems. Perseverance and these guidelines from experience may help in justifying genuinely needed systems sooner rather than later.
  • 1. Avoid both the highest- and lowest cost systems.
  • 2. Choose equipment that can perform many tasks.
  • 3. Buy good hardware and software separately; don't buy turnkey systems.
  • 4. Automate piecemeal, not wholesale never buy more than one of a piece of
        equipment you haven't used before.
  • 5. Adjust your lease or depreciation schedules to the reality that equipment
        will be obsolete within three years.
  • 6. If your justification isn't strong enough, wait a year.
  • 7. But if your justification strong, don't wait, or you'll lose more immediate
        benefits than you can recover in the future.
  • Letting Software Engineers Do Software Engineering or Freeing Software Engineers from the Shackles of Documentation BIBA 81-91
      Benson H. Scheff; Tom Georgon
    General Orientation
  • This is not a paper about documentation
  • This is a paper about:
  • --- Achieving higher software
  • ..... Productivity
  • ..... Quality
  • --- Minimizing software risk Underlying thesis
  • $30B worth of DoD software needs for the early 1990s
  • Not enough software engineers to fill these needs
  • Software engineers must be more efficient
  • Software engineering documentation is a good candidate for study
  • --- High cost
  • --- Pervasive activity
  • --- Strong repetitive elements
  • Managing Economics with Desktop Publishing BIBA 93-100
      Lisa Ruffolo; Susan Smith
    As managers of a business dedicated to producing the kind of computer documentation our clients want and their users need, we have had to educate ourselves and our writers to respond to the demands of our market. When we first started writing computer user documentation, our clients simply expected accurate, well-written user manuals, so we honed the writing and organization skills required for producing usable computer manuals. As computer users grew more sophisticated, they demanded software that was both powerful and easy to use. We had already discovered that you can't write a helpful manual for unhelpful, poorly-designed software, so we learned about systems design in order to test the software we document and improve the user interface. We researched how people learn so that we could design effective on-screen tutorials, help systems and other forms of on-line documentation. Now we are taking advantage of the desktop publishing technology that is revolutionizing the role of the writer so that we can streamline the production of documents to provide users with customized, up-to-date, accurate manuals.
    The Novice User Enters the Discourse Community: Implications for Technical Writers BIBA 101-110
      Karla Saari Kitalong
    The purpose of this paper is threefold: to critique existing definitions of computer literacy and the approaches to computer literacy instruction that such definitions engender, to suggest an enriched approach to computer literacy based on the sociolinguistic notion of the discourse community, and to outline some of the technical communications issues that arise when computer literacy and sociolinguistics are considered in tandem. The main conclusion that is reached in the paper is that, as communications professionals working in computing environments, technical writers and trainers need to pay increased attention to the contexts in which computing takes place, the linguistic conventions of language used in computing contexts, and the specific needs of computer users, in order to act effectively as a "bridge" between computing community "insiders" and "outsiders," or expert and novice members.
    SYMPLE, An Icon-Based Computer Language BIBA 111-119
      Erwind Earl Blount
    This paper will describe an icon-based computer language called SYMPLE. SYMPLE stands for Symbolic Programming Language, and is the end result of the continuing evolution of the icon as an information interface. Today's computer languages use the syntactical representation of bits as their root programming construct and are limited to the use of unique data structures in representing aggregate information (e.g., arrays, unions, linked lists). The conception of syntactical linearity in the English language (e.g., characters to build a word, words to build a sentence, sentences to build a paragraph, etc.) have carried over to computer languages resulting in the "Von Neuman" bottleneck of serial processing (one step at a time operations). SYMPLE conceptually and functionally avoids the serial bottleneck by handling information, and the processes regarding that information as one entity (the Icon). SYMPLE extends icon use from its present graphics symbolism to a fully interactive programming methodology. SYMPLE treats the icon as a piece of code (i.e., functions, subroutines, whole programs) or a graphics symbol, a communications routine, an operating systems call, ad infinitum.
    Textual and Visual Access to a Computer by People Who Know Nothing About It BIBA 121-133
      Patricia Baggett; Andnrzej Ehrenfeucht
    For some time now we have been working in the area of designing systems to help people do tasks. (Some people have accused us of being "driven by our toys.") In this paper we'll discuss two specific experimental studies whose results we used in designing a videodisc-based system for assembly of an object. First we briefly discuss the scope of the problems we tackle, and we give a description of experimental psychology and experimental computer science, and the underlying principles for designing our systems.
    Twentieth-Century American Poetry: Proposal for a HyperCourse BIBA 135-143
      John M. Slatin
    In this paper, I am going to discuss plans for using Apple Computer's HyperCard software to address certain problems in the teaching of twentieth-century American poetry. Hypertext and hypermedia systems are designed to allow rapid, non-linear movement through large and often highly diversified knowledge bases, typically consisting of numerous discrete elements, or "nodes," which may be linked with one another in many and complex ways. Hypertext is well suited, therefore, as a medium for presenting large bodies of highly complex technical information which often need not be read sequentially from beginning to end. And with the addition of graphics and sound capabilities like those provided by HyperCard, hypermedia becomes an excellent medium for studying poetry, another complex system in which a great many separate entities -- not all of them written documents -- are linked in many and complex ways.
    Writing Computer Documentation in English for International Users BIBA 145-151
      Jo-Anne Tanenbaum
    Writing computer documentation for use in several countries involves more problems than writing for use in only one country. My consulting experience at a major international bank illustrates these problems and their solutions.