APPLYING ACTIVITY THEORY IN THE

DESIGN OF USABLE SOFTWARE:

HOW PERSONAL BELIEFS SHAPE THE USE OF TOOLS







A THESIS SUBMITTED IN PARTIAL FULLFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF ARTS
IN
INTERDISCIPLINARY COMPUTER SCIENCE











Barton Friedland
October, 2006
ii


2006 Barton Friedland
All Rights Reserved.
a ^ ^ - ^ - . ^ - l l - r r z .
n I J I , r v v s u v J r
n ^ ^ - ^ - ' ^ - . i l . r r r .
n P P ! u v s u
p J .
l n n r a r r a r i h r r .
n I J I J ! v
Appr oved by:
n ^ ^ - ^ - . ^ - l 1 - r r r .
n P P ! v v s u v J .
Chr i s Br own, I nt er di sci pf i nar Y
Pr o f e s s o r o f Mu s i c /
co- Di r ect or of t he Cent er f or
Mi l f s Cot l ege, Oak. l and
Advi - sor
Cont empor ar y Mus. r c
ef r nudena Konr ad, Comput er Sci ence Advi sor
and Comput er Sci ence
Depar t ment of Mat hemat f cs
Mi f l - s CoI l ege' oakl and
El f e n Sp e r t u s ,
n a n a r f mo n j - o f
Mi f l s Co l l e g e ,
Mar i anne Shef don, Di r ect or
Mi f l s Col l ege/ Oakl and
of Gr aduat e St udi es
Pr i mf r y Comput er Scr ence
Mat hel nat i cs and Comput er
Oak l and
.J U_L.r e
Depar
r Sci ence Advi sor
Sc. r ence
anf or d
1[
To the spirit of learning


v






If the artist does not perfect a new vision in his process of doing, he acts
mechanically and repeats some old model fixed like a blueprint in his mind.
John Dewey, Art as Experience
vi
Table of Contents
Table of Contents...........................................................................................................vi
List of Figures .............................................................................................................. viii
Acknowledgements ....................................................................................................... ix
Abstract ......................................................................................................................... xiii
1 Introduction ............................................................................................................. 1
1.1 A General Problem .......................................................................................... 1
1.2 Scope .................................................................................................................. 2
1.3 Consequences ................................................................................................... 5
1.4 Research Approach.......................................................................................... 6
1.4.1 Ethnography and Grounded Theory .................................................. 10
1.4.2 Activity Theory....................................................................................... 12
1.5 Motivation for the Study............................................................................... 15
1.5.1 The Four Hats of Creativity.................................................................. 16
1.5.2 Commandline vs. GUI modes of computer use............................... 18
1.5.3 Working Assumptions .......................................................................... 21
1.6 Goals ................................................................................................................ 23
2 Data Analysis: Phase 1 ......................................................................................... 24
2.1 Basic Population Statistics ............................................................................ 24
2.2 Initial Impressions of SuperCollider 3.0..................................................... 25
2.3 What worked in SuperCollider 3.0.............................................................. 27
2.4 Suggestions to improve SuperCollider 3.0................................................. 28
2.4.1 GUI Requests .......................................................................................... 28
2.4.2 Starter / Example Kits............................................................................ 30
2.4.3 Assessment of Suggestions................................................................... 30
3 Implementation of Test Interface ...................................................................... 31
4 Data Analysis: Phase 2 ......................................................................................... 35
4.1.1 Response to SC Busy Box...................................................................... 35
4.1.2 When Beliefs Conflict ............................................................................ 37
4.1.3 Aptitude versus Belief............................................................................... 38
4.1.4 Assessment of Beliefs is Vital for User Acceptance ................................ 39
4.1.5 A Key Factor in Large Scale System Adoption Failures................... 39
4.2 Characteristics of Successful Adopters of SC3 .......................................... 41
4.3 Results of Phase 2 Quantitative Time to Completion Tests..................... 43
4.3.1 Overturning of the Dominant GUI Paradigm........................................... 45
5 Conclusions............................................................................................................ 47
5.1.1 Future Work.............................................................................................. 49
6 References............................................................................................................... 50
7 Appendix A Sample Interview Protocol for Informants............................ 54
vii
viii
List of Figures
Figure 1 Basic Structure of an Activity (Based on diagram by Kuutti)............... 14
Figure 2 The Four Creative Hats (Artist: Rich Gold) ......................................... 177
Figure 3 Class Diagram of TX Modular Framework ........................................... 32
Figure 4 Modification of TX Mod Framework........................................................ 33
Figure 5 Standard SC3 Programming Environment.............................................. 34

Note: Where not noted otherwise, images in this document were created by the
author.
ix
Acknowledgements

This thesis actually started long before the formal project of the thesis
began. Its roots are in previous work and relationships that were built when I
started my efforts to pursue the discipline of computer science.
Several people, some of whom are actually on my thesis committee, have
been instrumental in guiding not only this thesis, but in helping me to acquire
the skills and knowledge that are being exercised through this thesis.
I would like to thank the first person I reached out to and who has stayed
by my side throughout this entire process: Julie Zelenski. People like Julie, who
combine intelligence, enthusiasm, and a good heartedness toward others, are a
real gift. It is no understatement to say that without her I never could have gotten
where I am today.
Following a sequential order of people who have supported my efforts to
acquire knowledge, I would like to thank Terry Winograd for welcoming me into
his world, supporting my efforts, and introducing me to so many people who
have influenced and changed my life, including the late (great) Rich Gold, Robert
Horn, and Victoria Bellotti.
Rich taught me that it is possible to boldly and successfully span several
disciplines. His memory gives me hope that I too, can innovate from my unique
x
perspective on the world. Robert Horn showed me that what we see is reflexively
tied to how we think and his tireless support, vision, and friendship has carried
me throughout this process. Victoria Bellotti demanded that I do field research,
which turns out to be a fundamental aspect of this thesis; one of which I am
extremely proud. Victoria has also been extremely generous with her time,
reviewing drafts of this thesis despite her many other commitments. I am
extremely grateful for her guidance and support.
Jerry Cain has given to me exponentially. He has been a great friend and
the very best teacher I could ever hope to have in what some find to be an
unfathomable discipline. Maggie Johnson has also given me tremendous support
and encouragement when I was taking my first steps. It is due to both Jerry and
Maggie that I can attribute the good fortune I have had to also have been a
student at Stanford.
Mehran Sahami is the recipient of my recurring theme award for always
being there at a distance. He helped me in my first days with discrete math and
introduced me to the extraordinarily talented Diana Ly, who took time to
personally tutor me when I was a CS toddler.
Going back to Julie Zelenski for a moment, I should acknowledge that it
was also Julie who suggested that I might want to look at Mills College, which, in
her words, also provides a worldclass CS education.
xi
And so I trekked across the Bay to visit Dr. Ellen Spertus, whose office
looked like an explosion of computer parts and lego pieces, and whose
memorable words, ...if you come to Mills you will build your own computer
were all I really needed to hear to know that I had found the right person and
place to study computer science.
I knew even then that this very special woman was the very best teacher I
could possibly find. I am so very grateful to her for all of the hours sitting by my
side debugging and explaining. Her tirelessness in answering my neverending
questions, her incredibly honorable and disciplined sense of values, and her
inexplicably dry sense of humor have all given me a much richer understanding
of what it means to be a true hacker and computer scientist. I will also add that I
did build that computer with wires, chips and breadboard, which was one of the
singly most enlightening experiences in this process.
I am also very much in debt to Susan Wang, Almudena Konrad, Chris
Brown and all other Mills faculty who have provided me with such a wonderful
learning environment and have given me so many valuable skills and
experiences.
I would like to thank Mike Dillinger for his support in helping me take my
interview data and turn it into solid scientific theory and for his support in
xii
helping me structure this thesis. Thank you, Mike, for sharing your knowledge
and abilities so freely.
On a personal level, I would also like to thank my friends and family. I
would like to thank my parents. I could not have been able to do this without
their support. Thank you for believing in my dreams. I want to thank my
partner, Bruce, who has stood by my side even when I asked him to be quiet
because I needed to do my homework. I want to thank my dear friend Charlie,
who really should have been a computer scientist, for all of his help with my
schoolwork and for his support in all of my efforts. I also extend a very special
thanks to my brother, Jon David, who, despite how busy he is with the details of
his life and work, chose to pore over several early drafts of this thesis and was
extremely helpful in bringing about much improvement in form and style. And
finally, a most special and heartfelt thanks to my friend Marina LaPalma, whose
incredible understanding of the relationship between art and science has
broadened the scope of this thesis and helped me to be able to explain to you,
gentle reader, the very delicate line those of us who mix art and science must
walk each day of our lives.
xiii
Abstract

The general problem of tailoring software to individual differences is an
important issue with broad ramifications in software engineering and interface
design. In order to better understand this problem within a specific context, I
conducted an ethnographic study of a group of users who are involved as artists
in making electronic music with software. The study was motivated by the desire
to develop a more extensible system that could be customized through a GUI.
While I was unsuccessful at finding a general design that satisfied most of the
users, I found a number of interesting results. The findings presented in this
thesis are useful for interface designers and those in the HCI field and are
summarized as follows: 1) the study shows a chasm between what users think
they want and what they actually want; 2) the categorization of users into roles
with associated usage habits does not hold as a predictor for usage preferences;
3) the wellestablished Pareto principle, or 80/20 rule, did not seem to apply in
this study: no solution that required 20% of the population to share a consensus
came close to providing a complete solution for 80% of the users in the group. In
addition, I found that the use of activity theory as a method for data analysis in
the ethnographic study provides access to vital information that other methods
may not capture.
xiv

