The Desktop of Tomorrow:

From User-Centered to Information-Centered Computing

Norman Meyrowitz

Institute for Research in Information and Scholarship (IRIS)

Brown University

155 George Street

Box 1946

Providence, RI 02912

July, 1989

Minor Updates December, 1990

Draft 0.95

Abstract

How do companies like Apple and Microsoft pull the next rabbit out of the hat without upsetting those who like the current rabbit just fine? How does one make a substantial improvement to a user interface metaphor that has been touted and accepted as a substantial improvement over previous user interfaces? This paper attempts to outline a vision of the next levels of integration of the Macintosh, Windows, OpenLook-style desktop interface, pointing out many incremental changes and additions that independently will feel natural to those who have invested their cognitive stake on the desktop of the 80s, but when taken together will provide a substantially new and coherent infrastructure of the 90s.

1. Introduction

Part of the promise of the personal workstation is to transform data into information so that users can transform information into knowledge. As Richard Saul Wurman aptly put it more than a decade ago, an abundance of data is not always a boon. "Everyone spoke of an information overload," he said, "but what there was in fact was a non-information overload."

The desktop metaphor, created in its near-present form close to ten years ago, but the product of close to 50 years of thought and vision, was created to help address the problem of better access to and better creation of information using a computer. Today millions of individuals use the desktop user interface to develop and retrieve information in a way that they were unable to do with previous interfaces.

1.1 The Desktop Grows Up

Yet it has become macho for pundits to state that the desktop metaphor is on its deathbed — it has reached its maximum capability in aiding the user, and a wholesale replacement had better be on the horizon "real soon." Some of these pundits are actually those vendors who don't have desktop interfaces and would just as soon skip a generation than go through the effort of building one. Others, on the other end of the spectrum, are those that have large installed bases of users familiar with an existing desktop interface, and who see it easier to create a new interface from scratch rather than extend the desktop interface and keep it backwards compatible.

The desktop metaphor, however, has not reached old age. Rather, it has simply reached puberty. Like an adolescent, the desktop interface is gangly, awkward, and often doesn't do what you asked it to do. Few parents have the opportunity to discard their teenagers (though many may have fantasized such on occasion), and one must expect that few computer companies will have a chance to discard their interfaces in the near future. Part of the parenting process is aiding in the transition from childhood to maturity, and companies like Apple and Microsoft now must concentrate on taking the desktop through these wonder years.

This paper attempts to look at the desktop of tomorrow from the following vantage points:

• How can we extend the existing metaphor, rather than discard it, along with all of the expertise and training that has gone into it?

• How can we meld a variety of technologies, rather than use a single "popular" one, to empower the users?

• How can we make sure that hardware and processors are built to support a software vision, not vice versa?

• How can we make sure that the main purpose of the new desktop is enabling users to accomplish their tasks, not simply providing provocative technology?

• How can we develop a desktop interface that allows users to find and discover information that may not be on their local desktops?

• How can we assure that the desktop interface remains user-centered but also becomes information-centered?

This paper first provides an historical perspective on the desktop metaphor, and then discusses the data and the activities that users typically need in their daily work. It focuses on these areas by discussing the specific requirements and our suggestions for how these requirements can be met by user interfaces and technologies in the future. It follows with a discussion of the architecture that will be necessary to make this possible. Finally, a conclusion provides some overall observations about the future of the desktop and examines the feasibility and timeframe of the work to be done.

2. The Desktop — Updating the Vision

2.1 Historical Perspective

The desktop environment is the result of years of accumulated vision on the part of many pioneers in computing. Vannevar Bush, as early as 1932, anticipated the development of technology that would allow individuals to have, on a console at their fingertips, all the world's knowledge, and to create coherent associations between segments of this knowledge.

In the early 1960s, Licklider of MIT, a pioneer in the development of information retrieval systems, wrote an article that predicted the creation of online libraries in which users would be engaged in browsing, retrieval, and creation of new knowledge.

In the mid 1960s, Doug Engelbart undertook a massive effort at SRI in order to augment man's intellect with computer tools, and through his work, invented things like the mouse, multiple simultaneous windows of information, outline processing, network-wide hypertext, etc. Engelbart's work was the first large-scale attempt to use computing technology for the express purpose of enabling both individuals and groups of individuals working together. His notions of connectivity and of multiple views of information carry forward to today and are still largely unrealized.

In the mid to late 1960s, Ted Nelson coined the word "hypertext" to associate the non-linear materials that the computer could finally allow individuals to create easily. His books Computer Lib/Dream Machines and Literary Machines provided a conceptual blueprint for a computer environment for the user that provided deep integration of thoughts and ideas and multiple media in which to express those thoughts and ideas.

By the mid 1970s, Xerox's Palo Alto Research Center had pushed the notion of personal computing, with the Alto workstation and the Ethernet network. On the Alto, many personal productivity tools flourished. One of the most influential was Bravo by Charles Simonyi, et al., a pioneering, sophisticated WYSIWYG text editor that pioneered styled "looks" and piece-table technology. Alan Kay, Adele Goldberg, Dan Ingalls and others created Smalltalk, an extremely integrated object-oriented environment, one of the goals of which was to provide a seamless integration between productivity applications and programming. Smalltalk pioneered the use of multiple overlapping windows, allowing the user to deal with more than one context at a time. At the same time, Larry Tesler, with help from Peter Deutsch, solved the age old problem of how to point to text characters on the screen while developing the Gypsy editor. The idea of an insertion point between characters, as commonplace as this seems today, made way for easy selection of spans of characters, and more broadly, in the generalization of selection as a fundamental paradigm.

In later instantiations of Smalltalk, user interface issues became paramount. Browsers, which provided direct manipulation interfaces to file traversal, pop-up menus, selection as a basic and important system concept, and an integrated language in which users could modify the behavior of the system all began to provide a more powerful interface. Most importantly, Smalltalk articulated the concept of modelessness for the first time. The Teslerian tenet — "don't mode me in" — demanded that the user should always be in a state that he or she could easily comprehend. The user should always have a familiar environment, and should never get transported to an alien land from which, like Dorothy in Oz, it was impossible to return without some secret incantation. This notion of modelessness, coupled with many things occurring on the screen at the same time in overlapping windows, enhanced the number of activities users could undertake successfully at any given time. The Xerox systems also pushed the state-of-the-art in communications, by factoring the notions of file servers, electronic mail, electronic messaging, and shared printing into the desktop environment.

By the early 1980s, the closest ancestor to today's desktop environment — the Xerox Star interface — grew out of the previous work at PARC.

Several design goals permeated the Star:

