Future Generation Computer Systems 27 (2011) 100–108

Contents lists available at ScienceDirect

Future Generation Computer Systems

journal homepage: www.elsevier.com/locate/fgcs

Cooperative mechanisms for networked music

Marcelo Pimenta, Evandro Miletto ∗, Luciano Flores, Aurelio HoppeInformatics Institute, UFRGS, Caixa Postal 15064, 91501-970, Porto Alegre, RS, Brazil

a r t i c l e i n f o

Article history:Received 30 October 2009Received in revised form29 March 2010Accepted 31 March 2010Available online 8 April 2010

Keywords:Computer Supported Cooperative WorkWeb-based interaction

a b s t r a c t

One potential convergency of Web-based systems for social activities and music making is the fieldof networked music. This paper presents the main characteristics and discusses the rationale for thecooperative mechanisms implemented in CODES, a Web-based networked music environment designedto provide support for Cooperative Music Prototyping (CMP) by novices in music. The cooperativemechanisms of CODES were specifically designed and built in order to support a dynamic and creativeenvironment, enabling knowledge sharing by means of rich interaction and argumentation mechanismsassociated with the evolution of Music Prototypes (MPs), allowing any user to identify and understandothers’ contributions, besides preserving each creator’s original ideas, intentions and authorship. A briefdescription of CODES and its original concept of ‘‘music prototyping’’ is initially presented, characterizingthis activity as a particular kind of design. The essential concepts and descriptions of CODES cooperativemechanisms are then described, illustrating how they increase awareness of other users and theirintentions in the context of group activities for music prototype design.

© 2010 Elsevier B.V. All rights reserved.

1. Introduction

The Web is becoming increasingly attractive as a technology tosupport social activities. Today YouTube [1] and other social Webservices such as MySpace [2], and Flickr [3] have improved theinteraction between users and systems over the Web, and usersare getting used to new purposes, like engagement, entertainmentand self-expression. In fact, Web 2.0 has turned the passive userinto an active producer of content and shaper of the ultimateuser experience, and the Web is becoming a rich and idealmeans for social activities. One potential convergency of socialactivities and music making is the field of networked music [4],which allows people to explore the implications of interconnectingtheir computers, and share musical experiences as a socialactivity through music [5]. Recently, Internet-based networkedmusic has attracted wider interest of the music technologycommunity, and the existing applications have evolved towardsmore sophisticated projects and concepts including, for example,real-time distance performance systems, and various systems formulti-user interaction and collaboration. CODES — a Web-basednetworked music environment designed to support CooperativeMusic Prototyping (CMP), with special focus on novices — emergesin this scenario. Differently from YouTube, Flickr, and evenMySpace, where people only publish their content, networked

∗ Corresponding author.E-mail address:miletto@inf.ufrgs.br (E. Miletto).

0167-739X/$ – see front matter© 2010 Elsevier B.V. All rights reserved.doi:10.1016/j.future.2010.03.005

music systems should also provide ways to create contributionsand experiments. For this reason, we consider CODES as a systemformusic design (authoring), instead of a system just for publishingmusic. This implies a focus not only on community management(i.e., discovering, building ormaintaining virtual communities) butalso on experimenting andparticipating in specific designpracticesusing a suitable interaction vocabulary. Indeed, the design of anenvironment like CODES needs attention for the considerationslike characteristics of the user population, context, purpose, andconditions under which the technology will be used, expectationsof the product, and the nature of its influence on the userpopulation and on human relations. For novices however, onecannot merely replicate models of highly specialized people likecomposers and musicians.That is why the cooperative mechanisms of CODES were

specifically designed and built in order to support a dynamic andcreative environment, enabling knowledge sharing by means ofrich interaction and argumentation mechanisms associated withMPs evolution. They allow any user to identify and understandothers’ contributions, besides preserving each creator’s originalideas, intentions and ‘‘authorship’’.The goal of this paper is to discuss the rationale for the cooper-

ative mechanisms implemented in networked music environmentCODES (see Section 2), presenting their main concepts and illus-trating how they increase awareness of other users’ actions andtheir intentions in the context of group activities for CMP process(see Sections 3 and 4). Some results of initial experiments of theirusage (Section 5) are also presented and discussed.

M. Pimenta et al. / Future Generation Computer Systems 27 (2011) 100–108 101

2. CODES and the principles for cooperative music prototyping

