Lessons Learned from SUIT, the Simple User Interface Toolkit RANDY PAUSCH, MATTHEW CONWAY, and ROBERT DELINE University
In recent User
of Virginia
years,
the computer
Interfaces).
UI Toolklts, typically
Because
and Interface
make
model,
and
These
tools
two
science
Builders
that
typically
GUIS have
assumptions
second,
community
high-quality first,
operate
been that
he is willing
has realized
are difficult developed.
the
on
several
specific
support
Although
programmer
to invest
only
the advantages
to build,
these
has
weeks
tools
such
DOS,
as UIMSS,
are powerful,
proficient
as
(Graphical
such
some famlharity
becoming
platforms,
of GUIS tools
the
they
with
the
GUI
with
the
tool
Macintosh,
or
UNIX/X-windows. The
existing
professional
tools
specialists
m GUI
Toolkit.
SUIT
GUI
toolkit,
have
measured
and
design.
shders,
buttons, DOS,
less
development, Categories
and s—softuure softu,are:
graphics
packages,
—deuice
independence,
Information
General
Terms:
Additional gogy,
1,3.4
user
software
Words
portability,
rapid
has been
the
extensive
D.2.6
Design,
Phrases:
prototyping,
to hundreds
K.3.2
Human
Export,
tools,
of over
sites
made
as
Macinon the
during
its
120 users. Tools
and
Programming prototypmg, tccztton
Methodology and
an
such
paehages,
and Techniques
Education]:
Computer
educatzon
Factors
~graphlcal
software
we
Utilitles—czpp[
[Computers
science
We
the
of external
Engineering].
Graphics].
and
of time. prowdes
across
Miscellaneous—raptd
Graphics
Interface
builder
“widgets,”
Engineering]:
[ Software
or
can use SUIT
which
decisions
observations
Engineering]:
techniques;
hbrary
[software
D.2,2
interfaces;
Education—computer
experience
transparently
design
User
period
a set of standard
exported
1.3.6 [Computer
interaction
and
programming
is a C subroutine
Graphics]:
support;
the Simple
all in a short
run
majors,
the ‘ume to become
of an interface
GUI
apphcatlons
D 2 m [Software
SUIT,
itself,
and
science
investing
tool
editor,
from
computer
without
components
architecture,
we learned
Experimentation,
Key
SUIT
[Computer
Science
SUIT
layout
Descriptors:
teracttue;
reusable
no previous
SUITS
[l brarLes,
the
SUIT-based
platforms. describes
GUIS
we developed
with
hours.
boxes.
Subject
Environments—zn
and
three
and the lessons
Technique
with
undergraduate
build
fundamental
concepts
Jumors
check
paper
of most
the
an interactive
and UNIX/X This
those
than
UIMS, and
reach
to quickly
to distdl
college
after control
the wish
For thm class of users,
to explain that
external
internet.
who
M an attempt
productively
tosh,
are beyond
programmers
user
UIMS,
Interface,
user
GUI,
interface
learnabdity,
peda-
tocdklt.
INTRODUCTION This
is a practice
and
experience
paper
SUIT, the Simple User Interface Toolkit. building GUIS, called UIMSS, UI toolkits, Authors’
address:
lottes~ille, Permission not made of the
VA
emad:
to copy without or distributed
publication
Association
Computer
22903;
and
Science
fee all or part
Transactions
Thornton
Its date
appear,
Machinery.
on Information
of thm material
commercial and
advantage, notice
is given
To copy otherwise,
specific permission. (D 1992 ACM 1046-8188/92/1000-0320 ACM
describes
our
experience
with
In recent years, support tools for and interface builders have gained Hall,
University
of V@nia,
Char-
pausch(@
[email protected]
for direct
for Computing
Department,
that
M granted the ACM that
provided copyright
copying
that notice
requires
V.]
10, No. 4, October
1992, Page.
320-344
are
and the title
is by permission
or to republish,
$01.50 Systems,
the copies
of the
a fee and/or
Lessons Learned from SUIT
.
321
popularity, but they have been heavily skewed toward programmers who are willing to invest a large amount of time in mastering them. While these tools are appropriate curves
make
mers
who
for many them
wish
professionals
prohibitive to build
in the
field,
for undergraduate
GUIS,
but
who
their
extended
learning
students
or other
program-
do not
wish
to
invest
weeks
in
mastering the tool base. GUI building tools can be very deceptive: providing an interactive builder that provides mouse-based interface editing can obscure the fact that if the programmer is not familiar with the callback model for GUIS, attempting to attach functionality to the screen components will be extremely confusing. In academia, we tools,
not
should
be exposing
as a speciality
item
in
our
mainstream courses, such jects” courses. Unfortunately,
as undergraduate these courses
order
hidden
to teach
the luxury tools. sional
the concepts
of allowing
the students
inside
level
GUI-building course,
software engineering cannot sacrifice several
the GUI
several
to good graphics
weeks
model,
quickly
build
“graphical
front
the essential components essentials in a form that nothing
nor can they
to master
have
heard
in the C programming
produce a system design methodology implementation
many
(older)
GUI profesneed to but
can
to distill
and provided those who come prepared Our goal is not
GUI
programmers
design
times,
interface builder community. We
comment
tools is similar to programming Widget Set, for example, exhibits
decisions
which,
which is easy for novice GUI was relatively straightforward:
many
software, tools. attempted
to the language
of features” problems as did PL/I. not by providing a new “silver bullet”
of independent
afford
complicated
language.
the same contribution for the programming
current state of the art in GUI the 1960s and 1970s. The Motif same “interference SUIT succeeds
application
GUI development Toolkit, we have
in
in the GUI-building realm, but to combine existdesign that can be learned quickly. In this respect,
we hope SUIT can provide community that Pascal did
dozens
for various
of good GUI building tools can be used by programmers
but competency
to provide new capabilities ing techniques in a clean
certainly
ends”
the time to master complex the Simple User Interface
but
or “proweeks in
Outside of academia, a similar situation exists, where many programmers who do not specialize in GUI design often have
never take In SUIT,
with
students
a graduate
perform
stringent
when
idea, taken
the
but
by making
in combination,
programmers be willing user testing
that
languages in many of the
to learn. to rewrite
to every
The the
phase
in
an iterative fashion, and be willing to sacrifice “well-known” design principles for ease of use in the face of evidence from user observation. We have performed direct observations of over 120 separate users within a two-year time span during SUIT’s development. The end result is a ten-page tutorial which requires new users to spend between 1.5 and 3 hours learning to use SUIT, at which time they can begin using SUIT for programs of their own choice. This is a vast improvement over a four to six week learning curve we observed for our students with systems like Xtk [ 10], the Andrew Tool Kit [13], Interviews [4], and the Motif Widget Set. SUIT also provides a 160-page reference manual, much of which is also available via on-line help. ACM Transactions
on Information
Systems,
Vol. 10, No. 4, October
1992.
322
R, Pausch et al.
.
DESIGN APPROACH Throughout
SUIT’s
—exploit —make
development,
knowledge
and skills
the easy things
—perform
end-user
Current
UI
we applied
already
easy and the hard
testing
toolkits
the user
early
and
each system
provides,
UIMSS
users
who
tools because
principles:
has,
things
possible,
and
and often. tend
to violate
their users to learn a new programming Interface Builder [9] requires learning learning C ++. While these languages to use advanced
the following
point
by forcing
language. For example, objective-C, and Interviews are required to support
the NeXT requires the model
are focused
the learning
the
on their
threshold
first
task
at hand
of these
often
languages
fail
is too
high. Our design strategy was to leverage off the only existing skill we could assume our users would have: the ability to program in C. Therefore, anything
that
could
not be specified
be done by having any new concepts information to them
in a class-based via
its
with
SUIT’s
interactive
tools
would
have
to
the user write C code. Also, we acknowledged early on that we needed our users to understand, such as inheritance of interactive
production of a ten-page through the system. We
object-oriented tools.
As our
written explicitly
model, final
tutorial chose
SUIT
design
would
goal,
have to teach
we looked
which would walk the a written, rather than
to the
new user on-screen
tutorial format for two reasons: First, our most limited resource was screen real-estate, and putting the tutorial on paper reduced demand for screen space. The second reason was that we wanted to avoid confusion between “tutorial areas” and “real areas” on the screen. By using a paper-based tutorial, we could use the SUIT screen layouts without problem. While we do not argue that on-screen tutorials are appropriate in many applications, we felt that The
last
for SUIT’s design
target
constraint
audience, was
a paper-based
in the
type
tutorial
of users
would
we targeted
be superior. during
our
testing of the software. Working with the very best students, or even average students who were interested in GUIS, would have been a mistake. We wanted to target users for whom creating GUIS was a means to an end, not an end in itself. Therefore, we used a captive audience: students in undergraduate software engineering courses who had been assigned projects that required GUIS, but who would be graded on the overall result of their effort, of which the GUI was a small fraction. By constantly observing new users, we were able to maintain perspective on the difficulties they face when trying to understand the SUIT model. This sort of user testing is well understood in some corporate cultures, most notably at Apple Computer. This technique was also used with great success in the development of Trillium [3].
ARCHITECTURE This section gives a high-level description of SUIT’s internal describes SUITS basic data model. We begin by discussing ACM
Transactions
on Information
Systems,
Vol
10. No
4, October
1992.
architecture and platform portabil-
Lessons Learned from SUIT ity,
then
object,
cover
several
its interactive
popular
UI
builder
models,
tool set, and how it composes
SUIT’S and links
.
323
definition objects
of an together.
Portability A user interface tion
language,
mentation langaages
toolkit
feasible. standard
model:
than
it lacks
needed
to read
to be able
libraries
For
forms
of support:
and a graphics
always
graphics,
to store
operating
SUIT
and
support
function system
write
an implementa-
package.
in Pascal
Our
imple-
was not technologi-
as variables. was very
text
file,
Therefore,
small:
and the
we only
standard
C
this. a common,
such
DrawLine
We were
addresses dependency
an ASCII
we needed
operations
platforms.
C, implementing
the ability Our
ported
basic
support,
Pascal exists on all three platforms, but it varies widely [19]. Pascal is not powerfu~ enough to support the external control
we chose ANSI-C. 1/0
three
system
language had to be either C or Pascal, since they are the only widely known by undergraduates. Although Pascal is more widely
used and is simpler cally Also,
requires
operating
as
surprised
to find
low-level
graphics
package
DrawFilledCircle
and
few graphics
that
on each
packages
sup-
of the
implemented
for
all three platforms. Most researchers we contacted said that they had always ported between platforms by implementing small compatibility libraries for the specific graphics commands they used in their applications. This made porting their systems unnecessarily we would use a well-defined common project. We chose
to use SRGP,
the
time consuming, so we determined graphics layer from the beginning
Simple
Raster
being distributed by the Addison-Wesley of Interactive ond edition of Fundamentals al. [7]. SRGP
was already
implemented
Graphics
Publishing
Package, Company
Computer
Graphics,
for the Macintosh
that of the
which
was
with the secby Foley et
and X windows;
we
ported it to Turbo C on DOS, on top of Borland’s BGI graphics driver. Our DOS version of SRGP is now distributed with the textbook. Figure 1 shows the software layering SRGP has several range
that makes drawbacks.
of functionality,
we layered
SUIT portable. To overcome them a thin
Package) on top of SRGP. GP allows nates by providing arbitrary floating ing
standard
mixed motion naming
window-to-viewport
sample/event
input
model
graphic
widget authors point coordinate
mapping. of SRGP
and
package
In into
to provide called
to avoid systems
addition, a strict
GP event
a wider
GP (Graphics screen coordiand performconverts model
the
(mouse
is treated as a discrete event). GP also provides a color-and-font layer so that color-and-font table values can be properly set across
different platforms. Because GP was already providing support for fonts, we to implement a small, extensible language augmented its d rawText primitive for special characters and effects, including: @i(@fi)
Example
Text
@b(texzj @u(text)
Example Example
Text Text
@~+(text)
Example
@–
Example Text
(t~x~
Text
ACM
Transactions
on Information
Systems,
Vol. 10, No. 4, October
1992.
324
R. Pausch et al.
.
L
SUIT (Simple
User
Interface
GP (Graphics
I SRGP
(Simple
Toolkit)
Package)
Raster
Graphics
Package)
EBR Fig.
As long and the
as SUIT’-based number
tosh,
DOS,
only
remaining
the
1.
Layered
applications
of colors
they
mouse:
SUIT’s
recommend
that
for portabdity.
are restrained
use, the
and UNIX/X-windows point
software
platforms
of potential
applications
will
with
inconsistency
interactive
in their
applications
tools
assume
do the
same,
identical is the
choice
port
Macin-
look-and-feel.
number
a one-button although
of fonts
across
The
of buttons mouse,
we provide
on
and
we
access
to
whatever mouse buttons are provided by the current hardware. Another feature of GP is its handling of colors. In most graphics packages, if an application is developed for a color display, when it is ported to a monochrome red arrow
display, is drawn
a monochrome solution
display,
is to define
appearance],
various
artifacts
on a green both
the color
as in [“purple”,
appear.
background. (nonwhite)
colors
of each primitive “ black”].
Consider
In most
When
would as a pair
SUIT’s
Figure
systems, map
[color,
interactive
2, where
when
drawn
to black.
a on
GPs
monochrome tools
are used
to set an object’s color, a set of color chips appears when on a color screen, but a toggle button appears on a monochrome screen. A very different approach to portability is taken by XVT [ 14, 18], which provides a virtual toolkit on top of the native toolkit layer on each platform. The advantage of the XVT approach is that on each platform the application has the same look and feel as other applications built locally on that platform. There are two major drawbacks to this approach. First, XVT is forced to provide only those function common to all platforms—the lowest common denominator solution. Second, the user layout editors) on each platform.
must
use different
support
tools
(e.g.,
SUIT’S Data Model Most user interface toolkits for compiled languages use a “code dumping” model. The user runs a builder application and interactively lays out what the screen interface should look like. When the user exits this builder program, interior ACM
it “dumps” the of the “callback”
TransactIons
on Information
skeleton of a program routines, which are Systems,
and the user called when
Vol. 10. No. 4, October
1992.
then user
edits the interface
Lessons Learned from SUIT
Fig.
actions,
such
programs is ugly
as a button
is that
press,
the vast
Colors
occur.
majority
and can be mechanically
2.
325
on monochrome.
The
motivation
for
of the code to interact generated.
.
code
with
The drawback
screen
dumping widgets
to dumping
code is
that if the user ever wishes to go back and change, say, the location or color of a button, the builder program must be able to “parse back” the code that it had dumped. Of course, this requires preventing the user from editing the dumped code, although skeletons in separate creation. The code interface, button
that files
dumping
model
the programmer to a new
location,
database. maintains
if thought
is
must dump
rerun the application. SUIT uses a different understood
can usually from other
model.
also fire
awkward:
new In
code,
fact,
objects
should
and
a change
to
application,
recompile,
to say that provides
relink, SUIT
a front
the
drag
a
and is best
end to a
approach [1]. The database such as their location and
writes the database to permanent invoked, SUIT queries the database
go and what
for an application named foo. Applications programmers create
then
that
uses a similar screen objects,
been interested in platform portability, file as our permanent storage, instead
make
builder
it is fair library
color. When an application exits, SUIT storage, and when the application is next to see where
to
up a separate
of as a subroutine
The SERPENT system information about all
be done by dumping the callback code regarding things like object
color
to make
them.
If we had
not
we would have used the .Xresources we write a separate file, called foo.sui,
objects
by making
calls
such as
void Hl(SUIT_obJect obj) { printf(’’hello,
world\
n“);
} SUIT_createButton(’’hello”,
Hi);
which creates a screen button and attaches a callback function that is called when the button is pressed. The first time this program runs, the button has no screen location, so it appears at some random location on the screen. While the
application
is running, ACM
we
provide
Transactions
the
ability
on Information
to interactively
Systems,
lay
out
Vol. 10, No. 4, October
1992.
326
R. Pausch et al,
.
widgets on the screen (more on that later). SUIT records the location in the database
If the user moves and upon exit, the
the button, database is
written to disk. The next time this program runs, the SUIT createButton call will create the button, examine the database, and find th~ screen location that
was
modified
stored
during
at any time
SUIT
provides
the
that
previous
a program
a collection
execution.
Thus,
interfaces
can
be
is running.
of screen
objects,
where
each object
is described
object’s
state
and
displays
it
the
object
and
updates
by —its —a
state,
contained
C procedure
screen,
examines
that
handles
list, the
The property
list
containing
user
an object’s
[“label”,
“text”,
“floating point”, “Integer”, “boolean”,
Once objects, SUIT
input
to
state
is a set of [name,
the
type, value]
as in the following,
[(’diameter”, [“number of sllces”, [“has anchovies”,
table
on the
and
—a C procedure object’s state.
triples,
in a property
that
“plzza”l 10,5] 6] FALSE]
users understand that a SUIT-based application we introduce external control by explaining that
of all on-screen multiplexes
cursor. Users code for their property lists human-readable
objects keyboard
(this
is the database
and
mouse
input
SUIT based
maintains), on the
quickly understand that three different input handling and display procedures, in the state table. The contents of this ASCII
text
file
between
executions
is a collection SUIT maintains location
of a
and that of the
slider objects share but have a distinct table are written to
of the program.
After users understand that SUIT maintains a table of objects, we explain that SUIT’s interactive tools are provided by accepting some of the user’s input as commands to SUIT, rather than to a particular screen object. When user input occurs, SUIT queries the state of the CONTROL and SHIFT keys: if they are both down when mouse buttons are pressed, SUIT interprets the input as a command to move or resize a screen object and updates the object table accordingly. This use of keyboard modifiers allows versus build” mode used by other interface buiders, Interface Builder. Avoiding this mode switch is important
us to avoid the “run such as the NeXT for new users, and
we have experienced almost no cases of users being confused about when they are giving input to SUIT and when they are giving input to the application. The combination of SHIFT and CONTROL was chosen for very pragmatic reasons: very few window managers “grab” this combination by default, and they are two keys that most users can easily locate on the keyboard. The “main loop” of a SUIT-based application then looks like
ACM
TransactIons
on Informat]
on Systems,
Vol
10, No
4, October
1992
Lessons Learned from SUIT
.
327
forever do 1
wart for an input event IF(SHIFT & CONTROL) are down THEN handle as a SUIT-command ELSE { figure out widget we’re over call Its input handler } paint any objects who’ve changed } SUIT maintains a “needs to be repainted” bit next to each object: properties of an object change, then SUIT sets this bit. At the bottom loop, all “needs This
provides
will
change
to be repainted” two important
several
times
objects sources
are repainted
of repaint
and their
optimization:
in on pass of the loop,
it will
bits
first,
if any of the
are reset. if an object
be painted
only
once;
second, we can avoid some repainting altogether by not repainting an object if its properties have not changed. Having grasped how external control works, many users find it mildly unsettling, because they in programs to sequence to be nearly
as difficult
or recursion.
have become accustomed to using the flow of control actions. Users do not, however, find external control as their
Once users
first
introduction
understand
the basic
to either mechanism
pointer that
variables
drives
SUIT,
we explain that a standard set of screen objects has already been mented and stored in a library. This motivates the question of how
implescreen
objects can be made to invoke application procedures, or “callbacks.” In the example of a slider, users understand how the input handler and painting procedure will cause the slider to behave properly, but are not sure how an application routine changed. We then object’s function
a value contained in that slider has function can be added to the slider
property list. If such a property exists, after changing the state of the slider
user-level
callbacks
As a final SUIT
can be informed that explain that a callback
as strictly
something
is the most
comment
difficult
on external
external
intellectual
control,
control:
the input handler calls object. This attachment
each
leap for most
we had
application’s
originally main
the of
users.
implemented
procedure
looked
like
{ createObject{
.,. }; createObject{.
,. };
... letSuitRuno, } Of course,
one of the objects
was usually
a Done
button
that
would
call
an
exit function to terminate the program. We added support for “internal control” applications by adding a routine that would check to see if any mouse ACM TransactIons
on Information
Systems,
Vol
10, No. 4, October
1992.
328
R, Pausch et al.
.
or keyboard
input
had occurred:
{ createObject(.
..);
createObject( . . . ); . while ((application’s
test))
{ (whatever the application
wanted)
SUIT_checkAndProcessAny
lnputo;
} This
was
extremely
important
needed to poll real-time versus external control
Objects as Abstract Many
students
mechanisms by treating displaying following
to
affect
objects
confuse
that
the
state.
applications,
notion
We have
as abstract
data
types
state. For example, properties:
SUIT
supports
[“minimum
value”,
“floating “floating “floating
[“current value”, [“maximum value”, which Figure
some
especially
those internal
Data Types
tend
that
for
1/0 devices, but it underscores the fact that is not necessarily a large difference.
point”, point”, point”,
of
an
object’s
state
and
had good success combatting
that
have
multiple
a bounded
mechanisms
value
object
with
the this for the
0.01 0.7] 1.0]
can appear as any of the following display styles [6, 16], shown in 3. A keystroke command (again, with keyboard modifiers down) cycles
between
the
establishing displaying experience data type.
various
display
styles,
and
this
has
been
very
effective
in
the difference between an object’s state and the mechanism for and altering that state. For many students, it is the most visceral they have had in understanding the general concept of an abstract
User Defined Users may subroutines
Property define with
Types
their SUIT
own that
types for initialize,
use in property copy, destroy,
lists by registering convert the type to
ASCII, and convert from ASCII to the type. The ASCII conversion allows SUIT to write the interface file that is saved between executions, and to convert one arbitrary type to another by going through an ASCII representation. Users may also register a custom widget that interactively edits that type. The Class
Mechanism
Subclassing and inheritance are complex ideas. When we first show students SUIT, we explain that SUIT provides a collection of screen objects, each of ACM
TransactIons
on Information
Systems,
Vol.
10, No. 4, October
1992.
Lessons Learned from SUIT
Fig.3.
which that
belongs
necessary real
to one class,
class. When
motivating
to briefly
reasons,
abstraction,
and
value
are which
display
can inherit
some portion
of course weaker
based
they
of their
mechanisms,
are not ready
on issues
undergraduates
329
styles.
the class and inheritance
lie to our students;
which upon
Bounded
.
such have
state
to appreciate as modularity
a tenuous
from
we find
grip.
it the
and Stu-
dents understand concrete explanations much better than abstract ones, and once they understand the concept, one can revisit the motivation for it. Therefore, we explain that having each object store values for each possible property is wasteful, especially when many widgets often have the value for a property. Although provide a motivation the value object’s
the storage savings are not really of concern to us, they that students readily accept. When a program requires
of a property,
state.
If SUIT
SUIT
looks
does not find
first
in the property
the requested
list
property,
containing it then
looks
that in a
property list stored with the object’s class. If the property is not found at that level, SUIT looks in a global property list. If the property is not found in the global property list, SUIT creates it using the type’s initialization routine to establish a default value.
The Property Editor Students do best with concrete, visible items. Screen objects are good for explaining object-oriented programming, as shown by the early success in Smalltalk [8]. The problem with class and global property lists is that they are no longer implicitly visible. The prototype-instance architecture [ 11] does ACM
Transactions
on Information
Systems,
Vol. 10, No. 4, October
1992
330 not
R. Pausch et al.
. really
visible
solve
on-screen.
this
problem,
because
We provide
a direct
prototype
objects
manipulation
[15]
are
typically
not
editor
that
property
allows users to interactively examine and alter the state of obj ects. The SUIT property editor, which is shown in Figure 4, always displays the object, class, and global property lists when allowing the user to edit the state of an object. Users alter a property’s value by clicking on that property with the mouse; boolean
properties
type-in
box or a type-specific
shown
in Figure
the user
toggle
when
clicked, dialog
5. If an object
can take
that
object
level,
thereby
object
level
and the
is currently
property
value
copying user
and other
box, such
it.
If
wishes
properties
inheriting
and drag that
the
up a
from
font
its class,
class level
to the
specified
at the
is currently property
bring
box for type
a value
it from
a property
to have
either
as the dialog
default
to the
class’s
specification, the user drags the property from the object level to the trash can, deleting the object level property. In the same way, properties can be manipulated at the global level. An exrcise in the SUIT tutorial asks the reader to make all labels in an application blue, and then have one particular label override that default and be red. Property use
sheets
date
a spreadsheet
contribution
back
model
is to always
This
produces
the
mechanisms
tremendously inheritance
some
to (at least)
for
expose
screen
the
clutter,
for accessing
successful; in less than
accessing
the
fixed
but
inherited
Xerox
attributes three
Star
Other [12,
levels
also avoids state.
[2].
of objects
The
on every
having
the
property
invocation.
student
editor
Our learn
has been
it allows our students to understand and use state Five minutes. We believe this is due to the combina-
tion of limiting the class hierarchy to a single level—exposing all three levels—and using direct manipulation. Other systems, such as Sun’s DevGuide, use custom panels class, editor.
systems 20].
rather than a scrollable The drawback to using
list of properties a custom panel
information
at
for each widget
as in the SUIT property per widget class is that it
either requires the authors of new classes to create those panels by hand, or requires the system to provide an automatic layout tool for an arbitrary set of properties, a task beyond a new widget class, the class.
most current systems. With SUIT, if a user defines property editor will work automatically with that
Linking Objects to Other Objects By default,
SUIT
provides
a very
simple
linkage
mechanism.
Application-level
callbacks can be registered with objects, and those callbacks are invoked by the input handlers for the screen objects. A more complicated problem is how to provide a general linkage mechanism between screen components and arbitrary user routines. The NeXT Interface Builder solves the problem by allowing the user to draw a connection prompting the user to specify details dialog boxes. SUIT provides a simpler handles a large number of common confusion about whether the fh-st object is linked to the first. ACM
Transactions
on Information
Systems,
between two screen objects and then about the linkage via a sequence of but more limited form of linkage that cases and avoids the novice’s usual is linked to the second, or the second
Vol. 10, No. 4, October
1992.
Lessons Learned from SUIT
Fig.4.
.,.
Property
Many
linkages
drawing
.,.
between
aspect,
program
331
editor.
Fig.
a particular
.
on-screen
or property,
in Figure
6, the
objects
merely
of another. slider
5.
allow
For
controls
Font
panel.
one object
example, the number
in
to control
the
of sides
polygon in the
polygon. Rather than attempting to link two existing objects, a SUIT user would start with only the polygon object and then invoke the property editor. The user would then drag the “number of sides” property to the “EXPORT icon (a picture of a moving van), which causes SUIT to create a new object that controls that property. This also has the side effect of locking the property, which is shown with a small “1ocW icon in the property editor. This avoids the ambiguous situation of the user modifying the polygon’s “number of sides” in the property editor after exporting it. In fact, the program shown in Figure 6 can be created with no programming, starting with a blank screen. The user creates a “polygon object” via ACM
TransactIons
on Information
Systems,
Vol. 10, No. 4. October
1992
332
Fig.
.
6.
R, Pausch et al.
Polygon
application
the menu of standard objects and then exports that polygon object’s “number of sides” and “filled” properties. In a similar fashion to the EXPORT icon, the INFO icon can be used to gain information
about
a property.
Users
on-line help describing the data type of what the property is used for.
can drag
a property
of the property
to this
icon and get
and a textual
description
Hierarchy With with
most
interface
the geometric
toolkits, tree
that
novices visually
confuse nests
the
objects.
logical
tree
We avoid
of subclasses
this
problem
in
SUIT by limiting classes to one level and by hiding the geometric hierarchy from novice users. As an aside, the motivation for providing rich subclasses of objects is somewhat weak; it may help the implementor of the toolkit, but most users of the toolkit do not want to have to know that class “button” has been derived should make
from class “label” it easier to create
but our discussions with frustrating than helpful. Although
some
basic
in order to use it properly. custom widgets by subclassing
Motif
users
SUIT
objects
revealed
that
are actually
most
find
hierarchical
In theory, this existing ones, the process collections
more of
other objects, we provide procedural and interactive operations that treat these objects atomically. By providing interactive tools that allow users to move and resize multiple objects at one time, we sidestep the only motivation most novices have for wanting to compose basic objects into a hierarchy. Once users are comfortable with the basic system, we introduce them to interactive manipulation of hierarchy. SUIT allows users to create a composite object which geometrically contains other objects. One type of composite object, the bulletin board, does no rearrangement of its children. Another, the stacker, has vertical and horizontal tiling display styles (vboxes in Interviews/TeX terminology). A third, the pull down menu, hides its children until it is pressed. Screen objects can be nested within a composite object by dragging them inside it. Any object can be nested into any of the composite objects, and new users are often delighted when they discover they can place clocks and sliders in pulldown menus. When objects are inside a composite object, there is ambiguity as to which object should receive input. For regular input, this is simple: the input ACM
TransactIons
on Information
Systems,
Vol
10, No
4, October
1992
Lessons Learned from SUIT handler
for the outer
object
merely
passes
child. move
Input directed toward SUIT’s an object, is more problematic.
open
a composite
border receive
around SUIT
widget.
When
not
lookup
specify
geometric
is affected:
its color, parent
should
(the
an
object
semantic
of implementation rule: if an object
it be the
list,
and if we still
moving
is inside color
menu)?
and intellectual does not specify
to the appropriate
draws
a special
up to be a sibling in
several
a pulldown
of its
There
SUIT
to to
and not the outer object, will outside the boundaries of its
complexity
if a button
could implement a flag per property but look at parent, not class,” which
property
is open,
autonomous,
pulldown
down
333
interactive tools, such as an attempt This is resolved by allowing the user
it to indicate that its children, commands. If a child is moved
geometric parent, it becomes parent in the geometry tree. Geometric hierarchy adds property
the input
.
class (all
of its
ways.
menu buttons),
is no one, correct
First,
and
does
or of its
answer.
One
in each object indicating “not specified, provides all possible options at the cost complexity. a property,
do not find
Instead, SUIT we look first
the property,
uses a simple at its class’s
we walk
chain until an answer is found. The class property lists not consulted; we concede this is an arbitrary decision,
up the parent
of the ancestors are but so are all other
solutions.
Employees In
SUIT,
each
object
multiple representations may be simple or may consists
of other
represents
an
objects,
these
objects
display style. Figure 7 shows the The speedometer and thermometer have no employees,
while
the
style.
When
thermometer,
SUIT neither
this
one “cycles” the
nor
sent
appear
a bounded three
through input.
are known
display
style
scrollbar’s
is implemented
painted
data
type,
which
as the
can
employees
display styles for a bounded display styles are simple
the scrollbar
arrow buttons and an elevator. The employees of a display display
abstract
have
called display styles. Each of these display styles be composed of other SUIT objects. If a display style
style only
while
the
value
object
from
employees
visibility.
When
has three
employees: object
objects
an object
from
two
is in that
the scrollbar
are no longer
Invisible
one cycles
of that
value object. because they
needed. in
SUIT
to In are
one display
style to another, the employees of the old display are made invisible and those of the new display are made visible. We chose to change the employees’ visibility rather than create and destroy them as necessary, so that the employees’ properties would be retained when the user cycles away from the display style and back to it again. In terms of geometrical composition, employees are very similar to children. Both may inherit
children and employees move and resize with their parent’s properties. The only difference
their parents and between them is
that a child exists for each of the parent’s display styles while an employee exists for only one. To make this distinction clear, consider a possible implementation of an object that allows the user to scroll through a picture. One display style might use scrollbars along each axis to represent the ACM
Transactions
on Information
Systems,
Vol. 10, No. 4, October
1992.
334
R. Pausch et al.
.
Fig.
portion
of the
object
picture
(a rectangle
tion.
In
the
7
Employees
currently
within
being
another
implementation,
in display
viewed.
rectangle)
the
styles
Another
might
to represent
picture
object
use a panner
the
would
same
informa-
be a child,
since
it
would necessarily be in every display style. The scrollbars would be the employees of the first display style, and the panner would be the employee of the second. In practice, employees are rarely used. The only object in SUIT’s standard library that uses them is the scrollbar mentioned above. There are two main reasons to merit
for this. The first is that, if an abstraction breaking it down into several component
only
one good way
only
one display
employees. tions
The
usually
one display makes
to represent
style. second
have style
employees
this
An object reason each
only
is that
a particular for
abstraction;
with
of their
who
in mind,
objects.
thus
one display
those
interface
is sufficiently objects, then
Again,
the
use SUIT and
object
style
would
have
has no need for to build
therefore
having
complicated there is often
applica-
only
one display
design style
unnecessary.
The last portion of the architecture many systems, such as Garnet, support
supports semantic linking a constraint model where
of state: the pro-
grammer specifies a relationship that should remain true, and the system ensures that it does. For example, the programmer can make one object state “above” another on the screen by establishing a constraint between their viewports. in SUIT’s model is similar: we allow the programmer to register an interest an object by specifying a procedure to call each time object changes. The procedure is called with parameters
any property of that indicating the object
that is in question, the name of the property that changed, and the old and new values. This interest routine will then set any properties for that (or any other) object. This is, in fact, how SUIT makes sure that buttons are the same size as their text. It registers an interest in each button, and if the “label” property of a button changes, SUIT recomputes a new “ viewport” property based on the size of the text. While this behavior could have been implemented in a specialized constraint language, we believe that simply writing a subroutine in C is the most straightforward way to establish the relationship we wish to maintain between the string in the button and the button’s viewport. ACM
TransactIons
on Information
Systems,
Vol.
10, No
4, October
1992.
Lessons Learned from SUIT
.
335
OUR EXPERIENCE WITH USERS The next based
two sections
on our
they motivated. to the
are our most
experience These
programmer
with
important
our users
two sections
interface
and
contribution,
both
the changes
in the
are delineated
and the
data
tools that we provided in the interface builder. learned from the programmer’s interface. Our most important
observation
is that
by whether
model
we were
system
are that
the change
or to the
We begin
of which
was
set of interactive
with
defeated
the lesson
on only
we
one front:
the general idea of callback-based programming was something we were never able to have the tool teach as part of the process. We were able to write a four-page addition, to be read before the tutorial, which makes it possible for most students to understand external control. In hindsight, we should not have been surprised that external control was the single most difficult concept
for college
programs
whose
are read
juniors.
execution
in the source
are subroutines Pascal, external
Introductory
programming
paths
follow
closely
code. Callback
functions
courses
the order
that
are typically
stress
writing
the statements not covered,
nor
that take functions as parameters. In fact, in ANSI-Standard control is not even possible, because function pointers cannot
be stored into variables. All but the very best
undergraduates
are accustomed
to encoding
state
in
the flow of their programs, and they have great difficulty adjusting to the model in which they write small fragments that can be called in any order, at any time. In fact, a common “coping strategy” we saw was for a single button’s ality. force
callback
Students the user
interface
within
procedure
to encapsulate
a huge
chunk
also tended toward moded interfaces, dialog at each step, trying to mimic
of program
function-
where they attempted to a command-line prompt
a GUI.
Custom Widget Authoring Another tively
major painless
we found
that
observation in SUIT, students
is that,
and early went
although
versions
to great
creating
new
of the tutorial
extremes
widgets
is rela-
had students
to avoid
writing
do so,
their
own
custom widgets. The end result of this is very positive. Whether motivated by fear, laziness, or by good software engineering principles, students reused existing When
code wherever students did
possible. write custom
widgets,
we
saw
two
major
recurring
problems. The first common problem was in using coordinate systems. The abstract floating point “world” coordinate system is much easier and more flexible, but is not what students expected. Concrete things are almost always
easier
to grasp
the desire to draw in several custom widgets,
than
abstract
ones, and students
uniformly
expressed
screen pixels. However, after students had they usually began to appreciate the abstract
written coordi-
nate system. The second major problem with custom widget authors was a general lack of understanding of the SUIT “database model,” in which input procedures change properties in the database and paint procedures may only examine ACM
Transactions
on Information
Systems,
Vol. 10, No. 4, October
1992.
336
R. Pausch et al
.
the
database.
This
division
caused
major
problems:
almost
every
attempted disabling
to paint within the input procedure. We considered the graphics library routines before calling a user’s
and then procedure
reenabling them after the would trigger a run-time
probably wrong.
would
Students custom had
not have
were
able
widgets.
to write
When
difficulty.
tutorial
they
Based
on creating
helped
on
call, so that any painting inside a hit error. We abandoned this because it
a student most
these
two
widgets.
understand
programs
attempted
custom
student
mechanically input handler
without
to create facts,
we
Students
what
custom
were
doing
creating
their
own
widgets,
they
often
removed who
they
the
needed
section
to create
of the custom
widgets were eventually provided with an example program that created simple widget. Students were more successful in modifying this program meet their needs than they had been working from a clean slate,
a to
Make Easy Things Easy In several
places, we were able to apply design principle of “make easy things The first was with moded interaction techeasy, and hard things possible.” niques: dialog boxes that grabbed the input focus and required an answer from
the
identified for them:
user
before
the most
SUIT_inform
other
SUIT —ask(char
* question,
to these,
passed
again
accept
input.
simple
We
functions
* question);
SUIT_askYesNoCancel(char
addition
would
cases and provided
* question);
SUIT_askOKCancel(char
In
objects
requested
(char * message);
SUIT_askYesNo(char
When
screen
commonly
an
*question); char * answerl,
we provided
arbitrary
SUIT
char * answer2);
one general-purpose object
as a parameter,
moded it
dialog
nests
in
box. it
an
OK/Cancel dialog box and allows the user to interact with the widget until the user presses either the OK or Cancel button. These routines seemed to meet
all of our user
Another techniques,
needs
for moded
common case was the such as rubber-banding
dialog
boxes.
need by users for lines or dragging
dynamic objects
interaction around the
screen. We provided a simple routine that XORd a rectangle at the current mouse position as long as the button stayed down. The final screen coordinate would then be functionally returned. This, combined with a utility function SUIT ObjectAt(x, y), made it easy for users to implement simple drag-anddrop ~echniques, such as dragging objects to a trash can. In addition to the rectangle drag, we provided a text string drag routine and a general-purpose drag routine that called an application callback each time the mouse moved. Most of the time, the rule of thumb is that anything one sees on the screen is part of the SUIT interface, is stored in the database, and is restored “as is” the next time the application is run. In some instances, this is not desirable; for example, in some applications it makes more sense for scrollable lists to ACM
Transactions
on Information
Systems,
Vol. 10, No. 4, October
1992
Lessons Learned from SUIT return
to the top of the list
added
calls
entire
object
be saved
than
to make
particular
could
be declared
between
retain
their
properties
old location.
temporary.
application
337
this,
we
fashion,
an
To support
In a similar
temporary-meaning
.
none
of its state
would
invocations.
Name Space Issues Like
other
of static
dynamic
checking
systems,
we rapidly
developed
a problem
on our name
spaces.
For example,
property
are just character strings, searched at runtime users need not declare a property before using misspell a property’s value. A classic story
spent
several
hours
had no effect. By misspelling the “has border” new Boolean property, never again examined. LISP-based often
systems, need
such as Garnet,
to create
avoided spelling problems preprocessor and including #define in
SUIT lems.
trying
to figure
out
why
the
new
property, the student created a This is a common problem in
where
properties.
accidental We
for the SUIT-provided a line such as
kept
slot
this
properties
creation
is a
flexibility, by using
but the
C
HAS_BORDER “has border”
suit. h include
the
standard
in SUIT
compares. Since user error is to
“has boarder”, FALSE);
SUIT_setBoolean(myObject,
most
using string it, a common
name, thus generating a new property with a default involves one poor student who was trying to remove the
border of an object and following line of code:
problem. Users
due to the lack names
set. This,
file
be case-insensitive,
Other Programmer
for
combined
each
with
SUIT-provided
the decision
effectively
solved
property
to make our
name
all string
dynamic
name
in
the
compares space
in
prob-
Issues
Under certain conditions, it became necessary to prohibit users from altering a property via the property editor. For example, users tended to randomly play with various global-level properties, which often caused problems. some properties, so that the user could no longer change Therefore, we locked them
with
the interactive
property
editor.
The remaining
semantic
question
was whether this would also prohibit the application programmer from setting the property. (We rejected the idea of having two different lock bits per property to specify both cases.) Because the programmer also had the ability to query whether properties were locked, and to lock and unlock them, we decided to make the lock prohibit the interactive user only from changing the property, and this has worked well in practice. From the beginning, we felt it was important to support animation in the toolkit. In our demonstration programs, we provide bouncing balls that move at a constant twenty pixels per second, regardless of the speed of the underlying
hardware.
(If ACM
the
hardware
Transactions
is slow,
on Information
the
balls
Systems,
will
appear
Vol. 10, No. 4, October
at a 1992.
338
R. Pausch et al.
.
lower
number
of intermediate
the hardware is fast, their this, we needed to provide tion,
which
we added
to GP because
found it useful to support property is true, SUIT whether
positions,
and their
motion will appear a device-independent
it was the most
properties
will
be choppier;
if
to support SUIT getCurrentTime func-
a boolean animated automatically calls
or not any of the object’s
motion
smoother).
In order
con~enient
layer.
We also
property for all widgets; if this the object’s paint procedure, have
changed.
INTERACTIVE TOOL OBSERVATIONS We present
here
use SUIT’s
a variety
interactive
Gathering
Feedback
Gathering
feedback
users
to send
of insights
that
we gained
from
watching
people
easy. We encouraged
all our
tools.
from
experts
electronic
mail
was relatively
to the
SUIT
account
if they
had
questions
or
comments. From the mail we received, we were able to deduce which parts of SUIT were causing programmers the most trouble, and therefore, which parts needed fixing, better documentation, or both. By comparison, gathering feedback from novices was much harder. The only real way to find out which parts learn was to give the SUIT tutorial worked students
of SUIT were hardest to novices and watch
through it. Our standard observation protocol was to seat pairs of at UNIX workstations with an observer from the SUIT team sitting
behind them, silently taking notes on the session. Pairing the students off was a vital part of the people
for novices to them as they
are told
to work
together
they
talk
observation.
to each other,
often
When
saying
two
what
is
going on in their minds as they work through the tutorial. This forces into the open a dialog that, with one person, would be entirely internal. By eavesdropping on a pair of collaborating students, we can learn about which parts of SUIT
(and
the
tutorial
itself)
that
new
users
find
easy
and
which
cause
confusion. SUIT’s design was changed innumerable times because of difficulties we saw from these silent observation sessions. Keeping the observers quiet during the observation sessions was crucial. One reason observed—a
user testing is hard is that the observer can often influence the problem quite familiar to anyone who designs surveys. This is
especially true here, because it was often the SUIT implementors themselves who did the observing. We maintained a strict policy of “sitting on our hands” during the observations; get up from their chairs
under no circumstance were the observers allowed to and help the users get out of a bind that SUIT or its
tutorial had put them into. If they did, we required the observers to deliver a standard apology: “I’m sorry I wrote such bad software. Here, let me help you with that.” Needless to say, the observers remained seated. We tested SUIT and its tutorial as often as possible and with as many people as we could. This often meant living off the kindness of the professors in the department teaching approximately 45 students ACM
Transactions
on Information
software engineering. This per semester from this one
Systems,
Vol. 10. No. 4, October
1992.
gave class
us a pool of alone. Other
Lessons Learned from SUIT classes
gave us more
the large number taping was never We would experience. notes that
opportunities
like
to note
that
really
relearning
testing
benefits
from
and
field what
the
from
the experience
the observed
scientists from
everyone
benefit
and to be observant;
programmers users. The user
on novices.
339
Because
of people that went through the user testing process, a practical alternative to real, live observation.
The observers
computer
to test the software
.
from test
parts
electronic
a kind
of the
mail
a massive
user
of Iearning
how to take
of “cultural”
as part
of their
software
from
our
of
video testing
lesson, craft;
will
more
i.e.,
and
confuse
advanced
the new
users
yielded a great deal of practical knowledge, which we can summarize under three categories: SUIT’s basic feedback techniques. SUIT’s different interaction techniques, and SUIT’S methods of creating and composing widgets.
Feedback Techniques XOI?
is
As
dangerous.
interactively, imagine.
useful
we found Some
that
platforms
a technique XOR
define
was the
as this
not
bit
nearly
is for
moving
as portable
representation
graphics
as one might
of “black
to be all
zeros, which has no effect in XOR mode! The solution here is to always use a representation that is all ones as the color to XOR with, not the “black” that is provided by the native graphics environment. On platforms with color displays, the XOR the result of an XOR operation is ill-defined results
in a third
color,
the value
the color table, which “lucky,” but of course, SUIT Take
XORS care
a faint when
nique
of drawing
some
direct
cannot anything
blue
line
drawing
of which
a light
handles.
“handles”
on objects
manipulation
depends
be predicted. can change
onto
operations
problem is even worse because in color. XORing two colors on the values
loaded
into
Often, we found that we got the color table—so sometimes
grey background.
SUIT that
uses the standard feedback techare “selected” for the purposes of
(e.g.,
resize).
As is the
convention,
we
drew these handles as small black squares in the corners and on the edges of whatever objects were selected. Users complained that we sometimes drew these squares handles were Choosing transferred
on parts of widgets essentially invisible some the
other
color
problem
that were already black on black.
was
clearly
of someday
not
the
drawing
red
black, solution; cm red,
meaning doing or blue
that
the
so merely on blue.
Eventually, we solved this problem by outlining each of the black handles with a l-pixel-wide white border, producing a handle that is visible under all circumstances. problem isn’t Animation
We learned that sometimes the with engineering, but with graphic draws
attention
and
raises
best answer design.
expectations.
to an interface
We use animation
in
SUIT as a way of drawing the user’s attention to a particular part of the screen, especially when there is an abrupt change to the interface. Animation has the effect of saying, “Look here! This just changed!” For example, when the user creates a new widget interactively, SUIT animates a rectangle that ACM Transactions
on Information
Systems,
Vol. 10, No. 4, October
1992,
340
R. Pausch et al.
.
collapses where
from the
animates animates back that
the edges of the window down toward much the same widget appears,
the center of the screen, way as the Macintosh
new
a rectangle when a new folder is opened. SUIT’s export icon also when a property is exported—a truck drives off the icon as feedthe property was exported. This charmed most users who saw it,
but other users were disappointed because other icons animate. Whether the whimsical charm of the moving enough to warrant its removal is a matter of debate.
Interaction Muscles
and buttons didn’t truck is different
Techniques as
separate
modes.
“run”
SUIT
is unlike
some
modes.
SUIT’s
and “build”
other
interface
interactive
builders
tools
that
have
are present
with
the program as it runs, blurring the difference between running and building. To distinguish between events that are meant for the application and those meant for SUIT, we use a keyboard modifier. If the SHIFT and CONTROL keys are held down when the mouse is clicked, we sent otherwise the event is passed on to the application. Unlike the chance SHIFT
and
talking
to.”
Direct
of confusing
run
CONTROL
manipulation
menu-driven
model
and build
keys,
beats
in
the
so there
mode
are zero; the user holds
is a constant
We
menus.
design
reminder
originally
of SUIT’s
results. Changing a property entailed menu to choose the desired operation:
the event to SUIT, a moded interface,
used
property
a “cut
editor,
down
of “who
and
with
clicking on a property, then move a property up a level,
the
you’re
paste”
dreadful
accessing a move down
a level, delete, and so on. The temptation to drag the property itself in order to move, copy, or delete it was overwhelming. The menus always seemed to put the properties “at arm’s length” from the user. We eventually abandoned the menus With produce
in favor
of a “direct-manipulation”
style
ple, clicking on a color property produced a selection and clicking on a font produced a listing of available Text properties are the only ones that break this press
of editing.
direct manipulation, users could now simply click a widget that allowed them to edit that property’s
OK
to
accept
the
change”
model
on the property to value. For exam-
of colors to choose from faces, sizes, and styles. “click, get a dialog box,
of interaction.
Clicking
on
a text
property wraps a type in a field around the currently displayed characters for the value of that property. This is clearly an irregularity, but one that is a benign exception to the rule—rather than strict adherence to consistency, we opted for keeping the user’s attention focused on the string he is already looking at, rather than producing a dialog box in some other part of the screen. Moving a property from the class level to an object level was done by the familiar “drag and drop” action, Users clearly liked this style better than the old menu “move up a level” command. Users also showed in testing that they had no trouble understanding that dropping a property on the “info” widget produced a dialog box with information about the property or that dropping it on the trash can deleted it. ACM
Transactions
on Information
Systems,
Vol.
10, No. 4, October
1992
Lessons Learned from SUIT As it turns
out, the presence
of the trash
can implied
power
not (at first) possess. We observed that users extended metaphor in their own minds to apply to the whole properties; in many tutorial trash can and were startled our users
understood
We always widgets, were delete widgets made
observation to discover
the concept
our users
happy.
that
“drag
before
341
SUIT
did
and drop” as well as
widgets
trials, users dragged that nothing happened.
of “regularity”
saw the property being dragged from with the property
the
.
widgets to the It seems that
we did.
editor as a place where properties, not place to place, but so many people tried to trash can that we added the feature and
By extending
this
principle
further,
we also provided
help strings for widgets dropped on the info widget. Dropping a widget on the “export” button still does nothing, as the semantics for this are not well defined. By providing this harmless but useful level functionality, we obeyed “law of least astonishment” at the expense of the “purity” of the model.
the
Widget Creation and Composition Users
liked
“export”
“export.”
widget,
If a user
SUIT
creates
drops
a property
a widget
onto
the
corresponding
property
to
the
editor’s
type
of the
property. Color properties produce color chips, text properties produce text entry widgets, and so on. The widget then controls the value of the property that
was “exported,”
providing
a short
cut to the full-blown
property
editor
by
giving the user a single widget in the application interface that controls the value of a property. This was seen by many of our users as a way of avoiding a fair bit of uninteresting code in their applications. Interactive widget creation is only for demos and decoration. While always impressive in a demo, the ability to create new buttons and sliders on the fly is really
not very
can be added specified. harder
useful.
nicely,
Because than
Items
but most SUIT
that items
is based
in a LISP-based
system
act merely have on
as decoration,
attached
C, runtime
like
Garnet;
such
functionality binding SUIT
would
as labels,
that would
must
be
be much
need to compile
and link code on the fly-something that a LISP-based system need not worry about. If the user creates a button interactively, how does he or she attach a callback function to it? Attaching the callback is usually done with the creation call, but here the button has already been created! At present, the
the
C source
only
way
code file
and
to do this makes
is by hand:
a function
the
call
programmer
that
pointer to the button, referring to the button by its provided when the widget was created interactively. incorrectly results in a fatal runtime error. AS a practical matter, SUIT’s interactive of use for widgets with no functionality—labels that exist purely for show).
Composition purpose
opens
up
a function
unique string Spelling the
name name
creation of widgets is really only and “place mats” (rectangles
of Widgets
In the begining, only
attaches
we saw the
is to contain ACM
need
other
for a composition
widgets.
Transactions
In a fit
on Information
widget–a of whimsy, Systems,
widget
whose
we dubbed
Vol. 10, No. 4, October
this 1992.
342
new
widget
container try
R Pausch et al.
.
type
managers,
Tupperware
Tupperware.
class that
could
pulldown
was
be used for horizontal menus,
dialog
boxes,
seen
as a general-purpose
and vertical and
any
stacking
other
type
geomeof widget
that might contain other widgets. To us, the only distinction between these different screen objects was in the way they displayed their subordinates (or “children” in SUIT parlance). We therefore implemented a Tupperware class with display styles bulletin board, menu, vertical stacker, and horizontal stacker. Our users saw things differently. To them, a menu and a bulletin board (dialog box) were two different things, and pretending that they were the same only served to confuse them. As it turned out, we had difficulty in maintaining the code for this behemoth widget, and so reimplemented it as several different widgets. This removed ably for our users. Again, cleanliness learning
curve
bugs and cleared the way considerof the model was sacrificed for the
of our user base.
CONCLUSIONS By using
a reduced
providing
direct
model
for
manipulation
subclassing, tools
hiding
for property
geometric
setting
hierarchy,
and linkage,
and
we were
able to radically reduce the learning time and complexity for a user interface toolkit. By keeping the toolkit’s implementation lightweight and building it on top of an easily ported graphics package, SUIT on a wide variety of platforms. College
juniors
who were
not familiar
we have
with
been
external
able to implement
control,
and had never
seen another UI toolkit, were able to use SUIT productively after roughly two and a half hours. Our undergraduate software engineering class projects have been able to expand their scope significantly by using SUIT, and the students were highly motivated by being looking interfaces for their projects. The best validation of a tool like SUIT which
must
rely
only
on our
printed
dence via electronic mail. At the time over 100 external internet machines,
able to easily is when
produce
professional-
it is used by external
documentation
and
of this writing, SUIT and is being adopted
limited
sites,
correspon-
has been FTP’d to for use in under-
graduate courses at a number of universities. Professional research ries are also finding SUIT attractive; as is often the case, a powerful is easy for novices to use is often attractive to experts as well. Our original desire was merely to produce a tool that would
laboratotool that introduce
students to relatively difficult concepts, specifically external control and inheritance. We had presumed that after spending a few weeks with SUIT they would outgrow it and move on to other more mature and complex systems such as UIMX [17], based on Motif Widget set, or Interviews. Instead, we have observed the phenomenon that also occurred with Pascal: unless students discovered a specific need to move to a more advanced platform, they continued to use SUIT for their own research projects. Our major regret is that we implemented geometrically hierarchical widgets. This more than its end value to most ACM
TransactIons
doubled the complexity users at less than five
on Information
Systems,
Vol.
10, No
of the system, percent.
4, October
1992
and we estimate
Lessons Learned from SUIT In
this
paper,
important
we
have
to remember
process, students.
with
presented
that
dozens
the
SUIT’s
of versions
final
incarnation
development
released
was a
and
tested
.
343
of SUIT;
continuous,
it
is
iterative
for feedback
with
real
Getting SUIT SUIT
is provided
without
charge
to academic
and. nonprofit
organizations.
access to the internet can type finger suit@ uvacs.cs.virginia. on how to get and run the software.
Readers with for directions
edu
ACKNOWLEDGMENTS
We would
like
to thank
Roderic
Collins,
Jim
Defay,
Pramod
Dwivedi,
Bran-
don Furlich, Rich Gossweiler, Drew William McClennan, Kim Passarella,
Kessler, James Leatherby, Chris Long, Anne Shackelford, Hans-Martin Werner,
and
Nathaniel
contributed
also
thank
Young, all
all
of our
of whom
users,
allowed us to use their acknowledge the help
especially
to SUIT’s
Anita
students as guinea of the anonymous
Jones
Marc
We
Brown,
who
pigs for early versions of SUIT. We referees, whose comments led to
substantial improvements in the paper. SUIT should not be confused with SUITE similar
development.
and
[5],
a project
at Purdue
with
a
Serpent:
A
name.
REFERENCES 1. BASS, L. J., CLAPPER, B. M., HARDY, E. J., KAZMAN, R. N., AND SEACORD, R. C. user
interface
environment.
D.C.,
(Washington, 2. BEWLEY, design
W.,
on Human
8010
Factors
Trillium
1990),
ROBERTS, T.,
of Xerox’s
3. BLOMBERG,
Jan.
In
Proceedings,
‘Star’
Computing
Systems,
Off Ice Workstation. Systems A.
22, (Feb.,
5. DEWAN, P. TR-60-P,
1989),
A Guide
Feb.
7. FOLEY,
1986),
Wash.,
Apr.
Editzon
Dec.
12–15,
1983),
on participatory CHZ’90 1990),
factors
of ACM
in
the
Conference
pp. 72–77.
design:
Conference
testing
CHI’83 Lessons
on
Human
from
the
Factors
in
pp. 353-359.
Composing
user interfaces
with
interviews.
IEEE
Software
Engineering
Research
Center,
Purdue
Univ.
SERC-
C. F.
Dynamic
process
visualization.
Comput.
Grab.
Appl.
6, 3
FEINER,
S., AND HUGHES,
). Addison-Wesley
J.
Publishing
Computer
Co., Reading,
Graphzcs:
Principles
MA,
0-201-12110-7;
ISBN
and
AND ROBSON, D.
Smalltalk—80:
The
Language.
Addison-Wesley,
Reading,
1989.
9. MAHONEY, In
Human
1990.
8. GOLDBERG, A., Mass.,
J.
1-5,
W.
Proceedings
16-25.
(2nd
T385.C587,
Conference,
8-22.
to Suite.
J., VAN DAM, A.,
Practice
Technical
1990.
6. FOLEY, J. D., AND MCMATH,
(Mar.
(Boston,
of ACM
4. CALDER, P., LINTON, M., AND VLISSIDES, Computer
In
Reflections
Proceedings
(Seattle,
USENIX
pp. 245-258.
in Computing In
1990
SCHROIT, D., AND VERPLANK,
J., AND HENDERSON,
Experience.
Winter
M.
Tuto?val
Interface
Notes
from
(New Orleans, IA,
Builder the ACM
1991).
and Object-Oriented SIGCHI
Available
from
Human NeXTj
Design Factors
Inc.,
in the NeXTstep
in Computer
900 Chesapeake
Environment.
Systems Drive,
Conference,
Redwood
City,
CA 94063415-424-0200. 10. MCCORALWK, SIGGRAPH
J., AND ASENTE, Symposum
P.
An
overview
of the
on User Interface
Software
ACM
on Information
X toolkit.
(Banff,
In
Alberta,
Pm.eed,ng. Canada,
of the ACM Oct.
1988),
pp.
46-55. Transactions
Systems,
Vol. 10, No. 4, October
1992.
344
R. Pausch et al.
.
11. MYERS, highly
B., GIUSE,
D., AND DANNENBERG,
interactive
12, MYERS, B. ceedings
user
Graphical
of ACM
LA, Apr 27-May 2,
Garnet:
IEEE
Comput.
Techniques
in
a spreadsheet
CHI’91
13. PALAY, A. J., HANSEN,
B.
interfaces. Conference
1991),
on Human
Conference
14, ROCHKIND, ming
M.
J.
Institute,
support
for graphical,
11 (Nov. 1990). for
Factors
specifflng
user
in Computing
interfaces.
Systems
(New
In
Pro-
Orleans,
pp. 243-250.
W. J., KAZAR, M. L., SHERMAN, M. S., WADLOW, M. G., NEUENDORFFER,
T. P., STERN, Z., BADLER, M., AND PETERS, T. Technical
Comprehensive
23,
Proceedzrzgs
Technical Ltd.,
(Dallas,
overview
January
16,
The Andrew
TX, Feb.
of the 1989,
extensible
API
Ltd.,
toolkit—An
1988),
overview.
In USENIX
pp. 9-21.
virtual Box
toolkit.
17665,
Advanced
Boulder,
CO
Program80308
(303)
443-4223. 15. SCHNEIDERMAN, Comput. 16. SIBERT, system.
B.
16, 8 (Aug. J.,
HURLEY,
Comput.
17. USER INTERFACE Suite
443,
19. WELSH, 20. WILDE,
ACM
J.
manipulation:
1983),
57-69.
W.,
Graph.
A virtual
toolkit and
N., AND LEWIS, C.
Proceedings
of ACM
Wash.,
1-5,
Apr.
Transactions
(415)
step
An
beyond
programming
object-oriented
Also
user
in proceedings
FOR X.
Visual
Edge
Mac.
BYTE
for windows
and the
Insecurities
in Pascal.
Conference
Systems,
interface
Software
Ltd,
IEEE
management
of SIGGRAPH
Softw
interactive
on Human
14, (Mar.
Prac.
Expe.
graphics:
from
Factors
in Computmg
pp. 153-159.
on Information
languages.
’86 101
First
St.,
948-0753.
Spreadsheet-based
CHZ’90
1990),
T.
1986).
TOOLmT
CA 94022
Ambiguities
A
AND BLESER, 20, 4 (Aug.
MANAGEMENT
Los Altos,
18. VALDES, R.
Direct
Vol
10, No. 4, October
1992
1989),
209-210.
7, (1977), prototype Systems
685-696. to tool. (Seattle,
In