1

1 Introduction


1.1 A General Problem

Regardless of how many features a software application provides, there
eventually comes a moment where the user of that program tries to do
something that either the program will not do, or, which they can not figure out
how to do even though the software is completely capable of doing what the user
wants. I refer to this problem as the boundary of usability.
People and organizations develop software for a variety of reasons.
Motivators include personal interest, company directives, market research, and
results coming from scientific testing. Some efforts result in software that better
serves the needs of the users for whom it is designed than others.
Yet, any software, regardless of how well it meets the needs of the set of
users for whom it was designed, will eventually be encountered by some user in
that set who finds it does not meet her needs. Minimizing the number of these
disempowered users is an important goal in system design.
The general problem of designing and implementing a software package
which meets the needs of the largest possible number of its users is a continually
2
present goal faced by any entity that develops software. It is an extremely
important issue with very practical implications. I refer to this issue as one of
general adaptability throughout this thesis.
1.2 Scope

A few specialized solutions for designing software based on user
differences exist. For example, methods to localize software for various
languages are wellestablished such that the creators of applications can
systematically plugin different languages to an application without having to
rewrite the entire application from scratch for each language.
If languages were the only differences between users, the scope of the
problem would be small indeed. But people are diverse and their differences
great, resulting in a problem whose scope is exceptionally broad.
The problem is so widespread that many feel computers cause more
problems than they solve. Upon receiving the Turing Award, the highest award
granted in the field of computer science from the Association of Computing
Machinery (ACM), Edsger Dijkstra, in his 1972 recipient lecture, claimed that:
...the electronic industry has not solved a single problem, it has
only created them it has created the problem of using its products. To
put it another way: as the power of available machines grew by a factor of
more than a thousand, societys ambition to apply these machines grew in
3
proportion, and it was the poor programmer who found his job in this
exploded field of tension between ends and means. [8]

Spector and Wang, two researchers who have explored issues relating to
integrating technology into learning environments, support and expand the
scope of Dijkstras claim:
the problem raised by Dijkstra in 1972 in the context of software
engineering remains one of the central problems with regard to learning
environments and performance technologies. [40]

Artist and Scientist Rich Gold, a former member of the Xerox PARC
research project on ubiquitous computing [45, 46], also spent a great deal of time
and effort looking at the issue Dijkstra raised. In Golds book, The Plenitude, he
generalized the problem even further, applying it not specifically to computer
technology, but to the process of problemsolving in general. Gold framed the
problem as Desire in Context [14], where proposed solutions can be seen as the
paths from a particular context to a particular desire. Under this view, upon
implementation of a solution, the context changes, spawning many new desires.
Gold provides an example:
The Ramifications of the Solution called the Golden Gate Bridge are
many. For instance, there is Smog, which is caused when large numbers of
cars act to satisfy the Desires of their owners. Large numbers of vehicles
4
also creates Traffic Jams which, at times, can make it so slow to go over
the Bridge that desire once again becomes Desire. Engineers all over the
world are trying to find Solutions to Smog and Traffic. [15]

For Gold, the problem is not one of technology, but lies instead in the
nature of problemsolving in general; all solutions create new desires and
problems, many of which cannot be identified until the solution has been
implemented.
Entire disciplines, such as humancomputer interaction (HCI) have been
formalized to address the problem of general adaptability within a very specific
context: how to optimize interaction between humans and computers.
In this thesis, I am focusing on the HCI context of usability rather than
Golds more general view. It is important, however, to note that the HCI problem
is not simply one of usability; as usability, in turn, affects other areas such as
learning and performance.
Users who employ software in one fashion at a particular point in time
may at some future point gain some experience, understanding, or insight that
may cause them to move from one mode of usage to another. If the software does
not work they way they want or expect at that future time, the user may decide
that the software no longer meets their needs.
5
1.3 Consequences

The consequences of not having more solutions to the problem of general
usability are significant. Without more solutions, software will continue to be
produced whose features go untouched because users do not know where to find
them or how to use them. Users of software A may become so frustrated with
it that they may switch to software B to accomplish the same task. These users
may feel that software B works better for their needs than software A.
While there are clearly monetary issues at stake for commercial entities
whose software does not meet the needs of its users, another key consequence is
loss of productivity for the individual. Consider software that is designed to help
people learn. If it does not help some of the people, for whom it was designed, to
achieve their goals, this represents a loss in human growth, which may or may
not be monetized.
The consequences of this problem are indeed widespread and far
reaching.




6
1.4 Research Approach

Any model of the world provides a frame of reference, a perspective, a
lens through which to view events. Applied to the same set of observations,
differing models predispose one toward differing conclusions and consequences.
Marxism, Feminism, Christianity, Science, Zen Buddhism; each provides such a
model.
Carol WilderMott Rigor & Imagination

