Donald L. McCracken

Experience with the ZOG human-computer interface system

Abstract This article is primarily a reflection on more than 8 years of research with the ZOG human-computer interface system. During that time we have experienced extensive use of ZOG. We begin the article with a short description of the current ZOG implementation; then we proceed to a higher plane to describe a general ZOG philosophy that has evolved from our experience. Following the philosophy, we briefly describe the applications we have explored with ZOG, including a major application project for the Navy. Then we provide a critique of the current ZOG implementation by elucidating its strong and weak points. We end the paper with a brief glimpse at our plans for ZOG in the future.

Collaboration in KMS, a shared hypermedia system

This paper describes how we use a hypermedia system (KMS) for our collaborative work. Based on our experience with KMS and our previous research with the ZOG system at Carnegie Mellon University, we believe that a shared-database hypermedia system provides a powerful foundation for collaboration. In this paper, we show how the shared-database capability of KMS, plus particular aspects of its data model, address six of the fundamental issues facing designers of collaborative work systems.

The data model is the heart of interface design

For the past six years, we have been developing a commercial hypermedia system (KMS) based on our previous research with the ZOG system at Carnegie Mellon University. Our experience with ZOG and KMS has convinced us that the data model underlying an interactive system is more important than the user interface in shaping the overall system. In this paper, we show how the KMS data model has influenced important aspects of the user interface. In particular, we show how the properties of KMS frames—their spatial nature, breadth-first view, homogeneity, small size, etc.—affect the nature of the KMS user interface.

PLEXUS: a hypermedia architecture for large-scale digital libraries

This paper describes an approach to developing large-scale digital libraries using hypermedia technology. The research described involves the development of a digital library prototype, called ‘TLEXUS”, that combines distributed hypemwdia technology developed by Carnegie Mellon University and Knowledge Systems over the past twenty years-along with advanced file system meamh doneatCMUduringthepast tenyears.Theprincipal ob~ve of the work is a design capable of very lar@eoperation (both in tennsof thesizeof the database and the number of concurrent users) at viable costs. The full-scale PLEXUS system is designed to exploit the amhitecture of the next-generation Intemet—in order to provide sub-second response for accessing any portion of a petabyte-scale database for at least one million, and perhaps as Pemission to copy without fee all or part of this material is grantedprovided that thecopiesarenot madeordistributed for directeommeraal advantage,theACMcopyrightnotice andthe title of the publication and its dateappear,and notice is given that copying is bypermfsion of theAasociation for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. Cl 1993 ACM w9791-630-l/’93/oolo/Ull 1

Design of hypermedia script languages: the KMS experience