• The designers determined that users should simply point to specify the task they wanted to invoke, rather than remember commands and type key sequences. They believed that the user should not need to remember anything (of consequence) to use the system.

• An important consideration was the development of an orthogonal set of commands across all user domains; the copy command in the text formatter, for example, should have similar semantics to one in the statistical graphing package.

• The system was designed to operate by "progressive disclosure." Star strived to present the user with only those command choices that are reasonable at any given juncture.

• Finally, Star was an interactive editor/typesetter; the screen was, for the most part, a facsimile of what the final document would look like.

The Star development team, which worked several years considering possible models, remarked:

The designer of a computer system can choose to pursue familiar analogies and metaphors or to introduce entirely new functions requiring new approaches. Each option has advantages and disadvantages. We decided to create electronic counterparts to the physical objects in an office: paper, folders, file cabinets, mail boxes, and so on—an electronic metaphor for the office. We hoped this would make the electronic "world" seem more familiar, less alien, and require less training. (Our initial experiences with users have confirmed this.) We further decided to make the electronic analogues be concrete objects. Documents would be more than file names on a disk; they would also be represented by pictures on the display screen. [From "Designing the Star user interface" by D. C. Smith, C. Irby, R. Kimball, B. Verplank, and E. Harslem in April 1982 issue of BYTE magazine, ©1982 Byte Publications, Inc.]

For the personal computer user in 1983, familiar with either a CP/M, Apple II, or MS-DOS command line interface, it was the original Lisa desktop metaphor, the forerunner of today's Macintosh desktop, that opened new vistas for the masses, in that the computer changed from a data-centered box to a user-centered box.

Drawing on the work of the Xerox Smalltalk and Star interfaces before it, the Lisa pushed the metaphor of a direct-manipulation interface. Some have called this an icon-based interface, but in fact, icons were but one of the components of the vision. Most importantly, the desktop metaphor enforced the notion of a single focus at any given time — the selection — to which operations, typically chosen from a pull-down menu or keyboard/mouse equivalent, could be applied.

This interface was most obvious in the Finder, where icons represented the common nouns of the office — files, folders, trash cans, and tools — and menu items, representing the common verbs of the office — open, close, save — operated upon the nouns. Multiple, overlapping windows allowed several folders to appear on the screen simulating the pieces of paper on a desk. The notion was to make as modeless an environment as possible: one didn't get caught in printing mode or delete mode or edit mode.

The Finder represented the formerly difficult world of the hierarchical file system directory through an intuitive interface in which folder icons could be opened to reveal windows that contained nested folders and documents, which themselves could be opened. The user never had to explicitly specify nodes in a tree; rather, the user perused the tree by actually traversing it through the action of opening folders and documents. Yet the Finder, while based upon direct manipulation in many ways, missed several important features that might have made it easier to use.

The themes of the first desktop metaphor were:

• Modelessness

• Consistency

• Progressive disclosure

• Icon-based representation

• Selection/menu (noun/verb) interface

• What-you-see-is-what-you-get (direct manipulation)

The desktop user interface freed users from the bondage of idiosyncratic keyboard interfaces. Today the desktop on the Macintosh is a still powerful metaphor, but one whose potential has been stunted by the legacy of the tiny machine (128K of memory with a 342 x 512 pixel screen) on which the desktop metaphor was released. Microsoft Windows uses a different look and feel from the Xerox Star and the Macintosh, but largely is based on the same design contraints. The design constraints are limiting because they focus on:

• Individual users rather than groups of users;

• Standalone, rather than networked computing;

• Rigidity, rather than flexibility, in both views and operations at the Finder level;

• Insularity of data from other data;

• Insularity of applications from other applications;

In subsequent sections, this article hopes to identify the themes which are vital in overcoming these limitations and extending the life and functionality of the metaphor.

2.2 The Themes of Tomorrow

The updated vision of the desktop must be one that continues to uphold the traditions of the rich past of Bush, Engelbart, Nelson, Kay, Simonyi, Smith, Tesler, and others. But it must seek to uphold those traditions by addressing themes that have always been part of the vision, but have not yet been given sufficient emphasis in practice.

We believe that these critical themes are:

• Integration

• Aesthetics

• Perspective

• Access

• Service

• Community

• Adaptation

By integration we mean the ability of the system to not treat data as separate, private islands, but as components that can be easily linked, associated, combined, and incorporated through the use of general desktop support. Similarly, applications should not be treated as insular processing elements, but should be part of a structure in which they become tools that are used jointly, rather than separately. This goes much further than the copy and paste of today.

By aesthetics we mean the ability of the system to have an innate aesthetic that allows the user to become both familiar and intimate with the way the system. Part of this is a visual aesthetics — how the system looks. This requires making the information that is presented to people conform to the highest graphical design ideals. This may require changing part of the look and feel to make the fonts, icons, and controls a less overpowering part of the interface. It will require innate system support that lets users develop information with superb design as the default. The other part of this is an operational aesthetics — how the system feels. It will require continuing to enforce policy across applications that maintains consistency, reliability, familiarity, and direct-manipulability.

By perspective we mean the ability of the system to provide the user with not just a single viewpoint of the data/information space, but a variety of views, each of which provides an important slant on the data. User's should not feel enslaved by the metaphor; rather, the metaphor must be fluid enough to provide for a variety of vistas.

By access we mean the ability of the system to allow the user to determine what data exists in the system, explore it, browse it, retrieve it, and store more of it. The system needs to provide a variety of techniques for storing and indexing the data so that the user can retrieve it in any number of different ways — through query by name, content, keyword, or attribute. It needs to provide access to local data sources and remote data sources in a consistent manner. Access also means that the desktop environment itself should be able to be examined, queried, and manipulated like all other data.

By service we mean the ability of the system to provide, on demand, a set of general-purpose utilities that significantly enhance the user's daily work. Users need reference services, providing dictionary, thesaurus, quotation, encyclopedia lookup, directory services, which provide names, telephone numbers, ids, and process services, like spelling and grammar correctors, which filters existing data. And users need to be able to create new services — glossaries, lookup tables, etc. — that can be used by the individual or a group of individuals.

By community we mean the ability of the system to allow groups of users, not just individuals, cooperate in their daily idea work. It involves asynchronous transmission of information — mail, documents, faxes, conferences, etc., synchronous transmission of information — interactive messages, interactive forums, etc., shared access to data, and conventions for allowing synchronous and asynchronous group work.

By adaptation we mean the ability of the system to both be adapted by the user and to adapt to the user. The user must be able to tailor the system to perform functions that weren't specifically included by the system designers. The system must also be capable of explicitly or implicitly recognizing a user's preferences, and updating these as the preferences may change over time.