CODES is aWeb-based networkedmusic environment designedto provide support for Cooperative Music Prototyping (CMP) bynovices in music. Using CODES a novice may experiment withmusic by combining, listening and rearranging sound patterns,and cooperating with partners in order to create collaborativelymusical pieces — which we call Music Prototypes (MPs). We dis-tinguish music creation from music composition. Musical compo-sition is a complex activity and each composer has a unique styleand way of working, in addition to useful skills like writing mu-sical notation, handling instrumentation and orchestration, andother methods of sound production. As a consequence, compos-ing is considered as mostly a solitary activity. Music creation is adesign activity: the design of (new) sounds and/or the design of(new) combinations of (existing) sounds, forming (new) sound se-quences or (new) simple musical pieces. LikeWeinberg [6], we areinterested in providing any user — novices inmusic or experiencedmusicians — an access to meaningful and engaging musical ex-periences. Novices clearly do not act and think like musicians do.Novices usually do not have access to musical instrument and donot know how to play them, neither how to represent music us-ing traditional notations. Novices do not know the compositionaltechniques used to create music. In fact, the large corpus of formalknowledge associated to musical composition, in general, discour-ages the composition by novices. Clearly, the design activities formusic creation by novices andmusic composition activities are notthe same. Thus, an environment providing support for their activi-ties has specific requirements. As any design activity, we can adopta collaborative strategy to copewithmusic creation. During CODESdevelopment and usage, we have incrementally found out specificrequirements concerning how should be the cooperative mech-anisms in order to provide effective support to such design ofnon-technical products (like for instance music creation activi-ties of CMP) and CODES is the result and testbed of this research.Despite the considerable scientific production on music and audiotechnology in recent years, surprisingly it is difficult to find re-cent published research work devoted to networked systems formusic creation. The ones we found are clearly environments formusic composition, not music creation by novices (music proto-typing). The interested reader can find detailed descriptions in asurvey about IMNs — Interconnected Musical Networks, by Wein-berg [6]. Briefly, CODES is similar tomany of theseworks — like theFMOL System (F@ust Music On Line) [7], the TransJam System [8],Daisyphone [9], PitchWeb [10], CreatingMusic [11], JamSpace [12],and HyperScore [13], which enable users to contribute their ownmaterial and manipulate (listening, altering, refining, etc.) others’contributions, usually in an asynchronous interaction and off-linematerial manipulation, but no one supports both complex aware-ness mechanisms and argumentation of CODES.Two principles, learned and confirmed by findings obtained

during CODES development and usage [14], must be consideredwhen providing such support to novice-oriented music creationactivities: (a) Music creation by novices should be prototypical;and (b) Music creation by novices should be cooperative.A ‘‘prototypical’’ music creation process means novices can

draft simple musical pieces — we call them Musical Prototypes(MPs) in order to highlight the difference — which can be tested,modified, and repeatedly listened to, in a cyclical refinement ofinitial musical sketch until a final stage being reached. This processclearly resembles prototyping cycles adopted in industry and inincremental software development. Since music creation is in facta (music) design activity, it seems natural and straightforwardto adopt a prototypical process. In the music literature, draft iscommonly applied to such kind of creative work, but here theemphasis is focused on the cyclical prototyping process and not

on the product itself, and consequently in this paper ‘‘prototype’’and ‘‘draft’’ correspond to the same idea.In a ‘‘cooperative’’ music creation process, the refinement of

an initial musical idea is consequence of a collaboration of theauthor(s) of initial musical idea and of their partners, all membersof a group (in fact, a social network built by explicit invitation) thatwill be cooperating until a final consensual stage of MP be reached.In our opinion, novices in music need effective interactive supportto cooperate with each other for really producing music, becausethey do not have enough knowledge and confidence to createmusic by themselves. Despite music creation is usually consideredasmostly a solitary activity, we believe that an effective computer-based support stimulates the social ways of music creation.Through the prototypical and cooperative nature of CODES,

novices may thus have the opportunity to be, like experiencedmusicians are, the actors of their own musical experiences.

3. Idiosyncrasies of cooperative aspects in music prototyping

Music prototyping, since it is considered as a design process, hassome specific requirements and idiosyncrasies. The cyclic processof Music Prototyping is a kind of wicked problem — following themore generic Jeff Conklin’s definition [15] rather than the originalformulation of Rittel and Webber’s pioneer work [16]. Indeed, likewicked problems, music prototyping are characterized by:

• having no stopping rule;• resulting music prototypes are not true-or-false or right-or-wrong, but better or worse (trade-off);

• people involved in the process have radically different worldviews and different frames for understanding the problem.

