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 well-established 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.
Original Title
Applying Activity Theory in the Design of Usable Software: How Personal Beliefs Shape the Use of Tools
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 well-established 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.
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 well-established 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.
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?