A system that was designed around these themes would provide degrees of freedom greater than in the desktop of today. Users would begin to work together in teams and groups, sharing documents and annotating them jointly. Documents would become composite, containing data of more than one type, in a layout — outline, magazine style, technical memorandum — that was most suitable to the user's needs. The users would be able to switch back and forth between these alternate layouts easily.

Part of the allure of computers is their ability not to simply be presentation devices, but devices in which discovered information can be reintegrated to make even more coherent information. Users want to treat information as a sophisticated web of knowledge, not as discrete documents that need to be hunted down each time they can be used. There need to be mechanisms for creating such information associations. Integration of data in the new desktop must be much more sophisticated. Users need to be able to make static associations such footnotes, annotations, and static cross references, and dynamic associations, such as links over which data is broadcast as soon a master copy of the information changes.

Users would be able to add keywords and attributes to any object in the system for later retrieval not just by name, but by keyword and attribute value. All elements in the desktop environment would be represented as not only visible objects, but queryable objects. Users could ask the system for all folders updated after a particular date, all applications that haven't been accessed for a year, or all documents that were perused by the team today. As first class objects, users would be queryable, too. What users are currently on the network? What groups is this user a member of? Even the system would be queryable as an object. One could ask the system object what processes were currently running, how much memory was installed, or how much disk storage was being used.

Besides retrieval by name and attribute, a future system would provide retrieval by content, allowing the user to easily retrieve information based upon full-text searches wherever there is text in any application.

Most importantly, a single query interface will allow users to do name searching, keyword searching, attribute searching, and content searching all at once. A uniform, user-oriented interface to system information provides an important basis for information discovery.

The system will provide services that become second nature to users. A set of dictionaries (prioritized by the user) would be available anywhere in the system that text exists, such that a user could simply touch on a word and look it up. Thesauri would be similarly configured. Spelling correction and grammar correction services would be provided, such that users could check the spelling or grammar of any text in the system with a common interface.

In the desktop of the future, users must be given greater support for acquiring data. Systems will need to support not only the interactive editors, utilities, and document translation programs that typify the majority of data entry functionality today, but also real-time data acquisition systems, autonomous optical character readers, and even handwriting recognizers. The systems of the future need to make such operations as easy as using the copying machine in the office or local library. The desktop will also provide agents, fueled by appropriate scripts and stored queries, to peruse newswires, bulletin boards, and other data sources to find information of interest to the user.

Presentation of data must also be made easier through system-supplied functionality. Users, not professionally trained in graphic design, will be provided with system-catalogued styles sheets for all types of graphic display. Whether it be styles for visualization of scientific data ("get me all the styles you have for a 3-D scatterplot"), styles for page layout ("get me all the style sheets for newsletter pages that you have on file,"), styles for word processing ("get me all the styles for footnotes you have," or "get me all the style sheets for theses"), styles for presentation graphics ("get me all the styles for a presentation in a room seating 1000"), the system will provide a uniform mechanism for storing, querying, and manipulating styles and style sheets to prevent the user from having to procedurally specify every last point, pica, and paragraph rather than concentrate on the content.

Users cooperate with one another on daily tasks, and need computer support for such cooperation, whether it be shared editing, shared databases, or shared annotation. The desktop of the future will have built in support for such cooperation, with facilities that allow simultaneous annotation of documents of any data type. Synchronization mechanisms will allow multiple users to simultaneously edit the same document, both in terms of editing different sections of a document simultaneously and in terms of having a "chalk-passing" protocol so that users in a meeting room, or connected by network and telephone, can share one keyboard and one mouse to accomplish their daily work.

The overriding goal is to have the massive increase in system-wide functionality not appear as a collection of ad hoc goiters haphazardly adhered to the side of the system, but rather as a coherent whole, where the additional, general functionalities built into the system provide the users with additional leverage to do their daily work. The desktop of tomorrow will still follow the dictum of "don't mode me in." But the hope is that the baseline system — the modeless state in which the user most often resides — will provide a richer set of operations over a larger range of data types than currently available. We now look at the requirements and future directions for both this data and the associated operations.

3. Requirements & Future Directions

3.1 The Data

Before one tries to design the next environment for information management, it is important to try to enumerate both the types of information that users will need to act upon and the types of activities they will want to perform on that information. The section attempts to summarize the limitations of the current environment in regard to data, the requirements for the future, and suggested technological directions. The next section does the same for the operations on the data.

3.1.1 Data Types

Below, we address each of the data types that we foresee as necessary for the future desktop. Because each of these data types is worthy of an individual requirements document, we address most of them quite briefly. Most importantly, these data types appear to be the ones that require building block support in the lowest levels of a new environment.

Rich Text.

The text that users desire to manipulate is becoming quite sophisticated. Wherever they edit text, users need functionality that includes standard line justification, standard font changes (face, weight, kerning, etc.), standard tabs. But it also needs more sophisticated features, such as automatic figure numbering, justification around irregular objects, indexing, table of contents management, etc. As well, as detailed below, text support needs to move from the procedural, where users designate the exact formatting specification for every element, to the declarative (markup), where users simply identity the type of each element, and the formatting is done behind the scenes. This functionality has been adopted in the batch world of text processing over the past ten years, but it has not yet been captured, in great spirit, by the world of interactive word processing, largely because of the difficulty of creating an easy to use interface.

Structured Graphics.

Similarly, the structured graphics that user manipulate these days is significantly more sophisticated than that of six years ago. In particular, the use of color (especially "true color" deep bitmaps), the use of spline and Bezier curves, and, in many cases, the desire for three-dimensional structured graphics puts extreme stresses on the graphic models available today. The desktop of tomorrow must include as a basic building block structured graphics editing that meets these needs.

Bitmap Graphics.

Bitmap needs have continued to escalate as well. With the introduction of deep color bitmaps, numbers of features that were not particularly necessary for monochrome bitmaps, like sophisticated burn-in, waterdrop, smoothing, and the like, are becoming essential features for bitmap editing. A standard color bitmap editing building block is of importance in a system of the future.

Three-dimensional/Rendered Graphics.

Personal computer platforms are beginning to be used for sophisticated three-dimensional real-time, and non-real time graphics, both wire-frame and rendered. Currently, with only a two-dimensional imaging model, three-dimensional graphics applications on the Macintosh or under WIndows must first essentially implement a three-dimensional imaging model and then build the application on top of this model. The systems of the future must include both a three-dimensional imaging model which includes lighting and shading models for rendering, and a three-dimensional building block, which provides an interactive 3-D graphics editor upon which applications developers can build.

Spreadsheets.