Due this wicked nature, there are many possible strategies(see [17]) to cope with Music Prototyping, and we adopt a col-laborative strategy. Cooperative approaches for music prototypingprocess need to provide a very specific kind of support for collabo-rative activities. In fact, the conventional cooperative approacheswith fixed goals and roles, which not allow unsystematic andopportunistic negotiation, are not adequate for the dynamic, cre-ative and collaborative nature typically related to collaboration inarts (music, painting, etc.).Themain differenceswe have found comparing the cooperative

support for CMP we have defined in CODES development aresummarized in Table 1, with some characteristics generally foundin cooperative environments for technical product design, like inmanufacturing, construction, etc.For technical products, there is a need for specifying a priori a

product model in order to standardize the process and determineas precisely as possible the requirements of the final result. Formusic prototyping, the emphasis is on the subjective aspects ofthe act of creation rather than on defining precisely the results ofcreation. Sincewe cannot predict a priori the final result, the designprocess is guided by the creation or creativity itself, instead of aprevious specification.As this process emerges from the cyclic interactions of the

group, based on contributions from/to each other, the ‘‘control’’of the process is done by negotiation between members, withoutthe need for the role of an explicit controller. Thus, the ‘‘decisions’’are supposed to be consensual by negotiation, and not imposedby the authority of a leader. We believe that it is not necessary tomake a distinct and explicit representation of the leader, becauseusually in a hierarchical group, the leader’s opinions and actionsmay inhibit the other users’ participation.Indeed, interactions can evolve as time passes, and the ‘‘more

skilled’’ users can be recognized and respected naturally by thegroup while suggesting and justifying their contributions. Thisallows total flexibility without needing prior role definition, task

102 M. Pimenta et al. / Future Generation Computer Systems 27 (2011) 100–108

Table 1Collaborative aspects for technical product design and music prototyping.

Collaboration for technical product design Collaboration in music prototyping

Main goal Product design according to a product (orrequirements) model

Creative product resulting of a mutual understanding; no previous productmodeling; mutual learning process is as important as the product itself

Group topology Typically, a hierarchical group with a leader Typically, a non-hierarchical group without formal leadersControl Coordination ArgumentationPlanning and decisions Rigid and systematic plan definition, decision

order following planningUnsystematic and opportunistic negotiation

Roles and tasks Fixed roles with responsibility assignment;pre-defined task allocation

No fixed roles, no responsibility assignment; flexible task allocation

Example Collaboration in manufacturing, construction, etc. Collaborative Music Creation

allocation or responsibility assignment for members. In a technicalproduct design, however, such role definition and responsibilityassignment is essential for design management.Because the cooperative music prototyping process can justi-

fiably be seen as a political process determined by conflicts andcooperation, the joint development of ideas by means of bothmulti-perspective approach andnegotiation support is particularlyimportant.Themultiple actors — all who are cooperating in the refinement

of the musical prototype — hold different perspectives on thecreative process and its results (the musical prototype), eachone with different backgrounds and opinions due to the contextthey come from. Therefore, it is essential to support mutualunderstanding and to resolve conflicts during cooperative musicalprototyping. A negotiation between these different viewpoints andgoals must be explicitly supported and maintained over time, thusthe decision-making process is cooperative and distributed.The basic idea of our CMP process is that members cooperate

not only by means of explicit conversation and explicit actionson a shared object space, but also by interpreting the messagesand actions of other actors in accordance with the model of theirthinking and acting, which has been built up in the course of theirinteraction.A shared objects space involves prototype-oriented informa-

tion, which comprises all information about musical prototypes,including their composition (combination of sound patterns, ver-sions formed by layers) and social-oriented information (includinginteractions between actors during the process). One significantconsequence of recognizing social-oriented objects as relevant in-formation is that, instead of considering modifications as only ex-plicit transformations on an MP, we also consider the changes onsocial-oriented objects.Unlike a conversation, where messages are categorized as to

their purpose within the conversation, for action, for clarification,for orientation, and so forth, conversation in CODES is simplycomposed by all recorded messages sent and received to/from theCMP actors, indexed to other relevant model components. Then,recording the actors’ messages is extremely useful to capture, inan implicit way, the background knowledge, concepts, definitions,and opinions surrounding their viewpoints.In addition, the music prototyping rationale may be explic-

