From CS 160 User Interfaces Sp10

Revision as of 18:11, 5 April 2010 by Vidya Ramesh (Talk | contribs)
Jump to: navigation, search


Group Roles

Problem/Solution Overview

Our application iCutDanceMusic is targeted towards dance group leaders and choreographers. Music is an integral part of the dance process, but dancers often use music in specific ways that conventional music players do not address.


Early on, we identified 3 tasks that reduce the productivity of a dance group:

  • Manually stopping and rewinding a section of music repeatedly
  • Attempting to seek to an exact time in the music for consistency
  • Needing to burn or compile sections of music for practice

These 3 tasks come about because of the need to practice a specific section of a song many times in order to perfect coordination. Even if only 10 seconds is wasted per cycle of stop/seek/rewind, this can lead to hours wasted over the course of multiple practices.


Our application seeks to resolve the issues above by allowing the user to dynamically splice and save clips of music from a whole song. By saving multiple clips and combining them, they will be able to create a 'routine' of clips, which can be used for performances or seamless integration of practicing many separate sections of music at once. By automating the process of starting/stopping a clip as well as putting clips together, dance groups may be more efficient in their practice methodology.


Easy - Editing a Saved Clip

This task has an user going into an existing clip and changing the length of the clip. Minimal movement is needed besides changing start and end times and saving, making this a fast and simple task for users.

Normal - Creating a New Clip

Creating a new clip requires more actions than editing one, making it a normal-difficulty task. Users first choose the song which the clip will come from, adjust the clip start/end times and then save and name the clip.

Hard - Creating a Routine

Creating a routine involves putting together multiple clips into a playlist organization. Users will repeatedly add clips and select the appropriate clip from the appropriate song. Lastly, the user must save the routine. Routine creation is difficult multi-step task, covering many of the application's features.

Revised Interface Design

Changes to Design Interface

After the user testing done in the Low-Fidelity Prototype assignment, there were a large number of changes we made to the design based on user feedback. Below, we display a table describing general changes to the design based on the user feedback.

Before (Lo-Fi) After (Interactive) Rationale for Changes
  • Issue from LoFi: While playing a cut piece of music, users sometimes had difficulty determining the length and location of the clip in the song. The scrubbers also brought up some issues; should they disappear or become disabled at certain points?
  • Changes: Instead of displaying the start and end times of the song next to the UI Slider, we decided to display the amount of time into the clip and the amount of item the clip has remaining. We also added an indicator so the user can track where they are in the clip that they are playing. Both of these will make it more apparently where the music is starting and playing from.
  • Issue from LoFi Users wanted to rename clips and routines when they wanted to.
  • Changes: We added a button near the navigation bar to be able to rename a clip. The button solution is not only intuitive for new users, but does not clutter up the UI too much.
  • Issue from LoFi: Changing the order of songs in a routine with our lo-fi prototype required the user to add and remove clips until the desired order was achieved.
  • Changes: We realized that iPhone natively supports drag and drop for table view cells. We used this functionality to provide an easier method of reordering clips inside of a routine.
  • Also, we made that big "Add New Clip" button, see the presentation notes for more writing on this.

Unimplemented Portions of the Interface

The following are sketches of unimplemented portions of the interface slated for the next iterations of our design. Greater detail on these unimplemented portions can be found below in the Prototype Overview.



Storyboards of Tasks

Here, we will want to go through all three of our main tasks (renaming/re-marking a clip, creating a new clip from scratch, creating a routine). We'll want to make storyboards for all three, similar to those in our lo-fi prototype, but just drawn out as graphics, with interspersed screenshots.

Prototype Overview

Implemented UI Overview

Here is a caption for the song list view (picture is a PLACEHOLDER).

Song List View [reference to picture of view]

This is the main view to see all the songs the user can create clips with. Accessed from the 'Songs' tab, it is hooked up to the iPod music library to display all the songs the user owns. Selecting a specific song takes the user to that song's clip view.

Song Clip View [reference to picture of view]

This view allows users to see the clips they have made so far for a specific song. The top bar has a back button which goes back to the Songs View. The edit button allows for users to rearrange and delete the clips they have already created. We used the default table view, which has red buttons on the left side to delete. Users can also re-arrange clip order by dragging them on the right. [reference to picture of edit view] At the bottom of the page is a button that allows users to create new clips, which will take them to the Play/Edit View. Choosing a clip can either take the user to the Play/Edit view or back to the Routine View if they were creating a routine.

