File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/80/c80-1087_metho.xml
Size: 26,835 bytes
Last Modified: 2025-10-06 14:11:17
<?xml version="1.0" standalone="yes"?> <Paper uid="C80-1087"> <Title>Programming</Title> <Section position="1" start_page="0" end_page="0" type="metho"> <SectionTitle> INTEGRATED INFORMATION MANIPULATION SYSTEMS (IMS) -- A COGNITIVE VIEW </SectionTitle> <Paragraph position="0"/> </Section> <Section position="2" start_page="0" end_page="0" type="metho"> <SectionTitle> Abstract </SectionTitle> <Paragraph position="0"> The personal computer of the future will offer its owner an information manipulatio, 9~stem (IMS). It will be a totally integrated system being able to manipulate arbitrary information structures, eg programs, prose, graphical objects and sound.</Paragraph> <Paragraph position="1"> An IMS will be an important step towards achieving the goal that we can do all our work on-line -- placing in computer store all of our specifications, plans, designs, programs, docummentation, reports, memos, bibliography and reference notes and doing all of our scratch work, planning, designing, debugging and most of our intercommunication via the consoles.</Paragraph> <Paragraph position="2"> We outline the basic principles underlying the design of an INS. We discuss the cognitive dimensions (specifically for text processing and programming systems) which should serve as the design criteria for systems whose goal is to reduce the cognitive burden and augment the capabilities of a human user.</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="metho"> <SectionTitle> Keywords </SectionTitle> <Paragraph position="0"> man-machine communication, problem solving, routine cognitive Skill, text processing, programming, display-oriented interfaces, uniformity, integrated systems !. Information manipulation systems (IM5) I.i Function and structure of an IMS The rapidly increasi,ng sophistication and cheap availability of computers make it likely that interactive man-machine systems will increasingly be exploited to deal with complex problems in many domains. IMSs should be prototypes for systems in which the computer and the human cooperate to solve problems and achieve tasks more quickly and more rapidly than either could do working alone.</Paragraph> <Paragraph position="1"> The effective utilization of such combined man-machine systems will require that the information-processing capabilities of the human component be as well understood and designed as those of the computer.</Paragraph> <Paragraph position="2"> The basic hardware to support an IMS consists of a personal computer dedicated to a single user which will have a high resolution, all points addressabte display and a mouse as a pointing device.</Paragraph> <Paragraph position="3"> individual machines will be connected in a network and they will possess computational power comparable to that of todays largest timesharing-machines. The LISP Machine (WEINREB & MOON, 1979) and the SMALLTALK Machine (as a first step toward the idea of a &quot;DYNABOOK&quot;; KAY 1977) are first examples of the technology we have in mind.</Paragraph> <Paragraph position="4"> The structure of an IMS is illustrated in diagram I.</Paragraph> <Paragraph position="5"> Diagram I: The structure of an IMS text processing \]programming I to provide tOto preparefill outddegcumentS~forms |\[.cdegmputatidegnal facilities { 'info1~aation manipulation system 1 / &quot;-... database manipulation graphics to access prestored to compose text information with pictures --570--Systems of this sort will be used for many applications: as office automation systems, as personai information systems (LAUBSCI4, FISCHER and BOECKER 1979), as research tools etc.</Paragraph> <Paragraph position="6"> We are convinced that real problems require an IMS and not only a programming language or a text processing system, like the following examples demonstrate: 1) tO write a paper for a conference, we need - graphics (to include diagrams and pictures) - database (to retrieve the references) - programming (to sort the references, to include teat runs, etc) 2) to support the development and modification of programs, we need an interactive program development system (FISCHER and LAUBSCH, 1980), including all the helpful features of the INTERLISP system (TEITELMAN 1978) like &quot;Do what I mean (DWIM)&quot;, Programmer's assistant, UNDO and History facilities This paper extends the work and the ideas expressed in FISCHER (1980</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 1.2 Uniformity </SectionTitle> <Paragraph position="0"> One of the obstacles computer systems present to the user is the diversity of differen~ languages and conventions which a user has to knew tO get a certain task done. To write an ordinary program in a conventional system the user has to know a large number of different languages, sublanguages and conventions, eg&quot; * the programming language itself (with conventions for specifying the control flow, external and internal data description etc) * the operating system (job control language, linkage editor and loader) * the debugging system (diagnostic system, symbolic assembler etc) * the text processing system (editor and formatter) The need for an integrated system is obvious to anybody who has tried to struggle through all the idiosyncracies of the different systems mentioned above.</Paragraph> <Paragraph position="1"> An IMS offers uniformity in several dimensions to cope with this problem: Linguistic uniformity: All tools (eg the programming system and superimposed modules as well as mere specific creations of the user) are made from the same material and thus part of the same conceptual world. This has the sociological benefit that the system's implementor and users share the same culture. Each module in the system can be regarded as a &quot;glass-box&quot;, ie it can be inspected by the user and the system can be explored all to the edges. This gives the user an amount of control aver his environment which is not reachable in other systems. Uniformity of interaction: This is based on a good interface, which provides a uniform structure for finding, viewing and invoking the different components of the system. The crucial aspect for this interface is the use of the display screen, which allows for many tasks the real-time, direct manipulation of iconic information structures which are displayed on the screen. Each change is instantly reflected in the document's image, which reduces the cognitive burden for the user. The screen should be regarded as an extension of the limited capacity of our short term memory (is it provides a similar support like pencil and paper does for the multiplication of two large numbers).</Paragraph> <Paragraph position="2"> 2. Experiences with existinq systems The author has had opportunities to work intensively with several advanced systems during the last few years. These systems form the background for the ideas expressed in this paper; they are the currently existing systems (known to the author) which come closest to our idea of an information manipulation system.</Paragraph> </Section> </Section> <Section position="4" start_page="0" end_page="0" type="metho"> <SectionTitle> 2.1EMACS and MACLISP </SectionTitle> <Paragraph position="0"> EMACS (STALLMAN 1979) is a real-time display oriented editor, which can be extended by the user. This allows users to make extensions that fie the editor better to their own diverse applications, to experiment with alternative command Languages and to share extensions which ace generally useful. It runs on large timesharing machines (eg PDP-IO) and large personal computers (eg LISP machine; WEINREB and MOON, 1979). It contains speciaI subsystems (&quot;modes&quot;; see Diagram 2) to take advantage of the structures which occur in the systems to be edited. EMACS is a single key-stroke system, which puts a heavy demand on our recall memory. For these reasons, it is specifically suited for the expert user.</Paragraph> <Paragraph position="1"> (extensibitity means that arbitrary modes can be implemented and uniformity implies that the user does not need to learn a seperate editor for each system) EMACS is well interfaced with the MACLISP programming system. EMACS and MACLISP are kept in the machine as parallel jobs which is a necessary requirement to switch back and forth with a few keystrokes. This is quite different from the editing philosophy of the INTERLISP system (TEITELMAN 1978) where the editor is an integral part of the INTERLISP system itself. The advantages and disadvantages of these two approaches (&quot;source-file&quot; versus &quot;residential&quot; systems) are thoroughly discussed in SANDEWALL (1978).</Paragraph> <Paragraph position="2"> Powerful personal computer systems (like the LISP machine) contribute to the extensibility and modifiability of an information manipulation system because they make the entire software system interaetively extensible by writing it in a higher level language (eg LISP) and allowing the user to redefine the functions composing the innards of the system (ie they provide the linquistic uniformity which we have mentioned in 1.2).</Paragraph> <Paragraph position="3"> they only requires the recoqnition of commands (ie no recall). These environments provide prototypes for man-machine interfaces which are heavily based on graphics. The problem of not having enough space on the screen is solved by allowing the windows to overlap. The resulting configuration considerably increases the user's effective work space and it contributes to the illusion that the user is viewing a desk top containing a number of sheets of paper which he can manipulate in various ways.</Paragraph> <Paragraph position="4"> Diagram 3: The DLISP display facilities (from Teitelman 1977) the display shows the following features: - several menues (which are context dependent and therefore can be kept small in size; they allow the recognition of commends and do not require a recall) - windows to receive and send messages - &quot;WORK AREA&quot; window which allows additional communication with the system selected text is indicated by reversing the color of the screen - the virtual size of the screen is increased because the windows can overlap</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 2.2 SMALLTALK and DLISP </SectionTitle> <Paragraph position="0"> SMALLTALK (KAY 1977) and DLISP (TEITELMAN 1977) are systems at Xerox Palo Alto Research Center, which rely heavily on a high resolution bit map display, a mouse as a pointing device and excellent software, which supports multiple windows with associated menues and multiple fonts (see Diagram 5 for an example); through their iconic representations and their menues Abilities like suspending an operation, performing other operations (eg to answer quickly to an urgent request received through the mail system) and then return without loss of context have turned out to be essential for many problem solving activities. The technique of using --572-different windows for different tasks does make this switching of contexts easy and painless.</Paragraph> <Paragraph position="1"> These systems combine the best features of display and hardcopy terminals. A standard complaint with conventional display terminals is that material that the user wants to refer to repeatedly (eg the text of a function, the trace of a program execution) is displaced by subsequent, incidental interactions with the system. In a situation like this when using a hard copy terminal the user tears off the part he is interested in. The equivalent action in a window system is to freeze the relevant portion of the interaction in a seperate window (eg like the &quot;WORK AREA&quot; window in Diagram 3) whose content will not be affected by the following interactions (see TEITELMAN, 1977).</Paragraph> <Paragraph position="2"> The graphical orientation of these systems has inspired research (eg SMITH 1977 and BORNING \[979) to create programming systems where more and more symbolic descriptions can be replaced by iconic descriptions.</Paragraph> <Paragraph position="3"> These efforts have the gnat to integrate some of the features whichhave made display-oriented editing systems so successful into programming environments.</Paragraph> <Paragraph position="4"> Teletype-oriented editors require sequences of commands like &quot;4DOWN 12LEFT 4DELETE&quot; to delete four characters somewhere in a buffer. In a display-oriented environment we see the content of the buffer on the screen and can move with the cursor (supported by continuous visual feedback) to the object to be manipulated. An example of symbolic versus iconic programming is given in Diagram 4. The operation to be performed is to change the value of the third element of an array. In the symbolic ca.se we have to &quot;tell&quot; the computer that we want to assign a new value to the third element of an array, whereas in an iconic programming environment the array would be displayed on the sereen and changed directly.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 2.2 TINTE and LOGO </SectionTitle> <Paragraph position="0"> TINTE (RATHKE i979), also a a real-time display oriented editor, has limited set of user-definable keys. It runs on a small personal computer and through its incrementaI design it can be used by users of all levels of expertise. Incremental design is one of the most essential features of a complex system, because the novice user of any reasonably powerful computer system is more confused than assisted by a full display of the information and options available to him.</Paragraph> <Paragraph position="1"> (Note:This paper was written with the help of TINTE). The interface between TINTE and the programming system LOGO (BOECKER 1977) is not as smooth as in the systems described above. The main reason for this is the limited memory space available in small computers which does not allow to load the two systems as parallel jobs.</Paragraph> <Paragraph position="2"> Our research during the last few years has not only been concerned with the technology of providing interactive computer service, but also with changes in conceptualizing, visualizing and organizing work and.</Paragraph> <Paragraph position="3"> research with these systems and in procedures * and methods for working individually and cooperatively (FISCHER 1979; FISCHER, BROWN and BURTON, 1978; FISCHER and LAUBSCH, 1980).</Paragraph> <Paragraph position="4"> --573-3. Theoretical considerations for the desiqn of an IMS If a civil engineer has to design a bridge, he acquires a detailed knowledge of the country side in which the bridge will be built and he will use the laws of physics to come up with a plan.</Paragraph> <Paragraph position="5"> Unfortunately things are not quite as easy with respect to the design of an IMS. Changing hardware is the smallest problem; the major obstacle is that there is no cognitive theory of sufficient predictive power (fulfilling the same function as the laws of physics for the bridge) which would be specific enough to provide a complete set of design criteria for an IMS. NEWELL and SIMON (1976) argue convincingly why research like the design of an IHS has to be carried out as &quot;empirical inquiry&quot; Despite the lack of a complete cognitive theory, work in Cognitive Science has accumulated a substantial body of knowledge which is important for integrated IMSs. The scope of this paper does not allow us to give a detailed description of our theoretical framework; therefore we mention only the most important aspects: i) research in AI and cognitive psychology has shown that knowledge is at the basis of all problem solving; the active research in the development of knowledge representation languages (like KRL and FRL) is based on this insight 2) psychological research and empirical evidence supports the hypothesis that &quot;thinking always begins with suggestive but imperfect plans and images; these are progressively replaced by better, but usually still imperfect plans&quot;. This hypothesis indicates the evolutionary character of complex systems, it implies that linear approximation is an important methodology and that debugging processes have to be understood thoroughly 5) problem solving theories about planning (which operates in a simplified abstraction space), analogy (which forms the basis for recognition methods), debugging (see previous point) and multiple representations (see 3.2) are not any more only directed towards the understanding of abstract and well-structured problems but investigate ill-structured problems in semantically rich domains (SIMON 1978) 4) knowledge about human information processig capabilities (eg about the limited capacity of our short term memory) shows that for complex systems there exists a need to prefold information for the user so that more pieces of the whole picture can be maintained in the user's immediate attention at once 5) SIMON (1969) has provided an insightful analysis of the structure of ce~lex systems (by showing their hierarchical structure, their property of being &quot;nearly decomposable&quot; etc)</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.1 Generative Processes </SectionTitle> <Paragraph position="0"> One purpose of an IMS is to support the creative aspects of the writing and programming process. Writing and programming often means to make a rough draft and refine it over a considerable period of time (in ether words: it subsumes all the processes required to go from the first idea to the final product; see FLOWER and HAYES, 1979). It includes the expectation of an &quot;unacceptable first draft&quot; which will develop through successive changes into a presentable form. An important general characteristic of computers is that they allow us to build quickly low-cost modifiable models which we can analyze and experiment with. We believe, contrary to the formal, verification oriented group in the Structured Programming community, that this view is as adequate for programming as it is for writing.</Paragraph> <Paragraph position="1"> Text processing and programming are examples of generative processes which are best understood as problem solving.</Paragraph> <Paragraph position="2"> Inadequate technologies (eg a typewriter, a batch system) force the writer or programmer to limit himself to a small set of strategies. For example he has to proceed in a serial fashion, whereby the form of the written word imposes restrictions on the generation of language and ideas. On the other hand it is well known that knowledge is not simply additive which implies that a new insight or idea may require a major restructuring of what has been done before.</Paragraph> <Paragraph position="3"> Creative writing and programming is an ill-structured problem (SIMON 1978). In these problem solving situations the problem solver has to contribute actively to the exact specification of the problem and he has to define criteria what will be accepted as a solution.</Paragraph> </Section> </Section> <Section position="5" start_page="0" end_page="0" type="metho"> <SectionTitle> ).2 Multiple Perspectives </SectionTitle> <Paragraph position="0"> The computer as an active medium offers more posibilities than paper for a person who wants to write, understand or read a report or a program. For complex descriptions it is often a big advantage to be able to generate multiple perspectives which facilitate or highlight certain aspects of a system. Multiple perspectives are able to resolve the basic conflict that symbols, which are ordered in one fixed order (eg on a printed page), serve as pointers to concepts which form a highly interrelated network. This implies that 9_2o sinqle linear order is adequate. The value of multiple perspectives can be illustrated in a nice way using ~ as an example: there may be many different maps for the same territory using large and small scales, showing the percipitation, the population density, the economical structure and any other relevant criteria.</Paragraph> <Paragraph position="1"> In reading text ean be selected according to the wishes or needs of the reader (to allow &quot;dynamic reading&quot;; a display screen can be regarded as a dynamic blackboard): l) for the novice and the expert, different parts may be left out or included 2) to get a global overview, we can generate a table of contents at arbitrary levels of abstraction 5) information can be reordered such that all oecurences of a certain concept are selected (which occur in other representations at arbitrary places) Similar possibilities exist representation of programs: for the i) certain modules of the program can be listed selectively (eg all the data accessing functions, all declarative information, all procedures which achieve a specific subtask); procedures can be listed in different orders (eg alphabetically or according to U~ calling structure) 2) the calling structure which Shows the connectivity structure between different procedures can be displayed at arbitrary levels of detail; the user should be allowed to define a &quot;view specification&quot; 3) symbol tables give a receding of information according to a different criterion ).5 Problem solving versus routine skill An IMS Should also support the routine skill (CARD 1978) of editing a manuscript or coding an known algorithm in the syntax of a programming language. In this case it helps to eliminate the boring, time-consuming and unproductive work of secretaries who have to spend long hours to retype manuscripts, to make only trivial changes to a prototype of a letter but still have to retype it as a whole and who become greater experts in using scissors and glue than in anything else. A routine cognitive skill means that the methods to be used are well known and that the sequence of actions which occur are of a modest variety (therefore there is little search to find out what to do next).</Paragraph> <Paragraph position="2"> 4. Implications for the process of system desi__q_n &quot;Truth emerges more readily from error than from confusion&quot;.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.1 The necessity for empirical investigations </SectionTitle> <Paragraph position="0"> \[t is generally accepted that when a program is to be written, specifications should be designed in advance. But for real design tasks or ill-structured problems (see 5.i) this is more wishful thinking than a realistic goal. The history of the development of text editors is a good example for this assertion (another example would be timesharing systems; see NEWELL/SIMON (1976) for an insightful analysis of this topic) and provides a good illustration of the co-evolution of implementations and interface specifications. As experience accumulates in using an implementation, more of the real needs and benefits are discovered causing the partial interface specifications to change. The chain of necessary steps leading to one of the systems described in section 2 starting with the availibilty of the display processors would have been simply too long for anyone to have imagined the final result before the first step had been taken (for a general discussion of these issues see FISCHER, BROWN and BUR\[ON, 1978).</Paragraph> <Paragraph position="1"> --575--</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.2 A design conflict </SectionTitle> <Paragraph position="0"> In the initial phase of using a text processing system it is very important that the introduction Of the computer system changes the tasks performed as little as possible. For computer naive user it is a traumatic experience anyway to change the tangebilily of a piece of paper by the illusiveness of electronic documents and files. It is a step that drastically alters the appearance of their tools.</Paragraph> <Paragraph position="1"> As users become more experienced and more familiar, the systems should take advanlaqe of the new medium. Strict adherence to normal typing conventions in an IMS is not always advantageous (eg good text processing systems do not require that the user pays attention to the end of a line, they allow him to define abbreviations, to experiment easily with the layout, they take care automatically for constraints, etc). Lack of attention to this essential phenomena is one of the reasons that many innovations fail.</Paragraph> <Paragraph position="2"> Regarding the efficient use of an IMS as a skill which develops over a long period of time and which gets used repeatedly (FISCHER, BROWN and BURTON, 1978) implies that we have to pay attention to the following design issues: I) time: how long does it take to accomplish a task? 2) errors: what kind and how many errors does a user make and how serious are they? 5) learning: how long does it take a novice user to learn to use the system (for a secretary, for a trained computer scientist)? 4) functionality: what range of tasks can a user perform with the system? How can it be made extensible to take care for unforeseen requirements? 5) recall: how easy is it for a user to reesll how to use the system for a task that he has not done for some time??</Paragraph> </Section> </Section> <Section position="6" start_page="0" end_page="0" type="metho"> <SectionTitle> 5. Empirical findinqs </SectionTitle> <Paragraph position="0"> Observing many people how they use IMS and taking into account empirical data based on interviews and questionaires, has revealed the following: i) the systems can reduce the psyc~logical stress of doing something wrong (because wrong things can be easily corrected) 2) they increase the willingness to experiment with new and different ideas 3) the small amount of effort to change things in a non-trivial way (eg to find a major rearrangenment of a text or a more modular solution to a programming problem) leads in many cases to an improvement not only in form but also in content Much more empirical work is needed to develop a detailed requirement analysis which can serve as a guideline for the design of the next generation of information manipulation system.</Paragraph> <Paragraph position="1"> Unfortunately the verdict of users is not particulary reliable: as usual, users of the respective systems tend to prefer what they are used to.</Paragraph> </Section> class="xml-element"></Paper>