Anchor | ||||
---|---|---|---|---|
|
Note: We created two separate designs for user testing, one which took a more user-friendly approach and another which focused exclusively on efficiency. After the first round of testing (which consisted of three music directors and an "elf" from the radio station) we dropped the design which focused on efficiency and merged the best design concepts from both into a single design. Because we ran each user in the first round on both designs (we counterbalanced so that an equal number of users started with either design) there was a significant learning and preference bias (the tasks remained the same across the two designs, therefore users were more comfortable by the time they tried the second design). This may have been an influence on the users' unanimous preference for the second design they were presented with. Nonetheless, we found it a useful exercise to use multiple designs in our first round of testing, since many details from both made it into the final design.
Quick Links |
---|
Prototype Photos
Anchor | ||||
---|---|---|---|---|
|
| v1.0 of user-friendly implementation |
| v1.0 of user-friendly implementation |
| v1.0 of high-efficiency implementation |
| v1.0 of high-efficiency implementation |
| v1.0 of reporting interface (both aforementioned v1.0 implementations use the same reporting interface) |
| One of the user testing sessions at the WMBR studio. |
| Some of the interface widgets and task cards used. |
| v2.0 of our merged implementation |
| A view of the testing session on Monday March 18th. |
| v2.0 of reporting interface |
Briefing
Anchor | ||||
---|---|---|---|---|
|
What follows is the briefing presenting to participants in the paper prototype tests:
Panel | ||
---|---|---|
| ||
Thank you for taking the time to help us test the prototype of our system. You will be acting as the “user”, our goal is not to test you, but to test our system and find flaws or inconsistencies that will improve the final implementation. One person from our group will act as a “computer” who will control the experiment and provide tasks that we would like you to perform using the interface. The other group members will act as “observers”, and will be taking notes on the experiment. We will be asking you to perform tasks that relate to your current music director duties, but using our interface instead of what you are normally used to. At a high level these tasks will include importing digital music, previewing music and getting CMJ reporting data. We ask that you do not ask interface related questions during the test itself (as this will better help us find faults in our interface) but we can answer anything after the test is complete. Thanks and have fun! |
Scenario Tasks
Anchor | ||||
---|---|---|---|---|
|
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 |
Prototype Photos
...
...
...
...
...
...
...
One of the user testing sessions at the WMBR studio.
...
...
Some of the interface widgets and task cards used.
...
...
...
A view of the testing session on Monday March 18th.
...
...
Briefing
KaJaMi Participant Briefing
Thank you for taking the time to help us test the prototype of our system.
You will be acting as the “user”, our goal is not to test you, but to test our system and find flaws or inconsistencies that will improve the final implementation.
One person from our group will act as a “computer” who will control the experiment and provide tasks that we would like you to perform using the interface.
The other group members will act as “observers”, and will be taking notes on the experiment.
We will be asking you to perform tasks that relate to your current music director duties, but using our interface instead of what you are normally used to. At a high level these tasks will include importing digital music, previewing music and getting CMJ reporting data. We ask that you do not ask interface related questions during the test itself (as this will better help us find faults in our interface) but we can answer anything after the test is complete.
Thanks and have fun!
Scenario Tasks
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 |
While KaJaM.zip is importing, you wish to preview one of the tracks | Preview (play) a track in the KaJaM album |
The track from the KaJaM album sounds familiar, and you quickly realize you have already imported the album and don't need it again | Delete the currently importing 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 _the Blue Dot _genre, but you want to look at "Electronica/RPM" | Filter the reporting data to show only "Electronica/RPM" |
Now all reporting data is on "Electronica/RPM" 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 |
Now that you are all done, you wish to go home | Done! |
...
Track # | Track Name | Artist | Album | Label | Release Date | Genre |
---|---|---|---|---|---|---|
1 | While I'm Dead | Starmarker | Killer Kilometer | Polyvinyl | 20/02/2013 | Electronica/RPM |
2 | Sand Beauty | Starmarker | Killer Kilometer | Polyvinyl | 20/02/2013 | Electronica/RPM |
3 | Silver Lining | Starmarker | Killer Kilometer | Polyvinyl | 20/02/2013 | Electronica/RPM |
Observations
...
Importing
...
Prototype Iteration 1
tasks
Anchor | ||||
---|---|---|---|---|
|
Legend (relevant for prototype iteration 1 only, note that reporting interfaces were identical in both designs for this iteration):
(U) - This point specifically references the user-friendly design
(E) - This point specifically references the high-efficiency design
Prototype Iteration 1
Advanced Tables - Table Plus | |||||
---|---|---|---|---|---|
| |||||
|
...
User
...
Import Files into the Library
...
Preview Song Tracks
...
Delete Importing Album
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
- High-efficiency interface requires very little mouse movement to reach the "X" button, whereas the user has to move the cursor all the way across the screen in the user-friendly version of the interface.
...
- User prefers that the user-friendly interface gave a confirmation warning before deleting album
...
- Learnability
- User found the both interfaces to be easy to understand in terms of what information is being displayed
- Both interfaces lack affordances in terms of what is editable and what isn't, user had to experiment by single clicking on the fields
- Efficiency
- User liked how both interfaces showed all the album and track information on one screen
- User noted the directly editable fields are very convenient
- Safety
- User noted a mistake in adding the genre can be easily fixed by clicking the "x" beside the genre tag
|
...
|
...
|
|
...
|
...
Music Director #2
|
...
- Drag and drop was very straightforward, no problem
...
|
...
- No issues with safety
...
- Learnability
- Found the play button rather fast, but double clicked instead of single click, figured out it pauses it by double clicking
- No trouble with efficiency or safety
...
|
|
...
|
...
|
...
|
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
- Tried to look for a way to drag the album into the trashcan
- Looked for a delete button by hovering over the currently importing album on the left pane
- Eventually the user hovered over the trashcan and saw the delete but did not click on it and tried to drag albums over to it
- Tried clicking on everything in the end to delete the album
- User notes usually the trash can is for dropping files on it, you don’t open the trash can ever
...
- User can drop multiple files into a trash can, is there a way to quickly delete multiple albums?
...
- User likes a place where you can open the trash can to look at deleted albums
...
- No problem with interpreting the track detail view and editing the fields
- User looked for a save button to confirm edits to the field (safety)
- Date pop up is unnecessary, people usually only care about the year of release, not exact date
- User likes the add genre feature to allow for sub-genres and easy deletion of wrongly labeled genres (safety)
...
- No issues with approval
|
...
"Elf"
...
|
...
- User noted that he will want to drop multiple files at a time
...
- User also noted that there doesn't seem to be a way to cancel a file dropped accidentally
...
- Learnability
- User was confused that the right side of the screen was completely blank, and instead clicked on "recently uploaded" tab to look for the tracks within currently uploading album
- The tabs are not labelled clearly to communicate what it is really for
- Efficiency
- Quickly found the play button to preview each track
...
- Learnability
- Found the trash icon quickly due to its red color
- Trying to kill the progress bar (to stop it from uploading)
- User wants a feature that allows for stopping the import but not delete it (pause it for now)
- Want to drag and drop the tracks onto the trash can to delete instead of clicking
- Efficiency
- Had trouble deleting all 3 separate tracks quickly, just deleting one at a time
- Repetitively delete everything is a concern: no expedient way to delete everything
- Safety
- Don't need confirmation message, especially if it acts like a recycle bin like on Windows
...
- Learnability:
- Quickly decided to double click on the song track name, then figured out the single click is better
- User suggested offering more affordances for single click because he is a "double-click" guy (learnability and efficiency)
- He got that "Unknown" is the album name rather quickly
- Don’t know what unknown date is (import date or release date?). Also English styled date is not good
- Efficiency
- What if there are different artists in each album (compilations are very frequent), want the ability to change the artist name for each track versus for the album (efficiency versus customizability)
- Various artists for the entire album, but separate artist name for each song
- User wants to potentially change the genre for each track
- User does not value visual album art as much and prefer to have everything displayed as he considers himself to be a database guy
- Safety
- No issues with safety
...
- No issues with learnability, efficiency or safety but want to see what he has approved during the current session (want to see what other people have uploaded recently)
Prototype Iteration 2
|
Reporting Tasks
Anchor | ||||
---|---|---|---|---|
|
Prototype Iteration 1
User |
---|
Prototype Iteration 2 | |||||
---|---|---|---|---|---|
User | Import Files into the Library | Preview Song Tracks | Delete Importing Album | Inspect and Edit Album/Track Details | Approve Album |
Student User #1 | Learnability: | Learnability: | Learnability: | Learnability: | Learnability: |
Student User #2 | Learnability: | Learnability: | Learnability: | Learnability: | Learnability: |
Student User #3 | Learnability: | Learnability: | Learnability: | Learnability: | Learnability: |
Observations (Reporting Tasks)
Prototype Iteration 1 | |||||
---|---|---|---|---|---|
User | Switch to Reporting Mode | Filter View by Genre | Sort View by Play Count | Export Reporting Data to Excel File | |
Music Director #1 |
|
|
|
| |
Music Director #2 |
|
|
|
| |
Music Director #3 |
|
|
|
|
|
"Elf" |
|
|
|
|
Prototype Iteration 2
User | Switch to Reporting Mode | Filter View by Genre | Sort View by Play Count | Export Reporting Data to Excel File |
---|---|---|---|---|
Student User #1 | Learnability: | Learnability: | Learnability: | Learnability: |
Student User #2 | Learnability: | Learnability: | Learnability: | Learnability: |
Student User #3 | Learnability: | Learnability: | Learnability: | Learnability: |
Prototype Iterations
|
|
|
| |
Student User #2 |
|
|
|
|
Student User #3 |
|
|
|
|
Prototype Iterations
Anchor | ||||
---|---|---|---|---|
|
Design | First Iteration | Second Iteration |
---|---|---|
Importing | The efficient design featured a text box and button, while the "friendly" design featured neither. | A text box added to the "friendly" design to provide affordances for pasting or typing URLs |
Managing Imports | The efficient design had a more visible "stop" button, next to the progress bar, while the "friendly" design placed its "delete" button far from the user's focus | The "friendly" design added a 'pause upload' button near the progress bar and changed the "No (do not approve)" button to a visible, red "Delete Upload" button |
Organization | The efficient design used a button to switch between upload and reporting modes and featured recent uploads on the same "upload" page, while the "friendly" design separated current from recent uploads, and used tabs for navigation | The "friendly" design reworded its tabs to be more clear as to their purpose |
Navigation | The efficient design assumed that scroll-bars would be used normally to scroll through recent uploads, while the "friendly" design used a button to scroll through the details while keeping the approve buttons static. | A scroll-bar replaced the "scroll-button" for scrolling through details in the "friendly" design. |
Reporting | The interface featured a single-genre drop-down box which required clicking on a "filter" button to filter. The release dates included and date ranges of playback counting were unclear. | Genre was converted to a Piazza-like tagging design much like that of the "friendly" design and removed the requirement to click on a "filter" button; release date ranges were made explicit and columns were added to clarify over which date ranges counts were collected |
Miscellaneous Features | N/A | Added a hover-based mechanism to view per-track artists for compilation albums; tooltips were added to clarify what each text field represented in the editor pane |
...
Design
...
First Iteration
...
Second Iteration
...
...
...
...
...
...
...
...
...