A Vision of Universal Functionality for Tomorrow's User Interfaces

Gary Perlman
Department of Computer and Information Science
The Ohio State University
Columbus, Ohio 43210 USA

Abstract
[1] Introduction
[2] Independence in User Interfaces
[3] Universal Functions and the Semi-Structured Toolkit (SST)
	[3.1] Data Structure
	[3.2] Lexical-Specifications for Maintaining Format-Independence
	[3.3] Universal Functions on (Lists of) Records
	[3.4] Field-Specifications for Maintaining Application-Independence
[4] Evaluation of Universal Functionality and the SST
	[4.1] Factors Affecting User Acceptance of Information Technology
	[4.2] Analysis of Other Systems with Universal Functions
	[4.3] How the SST Overcomes Previous Limitations
	[4.4] Experiences using the SST
[5] Future Directions
[6] Acknowledgements
[7] References

Abstract

In this paper, I describe universal functions -- functions that can be used in all applications -- and how they can be integrated in existing programs at the level of a common user interface. I consider reasons why some universal functions (e.g., search and sort) have failed to gain the same acceptance as others (e.g., print and copy). I describe a function library, the Semi-Structured Toolkit (SST), which provides universal functions based on abstractions for storage format- and data type-dependencies of semi-structured/frame-based information units. I explain how the SST overcomes obstacles to user acceptance of information technology, and end with a call for research on user interfaces for universal functions.

Keywords: information system functionality, application frameworks

[1] Introduction

Universal functions are functions that are useful in most applications. Some familiar universal functions move, copy, and delete objects. Other familiar universal functions open, save, close, and print files. The above universal functions are so common that application development frameworks for the Apple Macintosh and Microsoft Windows offer support for them in standard menus (move et al in the Edit menu and open et al in the File menu). In this paper, I will show that there are many more universal functions than the standard ones listed above and discuss how they can be integrated into applications. I will discuss the reasons why previous approaches to integrating universal functions have not succeeded and how to overcome those limitations. With the integration of standardized user interfaces to additional universal functions such as search, sort, view, and format, applications in the future will provide greater functionality and increase the productivity of users.

Over the past decade, there has been a dramatic increase in the consistency of how operations on the computer are performed, but little increase in the consistency of what operations are performed. In the video compilation, ``All the Widgets'' (Myers, 1990), we can see the evolution and de facto standardization of the way that users select and edit objects, scroll windows, execute commands, set options, and so on. This consistency has improved the learnability and usability of software. But since the advent of the Xerox Star user interface, which pioneered the concept of universal functions such as move, copy, delete, and change-properties (Purvy et al, 1983), there has been little increase in the repertoire of what operations are provided in all user interfaces. The more sophisticated functions offered by the Star, such as querying, sorting, formatting, and indexing, did not become part of all applications, and to the extent that they did, their user interfaces have been inconsistent. It could be argued that what commands are provided is a matter to be decided by the systems analyst, but the presence of some operations in many applications suggests that these operations are universal -- that they are applicable in all applications -- and that their identification and standardization of presentation will produce a general increase in the productivity of users.

[2] Independence in User Interfaces

Current user interface development software reflects the efforts to reuse development efforts for a variety of application domains, hardware/operating system platforms, and types of users. Each one of these types of reusability is an example of independence (Perlman, 1989) because: it allows the same application to be used on many platforms by many users; it allows the same platform to support many users using many applications; and it allows the same user to use many applications on many platforms. To allow the development of user interfaces to many applications, on many platforms, and by many users, these tools have had many functions and have been difficult to develop. Independence has both costs and benefits.

Application-independent user interface development software must have the expressive power to support the use of functionality in many applications. Well-known examples of application-independent software are toolkits such as on the Apple Macintosh, Microsoft Windows, X Windows, and libraries and interactive tools built upon them. From the application developer's point of view, application-independent development software has required a large learning investment by programmers, but has reduced the need for reinvention of interactive techniques. From the application user's point of view, relearning is minimized because many applications can share a common user interface.

Platform-independence means that applications can be ported to many hardware/operating system platforms. It requires that either applications use a small common subset of user interface functions (e.g., character-based systems), or that the same environment has been ported to many platforms (e.g., X Windows), or that a common set of abstract user interface functions have been built from platform-dependent toolkits (e.g., XVT (Rochkind, 1989); and SUIT (Pausch et al, in press)). From the application developer's point of view, platform-independence has meant avoiding platform-dependent functions, perhaps providing sub-optimal interfaces for specific platforms, but with the benefit of drastically lowered porting costs. From the application user's point of view, relearning is minimized because software on one platform can follow user interface conventions similar to those on others.