Play/Edit View [reference to picture of view]

This view is the main interface that users will be working with to create, edit and save views. The navigation bar contains the name of the clip and a button to rename the clip. The majority of the editing is done on the custom UI slider, which has 2 movable sliders that indicate the desired start and end of the clip. Just like the regular iPhone, the information displayed on the left and right of the UI slider is the amount of time that we have played into the clip, and the amount of time remaining in the clip. There is also information above the slider that displays the start and end time of the clip to the user. The bottom row of the view has buttons to stop/start, repeat and save the clip. When the user chooses to play the clip, a green indicator appears in the slider to show where in the song the music is playing. At the moment, all data is automatically saved when the user edits the clip.

Routines List View [reference to picture of view]

Like the song list view, this view displays the saved routines that that user has already created. There are buttons to edit the existing list as well as to add a new routine. Choosing the edit function allows for the user to delete an entire routine, or change the order that the routines are displayed. Selecting a routine takes the user to that routine's view. Choosing to add a new routine takes the user to a routine page with no clips and a default name. The new routine is automatically saved into the routines list view.

Routine View [reference to picture of view]

A routine view contains the list of the clips that the routine comprises. The navigation bar contains the name of the routine, an edit button and a button to go back to the Routine List page. Editing allows for users to delete/rearrange the clips in the routine. At the same time, the button to go back to the Routine List turns into an "Add clip" button. This allows the user to add clips to a routine, as well as prevents the user from going back to another while trying to edit the routine.

Omitted Functionality

  • Creating favorite clips and routines

We omitted this because designating "favorite" clips and routines was more of a bonus usability feature than a task-critical feature. We will still be able to perform the core tasks of splicing music and creating routines without the Home page favorites, and we can still access songs and routines relatively quickly, even without the convenience of the Favorites page.

  • Repeat and prompt-to-play functionality

These functionalities were omitted because we believed that they were not necessary to demonstrate the basic tasks our application features. Playback of clips and routines is important, and enhanced features such as repeat and prompt-to-play were important features to our experimental users, but we felt these were supplemental convenience features whose absence would not detract from the core utility of the application.

  • Persistent data storage

This functionality was omitted in particular with regards to the Clip data type that we support in our application. The routines are persistent and stored across uses of the application if they do not contain clips, but the clips within them must be recreated during each use therefore the routines with clips are not saved. This is because the song source which we are accessing in order to create the clip is not constant between the simulator and the actual iPod Touch device. This makes storing the clips a very tricky and difficult task that will require a lot of concentrated attention to implement. This functionality is not representative of the tasks that we wish to carry out on our application for this particular iteration so we decided to save adding this functionality for the next iteration.

  • Routine play-back

This functionality is the ability to play a routine so that all the clips are played in the correct order, immediately one after another. We decided to omit this functionality because it was not essential to the three tasks that we wanted to implement. During this iteration, we thought it would be best to keep the focus of our attention on carrying out the three tasks. We believe that adding this functionality will require a greater depth of knowledge of the Media Player framework and will require lots of planning to implement seamless transitions between the various clips. Since we already decided not add persistent data storage of the clips, it seemed logical to also leave this functionality for the next iteration.

  • General aesthetic and graphic design

General aesthetic design was very limited, and we hope to create more eye-friendly color schemes/interfaces in the next few iterations. However, for a first prototype, we felt interactivity and functionality was much more important than aesthetic design.

Wizard of Oz Techniques

We used no Wizard of Oz techniques in this interactive prototype.

Code Documentation

Needs more?

We used the Media Player framework that is packaged in the iPhone SDK 3.0. This framework provides the basic functionality of playing and accessing the user's iPod library. However, it is restricted a read-only access and any changes made by the user must be stored within the application's data. Within the framework, the classes of MPMediaQuery, MPMediaItem, and MPMusicPlayerController were essential to the implementation of our application.

The documentation for the framework can be found here:

Presentation Slides

Last updated: almost midnight Sunday

File:Igroup int presentation.pdf

File:Igroup int presnotes.pdf

[add comment]
Personal tools