TemporaryFinalPrototype
From CS 160 Fall 2008
Contents |
Design Evolution
(2 pages + sketches & screen shots - 15 points, Anthony) How did your UI change from initial sketches, low-fi testing and pilot usability test? Show what the major changes were and why they were made Explain which evaluation technique was most valuable to your prototype's usability and why.
==============================> NOT COMPLETE
Images
 Fig 1a: Contextual Inquiry: Main |
 Fig 1b: Low Fidelity: Main |
 Fig 1c: Interactive Prototype: Main |
 Fig 1d: Final Prototype: Main |
 |
 Fig 2b: Low Fidelity: Pre Campaign |
 Fig 2c: Interactive Prototype: Pre Campaign |
 Fig 2d: Final Prototype: Pre Campaign |
 Fig 3a: Contextual Inquiry: Campaign |
 Fig 3b: Low Fidelity: Campaign |
 Fig 3c: Interactive Prototype Campaign |
 Fig 3d: Final Prototype: Campaign |
|
 Fig 4b: Low Fidelity: Pre Practice |
 Fig 4c: Interactive Prototype: Pre Practice |
 Fig 4d: Final Prototype: Pre Practice |
|
 Fig 5b: Low Fidelity: Score |
 Fig 5c: Interactive Prototype: Score |
 Fig 5d: Final Prototype: Score |
