Final Design

"Describe the final design of your interface. Illustrate with screenshots. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluations you did (paper prototyping, heuristic evaluation, and user testing)."

Screenshot

Explanation

Originally, the main screen looked like the extended song list below. Our final design adopts a splash-screen-like design in order to highlight the name of the app and reassure users that they're in the right place, while remaining functional with a prominent "new song" button. The background is intended to be aesthetically pleasing but unobtrusive.

We limited the main screen to three saved songs to avoid overwhelming users. The "new song" and "about" buttons remain prominent. Tapping on a song launches the compose screen, shown below. Our original design included small "rename", "duplicate", "export", and "delete" buttons on each song, but our paper and heuristic evaluations noted that such nested buttons were confusing and difficult to use on a small screen. We therefore replaced them with a menu accessed by tapping and holding for a second or so; this method is nonobvious, so we also included an instructional note.

Renaming a song works by replacing the name in the song button with an editable text box; when the user submits (presses enter) the song is saved. Duplicating a song creates a new song named "Copy of NAME" and enters rename mode on that song. Deleting a song asks for confirmation, then slides the song button rightward off the screen. (It would perhaps be clearer for the button to shrink to nothing vertically with the buttons below sliding up, but technical properties of the Android API make implementing this animation difficult.)

Exporting uses native Android sharing functionality to display a list of possible transfer methods for the user to pick from. A MIDI file containing the song is sent via the specified method.

If the user clicks the "see all" button, this screen is shown. It lists all saved songs, allowing scrolling and searching (the list updates as a user types in the search box).

Here and above, each song button shows in approximate units the time since the last edit. Our original design used an absolute timestamp with second granularity, but testing convinced us that the extra precision wasn't useful. Currently the minimum interval shown is "<1 minute"; the display refreshes periodically in order to remain accurate.

The "about" button takes users to this screen, which is just a static message.

This is the compose screen for a song with no notes in it (e.g. a newly created song).

On the left is a vertical black line, which is the cursor showing the current temporal position in the song. Tapping on a blank section of the display moves the cursor to that point.

Along the top are various control buttons:
- "Play" starts playing back the song as audio; it's currently disabled because the song has no notes.
- "Record" starts recording notes from the microphone; this is described below.
- "To Start" moves the cursor to the beginning of the song, and is disabled because the cursor is already there.
- "Undo" and "Redo" work at the level of 'actions', either record or edit; these are described below.
- "Save" saves the song to private storage in the device memory.
- "Back" returns to the list of songs.

Along the bottom are track-manipulation buttons. The four colored buttons switch the current track, and the right button brings up the track tools menu. These are all described in more detail below.

A click track plays while the user is recording. The cursor turns the color of the current track, and moves rightward across the screen (the display scrolls so that the bar is never more than 3/4 of the way across). Notes are created at the cursor position when the app detects singing, and lengthen until they change pitch or stop; notes are deleted if the cursor hits them while recording into the same track. All buttons are disabled here, but "Stop" is available to stop recording.

Pressing "Stop" commits to the undo stack a record action, which incorporates all deleted notes and created notes. Thus, no matter how many notes a user records before stopping, all will be undone by one press of "Undo".

Here the user has stopped recording on the green track, and started recording on the purple track. All four tracks are drawn on top of each other; notes on the same track can't overlap, but notes on separate tracks can.

Though it's not pictured here, the play mode behaves similarly; all buttons except "Stop" are disabled, and the cursor moves rightward, playing each note it hits. However, the cursor is black, reflecting that notes from all tracks are played. (From heuristic feedback, if "Play" is pressed when the cursor is at the end of the song, it starts playing from the beginning instead of playing to the end i.e. doing nothing.)

Here notes have been recorded into all four tracks. Notes from the currently selected track are bright and large; other notes are dim and small.

The 'new' editing interface. Tapping on a note causes these icons to appear. Tapping the trash can deletes the note. Dragging the side arrows left or right changes the start and end points. Dragging the middle icon vertically changes the pitch of the note, and dragging it horizontally moves the whole note without changing its length. As notes in the same track can't overlap, the note stops when it hits something, and a red glowy thing appears to signal that it can't move or extend anymore.

Tapping away from the note deselects the note (and may select another note if that note was tapped). All changes made before deselecting or deleting the note are committed to the undo stack as an edit action.