itly recorded by decisions and arguments. This rationale-orientedapproach is not a novelty. CMP has common characteristics to oth-erswicked problems occurring in any domain involving stakehold-ers with differing perspectives, and thus Rittel’s technique calledIssue-Based Information System (IBIS) [18] can be adopted in or-der to facilitate documentation of the rationale behind a groupdecision in an objective manner.In our approach, decisions are goal-motivated consensual

choices, concerning alternatives of the action course. Argumentsare consensual explanation, not an individual message inter-changed between actors. Every decision or action may be linkedto (pro or con) arguments.

Fig. 1. Shared musical prototype using layers.

Notice that the actors cooperate via the shared object space,that is, either indirectly by means of musical prototypes theymanipulate and modify, or directly by means of conversation.Thus, the set of actions an actor may perform has been broadenedto include direct interactions with other actors, in addition totraditional actions of prototype manipulation. In fact, duringgroup activities people do not strictly act by goal-based productmodification. Unless the actors in these groups are, to some extent,multidisciplinary, the communication between group membersplays a crucial role to support cooperative and multidisciplinaryactivities.In the next sections we describe in more detail the cooperative

mechanisms implemented in CODES in order to provide support toCMP-oriented cooperation.

4. Versions in CODES: preserving authorship

Our starting point for the cooperative mechanisms in CODESwas simply integrating CSCW solutions to provide means ofsharing music, ideas, and to allow some feedback about theseprocesses. For this reason, a technical product oriented approachwas adopted in the early implementation of CODES, including atree structure version control mechanism, as used traditionally inconfiguration and version management of software engineeringprojects, to avoid conflicts and inconsistencies among the severalcontributions of a group.However, this tree structure mechanism has presented behav-

iors that did not fit some musical activities performed in CODES,allowing some drawbacks like authorship conflicts and depen-dency between users’ contributions. To avoid these dependenciesand conflicts, in CODES we now manage independently each userand their private contributions as an ‘‘individual layer’’. In this ap-proach, each layer represents one user’s view, and the union ofusers’ contributions (a combination of layers) results in a coopera-tive musical prototype version, as seen in Fig. 1.

M. Pimenta et al. / Future Generation Computer Systems 27 (2011) 100–108 103

Fig. 2. Music prototyping editing level.

By using layers in the design, each user has their own tree struc-ture, where each node represents a new contribution. Another im-portant characteristic of the layered approach is the independencebetween users’ contributions, where it is possible to replace onlyone contribution without the need of parallel activities such asreplication or sound pattern exclusions. Any user can browse be-tween the contributions, independently of the creator, keeping thecreator’s original ideas and authorship. It is also possible to editanother user’s contribution, by issuing a ‘‘modification request’’directly from the sound patterns of the editing area. See moredetails in the next section.

5. Group interaction mechanisms in CODES

CMP is herein defined as an activity that involves peoplecreating groups and working together on an MP as a sharedworkspace. In CODES, a cooperative musical prototype is initiatedby someone that creates a new prototype, elaborates an initialcontribution, and asks for the collaboration of other ‘‘partners’’by sending explicit invitations. Partners who accept the invitationcan participate in the collaborative musical manipulation andrefinement of the prototype. The group can publish the final orpartial results of their CMP in the public spaces (CODES homepage), in which interested users could discover it and then join thecollaboration as new partners.

5.1. Cooperative edition in CODES

CODES allows authenticated users to create and edit their MPscooperatively. Edition of anMP is very simple: sound patterns fromthe sound library are dragged and dropped in the MP editing area(see 2 at Fig. 2).

At any time, a usermay play theMP (see 3 at Fig. 2)— the soundsdisplayed in the editing area are played from left to right. To editanMP is basically to add or remove sound patterns, to change theirsequence, and so on. Once logged in the system (see 1 at Fig. 2),users can send explicit invitations to other users (authenticated ornot). The members list and group status are also displayed in themembers area (see 4 at Fig. 2).Each author’s contribution in the sharedworkspace is identified

by color: for example, the edges of sound pattern icons are colorful(the color obviously chosen by the user). In the members’ area, ausermay show or hide other users’ contributions (in fact, the otherusers’ layers) by clicking over the user id. It is possible to listen toeach layer separately, compare and combine contributions, and, ofcourse, save the result. The group status showswhen there are newcomments or new versions with icons.When someone contributes by adding a new sound pattern to

