Design Description:
|
Logging in
Each music director has their own account so that starting views are pre-populated with the albums that they've recently uploaded or approved. Furthermore, things like CMJ reporting data can be pre-filtered to the genres which they each deal with. |
 |
My Uploads
The starting screen after logging in. Approved and unapproved albums are listed on the left hand-side. In the prototyping stage there was some contention between efficiency and learnability/safety. In particular, a more spread-sheet like design for fast input of details and approval versus a more visual view with more whitespace. During the paper prototyping testing stage, there was some inconclusiveness as to the preferences of our user population, but this was resolved as the best way to move forward. |
 |
My Uploads: Dragging Files
A gray lay-over appears covering the entire screen when files are dragged over the interface. This was decided on during the paper prototyping stage as a clear way to inform the user that they can drag and drop anywhere, and not just the location that says "Drag files here to upload". It was a design decision to make dragging and dropping the only way to upload (as opposed to copy/pasting links or using a button) for simplicity. |
 |
My Uploads: Dropped Files
A screen appears informing the user of how files will be uploaded, as well as additional affordances for file manipulation within this dialog. |
 |
My Uploads: Upload Progress
A progress bar shows how close each upload is to completion. The pause buttons allow the user to pause the upload. It was decided after paper prototyping that this would be convenient since users should always be able to stop an upload. Additional, album details cannot be edited during the upload stage, this was decided for simplicity after paper prototyping since allowing detail editing would complicate auto-detection of details from the music files themselves (e.g. if the user is currently editing album name, and we find the album name from the mp3). This is a trade-off of efficiency for safety and simplicity. |
|
My Uploads: Uploaded
In most cases (like this one) details can be taken directly from the data found inside the music files, such as the album name, artist name, release date, record label and (sometimes, but more rarely) the cover art. |
|
My Uploads: Deleting Album
This was a major change we made after user testing during the prototype stage. Originally, a trash bin appeared in the upper right corner of the album detail pane, but it appeared out of the locus of attention such that users failed to notice it. When they did notice, they tried to drag albums onto the trash bin (instead of clicking directly on the trash bin). We decided to instead create two buttons on each album with clear color coding for Approval and Deletion. Deleting an album requires a dialog confirmation for safety. |
 |
My Uploads: Editing Album Details
Hovering over any editable field shows a yellow highlight around that particular field. This is to make it clear to the user which fields can be edited. For album details, clicking on a field opens up a small dialog allowing for immediate editing of the field. Saving the input requires either an enter key-press or clicking on the plus icon. This decision was made for both safety (accidental edits) and learnability (the pop-up has a title which tells you which field you're editing, e.g. artist name, album name, record label). These decisions were made after paper prototyping. |
|
My Uploads: Release Date
Clicking on the release date field opens a date-picker which allows selection of a date. |
|
My Uploads: Adding Genre
Clicking on "Add Genre" (or the plus icon next to it) opens a dropdown which allows for selection between either the most common genres used by music directors at WMBR or adding a custom-genre by typing in the text field at the bottom of the dropdown. These decisions were made after paper prototyping testing as music directors expressed their desire to tag albums with multiple genres, as well as add new genres easily. Later (in our final user testing for this GR) we discovered that they were excited/pleased with this feature.
Note: Clicking on "Add Genre" before our heuristic evaluation did nothing, but it was noted several times during heuristic evaluations therefore we changed it to have the same functionality as the plus button. |
 |
My Uploads: Editing Track Name
Editing track names allows for inline-editing. This was decided upon for efficiency's sake (e.g. an album with 15-20 track names we couldn't pull directly off the music files) even though it poses an internal consistency issue when compared to editing album details. Pressing enter or clicking off the inline field saves any changes made. Note that one can also modify the artist associated with each individual track (for compilation albums where each track can be associated with a different artist), as well as delete individual tracks. These features were added after paper prototyping testing based on comments made by users. Each track can also be flagged as FCC dirty (the triangular icon next to the "x" by each track) for marking a track as having swear words (something music directors noted as being useful). |
 |
My Uploads: Album Approval
Clicking on "Approve Upload" moves the album to the "Approved Uploads" section on the left. If a user tries to click "Approve Upload" on an already approved album, a tooltip informs them that the album has already been approved. |
 |
My Uploads: Searching Uploads
Entering text into the search field in the top left automatically filters the uploads on the left. Searched fields include artist name, album name, record label and (in this case) genres. The decision and implementation came after heuristic evaluation where it was noted that many uploads would create difficulties in finding a particular upload. It was also suggested that we make the approved and unapproved lists collapsible, so a minus button appears in the top of the lists for collapsing these lists (which changes to a plus icon when collapsed). |
 |