Third-party spreadsheets in the desktop environment have begun to diverge in functionality, adding features outside of the core of the original spreadsheet idea. Some of this is important functionality, but largely the additions have been of features that were not provided as general features of the system (scripting, embeddable graphics, etc.). In the future, there needs to be a spreadsheet class and protocol defined to which all spreadsheets adhere. Developers could still subclass their spreadsheet applications to provide additional functionality, but by having all spreadsheets adhere to a common subset protocol, the spreadsheet could begin to become a computational device used by other programs, not just by end users, regardless of the vendor of the spreadsheet. Similarly, by adhering to a common subset protocol, desktop scripting interfaces to spreadsheets (rather than macro languages written for each spreadsheet) could be written in a very general fashion. As well, spreadsheets would not need to implement full graphing capabilities, but could take advantage of more specialized graphing building blocks.

Chronological data (timelines, calendars).

Calendars and timelines are used all throughout the system in any number of ways, but there is no system support for such devices. The system should support a building block that provides common views of calendars and timelines, so that programs that need to use these (from scheduling programs to tracking programs to laboratory notebook programs, to room reservations programs, etc., etc.) can avail themselves of system-provided functionality and not spend the time reinventing the wheel of how to display and manipulate calendars.

Similarly, the following list describes even more building blocks that will be required in the desktop of tomorrow:

Voice.

Audio.

Music. MIDI,

Statistical info.

Modelling info.

Video.

Animation.

Bibliographic databases.

Personal databases.

External databases (non-local info).

Reference materials (dictionaries, etc.).

Cartographic materials (atlases, maps, etc.).

Symbolic mathematics.

The above constitute a non-exhaustive list of the data types that are required by large populations of users. Rather than try to provide a detailed discussion of each of those data types (whcih would need to be rather long to cover the sophisticated requirements of the 1990s), the next section makes a plea for an evolution from the standard monolothic applications of today to reusable, object-oriented building blocks of tomorrow, which can be "mixed and matched" as by the user with an appropriate compound document architecture.

3.1.2 Building Blocks

Most importantly, the above data types that individuals and groups will use in their daily work must be provided as "standard equipment" building blocks in the desktop of tomorrow. By providing sophisticated building blocks such as these, users begin on a higher plane than they do in today's environment, and developers of more sophisticated building blocks or multi-data type applications begin with far more off-the-shelf material.

This could have severe economic effects on third-party developers, who would be shut out if this were a closed system. But if system vendors such as Apple and Microsoft provide a standard protocol interface to which all building blocks adhere, and more specific standard protocol interfaces for each specific data type, multiple vendors could provide a better interface, more speed, and more functionality while adhering to the same low-level protocol. Such a standardized protocol interface for "pluggable building blocks" may actually encourage development by third-party vendors, because the areas for improvement will be clearly circumscribed. Third parties will concentrate on developing functionality that does not yet exist, rather than on reinventing the wheel.

3.2 The Operations

Above we have carefully arrayed types of data that typical users will want to handle. But how do those users want to handle that data? The activities that users perform on data is myriad: entering, acquiring, indexing, storing, finding, navigating, browsing, retrieving, filtering, exposing, collecting, presenting, manipulating, editing, refining, organizing, connecting, linking, communicating, sharing, exchanging, tailoring, and customizing, to name a few.

In our look towards the desktop of the future, we have chosen seven themes — integration, aesthetics, perspective, access, service, community, and adaptation — that we believe comprise most of these activities. In the section below, we detail these seven themes and the extensions to the desktop we propose to embody these themes.

3.2.1 Integration

Hypermedia

Anchors

The notion of the selection, the object or set of objects that is currently the focus of the user's attention, is a fundamental concept in today's desktop environment. Yet in the current desktop, the selection is an ephemeral entity; once a new selection is made anywhere else, the current selection is lost.

Yet selections, in some sense, are akin to highlighting a book with a fluorescent marker. Often, a user wants to select something in a document not just to perform a fleeting operation, but to mark the object or objects selected as important for later study. If the document is edited, the user wants the highlighting to stick to the objects that were originally selected. The user wants these selections to endure for the lifetime of the information. We call these persistent or "sticky" selections anchors.

Anchors are the basis of the next level of integration in the desktop, and are a fundamental element of a variety of functionalities. Just as document names are a handle to a rather coarse aggregation of information, anchors are a handle to a finer-grained set of information inside a document, to which a user wants to call attention. Just as selections are a concept independent of the applications in which they are used, so are anchors application independent. In fact, the importance of anchors is that they represent an application-independent way to retain references to important information within documents from user-session to user-session.

As such, anchors can be used in many ways. First and foremost, they are of particular interest as the source and/or destination points of hypermedia links (discussed further below). Second, they can be used without links, simply as a means to record an interesting bit of information, like a bookmark. In both cases, it is important to allow users to add keywords/attributes to the anchors, so that they can later perform retrievals for those anchors that fulfill a certain criteria. For anchors that contain text, the retrievals could use not only keyword information, but full-text search algorithms as well. Editors like the MPW editor have the notion of these named anchor-like bookmarks, but they are implemented as special purpose features of that application, rather than as system-supported functionality.

The implications for anchors can go further, however. Currently, the clipboard is a mediator that simply allows one application to write a data structure to a common "file" and allows another application to read that data structure. Once written to the clipboard, the data has virtually no ties to the document it came from. Because of this, operations like transpose and exchange are typically not implemented, because those operations need a clipboard that remembers not only the content of the selection from the application, but also the exact location of that selection.

Anchors essentially require that the clipboard remember not just content but location. Now, a Transpose command could be implemented easily. The user would create a selection and choose copy, as is normally done. The clipboard would remember the location of that selection. The user would now be free to browse and find the other part of the transposition. They would then select it, and issue the Transpose command. The Transpose command would copy the information in the second selection into the location of the selection on the clipboard, and then copy the content of the clipboard into the second selection. Since transpositions comprise a surprising large number of editing tasks, this seemingly innocent functionality could have great impact on the effectiveness of users. So anchors provide not just hypermedia functionality, but deep system capability.

Navigational linking

The navigational link, as shown in our own Intermedia system, adds an additional level of integration to the normal desktop environment represented by the Macintosh Toolbox or the Microsoft Windows environments. Where previously, one could simply copy information from one desktop document to another, with navigational linking, one can create links between any selected information in one document and any selected information in another document. These ties are persistent: they survive for the lifetime of the document, both in memory and on disk. One can follow these trails of links to explore a corpus of knowledge in the same way one might explore an encyclopedia. At the end of each link one can find not only text, but graphic diagrams, digitized images, timelines, three-dimensional manipulable models, animation, and even video or audio. Intermedia is a tool for both the author and the reader, for both the student and the scholar — it provides a way to connect information in sophisticated and complex ways.