an MP, it will be, by default, locked for other users, with a blurredappearance. The author of the contribution can set its ‘‘changeable’’status by clicking in the low-left corner of the sound pattern tounlock it, as shown in Fig. 3(a). After unlocking a sound pattern,it will be available for other users and will appear normally, notblurred anymore. With this kind of control, the aesthetic intentionof authorship is preserved. If some user wants to prototype oredit the other’s locked layer (or sound patterns), CODES offers aspecial mechanism called ‘‘modification request’’. This request isdone directly on the locked sound pattern and a ‘‘modificationmark’’ will appear for the sound pattern’s owner, who can acceptor decline the request (Fig. 3(b)).As an alternative, a negotiation process between these users can

be started, by using the ‘‘rationale’’ functionality. Indeed, due toexploratory nature of the CODES usage, one of its most importantcharacteristics should be the users’ possibility to perceive and

104 M. Pimenta et al. / Future Generation Computer Systems 27 (2011) 100–108

Fig. 3. Authorship control.

Fig. 4. Comment window.

analyze group members’ actions on music prototypes (or, to‘‘understand WHAT my partners are doing’’) and the reasoningbehind these actions (or, to ‘‘understand WHY my partners aredoing it’’). All of the aspects related to this support CODESprovides for argumentation (see Section 5.2) and awareness (seeSection 5.3).

5.2. Arguments in CODES

The Music Prototyping Rationale (MPR) mechanism is an effec-tive way to represent and to record explanations and argumenta-tions for each action or decision made during CMP. Each user mayassociate comments and arguments (in favor or against) to any ac-tion on any prototype element. Each argument is related to a useror the whole group and the current layer.The motivation for MPR is the ability for linking argumen-

tations to steps of a design process, proposed originally in theHuman–Computer Interaction area, and called Design Rationale(DR) [19]. It is a communication mechanism among design teammembers, to communicate past critical decisions, which alterna-tives were investigated, and the reasons behind the chosen alter-native. There are many models and notations for DR, like IBIS andQOC — see [19] for a good summary. Nowadays, DR is also adoptedby other disciplines (e.g. Requirements Engineering) and recog-nized as a possible way to allow a groupmember to obtain a betterunderstanding of other group members’ actions and decisions.In CODES, the basic elements of the MPR are ‘‘issues’’, ‘‘posi-

tions’’ and ‘‘comments’’. Issues correspond to decisions or actionsthat have been made or states which have been reached during anMP creation and refinement. For example, issues may be ‘‘Removalof a sound pattern’’, ‘‘Pause inserted after the 4th sound pattern’’,etc. Issues are goal-motivated consensual choices, concerningalternatives of the action course.

A ‘‘Position’’ is a statement or assert that resolves the issue.In the case of CODES, positions can be ‘‘pros’’, ‘‘cons’’, ‘‘idea’’, and‘‘important’’. They are graphically represented by the icons ‘‘smile’’,‘‘sad’’, ‘‘light bulb’’, and an ‘‘exclamation point’’, respectively.Comments are asserted in order to agree with a specific course

of action (comments in favor) or to express some objection(comments against). Additionally, comments may express somesuggestion, idea, question or generic observation about the issue.Comments are consensual explanation, not an individual messageinterchanged between actors. Therefore they are not a specific kindof message. Every decision or action may be linked to comments.TheMPR of CODES uses a hierarchical structure to represent the

reasoning of users (Fig. 4).Each entry in the structure may contain its author’s username

(User) and the content of the comment (Description). As users maywrite comments at different times, access to MPR in CODES is easyand possible from any location at any time.

5.3. Awareness mechanisms in CODES

The concept of ‘‘awareness’’ has received a lot of attention inComputer Supported Cooperative Work (CSCW) literature (see,for example, [20]), but it cannot be precisely and uniquelydefined [21]. In the context of CODES, there are three kinds ofawarenessmechanisms, in addition toMPRmechanism (describedin Section 5.2):• Action Logging, to keep an explicitly recorded track of the stepsthat led to the current prototype state.

• Modification Marks, to indicate to a user that a prototype hasbeen modified by others; and

• Version Control with layers, to keep an explicitly recorded trackof the steps that led to the current prototype state (described inSection 4).

M. Pimenta et al. / Future Generation Computer Systems 27 (2011) 100–108 105

Fig. 5. Action logging in CODES.

CODES has an action logging mechanism to record someinformation for all actions (like date, author, action, affectedprototype element, etc.), making them available for all partners toaware what was done and in which sequence. The action logging isresponsible for textually presenting a history of all actions carriedout by users in the system. When users perform changes on theprototype (insertion of a sound pattern, add explanations, etc.),they are recorded by the system. The result is a Group Memory, acommondatabase for all users sharing the samemusical prototype,which allows users—by querying the history recorded in the groupmemory — to understand not only their own activities but also theactivities of other group members. Fig. 5 shows a sample screen ofCODES,where it is possible to view an excerpt of the action logging.In the case of a sound pattern insertion, the system is able to