I employed an interdisciplinary research approach explore solutions to the
problem I have been describing. I decided to focus on one particular software
package and one set of users using that software as a basis to research possible
solutions.
A qualitative research approach, the ethnographic study [1113] from the
social sciences, was applied to collect data. I chose to employ activity theory [23,
33, 44] as a framework to analyze the data collected in the ethnographic study.
Activity theory is a general conceptual approach used to understand human
activity, derived from the discipline of human psychology, and has been
successfully employed in recent HCI research [5, 7, 10, 17, 19, 20, 29, 32, 33, 36, 39,
50].
The selected software was SuperCollider3 (SC3) [28]. SC3 is an open
source audio signal processing system written by McCartney et al. Interaction
7
with SC3 is primarily via a commandline interface along with the use of its
Smalltalkderived [18] programming language sclang. Like the programming
languages LISP [27] and Scheme [1], SC3 features a runtime environment where
statements are interpreted as soon as the user presses the enter key, allowing for
a flexible and dynamic programming environment where the user can make
changes to the system while it is running by executing additional code.
SC3 is used at Mills College as well as many other academic
environments. At Mills, it is employed as part of a curriculum designed to
support students in learning how to create musical instruments using software.
Creating and performing music may follow from this, but the creation of
software instruments by themselves is the primary goal.
I studied electronic music students enrolled in Mills Colleges Fall 2004 or
Spring 2006 Graduate Seminar in Electronic Music class, faculty members from
the Mills Center for Contemporary Music (CCM), and musicians from outside of
Mills who use SC3 in their work.
Under the approach I chose, the participants are referred to as informants
because their role is to actively inform the researcher. This is in contrast to the use
of the term subjects for experimental studies, where subjects are subjected to
certain experimental conditions and observed [34, 35].
8
Using an activity checklist developed by Kaptelinin, Nardi, and Macaulay
[17], I developed a set of domainspecific topic areas and questions (see
Appendix A) that I posed to each informant. Interviews were conducted in two
phases, separated by an implementation phase where a test interface was
assembled before proceeding with further research.
The first phase of interviews was designed to gather details about the
informants, as well as their musical backgrounds, technical experiences,
preferences, and interests. Questions about sound creation, composition,
arrangement and performance, as well as their ideas for the ideal SC3 interface
were also posed.
The phase 1 interviews were then analyzed and used as a basis to attempt
to generalize the requests of the informants and assemble a user interface that
contained many of the common features that were requested. This interface was
then presented to the informants and tested as part of a second phase of
interviews, where, in addition to gathering information similar to what was
gathered in the phase 1, the informants were presented with several tasks to
perform using both a test user interface and the standard commandline interface
in SC3. These tasks were timed and observations were made about the
informants as well as feedback solicited from them about their experiences in
working with these two very different approaches to interaction.
9
Some of the informants who participated in the phase 2 interviews had
also participated in phase 1. This provided an opportunity to checkin with these
informants regarding what work had been accomplished in the interim, and
what goals had been achieved. Phase 2 also provided an additional chance to
gain a broader perspective about the informant by exploring what had changed
between the first and second interview.
The style of the interview was conversational; if an interesting
conversational thread arose in the interview, it was opportunistically followed.
Whenever possible, interviews were conducted at the informants studio or
workspace, so that the tools used to make their music were at hand [43].
Electronic audio recordings were made of all interviews.
During a typical interview, I explained that the purpose of the study was
to look at ways to improve the usability of the SC3 system and to learn what was
involved in making electronic music, what sorts of software the informant used
for this task, and what reasons the informant had for using or not using certain
software. Rather than strictly following the list of questions, I allowed
conversation to flow naturally but made sure all topic areas were covered.
Interviews ranged from 13 hours per informant. In total, 23 informants were
interviewed over a 13 month period.
10
1.4.1 Ethnography and Grounded Theory

In anthropology, or anyway social anthropology, what the practitioners
do is ethnography. And it is in understanding what ethnography is, or more
exactly what doing ethnography is, that a start can be made toward grasping
what anthropological analysis amounts to as a form of knowledge. This, it must
immediately be said, is not a matter of methods. From one point of view, that of
the textbook, doing ethnography is establishing rapport, selecting informants,
transcribing texts, taking genealogies, mapping fields, keeping a diary, and so on.
But it is not these things, techniques and received procedures, that define the
enterprise. What defines it is the kind of intellectual effort is: an elaborate venture
in, to borrow a notion from Gilbert Ryle, thick description.
Clifford Geertz The Interpretation of Cultures

Ethnography is a qualitative approach to research, normally applied to the
disciplines of cultural or social anthropology, used to explain human social
phenomena. Many canonical texts written by luminaries of anthropology such as
LviStrauss, Margaret Mead, Bateson, and Malinowski employ an ethnographic
approach [47].
An extension of this approach, grounded theory [42], was conceived by
Glaser and Strauss as a model for research that would resolve one of the key
problems in social science: how to research the personal, or, using the term
introduced by Suchman, situated [43], views of others without superimposing the
11
nonsituated personal view of the researcher. Addressing this particular problem
involves two separate goals: avoiding the testing of a hypothesis and remaining
at a descriptive level.
According to Glaser and Straus, the danger of hypothesis testing through
a scientific model is that the view either fails to include what is relevant or
removes essential differences through the use of statistics. Conversely, they state
that the danger of description is that it is ambiguous, too localized, or produces a
description of value only to subjects. Grounded theory proposes a research
methodology that remains grounded in the conceptual structures held by the
subjects but still produces a descriptive theory that can be used to understand
and sometimes predict the reaction of these and similar subjects to future change.
Several researchers within the field of human computer interaction,
including areas such as usercentered design, human factors in computing
systems, and computer supported cooperative work (CSCW), as well as the field
of bioinformatics, have successfully applied the principles of grounded theory in
their work [2, 3, 25, 34, 35, 37, 38]. The majority of these researchers refer in their
work to a research approach based on the principles of grounded theory
synonymously with the term ethnographic study.
An important aspect of this type of research is that the informant is
providing a description of their perception about their experience. This is
12
especially important to take into account when undertaking this type of research
where any type of selfappraisal takes place. An informants perception is not
necessarily an accurate measure of that informants true abilities but instead their
idea. To obtain accurate performance measures, other methods must be employed
[49].
The research in this thesis was carried out under the abovementioned
principles for a number of reasons. Foremost among these was the desire to
develop a deeper understanding of the usage scenarios and patterns of the users
that were studied. Additionally, a fundamental notion of grounded theory states
that the theory should emerge from the data [42], which provides a foundation
from which a much broader theoretical net can be cast. Without presupposing a
theory, the researcher is less predisposed to focus on aspects of the data that
match what is in alignment with the hypothesis, incorporating data that may not
have caught his or her attention otherwise. Finally, in seeking outside advices
from experts in the field, such as Victoria Bellotti and Bonnie Nardi, this
approach to data collection came highly recommended.
1.4.2 Activity Theory

Ethnography provides an approach to collect data; however, as an
approach it does not provide the clearest direction with respect to the issue of
how to view or interpret data that has been collected. Activity theory is
13
championed as a framework for the analysis of ethnographic data in HCI
research by Kari Kuutti [20], Bonnie Nardi [33] and others.
Alexei Leontiev, based on earlier work by Lev Vytgosky, originally
developed formal activity theory in the domain of Psychology. It was Vytgosky,
however, who proposed its seminal research direction in 1934. Vytgoskys key
insight was based on the premise that despite the existence of various methods of
research to study distinct functions of consciousness, consciousness is a unified
construct and that the:
single functions were assumed to operate inseparably, in an
uninterrupted connection with each other. But this unity of consciousness
was taken usually as a postulate, rather than as a field of study. [44]

As Nardi puts it:
The object of activity theory is to understand the unity of
consciousness and activity. Activity theory incorporates strong notions of
intentionality, history, mediation, collaboration and development in
constructing consciousnessactivity theorists argue that consciousness is
not a set of discrete disembodied cognitive acts (decision making,
classification, remembering), and certainly it is not in the brain; rather,
consciousness is located in everyday practice: you are what you do. And
what you do is firmly and inextricably embedded in the social matrix of
which every person is an organic part. This social matrix is composed of
people and artifacts. Artifacts may be physical tools or sign systems such
14
as human language. Understanding the interpenetration of the individual,
other people, and artifacts in everyday activity is the challenge activity
theory has set for itself. [33]


When Nardi tells us that activity theory proposes a strong notion of
mediation [33], she means that the various components of an activity (Figure 1)
are shaped through the interactions of the various components of that activity,
such as a subject, its object, the tools, the rules, a community, or a division of
labor. Activity theory thus provides a multidimensional approach to interpreting
data by allowing the researcher to view the informant data through any of the
components of activity theory. As a method for interpreting qualitative
Figure 1 - Basic Structure of an activity (Based on diagram by Kuutti)
Artifacts / Instruments / Tools
Subject
Rules
The Structure of an Activity under Activity Theory
Community
Division of Labor
Object
Outcome
Transformative
Process
15
ethnographic data, activity theory allows for a wide set of interpretations of the
data that include, for example, the relationship a subject has to a community and
its rules that other data analysis approaches could easily overlook. For these
reasons, activity theory was selected as the method for interpretation of the
ethnographic data collected as part of this research.
1.5 Motivation for the Study