The endpoint of a link — an anchor — can be any entity that the user can select in that particular application. In text, a link anchor can be an insertion point, a character, a sequence of characters, a word, a sequence of words, a paragraph or the entire document. In graphics, the link anchor can be a single graphics object or a multiple-selection of graphics objects. In a spreadsheet, for instance, the link anchor could be a cell, a range of cells, a row, a column, or a set of rows and/or columns.

To make link creation as simple an operation as possible, Intermedia uses the same interface paradigm as the now familiar cut and paste operation. The user first selects the source anchor of the link and issues the "Start Link" command from the menu (see Fig. 1). This is analogous to selecting an item and choosing "cut" or "copy," with the exception that the selection from the "Start Link" command is remembered in the linkboard, the hypertext equivalent of the clipboard. The user is then free to do anything that is desired, including opening other documents, creating new documents, editing existing documents, etc.

Fig. 1: The "Start Link" operation

Fig. 2: The "Complete Link" operation

When the user finds an appropriate destination anchor for the link, he/she simply selects that anchor and issues the "Complete Link" command from the menu (See Fig. 2). This is analogous to selecting an item and choosing the "paste" command. When "Complete Link" is issued, a persistent tie is made from the anchor that is currently referenced in the linkboard to the anchor that the user just selected. This persistent tie will last eternally, unless a user explicitly deletes that link. Since links are bi-directional, a marker appears near the both source and destination anchors to indicate that a link exists and may be traversed. Following the link is as easy as selecting the link marker and issuing the "Follow" command from the menu (See Fig. 3). As a shortcut, the user can simply point at the link marker and "double-click" the mouse to traverse a link. The result of the follow operation is a traversal back to the other endpoint of the link, with that endpoint highlighted in gray (see Fig. 4).

Fig. 3: The "Follow" operation

Fig. 4: Result of the "Follow" operation

Five years ago, with the exception of people at Xerox PARC and a few pioneers using Smalltalk and Lisp in research laboratories and academia, the paradigm of "cut, copy, and paste" was virtually unknown. Now, with the advent of the Lisa and Mac toolboxes, and more recently, of Microsoft Windows, that paradigm is a familiar one, even to five-year-olds using MacPaint. This paradigm caught on for four reasons: 1) powerful things could be done with this paradigm; 2) the paradigm was extremely easy to motivate and teach to end-users; 3) the toolbox vendors touted the copy and paste protocol as an important integrating factor that all software developers should include in their applications; and 4) most importantly, the toolbox supporters provided the framework for copy and paste deep in the system software and provided developers the protocols that enabled them to incorporate the paradigm into their software with relative ease. The paradigm is so widely-accepted that consumers regularly sneer at and ignore software that does not provide full cut, copy, and paste support.

Hypertext/hypermedia has the same potential for making fundamental improvements to people's daily work. Like "cut, copy, and paste," making and following links fulfills factors one and two above — it provides a powerful integrating ability and it is reasonably easy to motivate and teach to idea workers. Yet hypertext/hypermedia will only catch on as a fundamentally integrating paradigm when factors three and four can be fulfilled. Linking functionality must be incorporated, as a fundamental advance in application integration, into the heart of the standard computing toolboxes — the Macintosh desktop, Microsoft Windows, Presentation Manager, NextStep, etc. — and application developers must be provided with the tools that enable applications to "link up" in a standard manner. Only when the paradigm is positioned as an integrating factor for all third-party applications, and not as a special attribute of a limited few, will knowledge workers accept and integrate hypertext and hypermedia into their daily work process.

Warm linking

Warm linking builds on navigational linking to allow even additional levels of integration. Where navigational linkage allows the end user to simply follow from an anchor in one document to an anchor in another document, warm linking allows for the exchange of data over that link.

In particular, warm linking allows the user to simply issue the "Push" command and send the contents of the anchor in the current document over the link to replace the contents of the anchor in the destination document. Similarly, the user can issue the "Pull" command and replace the contents of the anchor in the current document with the anchor that is at the other end of the link. A master paragraph could be kept in a central document to which many others documents linked, and when it was updated, the owner could simply "Push" the update anchored paragraph to all of the other documents. Using the same mechanism that is needed for navigational links, we have added an additional level of integration.

As part of our IRIS's Interemdia project, we have a working prototype of warm linking functionality. An implementation document [Catl89b] by IRIS discusses this further.

Hot linking

Hot linking extends the level of integration even further by providing automatic synchronization of linked anchors. In hot linking, one anchor is specified as the "master" and the other anchor is specified as the "instance." Whenever the master anchor is modified, the updated anchor contents is sent over all links attached to the master anchor to replace the contents of the instance anchors at the other end.

Hot linking (also called hot views or live copy/paste) has been implemented on the Macintosh, in several integrated applications (single applications that support multiple data types, e.g. Lotus's Jazz), but not as a general purpose functionality between any two applications. In the Microsoft Windows and OS/2 environments, mechanism exists for applications to publish a live copy/paste protocol based on the DDE inter-application communications mechanism, but few applications have supported this functionality in general. Microsoft's newly announced OLE protocol, which runs on top of DDE, and Apple's previewed System 7.0 software are expected to provide some level of live copy/paste functionality on a broader scale.

What is important in this, and future versions of the desktop environment, is to make sure that there is a single mechanism that will handle navigational linking, warm linking, and hot linking, rather than having three individual, conflicting models. As well, there are other issues that any system supporting hot linking must address: Is it possible for users to break the link? If so, do users get a copy of the master in place of the instance, or do they end up with nothing where the instance used to be? Can the instances be edited, or are they just read-only views of the master? Or can the instances be edited, overriding the information from the master in just that instance? In some cases, the owner of the master doesn't want the instances to be changed at all (the budget shouldn't be changed by anyone but the owner). In other cases, the user wants to have a change in any copy to reflect all copies (change any copy of the logo from Esso to Exxon and have them all update without having to find the master).

Having the instances be editable requires some significant technology. If one pastes an instance of a spreadsheet into a word processing document, and then wants to modify the spreadsheet, the full functionality of the spreadsheet must either be available in the word processing application, or alternately, the system must support a component software/composite document architecture. The ramifications of this are discussed in more detail below.

An issues paper by IRIS [Catl89] discusses the detailed questions surrounding the topic of hot linking.

Active anchors in dynamic media

Many of today's applications — word processing, spreadsheets, and drawing editors — are passive applications. They typically present information to the user and remain static until the user requests a different view or makes a modification. Following links into documents from these passive applications requires simply opening the document, scrolling to the requested anchor point, and returning control to the user.

