Abstract: objects have been devdloped. The diagrams, flowcharts, and other iconic representations we have long employed to communicate with other people can now be used directly to describe algorithms to computers. With the availability of graphics-based, personal workstations, these visual modes can eliminate the need to convert algorithms to the linear strings of symbols traditionally required by most computers. Linear, symbolic computer languages have been studied and refined extensively over the past 30 years, but computer language designers now face a new challenge: to provide convenient and natural visual programming lan-

Abstract: ion. A programming system should treat software as a hierarchical structure of neat abstractions. Conventional languages support this view syntactically by enforcing certain access rights within the program text. With standard editors and program listings, however, the programmer navigates through the program text in a sequential fashion. If the language were integrated into the programming system, though, the access path and the abstraction path would be unified and the system would embody the desired structure rather than merely support it. A pictorial system is the best vehicle for this, since it offers complete freedom in representing program navigation. For example, the depth dimension can be used to examine a piece of abstract data by enlarging its picture with a zoom effect, thus showing internal detail.

Abstract: Performance and subjective reactions of 76 users of varying levels of computer experience were measured with 7 different interfaces representing command, menu, and iconic interface styles. The results suggest three general conclusions:there are large usability differences between contemporary systems,there is no necessary tradeoff between ease of use and ease of learning,interface style is not related to performance or preference (but careful design is).Difficulties involving system feedback, input forms, help systems, and navigation aids occurred in all styles of interface: command, menu, and iconic. New interface technology did not solve old human factors problems.

Abstract: A personalized integrated telecommunications management system is described; it is composed of both graphical and audio interfaces to a number of telecommunication utilities. This approach utilizes a general purpose computer with a color display and speech-processing board to function as a conversational answering machine, voice or text electronic mail terminal, and on-line telephone directory with repertory dialing.

Abstract: Our research goals are to understand the nature of, construct and evaluate intelligent interfaces as knowledge-based systems In this paper we demonstrate the need for help systems as an essential part of human-computer communication Help strategies are based on a model of the task (to understand what the user is doing or which goals he/she1 wants to achieve) and a model of the user (to guarantee that these systems are non-intrusive and that they pay attention to the needs of individual users)We illustrate that passive and active help systems have to be constructed as knowledge-based systems Two operational systems (PASSIVIST and ACTIVIST) are described to show the usefulness of this approach

Abstract: In this paper the design and implementation of the University of Alberta user interface management system (UIMS) is discussed. This UIMS is based on the Seeheim model of user interfaces, which divides the user interface into three separate components. The Seeheim model of user interfaces is discussed along with its relationship to the design of UIMSs. The techniques used to design the three user interface components are briefly presented. A mixture of interactive and written notations are used in the design of the user interface. Some interesting features of this UIMS are interactive screen and menu layout, support for three dialogue notations, flexible interface to the application program, ability to adapt to different users, and the use of concurrent processes in user interface implementation The techniques used in the implementation of this UIMS are discussed.

Abstract: In Section 2, we discuss influences that affect the design of user interfaces with desirable characteristics. In Section 3, we present a list of ten desirable characeristics for user interfaces. For each of these, we provide explanations and we give specific examples of what we mean.

Abstract: We describe a prototype electronic encyclopedia implemented on a powerful personal computer, in which user interface, media presentation, and knowledge representation techniques are applied to improving access to a knowledge resource. In itself, an electronic encyclopedia is an important information resource, but this work also illustrates the issues and approaches for many types of electronic information retrieval environments. In the prototype we make dynamic use of the structure and semantics of the text articles and index of an existing encyclopedia, while experimenting with other forms of representation, such as simulation and videodisc images. We present a long-term vision of an intelligent user-interface agent; summarize previous work related to futuristic encyclopedias, electronic books, decision support systems, and knowledge libraries; and outline current and potential research directions.

Abstract: Graphical user interfaces are difficult to implement because of the essential concurrency among multiple interaction devices, such as mice, buttons, and keyboards. Squeak is a user interface implementation language that exploits this concurrency rather than hiding it, helping the programmer to express interactions using multiple devices. We present the motivation, design and semantics of squeak. The language is based on concurrent programming constructs but can be compiled into a conventional sequential language; our implementation generates C code. We discuss how squeak programs can be integrated into a graphics system written in a conventional language to implement large but regular user interfaces, and close with a description of the formal semantics.

