Pick Up Piano - GR6

DESIGN

Paper prototypes, focusing on the right problem: We discarded the concept of having a multimodal interface, i.e. our final design focuses entirely on ear training and does not have the “record and share” functionality.

Learnability, paper prototype: We have a sliding panel on the top of the page, which allows the user to either view the instructions or do ear training. This mechanism was a much better alternative to having instructions show up in dialog boxes and then disappear forever.

Learnability, efficiency: The final ear training exercise process is instinctive, fast to play, and can be entirely manipulated using keyboard shortcuts with minimal wait time in between commands.

Learnability, heuristic evaluation: In our earlier computer prototype, users had a difficult time interpreting multiple notes delivered by the interface while ear training. We discovered that learnability is best achieved by playing a single note at a time, and allowing users to guess them in succession. This design can also be smoothly expanded in many simple ways, for example, to allow for chords, or timed play.

OVERALL APPEARANCE

Color, heuristic evaluation: Our color scheme from GR4 was criticized by several of our GR4 testers, so we completely revamped it. We went from a plain white, gray, black color scheme to a wood based color scheme that uses black and a few pastel colors to draw attention to immediately relevant features. One of our user testers expressed that pianos don’t actually change color when touched and our TA pointed out that some of the colors we used earlier are very saturated, so we changed our piano's response on click be a much more modest color changes.

Fig: Overall Appearance

PANELS

The three panels from the initial GR4 prototype were kept, as they were well received by our testers.

Efficiency, heuristic evaluation: Their sliding animation was sped up, to increase efficiency, as suggested by one of our GR4 user testers. In the final implementation, the panel that it defaults to is controlled by cookies, also to increase efficiency, as a user mentioned they wouldn't want to flip through the first two panels every time they came to the page.

Learnability, paper prototyping: As mentioned earlier, the panel design gives the user the flexibility to skip reading the instructions and still know what to do in order to go back and read them. This increases the learnability and turned out to be a much better design that the dialog box.

Fig: First Panel

Fig: Second Panel

Fig: Third Panel

PIANO

Color scheme, heuristic evaluation: As mentioned earlier, the color scheme of the piano was redone to be much milder. Default colors are a pale golden gradient for the white keys, to subtly match the wood in the page background, and the black keys have a slight white gradient on the edges.

Affordance: On clicking a key on the piano, the gradient goes away leaving just the dominant color. The initial gradient gives the user the affordance that the keys can be pressed, and removing the gradient gives affordance towards the fact that it is already pressed.

Mode visibility, heuristic evaluation: When the user starts an exercise, possible keys are highlighted with a pale blue gradient. When users guess keys (using the mouse or keyboard shortcuts) the keys highlight a pale solid green or red based upon whether the guess was correct or incorrect respectively.

Mode visibility, heuristic evaluation: Several of our user testers felt that exercises lacked a feeling of completion, so we came up with the idea of persisting a correct guess (once the correct note is clicked, it remains highlighted in pale green until the next exercise is begun), which helps indicate the completion of an exercise and improves learnability by encouraging the user to try something else, besides the piano (i.e. the "New Tone" button).

Fig: Piano

SETTINGS

External consistency, heuristic evaluation: The settings dialog was cleaned up and a "Save" button was added, since some users were confused about when settings went into effect.

Fig: Settings

IMPLEMENTATION

Playing the piano was revamped completely in between GR4 and GR5. Previously, there were a number of problems with playing on the piano

i. scratchy wav files with a hiccup at the beginning of each file

ii. only one key could be played at a time (no chords)

