Embed Size (px)
Citation preview
Voice Warm-up application
Eduard Gamonal
College of Engineering
Northeastern University
Boston, MA
Nathaniel Smith
College of Computer Science
Northeastern University
Boston, MA
Benjamin Vieira
College of Science
Northeastern University
Boston, MA
December 3, 2012
Abstract
This paper presents aspects of a study on usability ofa voice warm-up application for singers.
The study examined singer’s behaviour at the timeof asking them to use the software. We focus on theinteraction between the computer and the singer withspecial attention to a set of usability requirements.We conducted the evaluation with a high fidelity pro-totype that allowed us to explore non-typical inter-action with a computer: sounds and images, like apiano or a staff, in application software.
To conclude we offer a summary of the lessonslearned over the course of the iterative design processand some key ideas to improve in future projects.
Author Keywords
Human-computer interaction, HCI, sound, music,singer, warm-up
ACM Classification Keywords
H.5.5 Sound and Music Computing
Introduction
Technology has penetrated in all sectors of the so-ciety. People use these new tools in many differentways depending on the task they want to accomplish,their education, their environment or even their phys-ical conditions, amongst others.
Musicians use plenty of specialized devices thathelp them do efficiently everyday tasks of their field.Some questions arise, like ”What kind of special needsdo they have?” or ”Does technology help or bother asinger?”.
We open this paper with a description of the prob-lem we tackle. We then discuss the final design of
the application and the alternatives we considered,high-level implementation issues, and the procedureand results of the evaluation. The final section of thispaper presents some lessons on HCI, like the conve-nience of having a participatory design and a prac-tical use of Nielsen’s heuristics [1] and design princi-ples.
Problem
There are two main problems when it comes to warm-ing up singers. One, most singers do not know how toproperly warm up, and two, you almost always needa piano around to run the warm-ups. When you donot warm up, or do not warm up properly, singingwill put a lot of pressure on your vocal cords causingdamage. The problem with always needing a piano isthat pianos are large. If you live in a dorm or smallapartment you won’t have the space to keep one. Ifyou’re in college there aren’t many places where prac-tice rooms with pianos are available.
The target user for this application would be asinger, primarily aimed at a student in college, butalso for use by any singer of any experience level.
We want to create an app that you can use towarm-up your voice with. An app that will act asa general piano for warming up purposes, as well assupplying additional features to the user. It will havea section for browsing pre-loaded vocal exercises andselecting them to warm up. Each exercise will have anexplanation with it detailing what it does and how toproperly perform it. In each exercise you will be ableto play / pause it, as well as speed up and slow downthe exercise. There will be a favorites feature too inwhich exercises that the user performs frequently canbe added to a list of favorites. These exercises willappear on the home screen for quick access.
1
Design
Final high fidelity prototype
The application is separated into a home screen andthree different sections: ”Discover Voice Type”, ”Per-form Exercise”, and ”Tone”. The home screen con-tains links to the three sections as well as a list of allthe exercises favorited by the user. If none are favor-ited, the favorite box displays ”You don’t have anyfavorite exercise yet.”
The ”Discover Voice Type” section allows the userto find their voice part by harmonizing with a pianoand selecting their highest and lowest notes. Themain section of the screen is a large keyboard. It isone octave and shows the octave you are in above it.There are arrows on either side of it to change theoctave up or down. Below the keyboard are two but-tons. On the left is the lowest note selector and onthe right is the highest note selector. In between isa screen which shows you the last note played. If nonote has been played then it will say ”Play a Note”.At the bottom of the screen, the selected range ofthe user is shown with a final accept button. Whenfinished the users voice part will appear on the homescreen as well as a challenge button where the usercan challenge their old range to see if they have im-proved or not.
The ”Perform Exercise” section contains screensfor the list of exercises as well as the screen showingthe exercise running. The first screen that you aretaken to is the list of exercises. There is a clickablestar next to each exercise to have it favorited. Agold star means the exercise is favorited and can beclicked again to reset it. To the right of the list isa box containing the description of the exercise thatthe user has last clicked on. Under the descriptionis a button allowing the user to perform the selectedexercise. When perform is selected a new screen isopened. On the top of the screen the title of theexercise you are performing is displayed. In the mainsection of the screen is a treble clef with the notatedexercise written on it. Underneath is the controls toplay, pause, rewind, and fast forward the exercise. Atthe bottom is another tool which allows the user tospeed up and slow down the entire warm-up. Thefinish button is in the bottom right-hand corner ofthe screen exits the exercise and returns you to thebrowse screen.
The last section is the ”Tone” section. This screenis mainly for the user to have an easy way to get anote, for example if they are learning a song and needthe starting pitch. The screen is an octave keyboardwhich is identical to the one from ”Discover Voice
Type” to keep with internal consistency. It displaysthe last played note underneath the keyboard as tohelp the user if they are not proficient with a key-board.
Design revisions
Many designs revisions were made throughout theprocess of building this application. We realized as wewent through revisions that many of our broad cate-gories could be condensed into one thing. For exam-ple, learning a warm-up and performing a warm-upbecame part of the same portion of the application.We originally considered these different sections toseparate new from experienced users.The new userwould be presented with instructions and a speedslider that the experienced user may see as a nui-sance. As we went thought designs we realized howwe could keep the instructions out of the way enoughso that it wouldn’t become an annoyance to moreexperienced users.
Figure 1: Cardboard – Home Screen
Once we felt we had a suitable app that userswould like, we went to paper prototyping. We gaveto prototype to several different test user and real-ized that maybe the application was not as intuitiveas we thought. Although the prototype was only pa-per at this stage, many users had problems using thekeyboard widget we had designed for the DiscoverVoice Type functions. In addition, some of the cos-metic choices we made at this stage either confusedusers, or caused them to make slow decisions whileusing the app. Specifically, the favorites system, inwhich exercises can be selected to be shown on themain screen for easy playback, was not as easy forusers to learn as we had originally thought. This wasdeemed to be a problem with the affordance of the
2
Figure 2: Cardboard – Home Screen after adding afavorite exercise
Figure 3: Cardboard – Discover Voice Type
star icons we used to represent favorites selection, aswell as the visual limitations of the prototype itself.(Especially the difficulty in making an element of thepaper prototype look ”clickable”, which is easier toshow consistently with Java Swing widgets.)
Another revision we did at this time was getting ridof the results screen in the ”Discover Voice Part” sec-tion of the application. We decided to get rid of thispage because all the information the page was dis-playing was already being displayed somewhere else.The vocal range was already seen on the page the userwas on before, and the voice part is always shown onthe home page. All the page seemed to add was onemore click to get through to get back to the homepage.
We then received some heuristic evaluations from3 classmates with 20 issues each. They pointed outthat some elements of our interface did not conform
Figure 4: Cardboard – Browse Exercises
Figure 5: Cardboard – Exercise
with some of Nielsen’s usability heuristics. The mostprominent of these problems were code-based, butsome were interface design decisions that needed tobe changed. These changes include adding error re-covery options in the form of confirmations dialogues,ensuring the user would not exit the exercise pre-maturely. In addition, widget and button sizes werestandardized among forms of the application in orderto be consistent visually.
In our third and final testing we used a high fidelityprototype with test users. Again we realized, withthe feedback from our test users, that there were stillmany fixes we could make to the application. Weagain had problems with favorites. This time withthe star icon itself. Many testers thought the starswere just bullet points next to each exercise name.This was surprising but because many users had thisproblem we realized it was a very important fix. Wemade the icon larger and more apparent, making it
3
Figure 6: Hi-fi – Home
Figure 7: Hi-fi – Home Screen after adding a favoriteexercise
look more like an interaction and less of part of thebackground. Many users said that they thought thestar was just a bullet point and not something click-able. Another piece of feedback we got was on thekeyboard the user had no way of knowing what oc-tave they were on. This caused problems with theusers trying to harmonized with the keyboard onlyto find that the keyboard had jumped two octaves.We added a simple text display showing the octavethe user was in on top of the keyboard to remedy thisproblem.
Implementation
Functionality
The prototype implements enough functionality toaccomplish the tasks given to the users. These havethe following views available
• Main screen with favorited exercises
• Browse exercises
Figure 8: Hi-fi – Discover Voice
• Discover voice type
• Play tone with a piano widget
• Discover voice type
There is no business logic implemented. However,the view layer has all required behaviour to simulatea real application.
Technology
In order to test if the functional requirements andthe look and feel was acceptable, we decided to makesome prototypes. This way we could check the useful-ness of the application, validate requirements and seeif our metaphores suited well the needs of our users.[4]
Two kinds of prototypes were implemented: lowfidelity and high fidelity. We built in all the neces-sary functions to test a certain set of tasks (verticalprototype), so in every new version of the prototypewe made design changes, but did not necessarily addnew features. Not being committed to one imple-mentation or idea let us apply changes rapidly andgo back to the users to test it.
The first implementation was a cardboard proto-type with a few detachable parts. The size was ad-justed so that it could be used with fingers instead ofa mouse. Because it had a clunky look, users gave usfeedback about their intentions, actions and expectedresults instead of non-interesting aspects in this stage,like colors or typeface. A member of this team playedcomputer and changed all detachable parts and othersmall pieces so as to have changes in the data dis-played that are consistent with the user’s action. Be-
4
Figure 9: Hi-fi – Browse
Figure 10: Hi-fi – Perform Exercise
cause a real system would generate music for the userto sing along, the person playing computer also sang.
The high-fidelity prototype is coded in Java 6 SEand needs to be run from Netbeans on any operat-ing system with a Java VM from Oracle. Ideally itshould run in a browser as an applet but the Javabrowser plug-in does not allow certain actions for se-curity reasons. The sound is generated with MIDI(javax.sound.midi.*).
The first experiments with sound generation madethe UI hang. As expected, CPU intense work needsto run in a worker thread to prevent the UI threadfrom blocking. Otherwise the application is not re-sponsive and this affects dramatically the user expe-rience. In any case, sometimes the application needsto be restarted after using the sound system. Prob-ably the sound device is not marked free so the nexttime the prototype requires sound, it can not gainaccess to it. This issue does not interrupt any of thetasks assigned to the user.
Figure 11: Hi-fi – Play a Tone
Because this is a prototype without any back-endlogic, not having a data model made it harder to im-plement the favorites feature. Users could not test itin the first iteration. It became available in the nextversions of the prototype in order to get feedback forthis feature.
Custom elements on screen, like the piano and thefavorites icon, are not widgets for simplicity. Theyare images in a label with OnClick callbacks. Theirlogic is encapsulated in a function and a very simplesystem of asynchronous messages solves the issue ofmaking data consistent across multiple windows.
Future work and issues
Extra on-screen cues, like pointing the current notein a staff while performing an exercise, are out of thescope of the project at the time of writing this report.However, implementing this feature is trivial. Wesuggest having a vector of variations of the image thatcontains the staff or, maybe more efficiently, overlay-ing another Swing component that behaves like anarrow.
Icons belong to the Tango Project. Because ofa lack of graphic design skills, some images mightnot be the best choice and affect visibility and map-ping of actions. Text next to them should compen-sate this bias. These icons are widely used in theGnome project. However, they are not common inMicrosoft Windows or MacOS. This clearly affects in-tegration with the platform and, therefore, externalconsistency.
5
Evaluation
Method
The target user is a singer, most likely in college.They can range in age from 13 - 50. Their ethnicity,or education should not make a difference on usingthis application. They do not need to have extensiveknowledge of computers. They can be at any levelof singing, from beginner to professional. This appli-cation is not intended to be used by people who aredeaf or blind.
We did two sets of user testing for this applica-tion with 5 participants each time. The first usinga paper-prototype, the second using a high-fidelityprototype. We scheduled and met with each user ina private room and had them preform the tasks given.One person welcomed and explained them the proce-dure and the others observed and took notes. In thelow-fidelity prototype, one team member played thecomputer. We then conducted a semi-structured in-terview to get comments and general feedback. Whenall the user testing was complete, notes were synthe-sized and a list of changes to the prototype was pro-posed.
Users
The users who participated in the evaluation were allsingers between the ages of 18 and 23. Both menand women were tested. All users were from vari-ous a-capella groups from around campus who grate-fully agreed to help out. These users had varying ex-perience with computers and applications, which al-lowed us to test users with similar singing experiencebut different computer backgrounds. The only demo-graphic which we would have ideally tested would bea group of older, less technologically inclined singers.Due to the difficulty involved in setting up a testsession with professional singers, however, we de-cided that a cross-section of users from singing groupson campus represented the majority of our primarystakeholders, and geared our design for the use ofthese singers.
In-lab Procedure
We started each section with a briefing describingwho we were, what we were trying to do, and whatwe needed of them. We let them know who the peoplewere in the room and how they would just be takingnotes as the tester was performing the tasks. We ex-plained to them how in no way was anything theirfault in performing the tests and that they should
just try to do the given task to the best of their abil-ities. We let them know that none of their personalinformation would be given out.
We gave each user three tasks to complete whileusing the application:
1. Discover their voice part and return to the mainscreen to view the results.
2. Find and perform the given exercise.
3. Favorite an exercise so that is shows up on themain page, for future use.
After they completed all the tasks we asked forfeedback and asked them what they were thinking asthey went through the different tasks.
Incidents
Throughout the process we isolated multiple designproblems from user testing.
Many users had problems finding out how to fa-vorite exercises. When told that to favorite an exer-cise they must click the star icon, many replied bysaying that they thought it was only a bullet point inthe list of exercises. To remedy this and to make thestar icon stand out more against the list, we made itlook more like a click-able part of the interface.
Users also had problems using the discovering voicesection of the application. It would usually take theuser a couple seconds before they clicked a piano keyand determined how it worked. We realized thatthere was not enough instruction on what exactly theuser was suppose to do. In the future, a different wid-get should be designed with clear cues.
Sometimes instead of clicking the browse button,users would click the ”tone” button and get lost. Werealized that the label ”tone” might not be the mostintuitive label. To fix this we re-labled it ”piano”,which users found better represented the functional-ity of that part of the application, as well as avoidingconfusion with the exercises.
We also found problems with the code itself duringtesting. We had issues earlier in which the descrip-tions between the different exercises would changedue to a bug. We fixed the code so the prototype didnot do this anymore. We also had problems with textoverlapping and getting squashed together. These is-sues were formatting problems in Java and were easilyaddressed to make text appear correctly.
Conclusion
Throughout the course of the project, we have at-tempted to create an application which can perform
6
all of the warm-up tasks a vocalist usually carries outwith a piano. In doing this, we had to successfullytranslate a physical instrument into an interface onthe computer that replicated the tasks that singersare used to carrying out, while adding all of the ad-vantages of being a piece of software.
Some of our most difficult tasks in the iterative de-sign process for this project arose from the challengesof condensing the piano into a screen sized applicationthat provided the same affordances of the instrument.Combining our knowledge of computer science, mu-sic, and interface design, we created several differentdesign ideas for each feature of the program.
By subjecting each stage of our interface to usertesting, as well as soliciting the evaluations of ourpeers, we were able to isolate usability problems thatwe had not considered. We found, through these eval-uations, that users desire to transition to the app fortheir every day warm-up tasks was highly dependenton initial learnability and efficiency of the applica-tion. Considering this, our focus in developing theinterface was to combine these two metrics by cre-ating an interface that was simple and minimalist indesign, while adding features to promote efficiency forthe learned user. We focused the application on thediscovery of voice type, and the performance of exer-cises. The browse dialog in particular is an example ofthis: new users can look through the entire catalog ofexercises while an experienced user can favorite cer-tain exercises, so they can be played in seconds fromthe main screen.
In today’s climate of portable electronics andlightweight utility applications, we attempted to cre-ate an application which allowed singers in any lo-cation to, with a smartphone or other device, warmup their voice without requiring bulky instruments orequipment. In the same family as guitar tuning ap-
plications or recording applications, we hoped to usethe creation of such an application to examine theunique challenges of designing software for use in thefine arts. Iterative usability testing with singers andvocalists has demonstrated both the viability of theniche market for music applications of this nature, aswell as the vital importance of user feedback in thedesign of such applications.
Acknowledgements
The work of this paper has been supervised by Tim-othy Bickmore and Lazlo Ring.
Heuristic Evaluators: Matthew Tebaldi, RyanWilliams, Benjamin Doyle, Deniz Ozkaynak.
Testers: Members of NU Acapella groups, espe-cially the UniSons.
References
[1] Jakob Nielsen and Rolf Molich, Heuristic eval-uation of user interfaces, Proceedings of theSIGCHI Conference on Human Factors in Com-puting Systems (New York, NY, USA), CHI ’90,ACM, 1990, pp. 249–256.
[2] D.A. Norman, The design of everyday things, MitPress, 2002.
[3] Y. Rogers, H. Sharp, and J. Preece, InteractionDesign: Beyond Human-Computer Interaction,John Wiley and Sons Ltd, 2002.
[4] D. Stone, C. Jarrett, M. Woodroffe, andS. Minocha, User interface design and evaluation,Morgan Kaufmann Series in Interactive Technolo-gies, Elsevier Science, 2005.
7