Abstract: User interface management systems (UIMSs) provide user interfaces to application systems based on an abstract definition of the interface required. This approach can provide higher-quality interfaces at a lower construction cost. In this paper we consider three design choices for UIMSs which critically affect the quality of the user interfaces built with a UIMS, and the cost of constructing the interfaces. The choices are examined in terms of a general model of a UIMS. They concern the sharing of control between the UIMS and the applications it provides interfaces to, the level of abstraction in the definition of the information exchanged between user and application, and the level of abstraction in the definition of the sequencing of the dialogue. For each choice, we argue for a specific alternative. We go on to present COUSIN, a UIMS that provides graphical interfaces for a variety of applications based on highly abstracted interface definitions. COUSIN'S design corresponds to the alternatives we argued for in two out of three cases, and partially satisfies the third. An interface developed through, and run by COUSIN is described in some detail.

Abstract: The paper argues that user models are an essential component of any system which attempts to be “user friendly”, and that expert systems should tailor explanations to their users, be they super-experts or novices. In particular, this paper discusses a data-driven user modelling front-end subsystem, UMFE, which assumes that the user has asked a question of the main system (e.g. an expert system, intelligent tutoring system etc.), and that the system provides a response which is passed to UMFE. UMFE determines the user's level of sophistication by asking as few questions as possible, and then presents a response in terms of concepts which UMFE believes the user understands. Investigator-defined inference rules are then used to suggest additional concepts the user may/may not know, given the concepts the user indicated he or she knew in earlier questioning. Several techniques are discussed for detecting and removing inconsistencies in the user model. Additionally, UMFE modifies its inference rules for individual users when it detects certain types of inconsistencies. UMFE is a portable domain-independent implementation of a system which infers overlay models for users. UMFE has been used in conjunction with NEOMYCIN; and the paper contains several protocols which demonstrate its principal features. The paper concludes with a critique of UMFE and suggestions for enhancing the current system.

Abstract: The development of a large menu-based interface to an operating system posed a number of interesting user interface questions. Among those were how to determine the user's view of the relationships among the myriad of functions in the system, and how to reflect those relationships in a menu hierarchy. An experiment utilizing a sorting technique and hierarchical cluster analysis was quite effective in learning the user's perception of the relationships among the system functions. A second experiment comparing a “broad” menu hierarchy to a “deep” menu hierarchy showed that users made significantly fewer inappropriate menu selections with the broad hierarchy.

Abstract: object model as the basic system organizing principle. With this model, all system activity can be thought of as operations on a collection of objects managed by the system and organized into classes called types. Examples of object types are documents, processes, and folders. In its simplest terms, the IPC provides the communication primitives and mechanisms for delivering operations to objects and delivering the results, if any, of operations back to invoking clients. Some processes, called object managers, play a special role in implementing objects. The Document Manager and Authentication Manager are examples of managers. Generally, when an operation is invoked on an object, it is delivered to a manager for the object that performs the operation. Every object has a Unique Identifier (UID) that is a fixed-length, structured bit string. It includes fields that specify the object type and the host upon which the object was created, as well as fields that serve to ensure its uniqueness. Although, ultimately, all references to objects are through UIDs, some managers also support symbolic naming. For example, the folder hierarchy of the Document Store implements a symbolic name space by providing a mapping between user-defined symbolic names and object UIDs in order to facilitate user references to objects. The IPC is message oriented, and it supports object-oriented addressing. Operations invoked on objects are sent as messages addressed to the objects. That is, addresses for messages are object UIDs. The object addressed is the operand, and the message data contains the operation and any additional parameters necessary to specify the operation. The role of the IPC is to deliver the message to the manager for the object (a process), which can perform the operation requested. Responses are sent as messages from object managers to requesting clients. When sending a message, a process need not specify the host where the addressed object resides. To deliver the message, the IPC must determine the host. Certain object types are such that

Abstract: A model of manuscript editing, implemented as a simulation program, is described in this paper. The model provides an excellent, quantitative description of learning, transfer, and performance data from two experiments on text editing methods. Implications of the underlying theory for the design process are briefly discussed.

Abstract: This paper argues that it will become increasingly important to extend our concept of user interfaces for individual users of computers to include organizational interfaces for groups of users. A number of suggestions are given for how to develop a theoretical base for designing such interfaces. For instance, examples are used to illustrate how traditional cognitive points of view can be extended to include information processing by multiple agents in organizations. Examples of design implications from other perspectives such as motivational, economic, and political are also included.

Abstract: Much recent research has been directed at the development of better tools to support the design, specification, implementation, and evaluation of human-computer dialogues. Such tools have been variously named “user interface management systems” (Kasik 1982; Buxton et al 1983), “dialogue management systems” (Roach et al 1982), and “abstract interaction handlers” (Feldman & Rodgers 1982). User interface management systems (UIMS’s) build upon concepts developed in earlier user interface specification and prototyping systems (Newman 1968; Mason & Carey 1 983). The state-of-the-art is now at the point where UIMS packages are becoming commercially available (Rubel Software 1983; Wasserman & Shewmake 1982; Woodmansee 1983).

