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).

DJ Interface

This is the interface used by the DJ to manage their music library, edit and create playlists, and start playing a playlist/open it up for voting. We elected to have two main panes. One displays all the songs in the library, while the other allows for the editing of playlists. This choice of one detail pane for the music library was motivated by our paper prototyping when we found out that multiple panes (such as one for song details and one for album organization) led users to be confused about how to use the interface. Another key design choice was to allow users to add songs to a playlist by dragging them. This choice was motivated by our paper prototyping when all the testers tried to drag songs but weren't 'allowed' to do so. In addition, we allowed for multi-select drag after computer prototyping and realizing there was an efficiency problem. An 'add song to playlist' dialog box was an
alternative to dragging but we found dragging to be much more intuitive and efficient for users.

Another important part of the interface was the use of tabs for playlist management. The use of tabs is common in many other interfaces so there was a relatively flat learning curve. After feedback from computer prototyping, we added a vote count to the songs in the playlist to give the dj more feedback and better visibility. The ability to rename a playlist was also added after feedback from computer prototyping pointing out the problem with error correction.

Voting Interface

This is the voting interface used by partygoers. A key design choice was to use plus and minus buttons to vote for songs. Originally, we had considered using a sliding interface. However, we noticed during paper prototyping that many people pressed the arrows that were supposed to afford sliding instead of actually sliding. The use of buttons ended up being natural and easy to implement. Only the song title and artist are displayed versus more possible meta data associated with a song such as length. Only those two fields were used to keep the interface simple and draw attention to the most important information about a song.

The icons on the buttons changed as a result of computer prototyping.
This was the original interface.
This is the new interface.

Computer prototyping showed that plus and minus buttons were more compact than words on a mobile phone device enabling the buttons to stay on the same line. In addition, neutral was changed to a vote count to give information to the users about how popular a song was. A vote count also makes it clear whether or not the users vote had been counted, a visibility problem noticed from the computer prototyping. Overall, the design of the voting interface was driven by simplicity and this fact was positively commented on in the heuristic evaluations.

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.

Server end for music management:

Possibly the most important decision was to branch off an existing opensource application designed for music streaming. While this cost a signficant amount of time in terms of getting used to their code base, and implementing the voting and UI in their framework, I think it ultimately saved time. However, this implementation tied us pretty closely to an using sql databases for a music management and votes. It is unclear whether this will scale very well, even to the 100 user mark.

In terms of UI design, people responded best to designs reminiscent of existing ones. For example, users liked having a tab interface for playlists. Although initally we thought it would be awkward, users also preferrred a simple table of all songs, rather than a more complex filtering system. 

Voting interface:

The voting interface was implemented within the framework of the existing open source application that we branched. This framework used jamon with linked java classes to handle requests. In addition to the templates, jQueryMobile was used, which adapted html compiled in a set syntax into a nicely displayed list that scales with various mobile platforms. This ended up working very well for us and, though it took a lot of tweaking, eventually made the interaction between music database and end user more simple.

Evaluation

Users

Describe how you found your users and how representative they are of your target user population (but don't identify your users by name).

User was a graduate student with some interest in music, not much in parties. User was friend.

User is an undergraduate with interest in music and parties. User not interested in throwing parties. User was friend.

User is also an undergraduate with interest in music and parties. User is somewhat interested in throwing small parties. User was friend.

Briefing

Users were given the same briefing from the paper prototyping.

Scenario Tasks

Add Music

• Add the album "The Fame Monster" by Lady GaGa to the library.
• Add the "Music" folder to the library

Playlist Management

• Add 3 songs from the music library to the default playlist
• Create a new playlist called "Friday"
• Change from default playlist to "Friday"

Voting

• "Like" a song
• "Like" a song, then change it back to neutral
• "Dislike" for any offscreen song

Usability Problems

 List the usability problems you found, and discuss how you might solve them.

Many users identified problems with drag and drop functionality with multiple items(Minor).  Swing's interface for this is somewhat less than intuitive, and more time could have been spent here.

Users would have liked to preview music directly from this application(Major). This would require enabling playback and/or streaming which was too much for us to implement in the limited time.

Users also felt it was awkward to give a URL directly out to friends, one user recommended using a QR code.

Users would have liked to see the songs re-order on the voting and playlist screens (Minor, Major respectively) The voting screen is client side scripting and could be re-ordered but would likely get confusing if ordering changed while editing. The playlist screen would simply require an event to be fired when a vote is cast and should be included.

User would have liked ability to save playlist using keyboard shortcut versus file menu (Minor). Add standard keyboard save shortcut.

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.

I definitely would have presented more fundamentally different designs, rather than modifications on a single theme. By the end of the iterative process, the end product was quite different(probably a good thing), but many of the changes occurred very late in the process. Also, in an attempt to save work, prototypes were done in swing, as to use them in the final design. It might have been more effective to do the products in an easier prototyping tool such as Flex in order to test more prototypes. In addition, we learned the value of testing and prototyping. Many issues that we hadn't thought of were brought out by these processes and led to a much better design in the end.  Testing and prototyping really showcased the benefits of iterative design, especially with regards to user interfaces.  By taking an iterative approach, we could take some risks such as having a sliding interface for voting. Then if it didn't work out, as in our case, we were able to easily change it to a better interface without suffering very much.

With regards to evaluating the results of testing and prototyping, it was very useful to aggregate all the comments. This made it easier to determine the importance of various comments since recurring problems indicated that the issue was a valid complaint. We attempted to figure out which features to prototype but trying to put ourselves in the user's shoes and thinking about the most critical functions.