The motivations for this thesis are borne out of my personal experiences
and perceptions. These can be traced from two primary sources. The first is an
abstract notion of the roles people play when engaging in particular disciplines and
the boundaries between these roles. I am continually fascinated with the fact that
while people come from diverse backgrounds, some people involve themselves
in multiple disciplines while others choose to focus on a particular area. My
interest is in how these choices affect the structure of a personal identity and
accompanying preferences. I argue that personal identity and preferences have a
great deal to do with whether people use computers at all, and, if so, what kinds
of software they prefer to use to do their work, and how flexible or interested
they are in learning new tools. The second motivation comes from my experience
as a student at Mills College where I observed a range of students with
16
seemingly similar abilities, some of whom did quite well, while others struggled
with the material. I describe these differences in detail below.
1.5.1 The Four Hats of Creativity

A primary motivating factor for this work comes from a lecture that I
attended on October 11, 2002, and which took place at the ongoing Stanford
Seminar on People, Computers, and Design entitled Desire in Context [14]. At this
lecture, Rich Gold discussed his notion of the 4 hats of creativity (Figure 2) to
represent roles he played during his life. The four hats are also introduced in his
book The Plenitude as follows:
During my life I put on and took off four hats of creativity: artist,
scientist, designer and engineer. I think of each one as quite distinct with
its own methods, world views, precedents, predecessors, style of dress,
interior decorations, histories, vocabularies, alliances, likes, dislikes,
prejudices, tools, techniques and demeanors. I can walk into an office and
know immediately if it is a designers office or an engineers office. I
instantaneously know if it is an artists loft or a scientists lab even if they
are filled with the same digital tools. Actually it is only with great effort
that I have begun thinking about them as hats; in some real way, for me,
they are states of being as different as alligators and elephants. [15]
17

Figure 2 The Four Creative Hats (Artist: Rich Gold)

Since I attended that lecture, something about the relationships and
boundaries between the roles Gold described have remained dominant in my
thinking. I have been interested in exploring whether it was possible to recast
and broaden Golds strict occupational classifications while maintaining the
essential notion that peoples abilities do fall into categories marked by particular
styles of thinking, and, as a result, particular patterns of computer usage within a
category. I was to find in the research undertaken for this thesis that the truth is
far more complex than I had imagined.
18
1.5.2 Commandline vs. GUI modes of computer use

While it was not always the case, personal computer systems that present
and allow manipulation of information visually through a graphic user interface
(GUI) are currently dominant. Much has been written with respect to the role of
visual information and the ways in which these graphical interfaces can be
leveraged as part of the learning process [6, 7, 16, 48]. Still, debate continues as to
whether commandline interfaces are more userfriendly, and therefore
superior to their graphical counterparts [2022, 41]. My findings question this
assumption, pointing instead to the usefulness of the tool as a more significant
measure of superiority for a given task.
In my observations as a student in the Fall 2005 Graduate Seminar in
Electronic Music class in electronic music at Mills, there were several interesting
challenges I observed students facing in this environment that appeared to relate
directly to the issue of commandline vs. GUI usage. For example, the majority of
the students enrolled in that class had no formal programming background, yet
SC3s primary mode of interaction is through a commandline and its formal
programming language, sclang.
There are many GUIbased software synthesis systems available,
including MAX/MSP and Reaktor, which enable people to manipulate graphic
objects to program softwarebased synthesis. One of the aspects that makes SC3
19
particularly unique among softwarebased synthesis systems is the fact that is
exposes a powerful programming language. As will be shown, some students
find this to be a potent tool, enabling the expression of functions that can not be
expressed as clearly in a visual environment. However, it may be that only a
subset of students are capable of fully grasping these concepts if this is their first
exposure to a programming language.
I observed that for many of the students, this was apparently their first
introduction to the discipline of computer science, by way of electronic music.
This appeared to add a significant degree of complexity to the task of learning
the extensive capabilities found within SC3. These students also faced the
additional tasks involved with learning and applying the basics of programming
constructs such as assignment, arrays, hash tables, and conditional logic. It was
noted that students who came into the class with previous knowledge of these
concepts will be positioned better to apply these concepts towards the
construction of musical instruments in software.
An additional hurdle for many students in the class had to do with
grasping a conceptual model of signal flow theory and synthesis that SC3
abstracts through sclang. Many students, in addition to never working with a
programming language before, had also never studied any form of signal flow or
20
synthesis theory. These students appeared especially handicapped in their ability
to assimilate the course material.
I observed that if a student is not able to overcome the hurdles of learning
how to program as well as fully grasping the essentials of signal flow and
synthesis theory, they may well miss out on a rich set of learning opportunities
available within the SC3 environment. One simple solution to this problem could
be to require that all students take a basic programming class as a prerequisite
before the class where SC3 is taught. This would, at the very least, ensure that
students enrolling in this class do not spend a significant amount of their
precious time learning basic programming techniques. This approach carries the
disadvantage of excluding students who have not taken such a prerequisite.
Another approach, that this thesis explores, could be to provide some
higherlevel constructs such as a GUI which provides visual programming
functionality for those students for whom programming is still a new or
especially challenging domain.





21
1.5.3 Working Assumptions

These and other experiences led me to a set of working assumptions that
can be summarized as follows:
1. Users can be categorized according to certain behavioral traits,
which may be a predictor for certain kinds of computer usage
patterns;
2. Feature sets in software applications can also be categorized and
mapped to the same categories that describe the set of users;
3. It may be possible to employ assumptions 1 and 2 to generate an
approach for solving general adaptability.
4. Programs that employ GUIs as their primary interface are easier
for people to learn, especially those who do not have a
background in computer science;
5. Students who have challenges learning or mastering a command
line environment may have an improved learning experience by
dealing with a GUI to learn the fundamentals of electronic music.

Based on these assumptions and the initial results from the phase 1
interviews, I assembled a test interface by slightly modifying Paul Millers open
22
source GUI framework for SC3, TXModular [30], in order to test these
assumptions.
As I was to discover, my initial assumptions were too simplistic. I was
hoping, by starting from Golds four hats, to develop a more abstract and general
formulation that could be applied to solve problems of usability.
For example, some software features or capabilities may exist in the same
form across all categories. Such a feature would be considered global to the
application. For example, it may be that the operation to save a document may be
identical for all users. Other features may exist in several categories but are
implemented one way for the artist category and another way for the
engineer category. A generalized example here is that the application may
expose a commandline interface for engineering types while exposing a
graphical user interface that has pleasing sthetic qualities for artistic types. Still
other features may exist only in one category for one group of users. A possible
example here would be a function available only at the commandline for
engineering types.
My hope was that such an approach to design would provide a modular
and extensible approach to software requirements analysis, enabling feature sets
to be mapped to diverse groups of users in a methodical fashion, and, in
addition, supporting discrete staging of feature sets during implementation.
23
Such an approach, if it were possible, would have the advantage of being
scalable, as more dimensions of differences could be added, creating a
multidimensional model that can be scaled to an arbitrarily high number of
dimensions, thus creating higher degrees of granularity between user segments,
features, and unique implementation steps.
1.6 Goals

This thesis seeks to explain what I have learned regarding the initial
beliefs and assumptions I held at the outset of the study. It also attempts to
explain what I learned from the group of informants I followed through this
study. This includes observations that can inform the design of systems meant to
adapt to differences in users. I hope, in particular, to shed light on the complex
relationship between the informants selfdefined goals and their own conception
of their identity. It is this relationship, between selfdefined goals and self
identification, rather than culturedefined role that I found to be the best
predictor as to what category of usage a person will tend to choose.
Additionally, I hope to show that the particular group I researched
demonstrates that there are cases where it is impossible to provide a single
computational platform to meets the needs of all users.

24
2 Data Analysis: Phase 1

The first phase of interviews was designed to gather details about the
informant, their musical and technical background, preferences, and interests.
Most of these informants had completed a seminar in computer music at Mills
where SC3 was the primary tool. Questions about sound creation, composition,
arrangement and performance, as well as their ideas for the ideal SC3 interface
were also posed. Below are some of the key quantitative data regarding the
population.

2.1 Basic Population Statistics

The following are some basic characteristics of the population of 23
informants:
Informant
Type %
Faculty 13%
Professional 22%
Student 65%

Musical
Parents %
Yes 61%
No 39%


25
Background in Music
Theory %
Yes 63%
No 37%

Had computer has a child %
Yes 52%
No 48%

Background in programming %
Yes 30%
No 70%

Background in signal
flow %
Yes 57%
No 43%

Strong in Mathematics %
Yes 43%
No 57%

All of these measurements were based on the informants selfassessment
of their own background and abilities, not on any objective test.
2.2 Initial Impressions of SuperCollider 3.0

One of the most consistent trends in data I found was an initial impression
of the system ranging from intimidation and fear to unbridled hatred. Here are
some examples of the answers informants provided when I asked them about the
first experiences with SC3:
26
I dont know what to do with it very confusing.
very frustrating.
just a big mess.
horrible and painful.
disconnect between musical mind and my programmatic mind.
pretty rough results were not up to my expectations.
gave up it turned me off.
how to harness the possibilities
[the] beauty of SC is that it is so open but thats a doubleedged
sword.
frustrating limitations in my understanding of the architecture not
the most intuitive thing.
Ill have an idea and not have any idea how to implement it.
I wish I was spending more time making music than programming.
I found the transition between graphical and commandline jarring.
timeconsuming, and youre constantly altering these little minutiae
values spending hours and hours, you know, Ive looked at this code so long this
IO looks like IO IO IO, its off to work I go

Not one informant I spoke to, when posed this question, expressed positive
feelings toward the tool. From an activity theory perspective, this evidence
implies that most informants held a view laden with a variety of forms of highly
charged negative emotion. This negative emotion represents a barrier the
informant would need to reverse in order to establish a comfortable relationship
with the tool.
27
2.3 What worked in SuperCollider 3.0

When I posed the informants the question, What worked for you in
SC3?, I received a broad spectrum of answers. About 60% of the informants
replied that they most liked the quality of the sound that the system produced. The
remainder of the responses was split across the population, with the designated
percentages:
liberated from commercial software (15%);
changed my idea of what I am capable of as an artist and musician (15%);
found it less ambiguous to program in code vs. programming with a
graphic user interface (10%)
What is interesting about the first two items in the list above is that they
do not refer to SC3 capabilities, rather, to the informants capabilities, either in
terms of changing their feelings, or expanding their view of themselves. Only the
most common response (quality of sound) and the least common response
(programmability) were actually observations about the tool itself.
In observing these responses, I began to take note that what was being
reported here was not simply a view of the tool, but also of the person, their view
of themselves, their view of the world, and a recognition that all of these factors
play significantly into the way that person constructs the activity.
28
2.4 Suggestions to improve SuperCollider 3.0

One of the fundamental reasons that this form of research was undertaken
was to uncover, from the users perspective, a clear sense of what improvements
could be made to the SC3 environment to make it more useful. When asked what
improvements should be made to the system, a variety of ideas emerged. These
fell into several general categories and are presented in the sections below in
order of popularity.
2.4.1 GUI Requests

This was by far the most popular type of suggestion. Over 85% of the
suggestions involved providing some level of GUI interaction to the SC3
commandline interface. Suggestions included the following:
Routing / patching interface;
Visual automation draganddrop a synth on to a routine;
Provide a method to program visually;
A visual inspector for a synth module;
A dock of all synth objects / libraries represented visually that could be
dragged on to palette and connected to other objects;
Provide a visual timeline or graph where one could lay out / draw events
or do a little draganddrop;
iPhoto for sounds

These informants expressed that having a GUI would provide greater ease
of use and minimize what was generally characterized for them as a tedious and
29
nonessential process of writing and debugging code. This group of people
generally felt that writing code was not an artistic activity. Having labeled it as
such, this group chose not to invest the same level of energy that other
informants, who did feel that writing code was inclusive to the artistic process,
would put into learning sclang. This selflabeling of what is and what is not
artistic turned out to be the most significant indicator as to how the
informant would direct their energies towards the use of their tools.
Most informants told me that art, being a creative endeavor, is not at all
like the work of science and that it is not possible to say with any precision what
is or what is not artistic. At least in the culture of the group that I studied, the
demarcation between art and science remained a personal choice and a matter of
subjectivity
1
.
Many of the informants felt that the commandline programming
paradigm did not fit their own selfimage of an activity within an artists work.
These informants felt that the process of programming negatively changed the
way their minds operated in such a way as to detach them from their artistic
sense of self. This schism between socalled scientific and artistic activities
was highly prevalent and observed in 92% of this group.
1
There are cultures, particularly traditional Asian art culture, where emulating
the master is the desired goal and individual differences are not at all prized.
This is one example where we can see, from an activity perspective, that culture
has a direct impact on the activity.
30
2.4.2 Starter / Example Kits

The remaining 15% of the informants requested a starter kit to support
them in particular exercises beyond those that were presented as part of the class.
These individuals seemed less interested in actually improving the way the tool
worked but instead focused on improvements that would help improve their
understanding and comprehension of the underlying functionality within SC3. This
group of informants was open to the idea of programming and did not feel in
any way that the act of programming was a violation of their artistic identity.
These informants were by far the most successful in terms of their assessment of
their performance in the class and in their level of comfort working directly with
sclang.
2.4.3 Assessment of Suggestions

Once I assessed what users wanted, my next step was to design and
implement an improved interface and evaluate users responses to it.
Since the vast majority of the population requested a GUI to mediate
between the many programming tasks they would otherwise have to engage in, I
reviewed the various requests and came to the conclusion that based on my own
resources, I could provide a limited GUI that mediated some of the common
tasks such as instantiating oscillators and synths, setting their parameters, and
patching the output of one module to the input of another. These seemed to be
31
tasks all of the informants engaged in and the idea that emerged was to build a
GUI test environment that enabled such activities from a GUI. My objective was
to determine whether when provided with such an interface the informants
would find it an improvement.

3 Implementation of Test Interface

In researching various approaches to preparing a test interface, I came
across Paul Millers TX Modular [30] framework for SC3 that did almost
everything I wanted.
Miller has invested a significant amount of time implementing an
extensive objectoriented framework that runs on top of SC3 and presents the
capability of executing many common tasks in SC3 using a GUI rather than a
commandline interface.
The following is an overall class diagram of the TX Modular framework:
32

Figure 3 Class Diagram of TX Modular Framework

33
Having identified a wellwritten and wellorganized framework, my
implementation was very simple and straightforward. The framework already
did virtually everything I had identified as a requirement in the Phase 1 process.
My modifications were therefore limited almost entirely to sthetic changes of
the GUI color palette based on my sense of color.
Below is a screen shot of my modified TX Modular code that I named SC
Busy Box, which I used as the test interface for Phase 2 interviews:

Figure 4 Modification of TX Mod framework

The channel strips, which are the columns on the left, are a familiar
metaphor for any user who has previously worked with a physical mixing
console and allow the visual control of parameters such as volume (amplitude),
34
stereo panning, sending of signal to other channel strips, as well as the notion of
an insert, which is the ability to place an effect directly onto the channel.
On the right side is an inspector, which allows specific parameters for
the synth module that is the source for any channel strip to be changed in real
time via the mouse rather than via commandline.
Contrast this with the standard SC3 environment:

Figure 5 Standard SC3 Programming Environment