This was approximately the original editing interface in our paper prototype. We decided to implement it because the 'old' interface below was confusing for some users, and direct manipulation seemed more intuitive. However, this interface is also somewhat suboptimal because the icons are small and hard to tap, and multiple accurate taps are required to successfully edit a note.

The 'old' editing interface. Tapping on a note causes this overlay to appear. Tapping the trash can deletes the note. Swiping left or right on the left side of the screen moves the start of the note backward and forward in time; swiping horizontally on the right side does the same for the end of the note. Swiping up or down in the middle of the screen changes the pitch. There's no way to move the note without changing its length. If the note tries to expand but hits something, it stops and a red glowy thing appears; also, the arrows that don't do anything are crossed out.
Tapping the back icon resets the change and commits nothing to the undo stack. Tapping the save icon commits all changes made as an edit action (as does deleting the note).

This was the interface we switched to for our second paper prototype iteration. It was intended to make it easier to edit notes by only requiring one accurate tap, and then giving users the whole screen for swiping. However, the overlay makes it difficult to see what's going on with the note, and even which note is selected; there's not enough feedback for actions the user takes.

Tapping on the track tools button brings the user to this screen, which has color-coded controls for each track. A muted track doesn't appear in the compose screen and produces no sound during playback.

The instrument menu allows the user to choose what musical instrument the track will be played as.

 

 

Implementation

"Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface."

Evaluation

Our users were friends from our living groups who had varying levels of interest in music. While they're all MIT students and so might not be generally representative, MIT students seem to have a pretty wide range of musical inclination and so weren't a particularly bad sampling of our user population, though most of them were programmers (don't think any of them had programmed on Android before, though). Our app aims to be usable by people with varying levels of music experience and who are probably somewhat younger, creative and tech-savvy enough to carry a smart phone.

We conducted user tasks by telling the user the purpose of the app (record songs without having to figure out the musical notation and when you're on the go) and the target audience (should be usable by people without a lot of musical experience).

We mentioned that they should think out loud, and that we were testing the app's usability, not their intelligence.

We had two editing interfaces that we can't decide between. We tested this by having different users test different editing interfaces first, give us their comments on it, then switch and give us their comments on the other one. I should've been careful to not tell users who made which interface, but I think I failed at this for the first two.

We tried to stay silent during observation, only giving tasks, then at the end asking questions about certain things the user did that they didn't explain, or things they may not have discovered.

Tasks

1. Record something
2. Edit
3. Add a harmony line
4. Export

Transcripts

These should be summarized for final submission, but they're here in full for you guys to look at.

User 1

Android User
A capella singer
Starting with old edit interface, then getting commentary on new

1. Record Something

2. Edit a note

3. Record a harmony or something

4. Export song

Did you notice you can change instruments?

What did you think of note editing interface?

Try (DD's) interface. I tell him my phone takes longer to record things.

Compare them.

User 2

Using DD's interface first.
iPhone user
Casual composer, doesn't often finish songs

1. Record a song

2. Edit

3. Record another track

4. Export the song

What do you think of this editing interface?

Try Alan's interface

Impressions on this interface

Compare interfaces.

Could you tell what's disabled?

User 3

We're starting with Alan's interface.
Singing and playing instruments since he was 7
Doesn't own a smartphone, so I briefed him on Android usage. Function buttons, long tap, and zoom gesture.
Course 18 and 8, "I'm definitely not a computer person"
We are sitting next to the piano and I mention that piano records nicely.
Bit worried about this user test because he seemed unwilling to hurt our feelings or worried about not making mistakes.

1. Record a melody

2. Edit a note

I suggest he tries to move a note over, since he didn't try it.

3. Record a harmony

4. Export the song

Opinions on this note editing interface?

What is x?

Try DD's interface.

Opinions on this interface?

Asked if he noticed moving left to right in this interface

User 4

Starting with DD's interface
"I warn you, I do usability testing for my lab, so I will, like, give you user interface feedback."
singing for as long as can remember in a wide variety of genres
"I just finished singing, so I'm warmed up"
Course 6, so technically advanced
"I don't have any theory background, only performance."

1. Record a melody

2. Edit a note

3. Record a harmony

4. Export the song

Try other interface

Compare interfaces

Is there anything in (alan) interface you would want in (dd)?

Unprompted

Disabled buttons

Discovered usability issues

Issue

Description

 

 

Reflection

"Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations."