<PRE>
This directory contains postscript versions of many of the papers
published by the Garnet group at Carnegie Mellon.
agateCHI93
garnetIEEE
giltSpaghettiUIST91
lapidary
marquiseCHI93
ooprogOOPSLA
spreadC32CHI91
tochi
uimssurvey
uisurveyCHI92
whyhardTR
Below are the abstracts from the papers. These abstracts are also in
individual files (mainly to make it easier to view them from mosaic),
with the extension .abstract.
***********************************************************************
garnetIEEE
----------------------------------------------------------------------
Comprehensive Support for Graphical, Highly-Interactive User Interfaces:
The Garnet User Interface Development Environment
Brad A. Myers, Dario Giuse, Roger B. Dannenberg, Brad Vander Zanden,
David Kosbie, Ed Pervin, Andrew Mickish, and Philippe Marchal
IEEE Computer. Vol. 23, No. 11. November, 1990. pp. 71-85.
Translated into Japanese and reprinted in Nikkei Electronics,
No. 522, March 18, 1991, pp. 187-205.
The Garnet User Interface Development Environment contains a
comprehensive set of tools that make it significantly easier to
design and implement highly-interactive, graphical, direct
manipulation user interfaces. The lower layers of Garnet provide
an object-oriented, constraint-based graphical toolkit that
allows properties of graphical objects to be specified in a
simple, declarative manner and then maintained automatically by
the system. The dynamic, interactive behavior of the objects can
be specified separately by attaching high-level ``interactor''
objects to the graphics. The higher layers of Garnet include an
interface builder tool, called Lapidary, that allows the user
interface designer to draw pictures of all graphical aspects of
the user interface. Unlike other interface builders, Lapidary
allows toolkit items, such as menus and scroll bars, to be
created as well as used, and Lapidary also allows
application-specific graphical objects (the contents of the
application's window) to be created in a graphical manner. Other
high level tools include an automatic dialog box and menu editor,
and a spreadsheet program for specifying complex graphical
constraints. This paper provides an overview of the entire
Garnet system.
***********************************************************************
agateCHI93
----------------------------------------------------------------------
Extending An Existing User Interface Toolkit To Support Gesture Recognition
James A. Landay and Brad A. Myers
Adjunct Proceedings of INTERCHI '93, Amsterdam, The Netherlands,
Apr 24 - Apr 29, 1993. ACM, New York, 1993, pp 91-92.
Gestures are a powerful way to specify both objects and operations with a
single mark of a stylus or mouse. We have extended an existing user
interface toolkit to support gestures as a standard type of interaction so
that researchers can easily explore this technology.
***********************************************************************
giltSpaghettiUIST91
----------------------------------------------------------------------
Separating Application Code From Toolkits:
Eliminating The Spaghetti Of Call-Backs
Brad A. Myers
ACM Symposium on User Interface Software and Technology, Hilton Head,
SC, Nov. 11-13, 1991. pp. 211-220.
Conventional toolkits today require the programmer to attach call-back
procedures to most buttons, scroll bars, menu items, and other widgets
in the interface. These procedures are called by the system when the
user operates the widget in order to notify the application of the
user's actions. Unfortunately, real interfaces contain hundreds or
thousands of widgets, and therefore many call-back procedures, most of
which perform trivial tasks, resulting in a maintenance nightmare.
This paper describes a system that allows the majority of these
procedures to be eliminated. The user interface designer can specify
by demonstration many of the desired actions and connections among the
widgets, so call-backs are only needed for the most significant
application actions. In addition, the call-backs that remain are
completely insulated from the widgets, so that the application code is
better separated from the user interface.
***********************************************************************
lapidary
----------------------------------------------------------------------
The Lapidary Graphical Interface Design Tool
Brad Vander Zanden and Brad A. Myers
Submitted for publication.
The Lapidary interface design tool allows thegraphics and run-time
behaviors that go inside an application window, as well as the
graphics and behaviors that go around the application window, such as
menus and scroll bars, to be specified pictorially. In particular,
Lapidary allows the designer to draw pictures of application-specific
graphical objects that the end user will manipulate (such as boxes and
arrows, or elements of a list), the feedback that shows which objects
are selected (such as small boxes on the sides and corners of an
object), and the dynamic feedback objects (such as hair-line boxes to
show where an object is being dragged). The run-time behavior of all
these objects can be specified in a straightforward way using
constraints and dialog boxes that allow the designer to provide
abstract descriptions of the interactive response to the input
devices. Lapidary also generalizes from the specific example pictures
to allow the graphics and behaviors to be specified by demonstration.
Finally, Lapidary supports the construction and use of ``widgets''
(sometimes called interaction techniques or gadgets) such as menus,
scroll bars, buttons and icons. Thus Lapidary allows all pictorial
aspects of an application to be specified graphically.
***********************************************************************
marquiseCHI93
----------------------------------------------------------------------
Marquise: Creating Complete User Interfaces by Demonstration
Brad A. Myers, Richard G. McDaniel, David S. Kosbie
Proceedings INTERCHI'93: Human Factors in Computing Systems.
Amsterdam, Holland, April 24-29, 1993. pp. 293-300.
Marquise is a new interactive tool that allows virtually all of the
user interfaces of graphical editors to be created by demonstration
without programming. A "graphical editor" allows the user to create
and manipulate graphical objects with a mouse. This is a very large
class of programs and includes drawing programs like MacDraw, graph
layout editors like MacProject, visual language editors, and many
CAD/CAM programs. The primary innovation in Marquise is to allow the
designer to demonstrate the overall behavior of the interface. To
implement this, the Marquise framework contains knowledge about
palettes for creating and specifying properties of objects, and about
operations such as selecting, moving, and deleting objects. The
interactive tool uses the framework to allow the designer to
demonstrate most of the end user's actions without programming, which
means that Marquise can be used by non-programmers.
***********************************************************************
ooprogOOPSLA
----------------------------------------------------------------------
Declarative Programming in a Prototype-Instance System:
Object-Oriented Programming Without Writing Methods
Brad A. Myers, Dario A. Giuse, and Brad Vander Zanden
Proceedings OOPSLA'92: ACM Conference on Object-Oriented Programming
Systems, Languages, and Applications. October 18-22, 1992.
Vancouver, BC, Canada. SIGPLAN Notices, vol. 27, no. 10. pp. 184-200.
Most programming in the Garnet system uses a declarative style that
eliminates the need to write new methods. One implication is that the
interface to objects is typically through their data values. This
contrasts significantly with other object systems where writing
methods is the central mechanism of programming. Four features are
combined in a unique way in Garnet to make this possible: the use of a
prototype-instance object system with structural inheritance, a
retained-object model where most objects persist, the use of
constraints to tie the objects together, and a new input model that
makes writing event handlers unnecessary. The result is that code is
easier to write for programmers, and also easier for tools, such as
interactive, direct manipulation interface builders, to generate.
***********************************************************************
spreadC32CHI91
----------------------------------------------------------------------
Graphical Techniques in a Spreadsheet for Specifying User Interfaces
Brad A. Myers
Proceedings SIGCHI'91: Human Factors in Computing Systems. New
Orleans, LA. April 28-May 2, 1991. pp. 243-249.
Many modern user interface development environments use
constraints to connect graphical objects. Constraints are
relationships that are declared once and then maintained by the
system. Often, systems provide graphical, iconic, or demonstrational
techniques for specifying some constraints, but these are incapable of
expressing all desired relationships, and it is always necessary to
allow the user interface designer to write code to specify complex
constraints. The spreadsheet interface described here, called C32,
provides the programmer with the full power of writing constraint code
in the underlying programming language, but it is significantly easier
to use. Unlike other spreadsheets tools for graphics, C32
automatically generates appropriate object references from mouse
clicks in graphics windows and uses inferencing and demonstrational
techniques to make constructing and copying constraints easier. In
addition, C32 also supports monitoring and debugging interfaces by
watching values in the spreadsheet while the user interface is
running.
***********************************************************************
tochi
----------------------------------------------------------------------
Integrating Pointer Variables into One-Way Constraint Models
Brad Vander Zanden, Brad A. Myers, Dario A. Giuse, and Pedro Szekely
Submitted for Publication
Pointer variables have long been considered useful for
constructing and manipulating data structures in traditional
programming languages. This paper discusses how pointer
variables can be integrated into one-way constraint models and
indicates how these constraints can be usefully employed in user
interfaces. Pointer variables allow constraints to model a wide
array of dynamic application behavior, simplify the
implementation of structured objects and demonstrational systems,
and improve the storage and efficiency of constraint-based
applications. This paper also presents two incremental
algorithms--one lazy and one eager--for solving constraints with
pointer variables. Both algorithms are capable of handling 1)
arbitrary systems of one-way constraints, including constraints
that involve cycles; and 2) editing models that allow multiple
changes between calls to the constraint solver. These algorithms
are also fault-tolerant in that they can gracefully handle and
recover from formulas that crash due to programmer error.
Constraints that use pointer variables have been implemented in a
comprehensive user interface toolkit, Garnet, and our experiences
with applications written in Garnet have proven the usefulness of
pointer-variable constraints. Manylarge scale applications have
now been implemented using these constraints.
***********************************************************************
uimssurvey
----------------------------------------------------------------------
User Interface Software Tools
Brad A. Myers
Submitted for Publication
Almost as long as there have been user interfaces, there have been
special software systems and tools to help design and implement the
user interface software. Many of these tools have demonstrated
significant productivity gains for programmers, and have become
important commercial products. Others have proven less successful at
supporting the kinds of user interfaces people want to build. This
article discusses the different kinds of user interface software
tools, and investigates why some approaches have worked and others
have not. Many examples of commercial and research systems are included.
Finally, current research directions and open issues in the field are
discussed.
***********************************************************************
uisurveyCHI92
----------------------------------------------------------------------
Survey on User Interface Programming
Brad A. Myers and Mary Beth Rosson
Proceedings SIGCHI'92: Human Factors in Computing Systems.
Monterrey, CA, May 3-7, 1992. 195-202.
This paper reports on the results of a survey of user interface
programming. The survey was widely distributed, and we received 74
responses. The results show that in today's applications, an average
of 48% of the code is devoted to the user interface portion. The
average time spent on the user interface portion is 45% during the
design phase, 50% during the implementation phase, and 37% during the
maintenance phase. 34% of the systems were implemented using a
toolkit, 27% used a UIMS, 14% used an interface builder, and 26% used
no tools. The projects using only toolkits spent the largest
percentage of the time and code on the user interface (around 60%)
compared to around 45% for those with no tools. This appears to be
because the toolkit systems had more sophisticated user interfaces.
The projects using UIMSs or interface builders spent the least percent
of time and code on the user interface (around 41%) suggesting that
these tools are effective. In general, people were happy with the
tools they used, especially the graphical interface builders. The
most common problems people reported when developing a user interface
included getting users' requirements, writing help text, achieving
consistency, learning how to use the tools, getting acceptable
performance, and communicating among various parts of the program.
***********************************************************************
whyhardTR
----------------------------------------------------------------------
Why are Human-Computer Interfaces Difficult to Design and Implement?
Brad A. Myers
Carnegie Mellon University School of Computer Science Technical
Report, no. CMU-CS-93-183. July 1993.
A revised version appears as: "Challenges of HCI Design
and Implementation," ACM Interactions. Vol. 1, no. 1. January, 1994.
pp. 73-83.
Everyone knows that designing and implementing human-computer
interfaces is difficult and time-consuming. However, there is little
discussion of why this is true. Should we expect that a new method is
around the corner that will make the design easier? Will the next
generation of user interface toolkits make the implementation trivial?
No. This article discusses reasons why user interface design and
implementation are inherently difficult tasks and will remain so for
the foreseeable future.