In the standard environment, all aspects of the system are controlled via a
commandline interface through sclang. The TX Modular framework is designed
to address this limitation.
35
Having found software that met the informants stated wishes, my next
step was to present this software to the informants and assess their response to it.

4 Data Analysis: Phase 2

The phase 2 interviews were very similar to the phase 1 interviews in form
and style, with three major differences. First, about 50% of the informants
interviewed had never used or been exposed to SC3 before. Second, instead of
soliciting ideas from the informants about how to improve the basic SC3
interface, they were presented with both the SC Busy Box GUI described in the
previous section and the standard SC3 interface and asked to comment on the
usability of each based on their particular usage goals. The third difference is that
timed tasks were recorded for each interface in order to obtain a quantitative
measure of how long it took an informant to complete a particular task in each
interface.
4.1.1 Response to SC Busy Box

Almost all users were immediately comfortable with the graphical
metaphors of channel strips and inspectors in the SC Busy Box and able to
perform the requested task of creating an oscillator and connecting it to an effect
36
significantly faster than in the commandline environment (see section 4.3 below
for quantitative comparisons).
This, however, did not mean that the informant felt that the SC Busy Box
interface was either usable or superior to the standard SC3 interface.
In over 94% of the population, informants stated that they would not use
the SC Busy Box interface to do their work. When pressed as to why they would
not use the interface, the answers fell into three general categories:

1. I would prefer to build something myself that is a reflection of my
artistic creativity (66%);
2. I find this interface too limiting (18%);
3. I do not find the tasks that the SC Busy Box supports to be within the
set of tasks I commonly use in my musicmaking process (16%)

The first and most commonly offered reason for rejecting the tool has
nothing to do with the tool itself. Instead, it reflects more on the informants
beliefs about the role of an artist. These beliefs define and limit what kinds of
tasks the artist engages in. For these informants, there is a very strongly held
belief that they should build things themselves. One informant summarized this
belief by stating:
37
There is a difference between making and playing a guitar, but in
a technological world where people have access to similar technology,
how do you differentiate what you do? Make your own.

There is an ironic paradox here: while one of the main benefits of
softwarebased systems is the ability to provide changeable or customizable
behavior without changing the hardware, research shows that only a minority of
users undertake the challenge of customizing the behavior of their software [26,
34]. My research supports these findings.
4.1.2 When Beliefs Conflict

Notwithstanding the overwhelming number of informants who shared a
similar belief, when pressed further on the ramifications, many informants
recognized a conflict in their own selfdefinitions. Specifically, many of the
informants who wanted to build their own tools also held a conflicting belief:
that applying their minds to the task of building a tool took them out of the
realm of creativity and into scientific activity, which they regarded as
unacceptable. One informant stated the conflict in this fashion:
[When thinking through the issue of] tool building vs.
instruments building and getting bogged down in the whole idea that I
can build these tools so maybe I should because using your own tools is
better than using someone elses tools. But I always feel I use other tools
38
in an unconventional manner anyway. Defining the tool involves a lot of
work that is not necessarily creative work.

More than 80% of the informants who were interviewed in phase 2
expressed this kind of conflict within the boundaries of their own selfdefinition
as an artist.
This conflict was also noted in section 2.4.1 and, at least for the population
I have studied, this factor is actually more critical than the tool itself because the
resolution of the conflict results in a tool choice that is consistent with that
informants belief system. Whether the tool does what an informant says they
want it to do or not turns out to be less important than whether the informants
beliefs about that kind of tool will admit the tool as acceptable to their
consciousness. This is a psychological and not a technical factor.
4.1.3 Aptitude versus Belief
Even among informants who might be thought of as having aptitude for
programming
2
, it was found that in all cases that when an informant felt that the
programming activity was not an artistic activity, that commandline
programming performance was poor. Conversely, informants who did not show
2
An informant who stated they had taken and performed well in programming
classes or were good at mathematics may be perceived as possessing an aptitude
for programming.
39
the same aptitude but felt that programming activities were part of an artistic
and creative process performed much better. This research shows that for this
group of informants that beliefs are a stronger indicator than aptitude for
performance.
4.1.4 Assessment of Beliefs is Vital for User Acceptance
Therefore, I argue that it is vital, in the design of usable and adaptable
systems that are designed for a wide variety of users, to include as part of the
design process a clear understanding of the beliefs informants have about the
tools they use in parallel with any effort to improve or design better tools if it
is a goal of the implementation that those tools be adopted and fully utilized. To
achieve adoption, at least in the population I studied, it is not enough to simply
take a list of requirements and implement against these.
4.1.5 A Key Factor in Large Scale System Adoption Failures

The study of beliefs regarding which activities an individual considers
acceptable is not a hot topic in current HCI work. I argue here that lack of this
type of qualitative information is a key factor in the failure of a wide range of
largescale system implementations.
According to InfoWorld, research conducted by Gartner / Meta Group
shows that on average, about 70 percent of all ITrelated projects fail to meet
40
their objectives [24] and attributes such failures to the fact that many largescale
system implementations such as ERP (Enterprise Resource Planning), SCM
(Supply Chain Management), and CRM (Client Relationship Management)
overlook the fact that they are dealing with a fundamental change in our
relationship with the enterprise [24].
Tom Amerongen of iFusion, a CRM consultancy supports this idea,
stating that CRM is not just about technology and that to turn a companys
CRM goals into true results, your CRM strategy must be considered holistically.
[4].
Susan Ehrlich, in her 1987 ACM paper on strategies for encouraging
successful adoption of office communication systems, also speaks to this point as
part of her conclusion, advising researchers to include studies that take
psychological factors into account as an aid to improve system adoption and
acceptance [9]. In her study, she used the term social conventions to refer to
the set of beliefs that users held and that needed to be addressed before a system
could be successfully adopted.
The research conducted within the scope of this thesis supports and
extends Ehrlichs findings by using activity theory as a data collection
methodology to uncover key psychological data that may impose barriers to the
acceptance of a system.
41
4.2 Characteristics of Successful Adopters of SC3

There were, however, a small percentage of users (9%) who were very
positive about the use of SC3 in its native commandline mode as a tool for
artistic expression. It is helpful to understand the contrasting beliefs that these
informants expressed in order to better understand the differences between those
who are and are not successful with this platform in its commandline mode.
Here are some of the comments from the people who were facile and
comfortable in this environment:
Code is my instrument.

I get a vision about what I want to do and I see it in code.

I see the entire instrument as a mental model in my head,
specified in code.

Ill have a sound world in my mind and Ill build it out, proceed
toward that, build instruments toward that, and perform toward
that.

What all of the informants who were comfortable in the commandline
environment had in common was an artistic embracing of the following two
skills:
1. An understanding of unit generators and signal flow theory;
42
2. A facile understanding of computer languages such that they could
think in code;
The second skill deserves further discussion. One of the informants I
spoke with offered the following description of what it means to think in code:
There is a point in reading code that youre not thinking about the
code functionally or descriptively. There are instead functional
relationships and you cease to think about syntax. This is the same
phenomenon that occurs when learning English. There is a point
where the words become transparent and you start to understand
meaning.

In my research, this fluency with a programming language was only
achieved by those who first made an internal decision that to wrap her mind
around the concepts surrounding the topic was an inclusive step in their artistic
journey. If an individual chooses the path toward sclang fluency, a number of
factors were observed to occur. These include that the individual reviewed
examples of wellwritten code, that she persistently focused her creative ability
into programming language constructs, and that she sought ongoing guidance
from an expert programmer. Only then was the individual able to achieve
fluency with sclang.


43
4.3 Results of Phase 2 Quantitative Time to Completion Tests