Yet many of the applications beginning to come into wider use today — animations, video clips, music playback, voice recording — are active applications. Here, when a link is followed into an document from an active application, there are many choices that must be made. Should I simply open the document but not run the action, essentially leaving the document open at the first frame, first bar of music, etc.? Or should their be some way of specifying a temporal span which is my anchor, so that following a link might run 30 frames of animation or 8 bars of music?

Papers by IRIS [PALA89, CATL88] address the action link question further.

Filtering/Querying

Given the basic hypermedia functionality above — supporting navigational, warm, and hot linking — it is important to look at giving users increased control over the link information that is viewed and edited, providing not only but browsing but information retrieval techniques in the multi-user hypermedia realm. Users should also be able to limit the links that are viewed, applying filters based on author, creation date, and modification date. Information retrieval techniques must be instituted so that users of a large, potentially unfamiliar hypermedia corpus can locate interesting and related information. We are looking at how the user, as well as the system, should assign attributes to anchors, links, and documents, and how a sophisticated query interface for such attributes should behave.

Constructing an effective query takes enough effort that if users are to use information retrieval, there needs to be a) easier-to-use interfaces for creating queries and b) system support for saving those queries. One of our fundamental beliefs is the queries of all types, both for hypermedia filtering and other information retrieval, must be represented and stored as concrete objects on the desktop. Queries must be made visible and manipulable to the users, not hidden away or created in modal dialog boxes, never to be seen again.

To make the stored query easy for the user to create, a standardized, graphical syntax for issuing queries must be developed. How much power should be provided to the user? Should the user have full boolean expression capability? Should there be the ability to have nested queries (like nested SELECTs in SQL)?

We have wrestled with these issues, and have developed what we call a token interface. Each token is an icon that when opened provides a property sheet that has all the attributes of the particular object for which it stands. The user fills in the token with values for those attributes. If a single token represents an entire query, the system looks for all objects that have values that match all the filled-in user values. If a user wants to do a nested query, the user can fill in an attribute with another token. For instance, to issue the query "find all documents created by nkm with anchors created by ny," the user would fill in a document token's createdBy: field with nkm and with the anchors: value with an anchor token. The anchor token, would in turn have its createdBy: attribute/value filled in with the value "ny."

This somewhat similar to the interfaces of Rabbit and of the Information/Object Lens system by Malone. But with the addition of tangible, movable tokens, we can go one step further, allowing users to compose boolean filters by arranging icons in horizontal or vertical compositions to simulate boolean OR and boolean AND, respectively. Essentially, the geometric layout of the the tokens is meant to conform to the physical notion of flow. Tokens aligned next to one another horizontally indicates that the information that will flow downward through them will pass through if they fulfill the criteria of any of the tokens in the horizontal stripe. The vertical composition will only let through information that passes through all of the tokens in the vertical stripe. By simply looking at the display, it is obvious to the user where s/he is widening or restricting the search (boolean OR or AND), without using boolean algebra.

An issues paper on this token interface covers this in greater detail. Besides filtering for hypermedia, we are also trying to meld the hypermedia "structure" search with full-content search to provide what appears to the user as a single search space. We discuss this further in the Access section below.

Virtual Links

A virtual link is different from other links because its destination point is not anchored to a precise selection in a document. Instead, the endpoint of a virtual link references some criteria, such as all of the documents that have the keyword "software avionics component." When a user follows a virtual link, the system searches for all of the documents that meet the criteria and presents the destinations in a list from which the user can choose. To specify the criteria, an author might define a desktop script or formulate a full-text or keyword search.

We are investigating how intelligent inferencing techniques could be used to find and suggest appropriate endpoints for virtual links. Endpoints should be ranked so that the ones that are more likely to be of interest to the user are set apart from the others, perhaps by placing them at the beginning of the list or via other user interface mechanisms. Each user might have a profile of rules that the inferencing engine could use to determine the ranking (e.g., the inferencing rules for aerospace engineers would place a higher ranking on information that met the criteria of a virtual link but also had a keyword of "aerospace"). Rules might also be constructed as a user browses through a web — the system could interpret the links that a user followed to determine what sorts of information s/he was most interested in and could construct rules accordingly. Because we believe that users will want to be able to view and modify their individual rule bases, we will need to design intuitive interfaces to allow this functionality.

While the functionality of virtual links and inferencing could be provided as a special feature of certain applications, we again see it as being an integral part of the standard desktop of tomorrow. Because hypermedia, by nature, is a flexible environment, authors are continuously adding to and modifying the information base. Ensuring that all of the related pieces of information are correctly linked to each other can become quite a challenge as the amount of information grows. By making virtual links available throughout the system, users will be better equipped to define links that will keep pace with a rapidly changing hypermedia environment. And inferencing techniques hold great promise for helping users to navigate through a large, changing body of information.

Component Software/Composite Documents

The current desktop environment encourages a model in which a single application operates upon a single data type. A word processor edits text, a graphics editor graphics, and a spreadsheet editor tables. As an acknowledgement of users desire to have documents that contain more than one data type, application implementors typically allow users to paste in static images of other data types (e.g. uneditable PICT graphics documents in Microsoft Word). Applications are islands, hooked together by tenuous bridges at best. Users can use interfaces like Multfinder to switch among a large number of applications, but this is awkward because windows tend to get completely hidden by other windows, and the resulting morass has none of the structure of the final document. Additionally, once the final document is created, there is no mechanism for retrieving the parts. If the user needs to edit portions of the document, difficult questions arise such as: What document is the original copy of this image in? What application was used to create it? If parts of the final document are copied by a user who lacks access to the original documents, the failings of this scheme become even more obvious.

Page layout systems tend to allow the editing of a small set of data types (typically several text formats and several graphics formats), but typically with their own extremely limited editors only good for touch-ups, rather than massive creation and editing. Not only are these editors often underpowered, but they have a different user interface than the one with which a user is normally familiar.

A letter to the editor, from a real user in a real computer magazine, states what users want rather eloquently [BRAI89]:

I have used the desktop metaphor in several incarnations - on the Macintosh, on the NeXT computer, and under Microsoft Windows. I think that the designers of these environments could significantly improve the genre by simply looking at their own real desktops and modeling their metaphors after the real thing.

I am most familiar with the Mac Desktop, so let me use it as an example. The way I use the Mac Desktop isn't anything like the way I use my real desktop. For example, I don't have a bunch of file folders on my desk - I keep them in a filing cabinet. On my desk is a pad of paper or a notebook. I can put anything I want on a piece of paper. On the Mac, however, everything is broken up into incompatible "documents" (i.e., spreadsheet, word processor, drawing, painting, and compiler documents are all completely incompatible and can be combined only in special cases).