Abstract: A Finite Element Analysis system having intelligent, interactive user interface features allows engineers without specialized knowledge in mathematical modeling to easily and interactively solve diverse problems. The system includes a digitizer tablet having a segmented work surface for entering pictorial data and for alternately selecting among processing modes from a menu. Alternate displays on a status screen are automatically correlated with the user positioning of a stylus on the digitizer tablet surface to provide the user with the information he needs for a particular contemplated action. A graphics screen displays a dumb cursor which tracks the position of the stylus in the graphics workspace of the digitizer tablet. An intelligent cursor automatically drawn on the graphics screen by a computer processor identifies a site of interest nearest the current location of the dumb cursor. The intelligent cursor anticipates the user's action in a selected mode and constrains these actions to valid operations within that mode.

Abstract: This paper reports on an experimental debugger for concurrent programs. Design objectives include a showing of greatest usefulness when dealing with multiprocess interactions, creation of a simplified more approachable interface for programmers, allowance for the systematic organization (and limitation) of debugging information by programmers, reflection of a natural view of concurrency, and portability. The design responds to a perceived need for debugging techniques applicable in systems of concurrent, communicating, asynchronous processes. During debugging sessions, a user is able to dynamically explore interprocess synchronization points, parallel actions and deadlock situations. The programmer interface is based on a transparent window multiplexer providing a set of windows for each concurrent process. The window manager interactively maps interesting windows to programmer-specified viewscreen locations, while relegating temporarily uninteresting windows to the background. In implementing a debugger for concurrent programs, a principal concern is the probe effect, or the possibility that the debugger itself masks synchronization errors in the program being debugged. For the examples explored, the probe effect was not observed to limit the localization of implanted synchronization errors.

Abstract: People everywhere are developing multi-window, integrated programming environments for their favorite computers and languages. This paper describes the Mesa programming facilities of the Xerox Development Environment (XDE). It is interesting for several reasons. It has existed in something similar to its current form for about 5 years. It has more than 500 users, many interacting with it 8 or more hours a day. Several million lines of code have been written by these users, including large, multi-author systems.Previous papers have dealt with the Mesa language [Geschke77, Mitchell79], the operating system [Redell79, Lampson80] and the processor architecture on which it runs [Johnsson82, Sweet82]. This paper describes the programming environment: the user illusion, the set of programming tools, and the facilities available for augmenting the environment. Section 2 gives a short history of the environment, including some of our original design goals. Section 3 describes the current state of the user interface and discusses a few of the schemes that were tried and discarded. Section 4 describes some of the program development tools available and discusses how features of the language have influenced their design, and indeed influenced what tools are in the set. Section 5 describes other tools that, although valuable to the programming task, are largely language independent. Section 6 talks about how easy it is to make additions to the system, and gives examples of user additions—some that modify the environment and some that simply provide new tools. Section 7 discusses what we feel are major successes and what we feel needs to be done in the future.

Abstract: Relational databases are of increasing interest for applications outside the traditional business data-processing environment We have introduced the notion of complex objects as one extension to a relational database system (System R) to better support these non-business applications, in particular, engineering design In this chapter, we discuss five aspects of complex objects: concepts and semantics, implementation, query optimization, efficient use within application programs, and user interface

Abstract: ADM is a system for developing user interfaces. We call it a dialog manager; it is similar to what others call a “User Interface Management System” [8]. Although ADM is still being developed, it has been used to construct several applications.A dialog manager divides an application into an “interaction handler,” which interacts with the user, and an “underlying application,” which processes user commands and data. With ADM the application designer writes the underlying application in a conventional programming language and defines the interface between interaction handler and underlying application in terms of “tasks,” things the user can do, and “states,” sets of tasks that are active at one time. The user interface designer defines the interaction handler in terms of “presentation techniques,” which present tasks to the user, and “structuring techniques,” which describe screen layout. Design decisions made for ADM include using a precompiled, declarative dialog description, a flexible division between interaction handler and underlying application, allowing either interaction handler or underlying application to maintain control, and the inclusion of help and error support.

Abstract: Few examples of formal specification of the semantics of user interfaces exist in the literature. This paper presents a comparison of four axiomatic approaches which we have applied to the specification of a commercial user interface–the line editor for the Tandy PC-1 Pocket Computer. These techniques are shown to result in complete and relatively concise descriptions. A number of useful and nontrivial properties of the interface are formally deduced from one of the specifications. In addition, a direct implementation of the interface is constructed from a formal specification. Limitations of these specification examples are discussed along with future research work.

