Lessons learned from SUIT, the simple user ... - ACM Digital Library

2 downloads 0 Views 2MB Size Report
RANDY PAUSCH, MATTHEW CONWAY, and ROBERT DELINE. University of Virginia. In recent years, the computer science community has realized.

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 [email protected],

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 [email protected] 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

Suggest Documents