Reporting
Clicking on the "Reporting" tab brings the user to the reporting section of the system. The reporting view (for CMJ reporting) is currently displaying all data for all albums. The genre tags (internally consistent with the tagging system in the "My Uploads" pane) allows for filtering the data by genres. After paper prototyping it was noted by users that having more data present in the table all at once would be useful (despite the added complexity of additional columns) such as the play count in the past week, past two weeks, past month and all time. This is to make the job of reporting play count data to CMJ easy. |
 |
Reporting: Filtering
The reporting view in this screenshot has been filtered for Electronica and the table has been sorted by plays in the last month in descending order. This is similar to the process a music director would go through in order to prepare the data for CMJ reporting. |
 |
Reporting: Export to Excel
Clicking on "Export This Table to Excel File" downloads a .csv file which can be immediately opened in Excel to show the data, filtered as per above. |
Back to the top
Implementation Description:
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
User Population
All users are Music Directors at WMBR and fall directly into our target user population. We connected with these users through a group member who is a DJ at the station, but not a Music Director (hence satisfying the project requirement that none of the group members fall into the target user group).
The 4 users are within the age range of 20s - 60s, with varying levels of technical proficiency. Three are female and one is male. All had a need for a music importing system such as KaJaM! Some use the uploading feature more while others are more concerned with the reporting function. Each Music Director is typically in charge of one single music genre. Some music genres deal with more digital content than others, hence usage of the KaJaM! application is expected to differ across users.
Conducting User Tests
User testing was conducted at the WMBR Radio Station located on MIT campus, lasting on average 30 minutes in length. We briefed the users by explaining the scope of our application (limited to importing music, not playing or managing the library), and our hypothetical scenario. The briefing is kept consistent across users by showing them the same instruction sheet. We also explained that we are interested in how users naturally interact with the interface, and assured them that there is no right or wrong way to use the application.
All users interacted with a Macbook laptop owned by one of our group members and used the attached Touchpad + Keyboard to navigate the KaJaM! interface. One group member was acting as the facilitator and was in charge of walking the user through the scenario tasks, providing assistance only when necessary. The remaining two members sat alongside the user and noted down critical incidents + usability issues.
We decided that a demo is not necessary due to the intuitive interface of the application. The scenario tasks presented to all users can be found as follows:
Scenario |
Task |
Imagine you are a music director, Lana, and you wish to upload some albums to the digital library via the KaJaM! interface |
Open KaJaM! and log into the system |
You have downloaded 2 albums onto your computer: Starmarker.zip and KaJaM.zip and wish to import them to the library |
Import Starmarker.zip and KaJaM.zip into the digital library |
Before approving the KaJaM! album, you want to listen to one of the tracks |
Play a track in the KaJaM! album |
The track from KaJaM! album sounds familiar, and you quickly realize you have already imported the album and don't need it again |
Delete the entire KaJaM! album |
The Starmarker.zip file finishes importing, and you wish to make sure all the track details are correct |
Inspect track details |
You find incorrect and incomplete track details you want to fix |
Edit track details to reflect the correct information* |
You wish to approve the album to officially file it in the digital library |
Approve the album |
Before you leave, you wish to complete College Media Journal reporting for the month |
Take a look at the reporting data in the digital library |
You notice the reporting data is displaying all genres, but you want to look at only "Electronica" |
Filter the reporting data to show only "Electronica" |
Now all reporting data is on "Electronica" only, but it is not sorted by play count in the last month |
Sort the reporting data by play count in the last month, in descending order |
Everything looks good, but you still want to make adjustments to the reports based on physical CD play count before submitting them |
Export the reporting data to Excel file format for further editing |
All done with the tasks! |
Done! |
*Assume Lana Googles the correct album information, so facilitator provides all the correct information to the user on a separate sheet of paper:
Track # |
Track Name |
Artist |
Album |
Label |
Release Date |
Genre |
1 |
While I'm Dead |
Starmarker |
Killer Kilometer |
Polyvinyl |
2013-02-20 |
Electronica |
2 |
Sand Beauty |
Starmarker |
Killer Kilometer |
Polyvinyl |
2013-02-20 |
Electronica |
3 |
Silver Lining |
Starmarker |
Killer Kilometer |
Polyvinyl |
2013-02-20 |
Electronica |
Usability Problems Observed
Describe the Problem Here. (Severity Level Here)
Details Here.
Potential solutions:
Details Here.
Describe the Problem Here. (Severity Level Here)
Details Here.
Potential solutions:
Details Here.
Describe the Problem Here. (Severity Level Here)
Details Here.
Potential solutions:
Details Here.
What Users Liked
Details Here.
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.