User-independence means that applications can be used by users with widely differing needs. For example, in many user interface toolkits, such as the Apple Macintosh, menus can guide users to the functionality they require, but experienced users can invoke the same functions with quick-keys. From the application developer's point of view, user-independence has required an increase in the number of ways the same tasks can be completed, but often this is supported in a well-designed toolkit. From the application user's point of view, the benefit has been to be able to get help when it is required, but allow shortcuts when it is not.

All of these trends in user interface toolkits have improved the learnability and usability of software. Except for some well-known universal functions (e.g, open/save/print/close file in addition to move, copy, delete, and change-properties), toolkits have not focused on the functionality of software. There are many more functions that are applicable to an equally wide variety of information-processing tasks. For example, searching for or sorting records based on the types and values of specific fields or formatting records using a template are universal functions that are either missing from many applications or, when present, are implemented differently. The incorporation of such universal functions should make application developers and users more productive. This is not to understate the importance of learnability and usability, for without them, increased functionality will not result in increased productivity.

[3] Universal Functions and the Semi-Structured Toolkit (SST)

Universal functions are functions that are useful in most applications. Virtually all applications have functions to open, save, close, and print files, and almost all applications have functions to move, copy, delete, and modify the objects they manipulate. These universal functions are so common that they occupy consistent locations in menus in many systems such as the Apple Macintosh and Microsoft Windows (open et al in the File menu and move et al in the Edit menu) and are considered a standard part of user interfaces. All of the non-standard functions to be discussed here are familiar to frequent users of applications -- particularly high-functionality applications found on personal computers -- such as database management systems, spreadsheets, and even word processors. Functions such as searching, sorting, and formatting objects apply to almost any information system. But even when a function such as searching or sorting might be useful in an application, it might be missing because it was not implemented as part of the development environment and it was not added from scratch by the application developer.

Applications usually differ in how their data are formatted when stored externally (and represented internally) and in the types of data processed. The approach presented here in the Semi-Structured Toolkit (SST), a C function library, is to extend the set of universal functions provided for application development while deferring design decisions that contribute to storage format-dependence, application-dependence, platform-dependence, and user-dependence. The SST uses an abstraction called a lexical-specification to adapt to different storage formats, while standardizing internal data structures. The SST uses an abstraction called a field-specification to adapt universal functions to application-specific problems by providing information about data types, ranges, etc. These two abstractions of data storage format and type add structure and functionality with minimal commitment to a rigid data structure. Because the SST primarily provides back-end application functionality implemented with portable code and without specifying a user interface, the issues of platform-dependence and user-dependence are avoided.

[3.1] Data Structure

Universal functions can be applied to any object. In the SST, objects are represented with Semi-Structured Records (SSR), based on the semistructured messages of Malone et al (1987). Both are similar to forms, attribute lists, and frames (Minsky, 1975). Semi-structured records contain a series of fields with arbitrary names and values with types such as number, date, and bitmap. In an SSR, the order of fields is arbitrary and often irregular, except that multiple instances of the same field are ordered.

Malone et al (1987) suggest several reasons why semistructured messages (and therefore semi-structured records) are useful: (1)They allow automatic processing (more so than free text). (2)They allow information sharing without the constraints of a rigid structure. (3)They conform to existing information processing practices (i.e., they are common). (4)Templates of messages can be provided to help users organize material. (5)They simplify the design of systems that can be incrementally enhanced and adopted. Semi-structured records allow more functionality on many types of information without the imposition of a rigid structure.

An example of a semi-structured record is shown in Figure 1. It is a bibliographic record containing eight fields presented in UNIX refer format. Each field begins with a % sign followed by a single-letter field-name.

Figure 1: A Semi-Structured Record (UNIX refer Format Bibliographic Entry)

%T The HCI Bibliography Project
%A Gary Perlman
%J ACM SIGCHI Bulletin
%D 1991
%V 23
%N 3
%P 15-20
%X The HCI Bibliography project has just released its first collections of a
free-access online extended bibliography on Human-Computer Interaction.  The
basic goal of the project is to put an online bibliography for most of HCI on
the screens of all researchers and developers in the field through anonymous
ftp access, mail servers, and Mac and DOS floppy disks.  Through the efforts
of volunteers, the bibliography is approaching 1000 entries, with abstracts
and/or tables of contents; eventually, citation information and hypertext
access will be added.  The first release contains the complete contents of
all the ACM CHI conferences, the complete journal Human-Computer Interaction,
and several other important sources.  Eventually, all of HCI will be online
and freely accessible around the world.

Another example of a semi-structured record is shown in Figure 2. It is a news article containing 13 fields (12 of which are named, followed by the unnamed body of the message). Except for the body, each field begins on a new line and each field's name-value pair is delimited with a : sign.

Figure 2: A Semi-Structured Record (Internet NETnews Format News Article)

Newsgroups: comp.human-factors,comp.infosystems
Path: perlman@moose.cis.ohio-state.edu
From: perlman@cis.ohio-state.edu (Gary Perlman)
Subject: HCI Bibliography Update
Message-ID: (1992Aug24.232143.11379@cis.ohio-state.edu)
Followup-To: comp.human-factors
Originator: perlman@moose.cis.ohio-sate.edu
Keywords: free bibliographic information
Sender: news@cis.ohio-state.edu (NETnews        )
Organization: Computer & Info Sci  Ohio State Univ  Columbus, OH 43210
Date: Mon, 24 Aug 1992 23:21:43 GMT
Lines: 313

The HCI Bibliography is a free-access online extended bibliography
on Human-Computer Interaction.  The basic goal of the project is to
put an electronic bibliography for most of HCI on the screens of all
researchers, developers, educators and students in the field through
anonymous ftp access, mail servers, and Mac and DOS floppy disks.
Through the efforts of volunteers, the bibliography has passed 4500
entries, with abstracts and/or tables of contents, totalling over
four megabytes.

The SSR data structure is at first glance a flat structure of strings incapable of representing hierarchical or graph multimedia structures. However, the names of fields can be chosen to share attributes to allow multiple subsets of fields to be defined and accessed by matching field names based on a substring comparison rather than an exact match. For example, a home-phone field could be an element of a home address subset and a phone numbers subset. Arbitrary links can be represented by interpreting the field value as part of a query. For example, any news article referring to the one in Figure 2 will include the contents of the Message-ID field in its References field. Finally, there is nothing in the definition of SSRs that requires string values, so with the appropriate lexical-specification, binary formats for graphics and sound can be read into SSRs. For efficiency, the input of large values may be deferred until needed; this can be done by storing a file name, offset, and object size.

[3.2] Lexical-Specifications for Maintaining Format-Independence

The formats in Figure 1 and Figure 2 differ in how fields are delimited and named, but both are well-represented as a sequence of name-value pairs. Given that similarity, the question arises, ``Why is different software used for accessing the different data types?'' One problem is parsing the storage format, which is addressed in this section. After the introduction of a set of universal functions in the next section, the other problem of domain-specific functionality will be addressed.

The storage format of semi-structured records varies widely from domain to domain and even within a given application domain. Fields might be tagged explicitly (e.g., the "Subject" field in Figure 2) or implicitly determined by position (e.g., the body of a news article is the last field and is unnamed). Fields might be delimited by newlines or special tags, and field names and values might be delimited by whitespace, typographical markup (e.g., a colon as in Figure 2 or an equal sign), or implicitly from knowledge of when a field name ends (e.g., a single character as in Figure 1 or a restricted character set for names).

The problem of incompatibility of storage formats must be solved before universal functions can operate on format-independent structures. Rather than requiring a specific format, which would reduce the applicability of the functions on which it would be based, a flexible scheme has been adopted in the SST that takes advantage of the regular structure of all semi-structured records. Although bibliographic records, mail messages, news articles, event calendars, etc. have different formats, they all are records of a sequence of (possibly unnamed) fields. The conventions differ for how records, fields, field-names, and field-values are distinguished, but these differences can be represented in a table that is used as a parameter to a parser/generator.

The unique approach of using parameterized software that reads and writes records in a variety of formats is one of the most critical features of the SST. It is more acceptable to users than the approach of requiring a specific format, an approach often used by applications, because it does not preclude the use of tools that work on the original format. It is more efficient, both in time and space, and more convenient for users than converting between different formats. If the syntactic structures were more complex, then variable-grammar-based parsing (Deerwester et al, 1992) or grammar-based conversion (Mamrak et al, 1987) would be necessary.

The SST contains functions that create (allocate) new and destroy (free) old records, and access functions to set and get the names and values of fields in records. There are universal functions to read and write (lists of) records from and to files, respectively.

read(record,format,file) reads a record stored in a specified format from a file.
write(record,format,file) writes a record in a specified storage format to a file.

The format provides lexical-specifications of how records, fields, names, and values are delimited. Once the records are internally represented in an abstract data type (ADT) that hides the specifics of the representation, all other universal functions operate on the record through the access functions of the ADT until the (possibly modified) record is stored in its format. This scheme hides the implementation details of both external and internal storage from all other functions so that any function following the ADT protocol can be universally applied.

[3.3] Universal Functions on (Lists of) Records