link this action with a corresponding mark in the editing area (ayellow background as shown in Fig. 5) if the user clicks on the logentry.CODES uses modification marks as the awareness mechanism

to alert new events to a user, like modifications on a prototypeor suggestions made by others. For each new action performed bya user, CODES (a) registers it in a log; and (b) marks it as a newcomment (for example, associating it with a ‘‘balloon’’ icon) or as anew contribution (with a ‘‘star’’ icon). See some examples in Fig. 6.By clicking on the icon, the user can retrieve information about

the action from the log.Another important modification mark in CODES is the modifi-

cation request: CODES marks elements of an MP (e.g. a sound pat-tern) to indicate an user has asked for a modification request tothis element from another layer. When the user needs to requesta modification to others, or when someone asks for a modificationrequest, CODES changes the icon accordingly. Some examples ofthis negotiation were presented as edition activities in Fig. 3 (a)and (b).

6. CODES usage: Preliminary experiments

CODES have been made available for use by actual users in ouracademic context. Following well-known subjective evaluationmethods from the HCI field, we made three experiments toobtain qualitative results from the use of the CODES environmentand its functionalities. The goal of first experiment was theevaluation of major usability problems and user satisfaction. Thesecond experiment was — beyond verifying usability problems —conceived to validate some cooperation issues related with theversioning tree and layered approaches. The third experiment wasconcentrated in evaluating the interaction assistance provided byCODES. Since the focus of this paper is cooperation mechanisms,only the second experiment is described.Our general goal was not only to get overall feedback (mainly

subjective) from users but to try out our proposals for CMP-oriented environments as well.In the experiment, five individuals, representative of the CODES

typical users (with ages from 20 to 35 years, having no musicalexpertise, and using CODES for the first time) had to performfifteen real tasks. See Fig. 7 for an illustration of the opinion pollcharacterization.These fifteen tasks were designed to simulate a scenario in

which a novice user would learn how to create, edit and cooperatein a musical prototype. Particularly, a cooperative scenario wascomposed specifically by three different tasks at the MP editinglevel. The tasks included creation, edition, and sharing of CMP.Time taken to complete all the tasks ranged from 20 to 50 min.The experiment carried out was the User Testing [22] and was

conducted in the presence of a facilitator (observer), a usabilityexpert. He just read each task for the user, and took notes of anyproblems found and any verbal comments from them. The subjects

106 M. Pimenta et al. / Future Generation Computer Systems 27 (2011) 100–108

Fig. 6. Example of modification marks.

Fig. 7. Opinion poll characterization of the experiment.

Fig. 8. A recorded session of user testing with CODES.

were instructed to talk what they thought while interacting withCODES, thus using the ‘‘thinking aloud’’ method [23]. Interactionand user comments were also recordedwith a video camera aimedat the computer screen (see Fig. 8).After performing the tasks, users filled out a formwith open and

closed questions. The open questionnaire posed seven questions

concerning Nielsen’s heuristics1 like visibility, contextualization,control and freedom, feedback, flexibility, and the musicalrepresentation in CODES as well.To answer to the eleven closed questions, a main question was

made: Do you agree with the following sentences? Thus, the subjectsshould choose one of the five options: Totally Agree, Agree, Neutral,Disagree, Totally Disagree.Different subjects were tested in order to get overall feed-

back of the users regarding usability, accessibility, and cooperativeissues. Besides, the tests aimed at discovering interface and inter-action drawbacks. Some users have also detected important draw-backs concerning the system feedback, according to the followingquotes:

‘‘Sometimes, the system would give more feedback’’. ‘‘I do notknowwhat is the session I am posting the comment’’. ‘‘I did notknow why should I choose a color when registering myself inthe system’’. ‘‘What means this icon in the editing area?’’

Despite these negative points, overall test results were favor-able and most of them have assigned ‘‘totally agree’’ as shows theFig. 9.The most important test results were those that allowed us to

identify some user needs that where not being addressed by theinitial design of CODES, and so would imply new requirements forthe system. For instance, users would like to do their contributionsand to combine themwith any of the others, but without changingeach participant’s original and previous contributions. Thiswas notpossible in an early CODES version. This test result is the origin ofa layer-based approach, described in [24].The experiment were intended to be developed in a very