Initial Sketches
Our initial Group Brainstorm described a general DJ serious game to appeal to a wide range of users. From the aspiring DJ to the seasoned beat-mixer. The functionality of the initial sketch was designed around the same logical progression a professional DJ would use while mixing in a studio, thus enabling players to explore each step of the beatmixing process. This can be further divided into 5 categories:
Beat Counting
A user is given a track that does not have a previously calculated BPM (Beats Per Minute) value associated with it. The user would then record an approximate BPM by hitting the spacebar each time a beat "hits" in the music. This would not only give the user more experience in detecting beats in music, but additionally create useful metadata for each track to facilitate matching tracks by BPM into compositions in the future. Once Orquesta has locked onto a BPM value, the track is paused and then saved.
Song Matching
Underlying this initial design of Orquesta would be a database of tracks; some with associated BPM values and some without. For those with defined BPM values, the song matching functionality enables the user to select from a "mixing palette" of desired tracks with the same BPM which will later be transferred to the primary beatmixing interface.
Beat Mixing
This element is where the user will be able to exercise the most creativity (see Figure 3a). From the pre-selected "mixing palette" of tracks with matching BPM values, the user may now switch on tracks at the desired intervals to create a unique composition. Additional controls will enable each individual track's sound to be adjusted. These controls range from volume settings, to equalizer settings (for example boosting bass and/or treble). Once the user is finished composing, they are able to save their track and submit it to the accompanying Orquesta website for rating.
Mix Rating / Feedback
Here the player is prompted to play, rate, and give feedback on submitted compositions via Orquesta's accompanying website. This site will allow users to create their own DJ profile, view other DJ profiles, and additionally submit and rate compositions from other DJs on the site. From a general standpoint, the site will have 3 main interfaces: (1) displays recently submitted compositions, (2) displays previously rated compositions sorted in descending order based on positive ratings, and (3) for viewing DJ profiles. The rating system would borrow from that which is used on a popular rating site, Digg.
Track Browsing
This final element allows DJs to explore compositions by BPM, rating, date, user, etc. The idea is that this will facilitate music selection for DJs preparing for an upcoming gig. For example a list of potential compositions organized by BPM can be sorted by average rating so only the best mixes are used for a particular performance.
Low Fidelity Testing
Our initial design turned out to be quite ambitious. Though we successfully acquired a genre for our serious game that we all would enjoy working with, we proposed enough functionality to frighten an entire army of programmers. In this iteration we honed our goals towards a more feasible, game-like implementation, and more or less decided on Adobe Flash as a platform for Orquesta.
Our revamped Low-Fidelity Prototype consisted of 3 different modes of play: Tutorial, Practice, and Campaign. Tutorial mode was a semi-interactive guide to give the user a solid foundation in the Orquesta interface. Campaign mode teaches and reinforces beatmixing skills through rewarding the user for successful track transitions "on beat." At the end of each level, a user is given the option to save their composition to play at a later time. Finally Practice mode is more of a freestyle mode, which allows the user to mix tracks together without any time or beat constraints. At the end of a Practice session the user is also able to save their composition. Additionally, a user is able to replay a previously saved composition by importing the composition from the Main Menu.
Major Changes
This iteration involved discarding a fair amount of functionality. We decided to do without: beat counting, song matching, mix rating / feedback, and track browsing. Our focus for this iteration primarily emphasizes the practice of beat mixing. As a consequence of Adobe Flash being new to us as a group, we did without the equalizer functionality for each track and drag and drop functionality. This was for the most part a result of managing complexity for a semester-long project, while still allowing us to implement an entertaining serious game.
Evaluation Techniques Used
We utilized the Low Fidelity Interview techniques addressed in lecture. Our group was broken down into several observers, greeter, facilitator, and computer. Key points that we had emphasized to each interview candidate was that the purpose of the interview was to identify potential issues before they occur in development. So they should not hesitate to identify any problems they might come across during the debriefing session.
Each candidate was asked to complete the following 3 tasks: (1) complete the tutorial, (2) successfully transition twice in campaign mode, and (3) save a composition from campaign mode. These tasks were intended to exercise a majority of the interface in addition to being broken down into easy, moderate, and difficult tasks respectively. Each time we detected some kind of event (i.e. "oh" or "that's cool") this item was logged and discussed during the debrief session.
In total we selected 3 interview candidates, each with a varied amount of experience with DJ equipment and/or software. Luckily we found subjects that perfectly matched our intended audience. One experienced subject, a moderately experience candidate, and finally a totally inexperienced candidate. Based on their varied amounts of exposure to traditional DJ software, we gained some really valuable feedback which resulted in a fair amount of refinement for the next iteration.
Goals For Next Iteration
The interviews have shown that for the most part our design is on the right track, with the exception of visual feedback, and saving functionality. In particular, visual feedback should be utilized to notify the user a track is or is not (see Figure 3b) playing. Though our design included the affordance of GREEN corresponding to ON and RED for corresponding to OFF, this was still not entirely clear to our audience. Additionally there was some ambiguity regarding saving a composition versus saving progress in Campaign Mode. We aimed to solve this confusion by notifying the user they are able to save their composition after a level in Campaign Mode in the preliminary instructions screen, and in the preliminary Practice Mode screen as well.
Interactive Prototype
As a consequence of the previous prototype being a pen and paper prototype, the Interactive Prototype likely involved the most work as the entire interface now needed to be implemented in Adobe Flash. This involved a number of obstacles, the largest including as a team becoming acquainted with the Flash development environment and how to implement the audio functionality for our project. In regards to the number of changes since the last iteration, there were a few but not any significant enough to merit any major overhauls to the interface.
Major Changes
Changes in to our design can be broken down into 4 categories: (1) saving, (2) objectives, (3) visual elements, and (4) low fidelity specific issues. Saving as was mentioned in the previous section was slightly ambiguous to several of our interview candidates. This was solved by explicitly directing the user is to save a composition at the Scoring screen after completion of a level in Campaign Mode. These directions were included in the preliminary Campaign Screen where objectives are described and instruments selected. Additionally, level objectives were not entirely clear to our interview candidates. To resolve this issue we clarified objectives in the Tutorial Mode as well as the preliminary level screen for Campaign Mode. Additionally, we resolved to add visual elements to the interface to indicate that an individual track is playing or not. This was achieved by placing labels on each knob for each of the individual tracks, as we unofficially decided to do without key bindings and the RED/GREEN indicators. Finally, there where some issues with the Low Fidelity Prototype which were unavoidable: latency with audio, click-ability of elements, etc. These were not interface issues in and of themselves, but required some time to work out whether or not we needed the cursor to change for some action, notification for another action, etc.
Evaluation Techniques Used
Our evaluation for this iteration was based off of the group TBD's Heuristic Evaluation based on the criteria learned in class. Since the evaluations were easily prioritized by heuristic violations, it was a trivial task to realize what needed to be changed for the next iteration.
Goals For Next Iteration
After group discussion of the TBD's Heuristic Evaluation, we resolved that most of the modifications required were trivial. None of which really merited significant modification to the overall interface. In order of decreasing priority, the categories of violations can be ordered as follows: visibility and system status, user control & freedom, and finally consistency and standards.
Regarding visibility and system status, we were still in need of additional visual indicators to notify the user if a transition was made on or off beat. We already had the record vinyl icon breaking, but this wasn't entirely obvious. Additionally, the knobs used to switch tracks on and off weren't sufficient indicators to our evaluators.
For user control and freedom, although we had thought we addressed the issue in this iteration, it still wasn't clear what save meant to TBD. Additionally, TBD recommended to include a separate list of tracks that may be imported into Orquesta. To address this issue, and to reduce the overall complexity of our project we decided to scrap the entire notion of saving and importing. This was also a consequence of Flash having limited access to the local filesystem, and our unfamiliarity with Flash as a group. By discarding saving and importing we not only were able to deal with that particular subset of heuristic violations, but reduce the complexity of our project significantly as this was left an unimplemented wizard of oz technique for this iteration.
Finally, regarding consistency and standards: in a nutshell our buttons were all over the place. Some were a dark blue, some where the native white Flash component buttons. Return to main menu buttons were not consistent, and button alignment was not standardized throughout the interface. This should be easily remedied by using only Flash component buttons and aligning buttons to give a standardized feel throughout the interface.
Pilot Usability
This iteration was primarily composed of fixing the heuristic violations from the previous iteration, and testing our interface yet again with a new set of volunteers. In addition to the changes identified in the previous section, the overall look and feel of Orquesta was updated. Particularly the color scheme was updated for consistency, and we adopted a vector illustration of a turntable for our logo (see figures [1-5]d).
Major Changes
See the previous iteration's list above for this iterations updates. As a group we decided to update each violation that was identified by TBA. In addition to the violations, we also addressed several issues that were listed as recommendations. These include: further clarification of level objectives in Campaign Mode and including a back button in the Tutorial Mode. One last item we assumed but never formally clarified was that there will be no key-bindings after this iteration. Previously we had left this item as a wizard of oz technique, but as a group agreed that key bindings where not necessary.
Evaluation Techniques Used
The evaluation techniques used for this iteration are very similar to those techniques used for the Low Fidelity interviews. In order to exercise most of the interface, the candidate is asked to complete three tasks. In this case, the three revised tasks were: (1) complete the tutorial, (2) obtain a power-up in Campaign Mode, and (3) successfully complete level 1 in Campaign Mode. We were required to modify the original three tasks as one of the tasks was saving a composition, a functionality we decided to do without.
In addition to the traditional interview techniques, particular heuristics where focused on to hopefully benchmark the effectiveness of the Orquesta interface. This assignment was completed individually, but across our group we each tended to focus on an event log and time it took to complete the requisite tasks. The event log allowed further analysis to examine which parts of the interface the user might be struggling with. For example, Anthony attempted to extrapolate the learning curve of the Orquesta interface by measuring the interval between transitions and comparing those results between the first attempt and the second attempt of the interview subject.
Goals For Next Iteration
As we as a group would have hoped, most of the required functionality for the game was successfully implemented without any major flaws. Additionally most of our users indicated that the interface was relatively straightforward. The only area we still seemed to be lacking in was visual feedback. Particular events didn't quite jump out enough to the user, and across the board our results for the Pilot Usability Study reflected this. For our Final Prototype, we should address the lack of adequate visual feedback and from a general standpoint focus on enhancing gameplay.
Final Prototype
As this is our last iteration, the Final Prototype included the finishing touches required to polish off the interface. Again, most of the updates had to do with visual feedback in addition to an easter egg feature included in the Practice Mode section of Orquesta. To balance the workload, each member of our group participated in a subset of the updates which we agreed upon were necessary. Each of these major updates are included in the section below.
Major Changes
The updates we've included in the Final Prototype are as follows:
- Cursor changes on mouseover of volume sliders
- Score indicator is now more integral to the interface, with animations emphasizing positive transitions and negative transitions (red tint of controls + strike indication)
- For our first level, "Bonus Transitions" are included to allow the user to accumulate additional points after they have complete the objectives for the level
- Beat assist indicator, so the user knows when Orquesta believes it is a valid time to switch on a track
- Added theme music
- Updated the tutorial to reflect the changes made to the primary interface
Evaluation Techniques Used
As this is our last iteration, our only benchmark is to successfully implement as many suggestions provided by the CS 160 staff as feasibly possible. Also from the standpoint of a semester-long project, our aim is to have a working serious game with at least one level.