Two quantitative tests were administered to phase 2 population to test
whether the SC Busy Box was more efficient at supporting users in performing a
particular task. This group consisted of a total of 10 subjects
3
. Each subject was
presented first with the SC Busy Box interface and asked to create a basic
oscillator that emitted some sound and connect this to some effect of their choice.
They were then asked to do the same task within the standard SC3 command
line environment. The results were very interesting.
For the first test, the shortest time to completion was 50 seconds and the
longest time was 3 minutes 20 seconds. The average time was 2 minutes, 17
seconds. In all cases, the subjects stated that completing the task felt like a
relatively straightforward task. In some cases, the subject pointed out some ways
they might change the GUI to make selection and state more obvious to them.
For the second commandline test, 60% of the population declined to
attempt the test. This was surprising, especially since some of the people who
declined were also in the category of being fluent in sclang and in principle,
should have been able to perform the task without issue.
3
Here I use the more common term subject as opposed to informant as the
individual is subjected to quantitative test and their responses are observed.
44
In all cases, the subjects estimate of the amount of work that would be
involved was in the range of several hours. Here are some of the comments that
the subjects provided in response to the proposal of the second test:
Youre kidding, right? Well be here all afternoon if you want me
to do that.

If you want me to do the exact same thing as what the GUI does in
code, to have any control over it would take me 2 to 3 hours and I
dont want to go through that.

Of the four subjects that did attempt the test, one gave up after 12
minutes, and for all subjects, the following physical symptoms were noted that
did not occur in the first test:
audible whispering to self in either a selfdeprecating or
questioning fashion;
heavy sighing;
significant changes in posture more bent over and head much
closer to the computer screen;

I hypothesize that some shift in psychological attitude occurred for these
subjects when setting themselves to the task of programming that altered their
behavior in this manner. Some subjects spoke about the notion of different
parts of their mind perhaps these physical expressions were habits associated
with that part of their mind.
45
For the three remaining subjects that did complete the second test, the
shortest time to completion was 6 minutes 20 seconds. The average time was 12
minutes 45 seconds, and the longest time to completion was 22 minutes 30
seconds. It is notable that it took subjects significantly less time than they
estimated it would take them to complete this test.
I assert that these tests do show that for the particular task that was tested
that the SC Busy Box interface was more efficient than the SC3 interface. The
subjects also reported that it was easier to use. However, as stated previously,
even those subjects who stated that they liked the interface said they would not
use it for the reasons quoted in section 4.1.1 above.
Based on the conclusions reported in the above referenced section, these
quantitative tests, while interesting, do not support any notion of the idea that by
providing a user interface to students that they would accept it as a tool to be
employed by their artistic vision.
4.3.1 Overturning of the Dominant GUI Paradigm

Another interesting feature that was noted among this subgroup of three
subjects is a preference for commandline tools over GUI tools for general
computer operation. Of this subgroup, 33% had some background in computer
science. The remaining 66% were selftaught. One of these remaining 66% ran
46
their own LINUX kernel with SC3 and worked almost entirely at the command
line for virtually all operations. This is behavior one might normally associate
with a hacker or programmer, but not an artist.
This preference may be important. If it can be shown in a larger
population, this may cast doubt on the almost unanimous assumption that the
GUI is superior to the commandline, especially since the population being
studied has been acculturated to art rather than computer science. In our culture,
we very often associate the artist with the type of personality who prefers
graphical tools and has no interest in learning about more technical matters.
These few individuals, while not the norm, are a significant part of the
population I studied and among its most facile in terms of their application of
their artistic abilities. Software designers would do well to take this feature into
account when designing future software for artists.







47
Electronic music pioneer and creator of the famous Moog synthesizer,
Robert Moog offers his personal view of the difference between a musician and
an engineer:
Musicians are intelligent people. If they want to build sounds up
or construct sounds in certain ways, they can learn techniques for
doing it. You dont have to be an engineer to use a synthesizer, but
you do have to understand that in order to make the pitch of a
sound go up and down regularly, you need a regularly changing
voltage to control that pitch. Once you experience connecting a
regularly changing controlled voltage to change the pitch, making
it go up and down regularly, it becomes a natural thing. Its just as
natural as, say, drawing a bow across a string. You develop a
feeling for it. You develop an intuition for it; thats different than
being an engineer or being a technical person and understanding in
great detail and great precision exactly whats going on. [31]

5 Conclusions

The results of this research suggest that the standards for judging GUI
interface quality in the HCI field may not apply to GUI design for software built
for artists or those engaging in what might be considered creative processes. It
also suggests that using an activity theory model to expose psychological factors
such as personal beliefs may be helpful in uncovering the adoption issues that
are the root cause of many largescale system implementation failures.
48
In the group I studied, it appeared that the wellestablished 80/20 rule did
not apply, in that individual differences preclude aggregating any set of
functions to support 80% of the user population.
The work in this thesis to design interfaces to meet the needs of
specialized subgroups of artists serves as an important warning to future
software and interface designers. The warning is like an early phase in interface
design between nave and experienced users, as referred to in MacCleans paper
UserTailorable Systems: Pressing the Issues with Buttons, which uses the metaphor
of the tailorability mountain to describe the levels of difficulty involved for
users to customize their software environments [26]. In this case, however, it is
the interface designer who would have to climb these mountains and it is my
observation that the levels are tenfold more in the creative space.
This thesis supports the notion that activity theory is a useful methodology
for qualitative data interpretation that provides access to levels of information
about the population for whom the software is designed.
Finally, this study questions the almost unanimous assumption that the
GUI is superior to the commandline. It was clear from the information provided
by the small sample of informants that there are people for whom the command
line is clearly a superior tool and this fact should not be disregarded by designers
of future software systems.
49
5.1.1 Future Work
It is my hypothesis that if clear arguments were presented to the
individual at the outset of the class as to the fact that individuals do make
choices about what they consider artistic processes and why an individual should
consider scientific activities such as programming an artistic activity, some of
the people who would otherwise choose against it may instead open their minds
to the idea and end up learning a lot more about what is truly possible within the
powerful SC3 environment.
A future study could explore this hypothesis using the same methods as
this study and report on the outcome.
50

6 References