With my real desktop, I might take a piece of paper and put some text on it with my writing tools. Then I might get out a set of drawing tools and draw on the same piece of paper. I can also jot quick notes in the margin. I might put a table of numbers on the paper and do math calculations on them using a math tool such as a calculator. I might have a book on the desk that I'm reading from as a reference while I'm writing. All the tools are out at the same time, and all of them are working on the same piece of paper. If I need more tools, I reach into a drawer and put those tools on the desktop, too....

All I want is an operating environment that I can draw and write on at the same time, just as I do on my real desktop.

What users want, and what we have begun to prototype, is a composite document model, where documents are composed of data of different types, each editable with the editor of the user's choice.

The component software system we are designing represents an evolutionary step in software user interface design. Powerful current user interface techniques will continue to be available. Multi-tasking, with multiple, overlapping windows will be supported. Cut, copy and paste commands will still be available for moving and duplicating data. All of these features will exist on a network of personal workstations where multiple users share access to a pool of documents. The documents may be linked to each other in hypermedia webs.

In talking about component software, we use the term editor to correspond to the present-day application program. Just as a user in a conventional system uses the MacDraw application to create a structured graphics document, a Component Software system user uses a MacDraw-like editor to create structured graphics within a document. An editor can be active, which means that it is loaded into memory and ready to be used; otherwise, it is inactive. This is analogous to an application, which may be running (active) or not running (inactive). The active editor that is currently in use is called the current editor. This is analogous to the Macintosh notion of a current application.

Chunks of data are manipulated and viewed in a rectangular (or perhaps polygonal) extent that we call a container. A document consists of one or more containers, each of which is associated with a particular editor. In general, a container can hold both data and other containers, and has one and only one editor associated with it. As an example, a document for a memo might consist of two containers, a text container for the text of the report and a structured graphics container for a diagram. If the author wants to add another diagram, then he or she would add another structured graphics container to the document.

Data will be stored in standard form(s) such that the user can choose which editors s/he prefers for each type of editing task. For instance, one user might set up a profile that says "for text format, use the Microsoft Word editor, for bitmap format, use the MacPaint editor, and for spreadsheet format use the Excel editor." When the user opens a composite document composed of these data types, these editors will be invoked on the corresponding data components. Another user might set up a profile that says "for text format, use the WriteNow editor, for bitmap format, use the SuperPaint editor, and for spreadsheet format, use the Wingz editor." When this user opens the same composite document as the other user, the same data components will appear, but they will be modifiable using different editors. We call these profiles editpacks or editor sets.

In our component software design, the storage system for the chunks of data that are viewed and manipulated in containers can vary. It can range from one chunk per file in a typical file system to one chunk per object in an object-oriented DBMS. Having the chunks stored separately, rather than all in a single data stream adds additional complexity. Given this architecture, I could have the same data appear in two different documents, merely by pointing to the same chunk. Even more interestingly, I might have one view of a set of data components as as an indented outline and another where I view these components as magazine article, with its complex, two-dimensional layout. Essentially, what are now applications that must have all sorts of mechanism for handling the creation and modification of content (page layout systems with their embedded text and graphics tools, outline editors with their embedded text and graphics tools, etc.) become editors whose main concern is not content, but how to manipulate, edit, and display containers that will be nested inside of it. One could now buy an outline editor that was capable of showing levels of detail, demoting and promoting nodes, etc., and choose the editors that one desired to create and manipulate the contents of nodes. This is can be an incredibly liberating technology if implemented correctly.

An end-user of a component software system will be able to create documents that incorporate a wide variety of media, all of which can be created and modified within the context of a single document. The user will be able to add new types of data and new editors in an arbitrary, flexible manner, just as the user can now add new applications to a computer operating system. The third-party developer is not shut out of the picture, but relieved of recreating a bunch of already existing editing functionality, and empowered to concentrate on the problem at hand.

As an aside, the label component software seems to be used to identify four related, but different concepts. Some use it as a synonym for a composite documents, where each data chunk is a component, and the data components are plugged together to make large documents. Others use it to identify a system in which a processing object (what Stepstone Inc. has called Software-ICs™) such as sorting algorithms or a compiler or a text editor could be replaced by another processing object that has the same program interface (much like one hardware IC could be replaced by another with the same behavior and pinouts). The third use of the component software moniker is the aggregation of the former two, where the component is a data/editor pair, such that each chunk of data carries around the editor(s) that can manipulate it. The fourth interpretation is a system in which the data chunks are stored as components in an object-oriented database management system. Thus the label component software, like hypermedia and object-oriented before it, has been rendered meaningless as a precise definition.

In fact, most systems are an aggregation of the various meanings. Our system design, for instance, actually comprises all of the definitions — we believe what is needed is composite document architecture in which the editors comply to a standard protocol and can be dynamically loaded in and out, where the necessary editors (or references thereto) are carried around with the data chunks, and in which the data chunks can be stored either in a file system or an object-oriented database.

Summary

Companies like Apple and Microsoft need to create, seamlessly woven into its desktop metaphor, the next levels of integration — persistent integration. They must provided persistent, hypermedia functionality deep in the system so that all third party applications can participate in a) navigational linking (following from one selection in document A to another selection in document B), b) warm linking (manual update of destination from source), c) inclusional ("hot") linking (the destination is updated every time the source is updated), d) action linking (the ability to invoke actions when a link is navigated, and maintain links to dynamic and temporal, rather than just static media), e) filtering and querying of the hypermedia structure, and f) virtual links (links with the destinations endpoints created in real time through querying and/or inferencing the data space.

To encourage such functionality, system vendors must provide a "linking protocol" that developers add to their applications much as they add "cut/copy/paste protocol," and a "linkboard," much the way they provide a "clipboard" for the storage of pending paste operations. As well, system vendors must provide a shared link database, since unlike cut/copy/paste, links are persistent and must a) be stored over time, and b) accessed by groups, not simply by individuals.

Finally, a component software architecture, allowing for composite documents and pluggability of editors, will provide a rather dramatic increase in user productivity and flexibility. The Apple Edition Manager and the Microsoft OLE Protocol are two important steps in this direction.

3.2.2 Aesthetics

The desktop of the future must conform to high visual aesthetics — presenting information to the user in a way that conforms to the highest graphic design ideals, and allowing users to present their information in the same manner. The desktop user must also continue to provide an operational aesthetics — maintaining consistency, reliability, familiarity, and direct-manipulability in operations on the desktop and within the applications that the system provides.

Visual Aesthetics