Abstract: The GRaphical INteraction System (GRINS) is described, which integrates an automation-based dialogue controller with a dynamic display model to provide a User Interface Management System. The linkage between the logical device interface and the graphical presentation of virtual devices is discussed. A display manager to support dynamic manipulations of hierarchically structure images is presented. Lastly a model of Display Objects whereby application-specific display objects can have computational constraints defined is described. The constraint system is equivalent to an attributed grammar and is evaluated using an incremental attribute flow algorithm.

Abstract: There is a consensus among designers on the need for a rigorous separation of the functionality of a computer system from its user interface. The principle remains sterile unless some way is provided to put it into practice. It is argued that designers of the interface between users and computer systems need a toolkit of abstractions that embody human factors knowledge while automatically executing the low-level details of the interaction. We believe that the notion of a user interface toolkit constitutes a reasonable way to enforce this separation. Given this approach, the next goal is the definition of a toolkit that is useful. The author points at some general benefits resulting from the toolkit abstractions. In particular, the user can avoid "communication deadlocks" by running several applications simultaneously; or he can obtain distinct views of an object through the external view mechanism; or, as a last example, he can interact by means of the dialog socket with the various applications on the workstation in a consistent way through a unique (refinable) dialog-handler (or a dialog-handler of his choice). Therefore, the proposed abstractions improve the quality of user interfaces when viewed in the large. Conversely, when viewed in the small, these abstractions cannot be guaranteed 100% "user-friendly": each class of users and each class of tasks have specific requirements that are to be satisfied on a case-by-case basis.

Abstract: Recent advances in hardware technology have made feasible the design of sophisticated image information systems. There is need for image information systems in many application areas. A survey of commercial systems that are currently available indicates the diversity of product orientations, nonuniformity, and lack of integration in their capabilities. A survey of R & D efforts indicate that many sophisticated techniques and concepts have been developed, but lack of integration again prevents their immediate applications. Based upon these considerations, an approach to software design for image information systems to achieve system integration is suggested, which emphasizes program portability and modularity, self-descriptive data structures, unified image processing language and programming environment, and flexible user interface. The concept of generalized icons is proposed as a means to help achieve such system integration.

Abstract: A logical next step in the evolution of the computer/user interface is the incorporation of sound, thereby using the sense of hearing in our communication with the computer. This allows our visual and auditory capacities to work in unison, which produces a more effective and efficient interpretation of information received from the computer than sight alone. In this paper we examine earcons, which are audio cues used in the computer/user interface to provide information and feedback to the user about computer entities. (Earcons include messages and functions, as well as states and labels.) Here we present design guidelines for the syntax of earcons. Earcons are constructed from pitches, rhythms, and motives, short sequences of notes with a specific rhythm and pitch, embellished by timbre, dynamics, and register. Compound earcons and family earcons are introduced. These are related motives that serve to identify a family of related cues. Examples of earcons are given. 18 refs.

Abstract: G-WHIZ is a QBE-style interface for the functional data model, with extensions that sup- port recursively defined structures such as part hierarchies. Explicit joins are rarely needed because set-valued and entity-valued functions of the functional model are supported. The recur-sive facilities are integrated with the rest of the language. G-WHIZ currently is being implemented as the user interface to a CAD/CAM DBMS.

Abstract: Love playing with those fancy menu-based graphical user interfaces, but afraid to program one yourself for your own application? Do windows seem opaque to you? Are you scared of mice? Like what-you-see-is-what-you-get but don't know how to get what you want to see on the screen?Everyone agrees using systems like graphical document illustrators, circuit designers, and iconic file systems is fun, but programming user interfaces for these systems isn't as much fun as it should be. Systems like the Lisp Machines, Xerox D-Machines, and Apple Macintosh provide powerful graphics primitives, but the casual applications designer is often stymied by the difficulty of mastering the details of window specification, multiple processes, interpreting mouse input, etc.This paper presents a kit called EZWin, which provides many services common to implementing a wide variety of interfaces, described as generalized editors for sets of graphical objects. An individual application is programmed simply by creating objects to represent the interface itself, each kind of graphical object, and each command. A unique interaction style is established which is insensitive to whether commands are chosen before or after their arguments. The system anticipates the types of arguments needed by commands, preventing selection mistakes which are a common source of frustrating errors. Displayed objects are made "mouse-sensitive" only if selection of the object is appropriate in the current context. The implementation of a graphical interface for a computer network simulation is described to illustrate how EZWin works.