restricted context, but until now it is possible to conclude that thesystem is intuitive and easy to use making users feel motivated byusing CODES for enhancing and sharing their musical experiences.

1 http://www.useit.com/papers/heuristic/heuristic_list.html.

M. Pimenta et al. / Future Generation Computer Systems 27 (2011) 100–108 107

Fig. 9. CODES general approval.

7. Conclusions

In this paper, we have presented some cooperation character-istics and mechanisms adapted for CODES to address the idiosyn-crasies of this CMP context, and discussed their rationale. We havepresented the motivation behind these adaptations: CMP dealswith the design of a music prototype. One of the main findings ob-tained during CODES development and usage is that systems aim-ing at providing effective support to such music creation activitiesof CMP shouldmeet equivalent specific requirements. Our ultimategoalwas to provide actual cooperation, social knowledge construc-tion, argumentation and negotiation among the different actors —most of them being novices in music — of MP design activities.This cooperation is supported here by a set of mechanisms spe-

cially adapted for CODES to handle awareness, music prototypingrationale, authorship, version control, and conflict resolution. Theyenable group members to use and reuse contributions from sev-eral versions of an MP, without losing track of each contributionand its individual author. The cooperative mechanisms of CODESwere designed and built in order to support a dynamic and cre-ative environment, enabling knowledge sharing by means of richinteraction and argumentation mechanisms associated with MPsevolution. Consequently, each participant may understand someundeclared principles and some informal rules involved in thecomplex process of music creation and experimentation, mainlyif this participant is a novice in music. Having access to the richinteraction and argumentation mechanisms in CODES, and experi-encing the process of music prototyping, we believe users may geta better understanding of the complex activities which aremusicalcreation and experimentation. In CODES, partners cooperate notonly by means of explicit actions on a shared object space and ex-plicit conversation, but also by interpreting the actions and, aboveall, the comments of other actors in their creative process.CODES is an innovative approach for collaboration in music, a

domainwhere it is very important to allow any user to identify andunderstand others’ contributions, independently of the creator,keeping each creator’s original ideas, intentions and ‘‘authorship’’,showing that networked music environments can offer even morethan ‘‘passive consumer’’ possibilities for novices in music. Sincewe have adequate and integrated tools, processes and concepts inone single environment, novice users can create music prototypes,cooperate effectively and experience the feeling of being thecreators of their own music. Finally, we think the proposalspresented in this paper— although developed for a specificmusicalcontext — can be useful to others CSCW design in other domains.

Acknowledgement

This work was partially supported by the Brazilian researchfunding councils CNPq and CAPES.

References

[1] YouTube [Online]. Available: http://www.youtube.com/.[2] MySpace [Online]. Available: http://www.myspace.com/.[3] Flickr [Online]. Available: http://www.flickr.com/.[4] M. Schedel, J.P. Young, Editorial, Organised Sound 10 (3) (2005) 181–183.Special issue on Networked Music, New York, NY, USA.

[5] M. Gurevich, JamSpace: designing a collaborative networked music spacefor novices, in: Proceedings of the 2006 International Conference on NewInterfaces for Musical Expression, NIME06, Paris, France, 2006.

[6] G. Weinberg, The aesthetics, history, and future challenges of interconnectedmusic networks, in: International Computer Music Conference, Göteborg,ICMA, Sweden.

[7] S. Jordà, O.Wüst, FMOL: a system for collaborativemusic composition over theweb. in: DEXAWorkshop, 2001. Proceedings... [S.l.: s.n.], 2001. pp. 537–542.

[8] P. Burk, WebDrum [Online] Available: http://www.transjam.com/.[9] N. Bryan-Kinns, P.G.T. Healey, Daisyphone: support for remote musiccollaboration, in: NIME ’04: Proceedings of the 2004 Conference on NewInterfaces Musical Expression. 2004, Singapore, National University ofSingapore, 2004. pp. 27–30.

[10] W. Duckworth, Making music on the web, Leonardo Music Journal, [S.l.] v.09(1999) 13–17.

[11] M. Subotnick, Creating Music. [Online]. Available: http://creatingmusic.com/.[12] M. Gurevich, JamSpace: a networked real-time collaborative music environ-

ment, in: Gary M. Olson, Robin Jeffries (Eds.), Extended Abstracts Proceedingsof the 2006 Conference on Human Factors in Computing Systems, CHI 2006,ACM, Montreal, Quebec, Canada, 2006, pp. 821–826. April 22–27.