150 many as thee million concurrent users. A specific goal of the project is todemonstmte thefeasibilityof very high performance (a sustained service rate in excess of 10QOOOtmsactionspersecond) at lowmst— appmcimatdy 1(XI tinws better than the price/perfb “aldatabasesystems. rrmnceof today’sbest Commercl

KMS: a distributed hypermedia system for managing knowledge in organizations

This briefing describes the design of the KMS script language and some of the lessons learned from experience using it. The language -the result of over 20 years of ZOG/KMS development -is a procedural, block-structured language characterized by a simple ‘command line’ syntax, a large number of intrinsic commands (approximately 800), and the use of nodes and links as a central aspect of the syntax and semantics of the language. The intrinsic use of nodes and links in the script language provides interesting opportunities, not only for the design of other aspects of the language such as control structures, but also for the use of hypermedia as a programming environment to facilitate development and maintenance of scripts. In addition to designing the language, we have used it extensively to develop many hypermedia-based applications. Our experience, and that of end-user organizations, strongly reinforces our general belief that a script language is a valuable adjunct to hypermedia systems and instrumental to the utility of hypermedia for real world task environments. HOW ARE SCRIPTS REPRESENTED? The KMS script language, called the “Action Language”, is a block-structured language that incorporates nodes and links as fundamental aspects of the syntax and semantics of the language. For understandability and useability, the syntax is kept to a command-line type of simplicity -and almost all ‘nesting’ occurs by links to other frames. “Agents” written in the action language can be as simple as a single line of code, or as complex as large hierarchies of KMS frames, distributed over multiple, heterogeneous machines in a wide-area network. Frames containing action language code are treated as programs, blocks, and routines; links to them are “calls” (versus gotos) with control returning after the node (and its subnodes) have executed. Agents are created and edited just like other KMS frames, and may contain supplementary text, graphics, and images (e.g., as comments) and any of these may be anchors for cross-reference links to other contents in the database (e.g., specifications). The use of hierarchies of frames to represent programs encourages a highly topdown, stagewise refinement style of programming. WHAT PRIMITIVES DOES THE LANGUAGE CONTAIN? Similar to other task-oriented environments like Mathematical, the KMS action language contains a large number of primitives (nearly 800) -due largely to the structure of frames, the types of objects they may contain, and their properties. In addition to primitives for objects and their operations, the language provides facilities for interaction with external entities such as files, directories, and processes. KMS supports interaction with external software by pipes, message queues, and sockets -rather than library calls via an API. This approach has the advantage of segmenting the interaction into separate processes, which enhances reliability (a library call that failed could crash an application). It also enables a more co-routine type of relationship between agents and external programs (either those subordinate or superordinate) -allowing, for example, KMS to iconify and deiconify at the direction of the user or any of the applications sharing a KMS server. The evolution of a large number of primitives has underscored the importance of using a simple, command-line type of syntax -without which we fear agents would become progressively more difficult to construct and maintain as the language continued to evolve. Hypertext ’93 Proceedings 268 November 1993 HOW ARE SCRIPTS EXECUTED? Agents are executed by KMS beginning at a designed “top” frame. The code on that frame is interpreted and executed, links to other frames are followed as required by the conditionality in the program and the state of data in the process. Additional frames are accessed only as needed (analogous to paging). Normally, depending on the size of the machine’s memory and the number of frames to be cached (set by users in their profiles), frames once read are cached in their parsed internal representation. HOW ARE SCRIPTS TRIGGERED? Scripts are normally triggered explicitly by the user by clicking on an active object with the left mouse button -the same button used for navigation. Thus script activation is an alter ego of navigation, if an object is attached to an agent, its link, if it has one, is not followed unless explicitly called for in the script (i.e., “Gotolink”). This overloading of the left button has worked well in practice -particularly because the predominate association of links and scripts to objects is with text objects and the user can determine visually by inspection, whether the object has a link property (denoted by a hollow bullet to the left) or an action property (denoted by a solid bullet to the left). Graphical objects may also be anchors for links or scripts, but have no visual cues to distinguish whether they are active and how. WHAT PROGRAMMING ENVIRONMENT FEATKJRES DOES THE SYSTEM HAVE? In addition to agents being written in frames and acting on frames (as their inputs and outputs), there is also an extensive programming development environment for developing agents -again in frames. This programming environment consists of on-line manuals including ‘construction sets’ from which the programmer can make copies of commands, illustrative examples of programs and procedures written in the action language, and debugging support. Access within this environment is enhanced by the availability of both functional and alphabetic indexes. The design of the language and the programming environment are tightly-coupled, in the sense that the evolution of a large lexicon of primitives in the language has depended critically on (a) the simplicity of the syntax enabled by using nodes as blocks, and links as calls, and (b) the programming environments role as an ‘external memory’ for the programmer [even we can’t remember the argument syntax of the primitives!]. Our experience has shown that the combination of frame representation of scripts, supported by on-line construction sets, and debugging support -facilitates a rapid code-test cycle and encourages a highly iterative, incremental development style of programming. WHO ARE THE TARGET USERS? The target users for the KMS action language are users who have programming experience (i.e., experts). It is not designed for novice or casual users. The primary reason is our belief that the process of developing applications is a task requiring training and experience. Although we do attempt to provide a rich environment (tools, documentation, and language design) to facilitate the development of agents, we do not feel this environment is yet capable of supporting users with little or no programming experience. TECHNICAL BRIEFING PLAN The basic points to be made in the briefing are: (1) An illustration of possibilities for using nodes and links as programming language constructs in a hypermedia script language, (2) The importance of simple language syntax in large lexicon languages (3) The value of using hypermedia as a programming environment, including on-line libraries of intrinsic commands and procedures (4) Illustration of sample typical scripts (5) Script invocation options (6) Discussion of execution options such as interpretation, dynamic compilation, and full compilation (7) Illustration of hypermedia-based debugging support Hypertext ’93 Proceedings 269 November 1993