• Created by Unknown User (dmiao@mit.edu), last modified by Unknown User (pipian@mit.edu) on May 13, 2013 15:22

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

Compare with Current View Page History

« Previous Version 23 Next »

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. In our heuristic evaluation several points were made about our original datepicker implementation. If a date was previously unset, and a user clicked to open the datepicker then clicked off of it, the date would be set to today's date. This behavior has been modified (the date does not get set in this case).

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). Furthermore, previous to the heuristic evaluation, users were able to play multiple tracks at once. This behavior has since been fixed.


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. There is a delay when loading different tabs (e.g. going from "My Uploads" to "Reporting"), and a lack of feedback was noted in our heuristic evaluation, therefore a waiting cursor was implemented to convey that the system was busy. 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:

Implementation Details

The interface was implemented on top of Django, with user-side UI code making use of jQuery and Bootstrap, as well as a number of UI-related libraries such as LESS to manage CSS styles, X-Editable for in-place editing, and Tablesorter for sorting tables.

Django enforces a model-view-controller-like design strategy, which was mirrored to an extent in the Javascript code. Each conceptual function (listing uploads, editing uploads, and reporting plays) was divided into separate JavaScript code and HTML templates for ease of maintenance, with server-side manipulation using separate controller functions ("views" in Django). Django models such as UploadGroups, Albums, and Tracks were mirrored in the JavaScript code with corresponding classes and objects used to help maintain UI consistency by posting events relating to those objects to the window (to allow list entries to dynamically update when the contents of in-place editors are saved, for example), and limited model-specific functionality (such as parsing metadata out of music files) was implemented as model functions.

While most HTML content is either produced server-side at load time or client-side at edit time, the reporting interface is unique in that it uses partial HTML to update tables when changing the release date filter. Changing the genre filter and sorting the tables are client-side functions which use the data in the HTML table itself to selectively hide and re-order rows, improving responsiveness lost in the release date filter.

Javascript functions were largely written as flat functions that strongly depended on the HTML5 event model to fire them and appropriately chain them to meaningful events to perform relevant actions both in the UI and on the server (e.g. drag & drop, in-place editing of server-side data, and XMLHttpRequest upload events).

Implementation Decisions

Perhaps the most complex code was that which permitted drag-and-drop uploads in the first place. Although the HTML5 drag-and-drop and file APIs did not actually restrict what was possible, practically all drag and drop code (including selection, dragging, and dropping of MP3 files in separate upload groups) had to be written from scratch from the underlying drag events to not only resemble behavior on image-hosting site imgur, but also to permit reorganization of unzipped MP3 files being uploaded much like dragging and dropping into different folders. Furthermore, different drag and drop event ordering in Firefox and Chrome required careful management of "dragleave" and "dragover" events to correctly manage the fading of the "Upload" overlay. The file upload API additionally offered in-line upload progress bar tracking which would not otherwise be possible.

Furthermore, in the reporting section, as mentioned above, we improved performance and responsiveness of filtering of the upload lists and reporting tables by doing client-side search of the various rows on each page, rather than relying on partial updates over the network. In practice, however, it may be necessary to only load uploads partially, leading to an XMLHttpRequest-based partial update mechanism for upload list searching, much like that used in release date filtering on the Reporting page.

Implementation Limitations

Because the code was initially written to map to the existing WMBR music database schema, a number of limitations arose from requirements imposed by Django (such as the requirement of exactly one primary key column, and an inability to use Django's custom column types like FileFields). Some of these issues were resolved by simply migrating to an appropriate backing table, while others were left only partially resolved pending a better resolution (e.g. genres are stored as comma-delimited strings rather than as separate models using a join table, which meant that JavaScript code currently splits a string for handling as separate tag buttons).

With respect to uploads, limitations in HTML5 and HTTP prevented the "pause" button dictated by our earlier feedback from behaving as expected (pausing the upload). At the moment, it is currently a placebo that does not actually effect the upload, as the only other alternative is to cancel the upload entirely and restart it when unpaused, which seems equally undesirable. Given the original use-case justifying the need for the "pause" functionality (i.e. pause would be clicked before "Delete Upload" which should cancel the upload in any case, it seems that a placebo effect would not have significant downsides and would nevertheless improve learnability by "having a button in an expected place" with some understandable behavior.)

CSS limitations in the implementation of X-Editable prevented the use of the "pop-up" design of album-level editable details with track-level details. As a result, consistency was broken between editing album-level details (which presented popup editors) and track-level details (which were in-line). Users generally did not seem to have much of an issue switching between the two, but several users expressed some general concerns about when data was saved regardless of the editor which might be exacerbated by the in-line editors. The benefits of the pop-up balloon for learnability, however, far outweigh the costs of inconsistency in not being able to use pop-up balloons for track-level ordering. In practice, however, pop-up editors should be used for all editors.

Similarly, limitations in X-Editable prevent using a date selector along-side a text-editor for date, without which, release dates may take longer to edit due to the need to search a calendrical display. A ComboDate editor was evaluated, but due to the ever-changing bounds of release dates (e.g. the system may need to support dates for many years in the future as well as many years in the past, making the year combobox difficult to scan), this may not be a sufficient replacement. As such, we stuck with the calendar editor, although it is not likely to be ideal.

Finally, space limitations from the standard HTML table layout algorithm resulted in the cramping of the "Play Count" columns, which may impede readability and understanding of the durations over which play counts are aggregated.

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.

  • No labels