[13] M. Farbood, E. Pasztor, K. Jennings, Hyperscore: a graphical sketchpad fornovice composers, IEEE C.G.A. 24 (1) (2004) 50–54.

[14] E.M. Miletto, M.S. Pimenta, F. Bouchet, J.P Sansonnet, D. Keller, Music creationbynovices should be both prototypical and cooperative— lessons learned fromCODES, in: 12th SBCM, 2009, Recife, Brazil. Proceedings, 2009.

[15] J. Conklin, Wicked problems and social complexity, in: Dialogue Mapping:Building Shared Understanding of Wicked Problems, Wiley, 2005.

[16] H. Rittel, M. Webber, Dilemmas in a General Theory of Planning, in: PolicySciences, vol. 4, Elsevier Scientific Publishing Company, Inc, Amsterdam,1973, pp. 155–169. [Reprinted in N. Cross (Ed.), Developments in DesignMethodology, J. Wiley and Sons, Chichester, 1984, pp. 135–144].

[17] S.J.B. Shum, The roots of computer supported argument visualization,in: P. Kirschner, S.J.B Shum, C.S. Carr (Eds.), Visualizing Argumentation Toolsfor Collaborative and Educational Sense-Making, Springer-Verlag, London,2003.

[18] H. Rittel, The Reasoning of Designers. Working PaperA-88-4, Institut furGrundlagen der Planung, Stuttgart, 1988.

[19] S.S. Buckingham, Design argumentation as design rationale, in: The Encyclo-pedia of Computer Science and Technology, vol. 35, Supp. 20, Marcel DekkerInc, New York, 1996, pp. 95–128.

[20] P. Dourish, V. Bellotti, Awareness and coordination in shared workspaces,in: Proceedings of the ACM CSCW 1992, ACM Press, Toronto, Ontario, 1992.

[21] O. Liechti, Awareness and the WWW: an overview, ACM SIGGROUP Bulletin21 (3) (2000) 3–12.

[22] J. Rubin, Handbook of Usability Testing: How to Plan, Design, and Conducteffective tests. [S.l.], Wiley, 1994.

[23] J. Nielsen, Evaluating the Thinking-Aloud Technique for Use by ComputerScientists, Ablex Publishing Corp, Norwood, NJ, USA, 1992, 69–82.

[24] A.F. Hoppe, E.M. Miletto, M.S. Pimenta, L.V. Flores, Cooperation in musicalprototypes design, in: 13th IEEE International Conference on ComputerSupported Cooperative Work in Design, IEEE, 2009.

Marcelo Pimenta is an Associate Professor at Instituteof Informatics, Federal University of Rio Grande do Sul(UFRGS), in Brazil. He is head of the UFRGS Computer Mu-sic Laboratory (LCM). He received his Ph.D. in Informatiqueat Université Toulouse 1, France, in 1997 and the bach-elor and master’s degree in Computer Science at UFRGSin 1988 and 1991, respectively. Since 1998, he is mem-ber of a multidisciplinary research group at UFRGS work-ing with topics in Human-Computer Interaction, SoftwareEngineering, and ComputerMusicwith emphasis in the in-tegration of these areas. Currently his research is focused

on collaborative design, adaptive interfaces, networked music, ubiquitous music,and user-centered software engineering.

Evandro Miletto is a researcher working at the Interdisci-plinary Center of New Education Technology, Federal Uni-versity of Rio Grande do Sul (UFRGS), Brazil. He is memberof the Computer Music Group (LCM) at UFRGS. Miletto re-ceived his Ph.D. and Master’s degree in Computer Scienceat the Federal University of Rio Grande do Sul (UFRGS), in2009 and 2005, respectively. Since 2002 he develops mul-tidisciplinary research including topics in Computer Mu-sic, HCI, and CSCW. He is also interested inWeb design andnetworked music focused on novice users.

108 M. Pimenta et al. / Future Generation Computer Systems 27 (2011) 100–108

Luciano Flores is a Ph.D. student in Computer Science atthe Federal University of Rio Grande do Sul (UFRGS), Brazil.His areas of interest are Human-Computer Interaction,Computer Music, Mobile Music, Ubiquitous Music, andComputers in Education. His other activities include DJing.

Aurelio Hoppe received his M.Sc. in Computer Science atFederal University of Rio Grande do Sul (UFRGS), Brazil.His areas of interest are Software Engineering, DistributedSystems, Computer Supported Cooperative Work, Webprogramming with Java, PHP, and FLEX applications.