You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

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.

Voting Interface

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. 

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.

Briefing

Scenario Tasks
Add Music
  • Add the song "Hey Jude" by the Beatles 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.

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. 

  • No labels