The following universal functions will be described informally to indicate their general purpose and their most important parameters, omitting the specifics of data types and other parameters controlling the precise behavior of the functions. Although these details are important for a specific set of functions, they are not important for understanding the main ideas. Furthermore, the set of functions is not meant to be complete, but instead provide a sample of the more useful functions. The architecture of the SST simplifies the addition of new universal functions.

There are universal functions that affect single records:

insert(field,record) adds a new field to a record.
delete(field,record) removes a field from a record.
change(field,record) modifies the value of a field, either with an interactive type-specific editor or a function.
display(field,record) displays the value of a field.
order(fields,record) changes the order of the fields in the record.
expose(fields,record) changes the visibility of the fields in a record.
format(record,template) inserts field values from a record into a formatting template.
filter(record,program) filters a record through a program
match(record,expression) indicates whether an expression (e.g., a Boolean combination of name-value relationships) matches a record.

There are universal functions that affect a list of records:

diff(record,record,fields) indicates the signed difference of two records compared with the named fields; it is used for searching and sorting.
search(records,expression) indicates the list of records matching (using match()) a search expression.
sort(records,fields) sorts the records according to the values in the specified fields (using diff()).
index(records) produces an inverted index of the records to speed search.
count(records) counts fields and records in a list.

There are also universal functions that do not operate on structured objects. These include a macro/programming capability, a thesaurus and spell checking feature (both these use the same functionality as the index function). These do not use the frame-based structure of the SST and are therefore more broadly applicable.

When reading through the list of functions, a useful exercise is to imagine them being applied to specific domains, such as word-processing, where the functions might apply to paragraphs. An annotation field might be inserted, as may a reader's rating of importance. Unimportant paragraphs could then be hidden, and those remaining could be sorted by importance. For collaborative writing, fields could be added to paragraphs to specify the author(s), who has read/write permissions, when it was updated, etc. Authors could search for paragraphs in which their name appeared in the author field and for which they had write permission. Object sizes could be counted and used to generate a formatted report. Similar possibilities exist for other applications.

It is also a useful exercise to imagine how a familiar system would be implemented with universal functions. For example, to implement an electronic mail system, most operations can be implemented directly by renaming universal functions:

delete: hide the message
edit: change the values of fields in the message
headers: display all undeleted messages using a format template
print: display the visible fields in the message
reply: copy old message, switching To: and From: fields, edit, and filter through the UNIX sendmail program
save: write the message to a file
undelete: make a message visible again

The most complicated operation is quitting from the mail reader because of all the bookkeeping necessary for what messages have been (marked as) deleted and saved to files, and because of the need to check the mail spool file for new mail that may have arrived during reading. New functions could be added with universal functions:

sort: reorder messages based on values in specified fields
search: search for messages based on values in fields
format: change the format of headers by changing the formatting template
index: index messages in many mail boxes for faster search access

A survey of the functionality found in many applications led to the conclusion that functions such as search and sort are universally applicable. These functions, typical of those found in DBMSs and Information Retrieval (IR) systems, are missing from or deficient in many applications, although some word-processing systems provide more elaborate universal functions for office-based tasks (e.g., address-list management). The functions are not difficult to implement so perhaps the reason they are missing is a lack of developer stamina. After developing software to represent records from scratch because of the lack of tools, developers might decide to provide the core application-specific functions and quit rather than implement a large set of universal functions that are not critical for user acceptance. The same argument has been given to explain poor user interfaces not built on top of a user interface toolkit.

[3.4] Field-Specifications for Maintaining Application-Independence

Returning to the question posed earlier about the data in Figure 1 and Figure 2 (``Why is different software used for accessing the different data types?''), in this section, the problem of application-dependent functions is addressed. I claim that most functions in domains are not domain-specific but only differ in the field-attributes (e.g., name and type) used by the functions. The universal functions in the SST provide most of the operations that users would want to use on bibliographic entries and news articles (and other domains) and many other functions can be represented by combinations of universal functions. Two notable examples of domain-specific functions are:

for bibliographic entries, special-purpose software would be needed to produce entries in a particular style for a particular word-processing system;
for news articles, special-purpose software would be needed to submit news articles.

In both these cases, the SST would still support much of the special-purpose processing and simplify their implementation.