One of the most important techniques in turning data into information is presenting it to the reader in such a way that the meaning is readily apparent. With the exception of the teaching of English composition, individuals are simply not taught means for the effective translation of data to information of any type, whether it be pictorial, graphical, tabular, cartographic, or whatever. These skills are possessed by a rare few who are designers, graphmakers, mapmakers, etc., who have developed professional skills.

But if the computerized desktop is supposed to provide the means for individuals to turn their data into compelling information, and if most individuals do not have the design skills to do this themselves, then it must be the system itself that provides this crucial repertoire. How can this be done?

Visual style sheets. In the late 1970s, an independent surge in declarative, rather than procedural, specification for text formatting was sweeping the research community. Rather than have individuals explicitly designate the formatting procedures for each element in the document (skip 3 lines, change to 14pt bold Helvetica, etc.), the movement called for users to simply declare the type of a particular entity, and have that entity formatted based upon an entity-to-format mapping behind the scenes. Now, users could concentrate on the content and structure of their documents, and not on the formatting details.

This notion of style has not been strongly promoted in today's desktop. Certain text applications, such as Microsoft Word, provide basic style notions, but they typically are at a relatively coarse, paragraph level. One needs finer-grained styles, that allow one to indicate indirectly the formatting for imbedded titles, for figure numbers, emphasized words, etc. As well, it is important to extend this style capability to other applications — calendars, graphics, spreadsheets, page layout systems, etc. — so that users can be more efficient by developing content, and not format. Imagine being able to change your view of a linear schedule to a graphical calendar simply by applying a different style sheet, or being able to change a tech report to a a magazine article just by applying a different style sheet. This capability of easily imposing different views — the Engelbart viewspec — needs to be recaptured in the desktop of tomorrow.

Most importantly, the notion of styles must be a fundamental one in the system, because it needs low-level support to work properly. In particular, there needs to be support for style-sheet sharing, so groups of users can share the same formatting specifications. We believe that the styles should be stored in the same commonly accessible, shared database that the system will have for other desktop functionality (see Access below). There needs to be support for binding a document with its associated style sheet when it needs to be transferred to a remote system. There needs to be support for allowing users to override particular styles without having to make explicit copies of entire style sheets. The user interface to the management of group style sheets is a challenge, but will provide extensive user empowerment worthy of the mission.

One interface that may meet part of this challenge is that of computer-expedited markup, using inferencing, heuristic, and expert systems techniques to help the user tag appropriate entities. It is often easier for people to simply procedurally change the format of something (e.g., select a piece of text and change it to italics), then to actually think about what descriptive markup that entity should be tagged with. But if the system, after the user made a procedural change to some text, could pop-up with a menu of suggested tags for that element from which the user could choose, part of the cognitive difficulty of tags — categorizing rather than simply doing — would actually be handled by the system. Of course, users should be free to use procedural markup when they need to.

Such work has not yet been undertaken, but appears to be quite promising.

Operational Aesthetics

Operational style sheets.

Just as the style sheets of above provide a way to describe a particular look without having to procedural indicate every formatting action, systems of the future need to provide similar ways for users to describe the specific way in which a particular task should be accomplished. Too often, the user-level commands are just too low-level for the user to easily accomplish the task at hand. A common, incredibly frustrating task is one of creating mailing labels in a word processor. The process is typically described in bits and pieces throughout a large manual, and consists of an enormous number of steps — changing the margins, changing the number of columns, altering the page setup, etc. What is need is an operational style sheet in which a user can save the procedures needed to perform a task under a single declarative name.

These operational style definitions may be active and built out of scripts (see below). Alternately, they may be instructional only, built with a combination of hypermedia, animation and scripting simply for the user to view the steps that must be taken.

More experimentation is needed in this area, but with system support for visual styles, it seems important to use a consistent metaphor to manage operational styles as well.

Document and Folder Templates.

One of the canons of the direct manipulation interface is that users should never be presented with a blank canvas if at all possible. Rather, the user's job should be one of taking an example of what they want, and refining it to be exactly what they desire, by changing both the content, and the form, if necessary.

On the Xerox Start and on the Lisa, this was partially solved by the notion of Stationery Pads. Opening an application provided a blank piece of application paper. But creating a document in that application, saving it as a stationery pad, and then opening the stationery pad essentially ripped off a piece of paper that contained a customized template.

Yet on the Macintosh, this canon was not followed, and templates could only be created through the laborious and idiosyncratic process of manually making copies of an existing template document (and trying hard not to overwrite the template document accidentally). Only recently have user interface guidelines suggested that applications add this capability, but since there is little mechanism in the toolbox to carry this out, this user interface policy has not seen widespread adoption.

Apple's System 7.0 and Microsoft's Windows reintroduces the Stationery pad metaphor for documents. Yet even this needs to be extended to be a more general function. Stationery pads allow a user to turn any document into an icon that represents, essentially, a new type of document. Double clicking on that object will create an instance of that new document type. But with the new multi-application world and multimedia world, often users want to instantiate documents together. This may be accomplished by allowing Folders to participate in the stationery pad mechanism. Now, I could turn a Folder into a folder pad so that when I click on the folder, I get instances of all the documents in that folder. Now, to create the appropriate documents for new employee, I would like to be able to click on a folder pad icon, and have the system create a new folder for that employee, with a payroll document, insurance form, biography template, health form, etc. And using system-supplied scripting functionality, I would like to have the new employees name and other vital statistics filled into those forms automatically.

The Stationery pad metaphor, extended to folders, and coupled with styles as described above, provide an important operational constant for the user.

Hypermedia Templates. Much of today's hypermedia literature mentions the problems of disorientation and being "lost in hyperspace." Better tools are needed to help authors organize a web so that they themselves and other users can better navigate and locate information within it.

One way to avoid this problem is to follow common styles in structuring certain classes of information. Such consistency helps readers to feel more comfortable browsing a web and to locate and access desired information. Stylistic guidelines benefit collaborators working on a new web—the authors are able to more easily see where the "holes" and other "trouble spots" are, thereby eliminating the potential problems of incomplete webs and even duplication of effort.

This will require not only document pads and folder pads, but web pads, which serve as templates that spawn a set of documents and folders that are pre-linked. Not only could each individual document contain template information, but there could also be a set of links between the documents, complete with suggested attributes and keywords. In the employee example above, the payroll, insurance, biography, and health documents would all be cross referenced at appropriate points, so users, for example, could easily navigate from the Blue Cross charge on the payroll record to the health form.

Web templates, however, do not need to be self-contained; users may want to design templates that provide links to and from existing documents. For example, a template for defining new engineering procedures within a company might need to provide links to all other related