iii. it only supported Chrome (Firefox used to give a mpeg/mp3 can’t be loaded error)
All of the above affected how smooth our interface felt when played on browsers, as scratchy audio and notes cutting each other off did not feel like a real piano. We fixed all the above problems by using .ogg files instead of .mp3 files. We also used better quality files we found after in a MIDI library on github.
The biggest design decision to simplify the exercise structure made our implementation even simpler, as we no longer needed to generate a database of exercises. Instead, the application now randomly chooses one out of a subset of notes to test the user with.
We do not actually have a backend (i.e. all our code is javascript, css and html). Also, out javascript code is very modular. We have pseudo-classes for piano, exercise_controller, cookie_management and so on similar to the structure for the “Rules” and “Board” we saw in the Checkerboard homeworks.

EVALUATION:
Many of our users were people who we interviewed back during the need-finding stage. they previously expressed interest in testing the final product, so they were easy to call back for a round of testing.
BRIEFING

The domain of our project is music, in particular, piano.

Our platform provides two different functionalities:

1. Free-play:
   • An interface to play piano on a computer
   • For people who don't have access to a real piano

1. Ear-training:
   • A technique through which one can learn to distinguish different elements of music (e.g. notes, chords) solely by hearing.
   • For people who want to transition from "read-and-play" to "listen-and-play"

TASKS

1. Play anything you feel like on the piano.

2. Change the settings, from beginner to intermediate, and make sure the keyboard shortcuts are showing.

3. Try out a few rounds of training. You are welcome to play for as long as you like.
DEMO

We did give a very short demo for the users before letting them have a go at it. The demo was just to demonstrate that the interface could be manipulated with the keyboard as well as the mouse. We wanted users to get the more efficient keyboard-based experience, because we imagine that's how most people will end up interacting with the interface, and we wanted their comments regarding that experience.
USABILITY PROBLEMS AND PROPOSED SOLUTIONS

The following are the problems we got from the 4 users we interviewed. Each problem is listed with its proposed solution:

• Immediately not clear piano can be controlled by keyboard (learnability)

We will show the keyboard shortcuts without the user having to set it. We have had discussions on when to show the keyboard shortcuts in the past, and we’ve been going back and forth between two ideas over iterations.

• Difficulty level description not important (aesthetics, unnecessary redundancy)

We propose to have a “difficulty level” visible div with only information being “beginner”, “intermediate”, and “advanced”. This is also a discussed topic, and we thought it would be a learnability problem if we don’t mention what the difference among the difficulty levels is.

• Difficulty level not visible but taking a lot of space (aesthetics, visibility)

Proposed solution same as above.

• Feedback notes are shown when playing, but in reverse order (learnability)

We propose to show notes in order of older to recently played from left to right. Previously, we showed the most recently played note at first, which was probably unnatural for the users.

• Feedback notes not beautifully shown (aesthetics):

One of our solutions is showing the notes played in musical notation (similar to sheet music). Another solution is to just make current letter notation bigger and nicely spaced.

• To get to the free play, I have to refresh the page (safety, efficiency)

We will add a button that clears the ear-training exercise and returns the users to free-play.

• No way of seeing progress (learnability)

We will add scores according to the accuracy of the user on the test, and give them labels such as “bronze”, “silver”, and “gold” according to their performance in each difficulty level.

REFLECTION:

We learnt a bunch of things over the course of the semester, for example

i. the importance of prototyping, and that users will always bring forward issues that never occurred to us before talking to them

ii. since our platform was super interactive (live piano on the screen), paper prototyping did not allow us to test some aspects effectively.

iii. our paper prototypes helped us narrow down to the actual problem even further, i.e. our needfinding was reinforced during user testing on the interface.
I think we underestimated the importance of prototype appearance fidelity. If we had another chance, we think it would have been worth the effort to make prettier paper prototypes, and have higher fidelity on the front-end for the GR4 prototype. Our users were consistently confused by and fixated due to problems arising from low fidelity in our interface, and thus gave us less useful information for iterating.
Overall, we are pleased we took this course and made our first significantly involved website. The iterative implementation and feedback process enforces by the course made us realize its importance, and also how to execute it well. We will continue to use the principles we learned as we expand on the what we have already built.