Data type-specific functions are useful for building domain-specific applications. For example, a word-processor might sort a list of persons' names using specialized knowledge about the structure of multi-word surnames such as Andries Van Dam and modifiers as in D. Austin Henderson, Jr.. It is possible to provide data type-specific functions in a way that maintains the application-independence of the SST, by attaching type information to specific named fields and by representing data values as strings (of characters or bits). In the Star's record processing, the most important properties of a field are its name, type, allowed format and range. Four types were supported by the Star: text, amount, date, and `any'. These allowed more control of type checking, comparisons, and display. The SST supports many types of data in fields, and is designed to simplify the addition of new types. The types currently implemented in the SST include:

alphanumeric (with an option to skip stopwords for title/subject subtypes);
numeric (with subtypes of integers and two subtypes of real numbers, and an option to ignore punctuation, such as for monetary values);
date (in many formats);
time (in a few formats);
a person's name (with knowledge about titles and multi-word names);
binary files (e.g., bitmaps, sound files),
email addresses (mainly Internet);
postal addresses (with knowledge of postal codes and country names).

Functions that use the data type of a field may use a specified type, apply a series of predicates on the value to try to determine the type, or, by default, treat the field value as a typeless string, which is adequate for most purposes. Typeless functions can be applied to any fields, records, or lists of records. These include generic functions (Rosenberg & Moran, 1984) to insert, expose, hide, delete, count, etc. fields or records. Adding a new type to the SST is like adding a device driver to an operating system. To add a new type to the SST,

a predicate is required to be able to automatically recognize the type,
a comparison function is required for searching and sorting,
a formatter is required for flexible report generation,
a platform-dependent display function may be required for dynamic display, and
a platform-dependent editor may be required for interactive editing.

To the extent that a viewer and editor can be made platform-independent, such as by only assuming a character display with standard terminal controls, those functions in the SST are more portable, although perhaps less usable.

[4] Evaluation of Universal Functionality and the SST

The evaluation of the SST will begin with a discussion of approaches to gaining user acceptance of new information technology. This will be followed by a discussion of how the SST overcomes obstacles to user acceptance. The section ends with a description of experiences with the SST.

[4.1] Factors Affecting User Acceptance of Information Technology

In this section, I will discuss some of the factors affecting user acceptance of new information technology. Any system that has a higher (perceived) cost than (perceived) benefit will have difficulties gaining user acceptance. But a system must exist before it can be accepted. Systems that are easier to implement will be more accessible to users. From the developer's point of view, incorporating universal functions has presented technical difficulties that have resulted in some design tradeoffs, resulting in data storage format-dependence and platform-dependence.

Accessibility and Integration: Systems that are more accessible and which integrate with other software are more acceptable to users (Nickerson, 1981; Helmreich, 1984). Cost is certainly a factor affecting access, but platform-independence is often more important. A system that runs on an obscure platform may be rejected outright, while one that only runs as a graphical user interface (GUI) might be rejected after users find they can not access their data over a telephone line or from an incompatible system. (This is not to say that GUIs are bad, but that systems must support different platforms.) Dependence on proprietary formats can reduce the applicability of systems to that data. Translation may not be a viable solution because it may reduce the efficiency of the system and the user. Integration with existing software and work practices is also important because system acceptance is evolutionary (Ehrlich, 1987) and users should not be expected to abandon access to familiar systems.
Preservation of Investment: Systems that preserve investment in skills and data are more acceptable to users. New systems require new training and possible loss of data. To the extent that a system is easy to use, training is minimized. To the extent that systems can read and write a variety of formats of data, the loss of data or the cost of its conversion can be minimized. If a new system is incompatible with a previously used system, then conversion of data format may be a one-way translation that may result in an undesirable loss of old functionality. It is better to complement existing systems than replace them (Ehrlich, 1987; Sassone, 1988).
Supporting Organizational Work: Systems that better match the workings of the group in which work is done are more acceptable to users (Malone, 1985; Ehrlich, 1987; Grudin, 1988; Eason, 1989). Systems that use proprietary data storage formats and which do not support sharing of information between workers will be less acceptable to users. Systems that use different user interface conventions and do not allow sharing of training among workers will be less acceptable to users.
User Efficiency: Systems that make their users more efficient are more acceptable to users (Nickerson, 1981). Faster response time, reduction of start-stop time, and reliability are three attributes that Nickerson (1981) cites as desirable to users. The benefits of many research prototypes are difficult to demonstrate because of these efficiency issues.
Flexibility of Functionality: Systems that provide more functionality are more acceptable to users. Nickerson (1981), Helmreich (1984) and Ehrlich (1987) discuss the problem of providing users with systems of limited functionality. Helmreich suggests that only users can determine which functions are of real benefit. This suggests that even in the absence of immediate uses for functions in a domain, information systems should contain a large set of potentially applicable functions in a toolbox (Helmreich, 1984; Eason, 1989). Also, systems should come with a usable mechanism to add new functions, or risk rejection by users who have come to depend on certain functions. One novel useful function may not be enough to attract users and one overlooked function may be enough to repel users.
Suitability to Unstructured Problems: Systems that provides flexibility in how they can be adapted to unstructured problems are more acceptable to users (Helmreich, 1984). According to (Lai et al, 1988), semi-formal systems:
- represent and automatically process certain information in formally specified ways,
- represent and make it easy for humans to process the same or other information in ways that are not formally specified, and
- allow the boundary between formal processing by computers and informal processing by people to be easily changed.
In effect, semi-formal systems provide support for as much structure as is desired, but they do not impose structure. This is in contrast to formal systems such as DBMSs or KBSs that require a commitment to a specific set of conventions that usually restrict users to specific file formats, functionality, and platforms. The philosophy behind semi-formal systems is that users can derive many benefits from minimal investment; this is desirable because the cost associated with formal systems often outweighs the benefits when applied to small or poorly structured problems. According to (Lai et al, 1988), semi-formal systems are most useful when there is some understanding of the structure of a domain, but not a complete understanding; in their view, this characterizes many current and future information processing problems.

[4.2] Analysis of Other Systems with Universal Functions

In this section, I will analyze systems with universal functionality, using the factors affecting user acceptance from the previous section. Following that, I will discuss how the SST overcomes the limitations of previous approaches.

DBMSs have limitations for many of the factors listed. Because of the demands of managing large amounts of data, application development systems based on DBMSs have tended to be platform-dependent and data format-dependent. (1) These design decisions limit the accessibility of the software and the ability of users to integrate that software with other tools. (2) DBMSs generally require that users learns a new interface but users are able to import their existing data into any DBMS. (3) DBMSs are often used in group settings where data are being shared and users can share their expertise, but many tasks done in groups (e.g., collaborative writing) are not well supported by DBMSs. (4) Most of the tasks we do on a daily basis do not require the ability of DBMSs to manage large amounts of data. When personal computers began to gain popularity in the early 1980's, DBMSs were touted as software that could be used in the home, for example, to keep track of household inventory and addresses. People found DBMSs more trouble than the limited benefits they provided (e.g., a sorted and nicely formatted grocery list). The slow start-stop time of DBMSs make them unsuitable for many tasks. And, although it is possible to use DBMSs to process electronic mail and news, I do not know of any such systems that people actually use. (5) DBMSs provide good support for many functions, and can usually be augmented by macros and calls to external programs. (6) DBMSs are not semi-formal systems (they are strictly formal), so it is risky to apply them to unstructured problems where early decisions may make work more difficult later.

Integrated application development environments like the Star (Purvy et al, 1983) did not gain acceptance for other reasons. (1) Although applications on the Star were integrated to an extent still unparalleled years after its demise, the high cost of the machine and its dedication to a graphical interface made its software less accessible. It proprietary hardware, software, and data format all contributed to a lack of compatibility with other systems. (2) Although a new and more usable system, Star was more of a statement of the Xerox vision of office automation than a market-driven product that preserved investment in equipment, skills, and data. (3) The lack of market saturation and its platform-dependence and data format-dependence led to interoperability problems that hindered inter-platform group work. (4) The Star system ran on a slow machine with limited memory, so although the system has an exemplary user interface, issues of response time and start-stop time limited the efficiency of users. (5,6) Star featured more functionality and flexibility than most systems a decade later. In sum, the lack of access to the Star, its performance problems, and its lack of integration into existing practices were enough to make the Star an unacceptable system.

Object Lens, now called Oval, is a generalization of the Information Lens (Lai et al, 1988, Malone et al, 1986) that supports many operations on semistructured messages. (1) Early versions of Object Lens were not accessible because it ran on the Xerox Interlisp environment; the current version is more accessible because it is written in Common Lisp, but that platform has its own accessibility problems. Because of its implementation as a purely graphical user interface, Object lens is not accessible from remote, non-graphical terminals. The limitations of the number of message formats recognized by Object Lens has limited its ability to integrate with other tools, but it integrates well with communications applications. (2) Object Lens can be used as an auxiliary tool in its environment, so it preserves user investment in skills and data. (3) Object Lens is designed to support group work coordination. (4) Object Lens tends to be slow to start and to respond on many platforms because of its dependence on Common Lisp. (5) Object Lens uses programmable rules to customize its actions to meet users needs, and it is based on the highly flexible Common Lisp environment to which adding functions is easy for Lisp programmers. (6) Object Lens is a semi-formal system that is designed to be suitable to unstructured problems.

Other tools and application development platforms have other limitations. ITS (Wiecha et al, 1990) has accessibility limitations. IR systems do not integrate with other software. UNIX tools (e.g., grep, sort, sed), integrated with the UNIX shell, has many attributes that make it an acceptable platform of universal functionality, but the data structure of a flat file of lines is too weak to build many applications (although some functionality abstracted from these tools, e.g., regex and qsort, is used in the SST). Applications such as word processors and spreadsheets all have many universal functions, but they operate on specific file formats and are often not implemented as functions to operate on all objects.

[4.3] How the SST Overcomes Previous Limitations

The SST partitions applications into:

storage formats, S, that specify record, field, name, and value delimiters;
data types, T, that specify how to check, compare, format, etc. values; and
universal functions, F, that read and write data with S and specify operations with T.

This architecture allows individual applications to be viewed as elements of the cross-product SxTxF. When viewed this way, adding to any of the independent components of the SST derives multiplicative benefits. By adding a new storage format specification so that a new object can be read/written from/to external storage, all of the universal functions can be applied to that data in its native format, ensuring compatibility with existing tools. By adding a new (application-specific) data type to the SST, all of the universal functions can be applied to the data type as though the functions were written for a specific application. And by adding a new universal function to the SST, that function is made available to all applications built with the SST. For example a ``search and replace'' function can be built with search() and change() and applied to mail, news, bibliographies, calendars, and so on.

Why should we expect that the SST will gain acceptance? (1) The SST is written in portable C, so it does not limit accessibility. The SSR data structure can be integrated into existing applications and can be used as a base for new applications, and the flexibility of data storage formats makes it possible to integrate SST functions with existing functions. (2) The SST is a function library that is not used directly, so it is neutral about the question of preserving investment in skills. Its ability to manage a variety of data formats preserves investment in data. (3) The SST is neutral regarding most organizational issues, but it does support many types of collaborative artifact creation, and it allows the transparent sharing of data that are incompatible among other systems. (4) The functions in the SST are compact, efficient, and robust. (5) The SST is designed so that if functionality is missing, it can be added with minimal effort and multiplicative benefit. (6) As a system based on semi-structured records in which format and data types can be specified at run-time, the SST is well-suited to unstructured problems.

[4.4] Experiences using the SST

The SST has been used to build applications for many types of semi-structured records:

electronic mail messages and news articles,
bibliographic records,
schedules of events shared among several users,
survey questionnaires administered through email,
programs and files in an operating system,
inspection checklists,
bug reports, and
personal databases such as address books, grade rosters, and inventories.

The SST has been used extensively for managing the HCI Bibliography mentioned in Figure 1 and Figure 2:

checking, searching, sorting and formatting bibliographic records;
organizing incoming and outgoing mail regarding the project;
generating parts of formatted documents, including procedure manuals;
tracking the progress of data input and validation volunteers;
gathering and analyzing data from surveys administered through mail;

and for other tasks. Many of these tasks have been accomplished using an interface to the functions based on UNIX filters connected via pipelines, an interface that runs equally well on DOS machines. Other applications have been implemented at other levels:

generation of reference lists in specific formats, implemented in C;
an X-based interactive graphical viewer, implemented in C;
a tool for building pipelines graphically, implemented on a Macintosh with XVT;
a Motif-based graphical interface for constructing Boolean expressions, in which expressions and operators are represented as semi-structured records, implemented in C;
a mail filter using search expressions and UNIX shell actions has been implemented to allow many of the operations provided by the Information Lens (Malone et al, 1986);

and there is ongoing development of an interpreted language to allow end-user programming at a higher level than shell programming.

[5] Future Directions

Universal functions can increase the productivity of information users. The SST is an example of one way to integrate universal functions into existing and future applications. The SST adapts to different data storage formats with lexical-specifications that allow it to parse and generate semi-structured records. The SST adapts to different applications with field-specifications that allow it to recognize, display, compare, and format domain-specific data. Although it might not be the best way to implement universal functions, experience with it has demonstrated that it is possible to adapt the same universal functionality to many different applications.

In the future, I expect that more universal functions will be integrated into application development frameworks so that along with the familiar File and Edit menus, functions to search, sort, format and so on will assume standard positions in application menus. Also, over time, the user interfaces to these functions will become standardized, most probably in control panels of complexity similar to the familiar print and save_as... functions. Our research agenda should include making such universal functions easier to use, but this research agenda must take place with the knowledge that there will be a need for higher-order consistency about how the functionality of sets of universal functions will be provided.

[6] Acknowledgements

This work was supported in part by the Ohio State University and ACM SIGCHI. I would like to thank Caroline Palmer, Ed Swan, and Srinivas Raghavan for their comments on this paper. This work evolved over a period of more than a decade, during which countless colleagues and students from UCSD, the Wang Institute, and the Ohio State University have given me ideas and feedback on less-general semi-structured toolkits. Most recently, Chandrasekhar Reddy and Steve Edwards have been influential in design decisions in the current version. I would like to thank Lynn Snider for her help with the XVT-based pipeline editor, Ed Swan for his help with the X-based record viewer, and Srinivas Raghavan for his work on an X-based Boolean expression editor.

[7] References

Deerwester, Scott C., Waclena, Keith, & LaMar, Michelle ``A Textual Object Management System,'' Proceedings of the Fifteenth Annual International ACM SIGIR Conference on Research and Development in Information Retrieval. New York: ACM. 1992. 126-139.
Eason, Ken ``Designing Systems to Match Organisational Reality,'' Proceedings of the HCI'89 Conference on People and Computers V. Cambridge University Press. 1989. 57-69.
Ehrlich, Susan F. ``Social and Psychological Factors Influencing the Design of Office Communication Systems,'' Proceedings of ACM CHI+GI'87 Conference on Human Factors in Computing Systems and Graphics Interface. New York: ACM. 1987. 323-329.
Grudin, Jonathan ``Why CSCW Applications Fail: Problems in the Design and Evaluation of Organizational Interfaces,'' Proceedings of ACM CSCW'88 Conference on Computer-Supported Cooperative Work. New York: ACM. 1988. 85-93.
Helmreich, Reinhard ``Human Aspects of Office Systems -- User Acceptance Research Results,'' Proceedings of IFIP INTERACT'84: Human-Computer Interaction. Amsterdam: North-Holland. 1984. 715-718.
Lai, Kum-Yew, Malone, Thomas W., & Yu, Keh-Chiang ``Object Lens: A "Spreadsheet" for Cooperative Work,'' ACM Transactions on Office Information Systems, 6, 4, 1988, 332-353.
Malone, Thomas W. ``Designing Organizational Interfaces,'' Proceedings of ACM CHI'85 Conference on Human Factors in Computing Systems. New York: ACM. 1985. 66-71.
Malone, Thomas W., Grant, Kenneth R., & Turbak, Franklyn A. ``The Information Lens: An Intelligent System for Information Sharing in Organizations,'' Proceedings of ACM CHI'86 Conference on Human Factors in Computing Systems. New York: ACM. 1986. 1-8.
Malone, Thomas W., Grant, Kenneth R., Lai, Kum-Yew, Rao, Ramana & Rosenblitt, David ``Semistructured Messages Are Surprisingly Useful for Computer-Supported Coordination,'' ACM Transactions on Office Information Systems, 5, 2, 1987, 115-131.
Mamrak, Sandra A, Kaebling, M. J., Nicholas, C. K., & Share, M. ``A Software Architecture for Supporting the Exchange of Manuscripts,'' Communications of the ACM, 30, 5, 1987, 408-414.
Minsky, Marvin ``A Framework for Representing Knowledge,'' In Patrick Winston (Ed.) The Psychology of Computer Vision. New York: McGraw-Hill. 1975. 211-277.
Myers, Brad A. All the Widgets (video). New York: ACM. 1990.
Nickerson, Raymond S. ``Why Interactive Computer Systems are Sometimes Not Used by People Who Might Benefit from Them,'' International Journal of Man-Machine Studies, 15, 4, 1981, 469-483.
Pausch, Randy, Conway, Matthew, & DeLine, Robert ``Lessons Learned from SUIT, the Simple User Interface Toolkit,'' ACM Transactions on Information Systems, in press.
Perlman, Gary User Interface Development. (SEI-CM-17-1.1) Pittsburgh, PA: Carnegie-Mellon University, Software Engineering Institute. 1989.
Purvy, Robert, Farrell, Jerry, & Klose, Paul ``The Design of Star's Records Processing: Data Processing for the Noncomputer Professional.'' ACM Transactions on Office Information Systems, 1, 1, 1983, 3-24.
Rochkind, Marc L. Technical Overview of the Extensible Virtual Toolkit. Boulder, Colorado: XVT Software. January 16, 1989.
Rosenberg, Jarrett K., & Moran, Thomas P. ``Generic Commands,'' Proceedings of IFIP INTERACT'84: Human-Computer Interaction. Amsterdam: North-Holland. 1984. 245-249.
Sassone, Peter G. ``Cost Benefit Analysis of Information Systems: A Survey of Methodologies,'' Proceedings of the ACM SIGOIS Conference on Office Automation Systems. New York: ACM. 1988. 126-133.
Wiecha, Charles, Bennett, William, Boies, Stephen, Gould, John, & Greene, Sharon ``ITS: A Tool for Rapidly Developing Interactive Applications,'' ACM Transactions on Information Systems, 8, 3, 1990, 204-236.