From: AAAI Technical Report FS-93-05. Compilation copyright © 1993, AAAI (www.aaai.org). All rights reserved.
Collaborative
Applications
for Long-Term Use
Michael
Eisenberg
Department of Computer Science and Institute
of Cognitive
University of Colorado, Boulder
Boulder, CO 80309-0430
Email: duck@cs.colorado.edu
Abstract
Computer
applicationsare designed,used, and assessedby
(often unstated) analogyto other tools and devices. When
viewedas appliances(e.g., telephones),applications are
createdandjudgedaccordingto standardsof ease of use and
rapid learnability; whenviewed,by contrast, as creative
media (e.g., musical instruments), standards
expressivenessand flexibility becomemoresalient. In
designingthis secondtype of application, providingthe
user with long-termcreative poweroften necessitates an
acceptance of various forms of complexity within the
application--for example,the application mayinclude a
"task-enriched" programming
environment;and further,
makingsuch an application truly collaborative suggests
the inclusionof features andtools that will supportusers
in learning both the application itself (including the
programming
language)and the domainof the application.
This paper elaborates on these observations, discussing
the designof collaborativeapplicationsfor creative, longterm use (and contrasting this design strategy with the
dominantcurrent trend in application development).The
paperconcludeswith a brief descriptionof our ownefforts
in collaborative application design: namely, the
programmabledesign environments currently being
prototypedin our laboratory.
Introduction
Personal computersoftware, as a phenomenon,
is now-dependingon one’s measureof these things--about twenty
years old. But for its users, designers, and critics--for
those burgeoning numbersof people whoseday-to-day
lives center upon computers--there is a continuing
struggle to define what, precisely, computersoftwareis
for. That struggle often takes the form of conflicting
metaphors,answeringthe questionof whatsoftwareis for
by focusing on what it is like. Thus, on one view,
softwareis like the writtenword,destinedto be the carrier
of a popularintellectual revolutionsimilar to that sparked
by the printing press [Friedlander1988,Kay1993];or it’s
like a physical environment,a virtual world, in which
users can moveandinteract [Rheingold1991];or it’s like
moviesor theater or television---entertainment
of a sort-but ideally less passivethan those other media[Crockford
1990, Oren1990, Laurel 1991]; or it is a tool, to be
integrated seamlesslyand"conversationally"into day-today activity [Winogradand Flores, 1986]; or, perhaps
moreominously,it is like the written wordbefore the
20
Science
printingpress, an inventionthat separatesthe worldinto a
populationof elite scribes anda muchlarger populationof
intellectually disenfranchisedcomputerphobes.
[Fischer
1993]
All these metaphors have compelling arguments to
accompany
them;and all provide fascinating insights by
focusing our attention on importantaspects of computer
software. But these varying metaphors--appropriateas
they maybe for different circumstances--do lead to
distinct and sometimesconflicting philosophies of
software design and use. For application software in
particular, this welter of interpretive metaphors
can prove
confusing: do wewishto design(and judge) applications
as entertainment,as handytask-specific tools, as meansof
expression, or as somethingelse entirely? This basic
task---of understanding what applications are, howwe
wantto think about them--takeson a newurgencyas the
sheer quantity, variety, and complexity of software
applications becomesoverwhelming.
This paper will use this notion of "interpretive
metaphors"
to focuson several issues that I believeto be
recurrentin the designof expressivesoftwareapplications.
A central theme, cropping up in one guise or another
throughoutthe discussion, is the question of pace, the
time frame over whichsoftware is used. If software is
designedto be encounteredbriefly, intermittently, to
perform
relatively
predictable
orconstrained
jobs
(orjobs
forwhich
failure
would
becatastrophic),
thendesign
criteria
ofsimplicity
andlearnability
become
paramount.
(Theoperant
metaphor
heremight
beonewhich
likens
computer
software
tonear-ubiquitous
appliances
likethe
telephone,
refrigerator,
orautomobile.)
Ontheother
hand,
if software
is designed
withthenotion
of long-term
individual
human-computer
collaboration
inmind,
then
complexity
becomes
harder
toavoid(perhaps
it is no
longerworthwhile
to avoidit altogether),
and
expressiveness
isthemost
important
dimension
ofdesign.
(Theoperant
metaphor
heremight
beonewhich
compares
computer
software
to themedium
of writing,
or to
musical
instruments.)
Thefirst section of this paper pursues the themeof the
previous paragraphby focusing on the tension between
learnability and expressiveness in the design of
collaborative applications. This is followed by a
discussion, in Section 2, of howthe current culture of
software developmentmight be viewedas antagonistic
toward achieving the goal of human-computer
collaboration.
Thethird
(andfinal)
section
ofthepaper
briefly
describes
somecurrent
workinourlaboratory
at
theUniversity
ofColorado,
andtheissues
thatthiswork
raises
forprospects
ofdeveloping
truly
collaborative
software
applications.
Learnabillty vs. Expressiveness
In keepingwith the tone of the introductory paragraphs
above, it maybe worth beginningthis section with an
analogy.
Imagine
thatwearepresented
withtwobrandnewartifacts,
never
before
seen:
thefirst
isa keyboardoperated
musical
instrument
called
a "piano,’"
andthe
second
isa similar
butslightly
enhanced
tool,
the"player
piano."
A user
ofthefirst
instrument
isexpected
tospend
months,
or perhaps
years,
mastering
theinterface;
although
theusermay,justbarely,
beableto coax
listenable
music
outofthepiano
during
thislearning
period,
itwill
almost
certainly
take
years
before
heorshe
canexpect
toplay(orcompose)
anything
oftruly
high
quality.
Inthesecond
case,
however,
thetaskismuch
easier:
theuser
simply
buys
a setofavailable
piano
rolls,
plugs
themintotheslotatthefront
oftheinstrument,
andlistens
tothecompetent
(ifperhaps
less
than
brilliant)
music
produced.
Certainlyboth these instrumentshavetheir strengths; but
those whosevalues are derived from the human-computer
interaction communitymight be inclined to judge the
pianorather harshly.Theinterfaceis, after all, difficult to
master--thelearningcurvecouldhardlybe steeper. Indeed,
out of a hundredbeginningpianostudents, perhapsonly a
small number will persevere long enough to create
listcnable music; manymorewill give up and moveon to
other pursuits. If wethink of the piano, then, as a tool
with whichto producemusic, it mustbe admittedthat it
is a rather inefficient one: slow,uncertain,anddemanding.
In contrast, the player-piano seemsto be a distinct
improvement:
if the user has to producemusicright away,
the appropriatepianoroll is obtained.Theinterface to the
instrument virtually guides the user into the musicmakingprocess.
Thecontrast is, of course, incompleteas stated: whilethe
pianois admittedlya difficult andfrustrating instrument,
it does offermtothose whofinally succeedin mastering
irma wonderfullyexpressive medium.Evenfor those of
us whodo not masterthe instrument(or evenattemptit),
the piano providesus with enjoymentthroughthe creative
efforts of those whodo. In contrast, the player piano
offers users a quick-and-easyselection. Whileenjoyable
andworthwhile
asa tool
fortherapid
recreation
ofmusic,
itishardly
a means
ofexpression;
andwhile
learnable,
it
simultaneously
diminishes
theroleandrewards
of
expertise.
Thecontrast betweenthe piano and player piano has some
analogymanimperfect analogy, granted, but still
illustrativemwith issues that arise in applications
software. Loosely, we might equate the player piano
examplewith efforts to create "user-friendly" software
21
whoseinterface is entirely driven by menus, dialog
boxes, icon selection, and so forth. Certainly the best
softwareof this type is learnable, and--like the player
piano--it guides the user into a relatively painless
selection amongdesigner-providedalternatives. Onthe
other hand, there is little rewardfor expertise in such
systems: while the experienceduser maybecomefamiliar
with a wider array of options (analogousto the player
pianouser acquiringa larger set of pianorolls fromwhich
tochoose),
thedevelopment
isoneof"breadth"
rather
than
"depth."
Thatis,oneknowsmoreandmoreabout
the
myriad
features
of thesoftware,
buttheinternal
computational
world--the
wayinwhich
thecomputer
can
serveto reinvent
theapplication’s
domain--remains
mysterious,
theprovince
ofthedesigner.
In contrast, programming
languagesare closer in spirit to
the piano. For manypeople, they require a long time to
learn; the initial rewardsof that learningprocessare small;
but the range of expressivenessthat accompanies
expertise
is tremendous.Perhapsmosttelling of all, programming
(like the piano) can becomea lifelong passion--an
activity that takes on morevalue over the course of a
lifetime precisely becausewehavebeengrowingwith it
for years. Thoughthe essential rules of programming
may
be learnedin a brief time (muchlike the rules of chess, or
the placementof keyson the piano), it is the progressive,
long-term combination of those rules in creative,
personalizedpatterns that gives the programmer
his or her
voice.
In point of fact, one can argue that the design values
represented by the piano and player piano---namely,
expressivenessandlearnability, respectively--neednot be
cast in oppositionin the realmof application software.
Ideally, software can be both learnable and
expressive.[Eisenberg1991] Whilethis line of argument
couldbe pursuedat length, the point worthmakinghere is
that expressiveness is the morefundamentalvalue for
long-termapplications: the question of whethersoftware
is learnable should be viewedas ancillary to the deeper
question of what one can do, eventually, with the
software. Andagain, the issue of timing is crucial:
expressive softwarecan and should be designedto foster
life-long passions, life-long development,
anda sense of
contemplation (or what Norman[1993] refers to as
"reflective cognition"), evenif this shouldcomeat some
cost in immediate
gratification.
The Frantic Culture of Software Development
Thebrief discussion of the previoussection admittedly
caricatures manyof the design questions surrounding
application software. But the issue of time frame does
come upmsometimes vividly~when looking at
descriptionsof currentapplicationsoftware.At least a half
dozenmonthlymagazinesare nowin large part devotedto
softwarereviews,and someof these reviewsare telling.
Onerecent magazinereviewof a paint programnoted that
the latest release of the program
hadadded70 newfeatures.
Other reviews from the past several months’ crop of
magazinesinclude the following statements:
extensive feature sets. Programs are comparedto their
competitors (and to their previous incarnations) according
to how many new featureshave been included;
presumably,
themorethebetter.
Clearly
someof these
features
willprove
useful;
butcollectively,
theysignal
a
troubling
trendin thedevelopment
of collaborative
applications.
Ontheonehand,
theypromote
a style
ofuse
inwhichtheendless
exploration
of newfeatures
takeson
moreimportance
thanthepatient
creative
mastery
of an
expressive
mediumlendingitselfto abstraction
and
composition;
at thesametime,theydistract
designers’
attention
fromthemorefundamental
taskof construcing
toolsthatofferthepossibility
of long-term
growth,
education,
andcreativity.
Theimpression
ostensibly
conveyedby the popularcomputer
pressis one of a
plethora
of ever-expanding
choice;
yetthefeeling
that
results
isonenotofpossibility
butofoverload,
similar
to
thefrantic
portrait
of multichannel
cabletelevision
portrayed
by [McKibben
1993]:
"XyWrite4.0... offers improvementsin performance
and dozens of new commands and ease-of-use
features." [PC WorldMay93 p.82]
"Publish It[ Easy is an entry-level desktop-publishing
program packed with page-layout features you’d
expect to find only in packages costing three times
the price... [It] offers a wider range of paint and
drawing tools than in previous version..." [Mac
Computingspecial issue 1993]
"The latest version of Theorist features several
important enhancements... In addition to adding
support for tables, the new version of Theorist
provides QuickTime support... Other new features
include support for Fourier transforms and Bessel
functions, the ability to create scatterplots fromtables
and matrices, and the ability to customize the
appearance of notebooks with different fonts."
[MacUserJune 1993]
"Type A personalities are five times as likely to
have a secondheart attack, according to Otto Wahl,
the psychiatry
professor at George Mason
University. Following vertical roasting on the
Spanik Vertical Roaster, a chicken can be~ism
carved with a carrot.
In Czechoslovakia,
Ambassador Rita Klimova tells C-SPAN, the
newly emerging democracy has spawned dozens of
political parties, including one for beer drinkers.
Sesame Street is brought to you this morning by
L, S, and 6. Only 11 percent of Americansfeel the
penny should be banned..."
"MacProject Pro is a significant
upgrade to
MacProjectII, providing tools for better organization
and entry of data, enhanceddisplay capabilities, muchimproved resource management, more-sophisticated
scheduling features..." [MacWorldMay1993]
Depending on one’s viewmmaybedepending on one’s
moodmthereis good news or bad in these reviews. Onthe
one hand, they reflect an astonishing pace of development
in application software, and a similarly astonishing
outpouring of creativity in design. Andperhaps they can
also be viewedas representative of an ever-growingrange
of possible activities for computerusers. But there is a
disturbing note as well, a frantic and unreflective note:
will the ninth iteration of our paint programeventually
include 500 more features, and if so how will we ever
accommodate them into our own work? And will those
500 newfeatures really improvethe software, and really
improve our understanding of graphics or design or
whatever---or will they simply overwhelm us with
choices that we can never explore? Might it be that the
accretion of features, motivatedin part by the needto sell
ever-newer
versions
of software,
proves
counterproductive
forthelong-term
user?
It maybe worth returning once more, briefly, to the piano
analogy. Would we really be better off if, every ten
months, a new version of the piano was introduced--a
new version largely incompatible with the previous one,
and manymore options added? Could such an environment
foster another Beethoven?Or--to put the question another
way--would the pace of this production really be
compatible with the pace of humancreative development?
The current culture of software development places a
heavy emphasis on the elaboration of large, varied, and
22
Programmable Design
Environments
In our laboratory at the University of Colorado, we are
currently developing prototype applications whose
purpose is to address (amongothers) the issues raised
the previous discussion. These programmable design
environments are intended to integrate aspects of
programmability,direct manipulationinterfaces, critiquing
and design rationale capabilities, and supportive learning
environments.[Fischer and Eisenberg 1992] The first of
these applications is a graphical design system primarily
aimedat the creation of charts and information displays;
the secondis an application for the design and simulation
of local-area computernetworks.
Thesetwo applications
are designedas modelsof
collaborative software in whichthe computersystem takes
on certain specific (and, we believe, appropriate) roles:
presenting a learnable (and aesthetically attractive)
interface, a full-ficdged programmingenvironment, a
catalog of previous work done with the application, and
critiquing/tutorial componentsthat act both to help users
in coping with the complexity of the domain (graphic or
network design) and with the complexity of the
application. Because these applications are designed to
include domain-specific programming environments as
well, they likewise address the issue of expressiveness
mentionedearlier. (Cf. the argumentsin [Nardi 1993].)
presenting the user with a programmingenvironment
enrichedwith appropriateprimitive proceduresandobjects
as building blocks, these systems allow the user to
develop a personalized vocabulary that can grow in
complexity over time--conceivably (and ideally), over
lifetime. (The portrait of the programmingprocess
suggested by these applications is consistent with the
picture of "metalinguistic abstraction"-- of using
languagesto build still other domain-enriched
languages--eloquently articulated by AbelsonandSussman[1985].)
Ourgraphic
design
application--whose
current
prototype
is builton topof theSchemePaint
system[Eisenberg
1991]--includes
a (still
rudimentary)
direct
manipulation
interface
forselecting
thetypeof chartthattheuser
wishes
tocreate
(e.g.,
barchart,
linechart,
scatter
plot,
andsoforth);
having
selected
thistypeofchart,
theuseris
abletolookat a variety
ofrelevant
examples
built
using
thesystem,
andemploying
language
primitives
(embedded
in theSchemeprogramming
language)
appropriate
to
building
thisparticular
kindofchart.
Forinstance,
a user
whowishes
tocreate
a barchart
ispresented
witha palette
showinga variety of "specialty" bar charts (multicolored
bars, bars with non-horizontal uppermostlines, bars
going aboveandbelowthe horizontalaxis, etc.); the user
can then access a languagetutorial specifically gearedto
this particular type of chart (e.g., whatlanguageformwas
used to create this particular sample), and can access
additional tutorials on the properuse and critiquing for
this type of chart (that is, whenthis sort of graphmight
be useful, or counterproductive,and why). In presenting
the user with a variety of examples (chosen for their
pedagogical or illustrative value), the application is
supplyingsomecontext-driven"feature"presentation; that
is, the system is providing the user with some
(presumablypopular)alternatives for creating newcharts.
Onthe other hand, becausethe systempresents not merely
a choice of existing styles of work,but rather an extensive
programming
environment, it gives the user the (more
difficult but ultimately more powerful) option of
developing new types of charts on his or her own;
moreover, it provides the user with assistance in
developingexpertise in the system-suppliedlanguage.
l% File Edit CommandWindow General Turtle
Color Bar Chart Examples
¯ MAKE-SIMPLE-COLOR-BAR-CHART
categories
values
colors
Usedformaking
a (simple)
multlcolor
barchart.
JExample:
(defineCOLOR-eARCHART
(MAKE-SIMPLE-COLOR-BAR-CHART
’(’dogs""cats")
’(1520)
Help
9:33Pld
SchemeChart
[o,?)
i
......T.....
....! ......
!..................
i..................
................................................................
i
i!
i
i
Sampl
HI ’
Graph
Pen
Iii,rl!~"
!I
t
i
fill .....?......
proc
i
click
i
I
p,,iXx<>
I"." ®?
.......................
i ........................................
..........................
i .............................................
]
.......?......
!
o, ~oo
.........................
i..............
i.............
]
[3, 0,:Off
Figure 1. A screen view of the graphic design application. Chartsare created in the SchemeChart
windowat bottomright;
the Pen windowprovides standardpaint tools; the Graphswindowprovides an overviewof standardchart types fromwhich
to choose; and, for a given graphchoice, a catalog of specific examplesis providedin the Sampleswindow.Finally, the
transcript windowat top provides an "application-enriched"Schemeinterpreter. [The systemis written in MacScheme
(Lightship Software,MountainView,CA)andruns on all AppleMacintoshcomputers.]In this figure, the user has selected
particular type of bar chart andhas used a menuoption to access relevant programming
examplesfor this type of chart; the
examples are shown in the windowlabelled Color Bar Chart Examples.
23
Figure 1 depicts a screen view of the application in the
course of a typical chart-design task: here, the user has
employedthe iconic catalog of bar chart designs (in the
Samples windowat bottom left) to select a particular
type of bar chart. She then uses a menuselection to
bring up a window in which a number of relevant
language forms--procedures that can be used to generate
this type of chart--are illustrated.
By editing and
evaluating these examplesdirectly, the user can create her
owncharts as modifications of the existing types; after
acquiring greater expertise with the language, the user
can ultimately access the definitions of these language
forms and create new types of charts within the
application.
"queried" the vertical axis of a newly-created graph; and
the systemresponds with a (still rather skeletal) list
procedures that are especially useful in altering chart
axes. (This feature is very similar to the example-driven
software-reuse system of Redmiles[1993].)
The second application--for network design--is built in
Repenning’s Agentsheets system [Repenning 1993] and
HyperCard, and will likewise include a programming
environment for simulation of networks; the current
prototype focuses on providing a rapid, computer-assisted
construction environment for network models (the
Agentsheets portion of the system), and on providing
tutorials in the theory of networkdesign (the HyperCard
portion of the system). Indeed, in both these applications
there is an emphasison the notion of learning on demand
[Fischer 1991] within the system; the applications are
created to encouragea seamless transition betweendesign
work (e.g., the user creating a network or chart) and
progressive learning about the system and the domain
(through catalogs, critics, and embedded
tutorials).
Figure 2 shows another technique for exploring the
language environment within the application; here the
user has selected "query mode"(the question markicon in
the Graphs window), which allows the user to select
graph elements from an already-created graph and to
access procedures relevant to the creation or change of
those graph elements. In the figure, the user has
File
Edlt CommandWindowGeneral Turtle
transcript
Help
946pi,I ,~ "
> > > ( p I o t.-char teo I or-baPehar"t I
done
Axls-Related Procedures
change-axis-length
expand-axis
shMnk-axls
change-axis-color
change-axls-sta~-pt
change-axts-end-pt
5.?04..- i
4..56~.
3.422,,
Y
Sampl
Graph
2.282,
Pen
fill
pFoc
1.141.
click
0
,.I
7,og’lt, do~lgO0
T
X
I.o$ liter 1’900
Figure 2. Here, the user has selected "query mode"(the question mark icon) from the Graphs window.By dragging the
mouseover a particular element of the newly-createdgraph(in this case, the y-axis), the user can access a list of language
proceduresrelevant to the manipulationof this element.
24
Acknowledgments
The work described in this paper was supported by NSF
grant MDR-9253425and by NSF Young Investigator
Award IRI-9258684. The author also gratefully
acknowledgesthe influence of Harold Abelson, Gerhard
Fischer, Clayton Lewis, and Gerald Sussman,as well as
that of the Human-ComputerCommunications group at
the University of Colorado.
HyperCard.(software) Apple Computer, Inc. Cupertino,
CA.
Kay, A. In Watch What I Do, A. Cypher, ed. MITPress,
Cambridge MA. 1993
Laurel, B. Computers as Theatre.
Reading, MA.1991.
References
McKibben, B. The Age of Missing
Penguin Books, NewYork 1993.
Abelson, H. and Sussman, G. with Sussman, J.
Structure and Interpretation of ComputerPrograms. MIT
Press, Cambridge, MA1985.
Addison-Wesley,
Information.
Nardi, B. A Small Matter of Programming. MITPress,
Cambridge, MA1993.
Crockford, D. "Integrating Computersand Television."
In The Art of Human-ComputerInterface Design, B.
Laurel, ed. Addison-Wesley,Reading, MA1990.
Norman, D. Things That Make Us Smart. AddisonWesley, Reading, MA1993.
Oren, T. "Designing a NewMedium." In The Art of
Human-Computer Interface Design, B. Laurel,ed.
Addison-Wesley, Reading, MA1990.
Eisenberg, M. ProgrammableApplications: Interpreter
Meets Interface. MITArtificial Intelligence Laboratory
Memo1325, October 1991.
Redmiles, David. "Reducing the Variability
of
Programmers’ Performance Through Explained
Examples." Proceedings of lNTERCHI’93, Amsterdam.
Fischer, G. "Supporting Learning on Demandwith
Design Environments."
In Proceedings
of the
International Conference on the Learning Sciences,
Evanston, IL 1991.
Repenning, A. "Agentsheets: A Tool for Building
Domain-Oriented Visual Programming Environments."
Proceedings of lNTERCH1
’93, Amsterdam.
Fischer, G. "Beyond Human-Computer
Interaction." To
be published in Mensch-ComputerInteraktion auf dem
Wegin die industrielle Praxis, H-D. Boecker and T.
Strothotte, eds. Springer-Verlag, Heidelberg, 1993.
Rheingold, H. Virtual Reality.
1991.
Fischer, G. and Eisenberg, M. "Programmable Design
Environments." University of Colorado Computer
Science Technical Report CU-CS-620-92.October 1992.
Touchstone, NewYork
Winograd, T. and Flores, F. Understanding Computers
and Cognition: a NewFoundation for Design. Ablex,
Norwood, NJ. 1986.
Friedlander, L. "The ShakespeareProject." In Interactive
Multimedia, S. Ambronand K. Hooper, eds. Microsoft,
Redmond WA1988.
25