1. Abelson, H., Sussman, G.J. and Sussman, J. Structure and Interpretation of
Computer Programs. MIT Press, McGrawHill;, Cambridge, Mass., New
York, 1996.
2. Adams, A., Blandford, A., Budd, D. and Bailey, N. Organizational
Communication and Awareness: a novel solution for health informatics.
Health Informatics Journal, 11 (3). 163178.
3. Adams, A. and Sasse, M.A. Taming the Wolf in Sheeps Clothing: privacy in
multimedia communications. ACM Press, Orlando, FL, 1999.
4. Amerongen, T. Hitting the Mark With CRM
(http://hosteddocs.ittoolbox.com/TA061503.pdf), Electronically accessed
on 6/12/2006, 2004.
5. Barthelmeiss, P. and Anderson, K.M. A View of Software Development
Environments Based on Activity Theory. Computer Supported Cooperative
Work (CSCW), 11 (12). 1337.
6. Bruer, J.T. Schools for Thought : A Science of Learning in the Classroom. MIT
Press, Cambridge, Mass., 1993.
7. Collins, P., Shukla, S. and Redmiles, D. Activity Theory and System
Design: a view from the trenches. Computer Supported Cooperative Work
(CSCW), 11 (12). 5580.
8. Dijkstra, E.W. The Humble Programmer. Communications of the ACM, 15
(10). 859866.
9. Ehrlich, S.F. Strategies for Encouraging Successful Adoption of Office
Communication Systems. ACM Transactions on Information Systems (TOIS),
5 (4). 340357.
10. Fjeld, M., Lauche, K., Bichset, M., Voorhost, F., Krueger, H. and
Rauterberg, M. Physical and Virtual Tools: activity theory applied to the
design of groupware. Computer Supported Cooperative Work (CSCW), 11 (1
2). 153180.
11. Geertz, C. The Interpretation of Cultures; selected essays. Basic Books, New
York, 1973.
12. Glaser, B.G. Theoretical Sensitivity: advances in the methodology of grounded
theory. Sociology Press, Mill Valley, CA, 1978.
13. Glaser, B.G. and Strauss, A.L. The Discovery of Grounded Theory: Strategies
for Qualitative Research. Aldine Pub. Co., Chicago,, 1967.
51
14. Gold, R. Desire in Context (http://hci.stanford.edu/cs547/abstracts/02
03/021011gold.html). Winograd, T. ed. Stanford Seminar on People,
Computers, and Design, Stanford University, Stanford, CA, 2002.
15. Gold, R. The Plenitude. The Present Press, Palo Alto, CA, 2002.
16. Horn, R.E. Visual Language: Global Communication for the 21st Century.
MacroVU, Inc., Bainbridge Island, Wash., 1998.
17. Kaptelinin, V., Nardi, B.A. and Macaulay, C. Methods & Tools: the activity
checklist: a tool for representing the space of context. Interactions Journal,
6 (4). 2739.
18. Kay, A., The Early History of SmallTalk. in The second ACM SIGPLAN
conference on History of programming languages, (Cambridge, Massachusetts,
United States, 1993), ACM Press, 6995.
19. Korpela, M., Mursu, A. and Soriyan, H.A. Information Systems
Development as an Activity. Computer Supported Cooperative Work (CSCW),
11 (12). 111128.
20. Kuutti, K. Activity Theory as a Potential Framework for Human
Computer Interaction Research. in Nardi, B.A. ed. Context and
Consciousness: activity theory and humancomputer interaction, MIT Press,
Cambridge, MA, 1996, 1744.
21. Landauer, T.K. The Trouble with Computers: Usefulness, Usability, and
Productivity. MIT Press, Cambridge, Mass., 1995.
22. Laurel, B. and Mountford, S.J. The Art of HumanComputer Interface Design.
AddisonWesley Pub. Co., Reading, Mass., 1990.
23. Leontev, A.N. Activity, Consciousness, and Personality. PrenticeHall,
Englewood Cliffs, NJ, 1978.
24. Lewis, B. The 70% Failure Survival Guide
(http://www.infoworld.com/articles/op/xml/01/10/29/011029opsurvival.ht
ml), Electronically accessed 06/12/2006 InfoWorld, 2001.
25. Lonkila, M. Grounded Theory as an Emerging Paradigm for Computer
Assisted Qualitative Data Analysis. in Kelle, U., Prein, G. and Bird, K. eds.
ComputerAided Qualitative Data Analysis: theory, methods and practice, Sage
Publications, Thousand Oaks, CA, 1995.
26. MacLean, A., Carter, K., Lvstrand, L. and Moran, T.P., UserTailorable
Systems: Pressing the Issues with Buttons. in Proceedings of the SIGCHI
Conference on Human Factors in Computing Systems: empowering people
(Seattle, WA, 1990), ACM, 175182.
27. McCarthy, J. Recursive Functions of Symbolic Expressions and their
Computation by Machine. RLE and MIT Computation Center, [Cambridge,
Mass], 1959.
52
28. McCartney, J., SuperCollider: A New Real Time Synthesis language. in
International Computer Music Conference, (Hong Kong, 1996).
29. Miettinen, R. and Hasu, M. Articulating User Needs in Collaborative
Design: towards an activitytheoretical approach. Computer Supported
Cooperative Work (CSCW), 11 (12). 129151.
30. Miller, P. The TX Modular System: an open source framework for
SuperCollider3 (http://palemoonrising.co.uk/), Electronically accessed
11/12/2005, 2005.
31. Moog, R. Interview. in Shapiro, P. ed. Modulations: A history of electronic
music / throbbing words on sound, Caipirinha, New York, NY, 2000, 206209.
32. Nardi, B.A. Beyond Bandwidth: dimensions of connection in interpersonal
communication. Computer Supported Cooperative Work (CSCW), 14 (2). 91
130.
33. Nardi, B.A. Context and Consciousness: activity theory and humancomputer
interaction. MIT Press, Cambridge, Mass., 1996.
34. Nardi, B.A. A Small Matter of Programming: perspectives on end user
computing. MIT Press, Cambridge, MA, 1993.
35. Nardi, B.A. and Johnson, J.A. User Preferences for TaskSpecific vs. Generic
Application Software. ACM Press, Boston, Massachusetts, United States,
1994.
36. Nardi, B.A., Whittaker, S. and Schwarz, H. NetWORKers and their
Activity in Intensional Networks. Computer Supported Cooperative Work
(CSCW), 11 (12). 205242.
37. Pace, S. A Grounded Theory of the Flow Experiences of Web Users.
International Journal HumanComputer Studies, 60 (3). 327363.
38. PriesHeje, J. Three Barriers for Continuing use of ComputerBased Tools
in Information Systems Development: a grounded theory approach.
Scandinavian Journal of Information Systems, 3. 119136.
39. Spasser, M.A. Realist Activity Theory for Digital Library Evaluation:
Conceptual Framework and Case Study. Computer Supported Cooperative
Work (CSCW), 11 (12). 81110.
40. Spector, M. and Wang, X. Integrating Technology into Learning and
Working: promising opportunities and problematic issues. Educational
Technology & Society, 5 (1).
41. Stephenson, N. In the Beginning was the Command Line
(http://www.cryptonomicon.com/beginning.html), 1999.
42. Strauss, A.L. and Corbin, J.M. Basics of Qualitative Research: Techniques and
Procedures for Developing Grounded Theory. Sage Publications, Thousand
Oaks, 1998.
53
43. Suchman, L.A. Plans and Situated Actions : The Problem of HumanMachine
Communication. New York, Cambridge Cambridgeshire, 1987.
44. Vygotsky, L.S. and Kozulin, A. Thought and Language. MIT Press,
Cambridge, Mass., 1986.
45. Weiser, M. Some Computer Science Problems in Ubiquitous Computing.
Communications of the ACM, 36 (7). 7584.
46. Weiser, M., Gold, Rich, Brown, John S. The Origins of Ubiquitous
Computing Research at PARC in the Late 1980s. IBM Systems Journal, 38
(4). 693696.
47. Wikipedia. Chauvet Cave: http://en.wikipedia.org/wiki/Chauvet_Cave,
2005.
48. Winn, W.D. Visualization in Learning and Instruction: A Cognitive
Approach. Educational Communication and Technology: A Journal of Theory,
Research, and Development, 30 (1). 325.
49. Woodruff, A. Personal Conversation with Allison Woodruff. Friedland, B.
ed., Berkeley, CA, 2005.
50. Zager, D. Collaboration as an Activity Coordinating with Pseudo
Collective Objects. Computer Supported Cooperative Work (CSCW), 11 (12).
181204.


54

7 Appendix A Sample Interview Protocol for
Informants

Background

Do you come from a musical family?

When did you become aware of music?

When did you start playing a musical instrument?

When/how did you first come into contact with electronic music equipment?

Do you compose music?

When did you start to compose?

Musical interests

What were your initial interests in music?

When did you start to become interested in electronic music?

What influences you most in choosing what you listen to now?

Technical ability / understanding of computer science

How long have you used computers?

Do you consider yourself a programmer?

Have you taken classes in programming or had any other formal computer
science education?

How comfortable do you feel with programming? With learning new languages?

Use of software for composition, production and performance of music
55

What software do you use to make music?

Do you use different software for composition, production, or performance?

What do you like about the software you use?

What is the most challenging thing that you do in your use of computers and
electronic music?

Use of SuperCollider3

Have you heard of a program called SuperCollider3?

If yes, how did you hear about it?

What do you use it for?

What do you like about it? Dislike?


(If the informant is selected for the user study, they may also be asked the
following)

Some users will be given the command line version of SuperCollider3 while
others will be given a user interface designed to support a specific set of tasks.

Please use this software to select a synthesizer named _______.

Please use this software to send the out put of the synthesizer named _______ to
the input of the effect named ________.

Did you find this task easy or difficult?

Why or why not?

(If user interface) Do you think of this as programming?

Why or why not?