Project By: T.J. Ward
Comments By: P.J. Binkowski
[Weakness] One thing that you mention in the Use Case for “Add Track to Collection” that doesn't seem to be covered by the system is a situation where the DJ is importing a track during a show and doesn't have time to add the metadata. Other than the current playlist, is there a specific place that the new track ends up? For example, you might have an inbox for unfiled content that the user can go through when time permits and add the necessary metadata. Another design alternative is to have the newly-added track show up only on the set list for that particular show but highlighted in some way so that the DJ knows that the content doesn't have a permanent “home” yet.
I don't really have any evidence to support this comment but either of the above options seem to support your somewhat opposing design goals. Your users need to be able to very precisely catalog their large music collections but sometimes an acquisition takes place under difficult conditions. Any solution to this problem needs to take both of those goals into account.
[Weakness] This hybrid solution is probably the best approach – allowing the users to organize the content in a way that matches their internal semantic map of the content. This is especially important in cataloging music where the categorization rules vary dramatically among users. However, given the nebulous definition of musical genres, you may want to allow the DJs to file the same song in several different genres as appropriate.
“When asked to provide definitions for named genres, people are often unable to express clear rules for constructing example pieces in that genre or to precisely delimit the boundary between proximal genres.” (Cunningham, et. al. 2003)
“The diffuse boundary between different genres make problematic the assignment of a single classification to a given work of music.” (ibid.)
[Strength] This collection of panels is evocative of the interfaces used by Macromedia Studio MX and Adobe's CS suite. A paneled system is a good way to go – given the limited real estate of a laptop screen. However, the evidence for this item is a bit thin since neither of the aforementioned companies have (or are likely to) publish usability data on their flagship products. However, you could leverage the similarity of these interfaces to your own product by doing some interviews with expert users of these products. Even though the domain is not the same, the user profile is similar (i.e. highly-motivated to learn the system in depth). Specifically you'd want to concentrate on the panels – how the users feel about them, how often they move them around, etc. That way, you'd be able to get some idea of the design issues before you start implementing your design in earnest.
[Weakness] The flexibility of this approach is probably the best option, however since you are using hot keys it would be advisable to make the system self-documenting (e.g. somehow making the system display the appropriate key combination when the action is performed via a menu or mouse response).
“In the menu, the shortcut is printed after each item so that the user can learn about the shortcuts by using the application.” (KDE Usability Project)
If you can find it1, you may want to include some additional evidence to support the use of hot keys for this design decision regards the higher speed that keyboard operations can be performed at – since the user group appears to be under considerable time pressure.
[Weakness] Also, since a lot the operations that you will be assigning hot keys to are drag-and-drop operations, you will need to do further design work to specify how the keyboard interactions will work. One specific problem is that you will need key combinations that allow the user to easily move tracks from one playlist panel to another. One way you could accomplish this would be to assign each of the open playlist panels a number (displayed on the panel's title bar) and use the number in a modal key combination (e.g. Ctl-1 would place a song in the main window).
“However, operations that rely on drag-and-drop, for example, may require more thought to make them keyboard accessible.” (GNOME Usability Project)
[Strength] From the highly detailed prototype graphic it is apparent that you have put a lot of thought into the colors and fonts used by the application. The interface looks pleasant and rather professional but in the process of composing the prototype you made a number of implicit choices that aren't really articulated in the design decisions. The high contrast would seem lend itself well to low-light conditions but it might be best if you had some documentation for this decision to pass on to a developer. The design isn't necessarily weak here but since screen readability seems to be a key design goal, you should probably bolster your design with some additional evidence
“For low ambient illumination applications, contrast shall be at least 90%, with the background luminance less than the figure luminance.” (NASA 1995)
“Color coding shall be compatible with anticipated ambient lighting throughout the mission.” (NASA 1995)
[Weakness - maybe] While they appropriately evoke a feeling of technology, the sans-serif fonts you chose may not be the optimal choice, according to the evidence below. But since this evidence seems to apply to continuous text, which is somewhat different from the text used in your interface, it may not be particularly applicable. Moreover, the sans-serif font may be a good choice in regard to DJ's enjoyment of the product because, as noted below, people tended to prefer the sans-serif fonts even though they read them more slowly.
Compounding the difficulty is the fact that the evidence is somewhat contradictory on the subject, as illustrated by the last excerpt below. Since your interface is primarily textual, I would recommend that you do some usability testing to see what combination of typeface and font-size are preferred by your users, especially considering the strenuous conditions under which a DJ normally operates. One option would be to let the users set the font face and size themselves – however, this will affect all of the other visual elements on the display, so you will need to consider carefully whether providing that flexibility is worth the cost in added complexity.
“At the 14 point size serif fonts tended to support faster reading. Serif fonts, however were generally preferred less than sans serif fonts . . . if the speed of reading is paramount then serif fonts are recommended.” (Bernard et. al. 2001)
“The research suggests that serif fonts may be easier to read in continous text than san serif fonts” (Boyarsky et. al. 1998)
“Various studies purport to show that serif type is more legible than sans serif type and vice versa. You can truly judge type legibility only within the context of the situation — on the screen — as users will see your Web page.” (Lynch and Horton 2003)
[Weakness] While the ethics surrounding the current Intellectual Property laws governing music files are open to debate, the designer needs to consider what information needs to be provided to the user regarding potentially potential copyright infringement and what file management processes should be included. Normally such considerations would be far removed from the concern of the designer, but the RIAA cases suggest that if you implement this product, you may be opening yourself up to copyright infringement suits. Even though the product does not manage the music files directly, it could be seen as facilitating illegal file sharing. I would recommend that you consider including a warning message to be displayed when the software is first installed and perhaps at other times as well. Such a message could help insulate you from the activities of your users.
“The Recording Industry Association of America (RIAA) today filed a new round of copyright infringement lawsuits against 532 individual computer users who have been illegally distributing copyrighted music on peer-to-peer networks.” (RIAA 2004)
“The industry late last week
sent "lawsuit notification" letters to a total of 204
people accused of illegally distributing over 1,000 copyrighted
songs through peer-to-peer networks, such as Kazaa and Gnutella,
according to RIAA spokesman Jonathan Lamy.” (Online NewsHour
Bernard, Liao, Mills (2001) “Interactive posters: internet: The effects of font type and size on the legibility and reading time of online text by older adults” Conference on Human Factors in Computing Systems Seattle, Washington Seattle, Washington pp. 175 – 176.
Boyarski, Neuwirth and Forlizzi (1998) “A study of fonts designed for screen display” Proceedings of the SIGCHI conference on Human factors in computing systems: Los Angeles, California pp 87-94.
Cunningham, Reeves and Britland (2003) “An ethnographic study of music information seeking: for the design of a music digital library” Proceedings of the 3rd ACM/IEEE-CS joint conference on Digital libraries: Houston, Texas pp. 5-16. implications
GNOME usability project, the “GNOME human interface guidelines 2.0.”. http://developer.gnome.org/projects/gup/hig/.
KDE Usability Project “KDE User Interface Guidelines”. http://usability.kde.org/hig/
Lynch and Horton (2003) “Yale Web Style Guide”. http://www.webstyleguide.com/index.html?/
National Aeronautics and Space Administration (1995) “Man-Systems Integration Standards”. http://msis.jsc.nasa.gov/.
Online NewsHour Report (2003) “Music Industry warns file sharers they could be sued.”.
Recording Industry Association of America (2004) “Press Release: New Wave of Record Industry Lawsuits Brought Against 532 Illegal File Sharers”. http://www.riaa.com/news/newsletter/012104.asp