A Vision of Universal Functionality
for Tomorrow's User Interfaces
Department of Computer and Information Science
The Ohio State University
Columbus, Ohio 43210 USA
 Independence in User Interfaces
 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
 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
 Future Directions
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
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.
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
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.
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.
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
(3)They conform to existing information processing practices (i.e., they are
(4)Templates of messages can be provided to help users organize material.
(5)They simplify the design of systems that can be incrementally enhanced
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
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
%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
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)
From: firstname.lastname@example.org (Gary Perlman)
Subject: HCI Bibliography Update
Keywords: free bibliographic information
Sender: email@example.com (NETnews )
Organization: Computer & Info Sci Ohio State Univ Columbus, OH 43210
Date: Mon, 24 Aug 1992 23:21:43 GMT
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
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
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.
The formats in
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
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
or an equal sign), or implicitly from knowledge of when a field
name ends (e.g., a single character as in
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.
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.
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.
- read(record,format,file) reads a record stored in a specified format from
- write(record,format,file) writes a record in a specified storage format
to a file.
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
- 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
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
- hide the message
- change the values of fields in the message
- display all undeleted messages using a format template
- display the visible fields in the message
- copy old message, switching To: and From: fields, edit,
and filter through the UNIX sendmail program
- write the message to a file
- 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
- reorder messages based on values in specified fields
- search for messages based on values in fields
- change the format of headers by changing the formatting template
- 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.
Returning to the question posed earlier about the data in
(``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:
In both these cases, the SST would still support much of the special-purpose
processing and simplify their implementation.
- for bibliographic entries, special-purpose software would be needed to
produce entries in a particular style for a particular word-processing
- for news articles, special-purpose software would be needed to submit
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
- 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,
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.
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.
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.
- 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
- a platform-dependent editor may be required for interactive editing.
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
- 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
- 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:
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.
- represent and automatically process certain information in formally
- 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.
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
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.
The SST partitions applications into:
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.
- storage formats, S, that specify record, field, name, and value
- data types, T, that specify how to check, compare, format, etc. values;
- universal functions, F, that read and write data with S and specify
operations with T.
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.
The SST has been used to build applications for many types of semi-structured
The SST has been used extensively for managing the HCI Bibliography mentioned
- 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.
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:
- 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 there is ongoing development of an interpreted language to allow end-user
programming at a higher level than shell programming.
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.
- 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
- 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);
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.
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.
- 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.
- 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,
- Perlman, Gary
User Interface Development.
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.
Proceedings of IFIP INTERACT'84: Human-Computer Interaction.
- 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.