Contextual Inquiry-Group:Orquesta

From CS 160 Fall 2008

Contents 1 Names and Contributions 2 Target Users (4 points) 3 Problem and Solution Overview (1 pt) 4 Contextual Inquiry - Interview Descriptions (15 pts) 4.1 Introduction 4.2 Overall Themes 4.3 Other Concepts to Consider 4.4 Specific Interviewer Notes 5 Task Analysis Questions (5 pts) 6 Analysis of Tasks (10 pts) 6.1 Learning to use Orquesta via Tutorial Mode (EASY) 6.2 Saving a composition (MEDIUM) 6.3 Creating a composition (HARD) 6.4 Modifying the default set of instruments (HARD) 6.5 Importing a preexisting composition (EASY) 6.6 Adjusting the tempo of an existing composition (MEDIUM) 7 Interface Design (20 pts) 7.1 Functionality Summary 7.2 User Interface Description and Sketches 7.2.1 Welcome Screen 7.2.2 Main Screen 7.2.2.1 Instrument Panel 7.2.2.2 Tempo Adjustment 7.2.2.3 Playback Control: 7.2.3 End of Song Screen 7.3 Three scenarios of example tasks with sketches 8 Analysis of Approach (5 pts)

Names and Contributions

Each team member’s name and a short description (one sentence per person at most) of how they contributed to this assignment.

• Stuart Bottom
  • Interviewer
  • Problem/solution overview
  • Interface Writeup
• Jimmy Nguyen
  • Interviewer
  • Solution sketches
  • Story Board (1/3)
• Anthony Kilman
  • Interviewer
  • Solution sketches
  • Analysis of Approach
  • Story Boards (2/3)
• Vedran Pogacnik
  • 6 Tasks Description
  • Interface Writeup
• Greg Nagel
  • Names and Contributions
  • Task Analysis
  • Interface Writeup

Target Users (4 points)

Description of users (1 short paragraph per person). Give a bit of relevant background on each subject. For privacy reasons, do not use real names or identifying information about your subjects.

Describe the rationale behind your choice of target users. For each of the three customers, give some details of their background, their likes/dislikes and priorities. Avoid information that may reveal their identity.

For privacy reasons, the interviewees real names have been changed.

Customer 1: Jane's experience with mainstream disc jockey applications varies from intermediate to advanced. She is not a DJ for a living, but regularly DJs for club events and local parties as well. Although not a professional DJ, she has significant experience both with popular applications and also applying the trade in the field as well. Her software of choice is Serato Scratch Live, which tends to be a popular utility used by most DJs in the club scene in San Francisco.
Jane is a good example of a fairly experience DJ with room for improvement. She is well versed, and performs on a regular basis; yet she still leads the life of a busy Berkeley undergraduate. Additionally, her primary hobby is DJing, which makes her a perfect candidate for the contextual analysis interviews.

Customer 2: Denise is a fellow student with lots of DJ experience in prior years. Years ago, she was a TA for the DJ decal on campus. She has a broad experience of DJ experience, working with analog and digital, and various equipment like turntables, vinyls, compact discs, midi controllers, analog samplers and synthesizers.
We chose Denise because not only does she have good DJ experience, but also as a fellow EECS student, she can help identify what tasks are feasible and should be added to the game. She also has a bit of experience in web application design, so it might be good later down in the class to ask her for opinions on UI design and features.

Customer 3: Jeff is a freshman in high school who enjoys games, and has a particular interest in learning how to beatmix tracks for inclusion as background music for homemade movies he edits. He has very little experience in sound editing, and has never used a beatmixing application before, but he is an accomplished video editor. He likes playing more "hardcore" games like Halo 2, and is also a big fan of "instant" games found on websites (e.g. Flash games that don't require the player to install any software). His main priorities for games include being interactive, speedy, and responsive - he dislikes having to wait for a game to react to a player's input. As a teenager, he is easily bored with games that are poorly implemented or frustrating to use, and likes games that can hold his attention well.
Jeff is a good example of a target user who is not interested in beatmixing purely for its DJing aspect, which demonstrates that our game has great potential to appeal to a broad set of players. We chose him because he represented a younger demographic of players who would potentially have great interest in our game. Additionally, the fact that he was not focused on becoming a DJ allowed us to consider the possibilities for constructing our game to appeal to a broader group of users.

Problem and Solution Overview (1 pt)

Problem and solution overview (short, 1 paragraph)

This overview should be a concise statement of the problem you are tackling and a brief synopsis of your proposed solution.

The importance of acquiring beatmixing skills for use in certain careers cannot be understated. We propose to develop a serious game to make learning beatmixing fun and interactive, in a way not addressed by professional beatmixing tools. This game will serve as a first-time introduction to encourage users to explore the beatmixing world more, and it will also serve as a convenient, fun sandbox to quickly test out new beatmix ideas - alone or with others - but without requiring the hassle of using professional-grade DJ software.

Contextual Inquiry - Interview Descriptions (15 pts)

Contextual inquiry interview descriptions and results (1-2 pages)

Describe the process you followed when conducting the interviews, and environment where you observed their work. Identify tasks and themes that the customers shared in common in their work practices. Then, note anything unique about each interview and comment on the rationale behind these events.

When interviewing users, it shouldnt be difficult to find users who play games and are familiar with your out-of-game tasks. For in-game tasks, you should try to find the most similar task which is still familiar to your user. It doesnt have to be in the context of a game - e.g. for planning workouts, you can ask users about their real workout schedule.

We will grade this based on the quality of your method in finding representative users and and how much you discover about any issues you might be able to resolve with an interactive system. For example, if you were designing a drag and drop scheduling application:

• Bad: You do a contextual inquiry with your dorm mates and they complain about how slow Telebears is and that navigation is difficult. The problem here is that you are not getting a good enough selection.
• Better: You do a contextual inquiry with a selection of undergrads from different years and majors (and they don't all live in your dorm)
• Great: You do a contextual inquiry with graduates, staff, and undergraduates. You discover that graduates only take two classes. Staff members don't take classes but only schedule meetings, which do not always meet at the same time every week. Undergraduates have too many classes, so drag and drop might clutter the interface.

Introduction

We carefully chose our customer interviews to gain as much insight as possible into serious and non-serious beatmixing applications. We chose two DJs with several years of experience, and a high-school-age gamer with a more peripheral interest in beatmixing for video background music. Both sexes are represented, and with this set of interviews we heard from a range of ages as well. Our interviews tended to follow the master-apprentice model of contextual inquiry - encouraging the user to describe what they do, and asking for clarifications as necessary. It was not possible to view each user in his/her work environment, simply due to the cost and unavailability of appropriate DJ equipment and venues. However, we relied on these users' open and frank discussion of their experiences to gain insight into professional DJ'ing tasks and contexts. For the third interview, we were able to observe the customer at work and play, as he demonstrated incorporating audio into his video editing toolkit and showed examples of games he enjoyed.

Overall Themes

Several consistent themes emerged from these interviews. The first major theme we gleaned is a sense of the importance of trial and error. In video editing, in DJ'ing, and in gaming, the only way to learn a task is to try it over and over until you've mastered it. Each of the interviewees emphasized the trial-and-error nature of their work, which translates directly to our game proposal. Keeping the "sandbox" nature of the game alive as much as possible will go a long way towards enabling aspiring beatmixers to learn what they need.

A second theme that emerged from the interviews is the importance of multitasking. For each of the interviewees, the ability to multitask was crucial to the success of all their tasks individually - that is to say, many of their tasks must be accomplished simultaneously due to time constraints or other factors, and the inability to do so jeopardizes their success. This is especially important for DJ's, as their professional image depends on their ability to keep the beat moving and flowing in a smooth, uninterrupted manner - and they must be able to manipulate the beat at will, according to the mood of the party. This is why DJ'ing is considered by many to be a performing art; in practice, its execution requires that the performer complete a set of complicated tasks simultaneously: finding the next song, beatmatching it, and setting up the mix for the right mood, all before the next track ends. The skill with which this is done is what separates the good performers from the not-so-good ones. The importance of multitasking for gamers in general cannot be under-emphasized, either. Many good games, especially the most immersive ones, challenge players by giving them almost more things than they can do at once. This juxtaposition of multitasking in games and in DJ'ing can be fused in our application like never before - a serious game to teach a real skill that inherently requires multitasking. In this sense, then, perhaps the act of beatmixing itself can be considered a game. The more our project can simulate, encourage, and train users in multitasking, the more immersed players will be and the more practice they will get for actual mixing.

The third theme that emerged is the necessity for feedback on mixes. All three of our customers emphasized the importance of communication with others in evaluating the quality of their work. It allows them to see what they've done right, and figure out what they've done wrong - it can be very difficult to evaluate your own work objectively. For DJ's especially, feedback is part of the learning process on their path to becoming a successful and respected beatmix performer, and an integral part of their professional success. As mentioned above, the more skilled a DJ is the more they are respected - and the way that skill is acquired is through trial-and-error plus hearing how others feel about your work. This feedback aspect will take more exploration on our part - it is not fully clear what the best way to elicit comments on mixes is yet. However, the ability to retain finished mixes for comparison and play them back while watching the actions of the mix artist is a first step toward soliciting user comments. Players may want more of a structured framework for feedback, or a different one altogether, but this will have to be determined in our prototype evaluation sessions. The important thing to note is that our game must enable some sort of feedback / collaboration scheme, in order to stay true to the inherently collaborative nature of beatmixing.

Other Concepts to Consider

There were several concepts that deserve important consideration in our UI design, but were not necessarily consistent with every customer. These include:

• Addressing what happens when "something goes wrong" in a beatmix: everything gets muted, the beat fails to match up, or a transition is fudged. These are more advanced training concepts that the game could potentially simulate, and allow players to acquire the skills necessary for successfully handling beatmixing even when things go wrong (Jane, Interview 1)
• It would be nice to implement a feature allowing users to import their own tracks into the game, which would allow much broader exploration beyond the current simple instrumental tracks provided in our proposal (Denise, Interview 2)
• We might consider a more formal training aspect for the game, which could allow it to appeal to a broader set of players in the same manner as Guitar Hero. This training feature would challenge players to mirror the actions of experienced "Master DJ's" mixing, and would give points to players who could successfully use the same timing and execution as the Master DJ (Jeff, Interview 3)
• We might consider implementing a greater level of user interaction on a visual level, such as with a webcam (which could also be incorporated with the suggestion below) (Jeff, Interview 3)
• We should consider implementing chat / community / team collaboration features into the game, where players can work on a mix simultaneously and comment on it to each other in real time: some might be mixing, some might be listening, but this would simulate the overall "fun" and "live" atmosphere of real DJ beatmixing (Denise, Interview 2; Jeff, Interview 3)

Specific Interviewer Notes

Specific notes on each interview are given below.

Interview 1: The contextual interview with Jane may be broken down into 3 categories with a particular emphasis on serious games: (1) tasks required, (2) how these tasks are learned, and (3) how things can go wrong. First, after discussing with Jane which tasks are the most common in applying her trade, the most important included the composition of playlists, BPM calculation, and tempo adjustment. Serato Scratch Live in particular has an emphasis on tempo and BPM calculation. BPM calculation in particular is intended to be an automated means to assist the DJ in choosing the next song in a mix. Although this utility is particularly useful to DJs, as Jane described “there is no substitute for experience.” Tempo modification is intertwined with BPM calculation, allowing a particular song to mesh with songs of varying BPM. Second, Jane learned these tasks in an informal fashion; a combination of playing with software in the comfort of her own home, and via instruction from a close friend who taught this trade for a living. For the most part though, Jane described the learning experience as experimenting with compositions in Serato, and showing her instructor to confirm if a particular composition was good or bad. Finally, Jane explained the various things that could go wrong for a disc jockey performing in front of a live audience. Ignoring technical difficulties, the most common error for a DJ is the inability to select the next song in a mix before the current one finishes. This error usually stems from a lack of experience in beat matching between songs. The worst thing that could result is that the DJ would simply drop in a random song without configuring a transition in the audio software, providing an awkward ambiance for the audience.

Interview 2: Denise believes that the people interested in using our application would generally have some sort of previous DJ experience, but it could also be used by people with some sort of interest in the whole field of music composition and DJ-ing. She said that the user will be able to adjust volume levels of the tracks and record songs based on the tracks supplied. The overall experience is learned through trial and error, which is pretty much how DJ-ing is learned. The hints supplied would be able to guide the users through using the whole application and the features available. Denise says all the tasks will be performed directly on the interface, using the various sliders and buttons, just like that on a real DJ mixer. The user will be controlling all of the music tracks, volumes, tempo and how they will be composed into the track. She said users can communicate with each other by listening to other people's tracks, voting for those tracks, and also by using the (potential chat room). The user has however much time to complete the tasks, as they can record songs over and over again. However, they may want to listen to the songs before hand to know what would potentially sound the best. Denise said if things go wrong, the user can redo things and adjust accordingly. Overall, Denise would like to see an option to upload songs.

Interview 3: The contextual interview with Jeff gave us important insights into how younger players prefer to interact with their games. The concept of interaction is very important to Jeff, and it is a primary motivator in keeping him engaged with the game – the more interactive it is, the more he is likely to enjoy playing it (and keep coming back to play it). If the game is not interactive, it is one of those games he might try but never buy or be interested in playing again. Throughout the interview, Jeff gave examples of what he considered to be good interactive features in games. In particular, he considers “Amped Up” (essentially a Flash version of Guitar Hero, located at http://www.molsoncanadian.ca/coldshots/ampedup.php) to contain several features worthy of note. The webcam interface - the game requests players to take pictures of themselves acting out certain things, then integrates them into the game - is particularly engaging to him – it allows the player to directly visualize him / herself as part of the game, and enhances the overall connection to the game. He suggested a multiplayer feature for games of this genre, where different players would control different instruments and work as a team. He also likes the ability to choose what instruments to incorporate at the beginning of the game. On the other hand, he dislikes the slowness of the Flash interface for this game – many times, it fails to respond to his keyboard commands and “lags out,” causing him to miss points he would have otherwise earned. This is also something crucial to keep in mind for our application. Finally, he emphasized the appeal of "Guitar Hero"-type games, and suggested we incorporate a more formal training aspect into the game where there are actually prerecorded tracks, and a player must follow them in real time to earn points.

Task Analysis Questions (5 pts)

Task analysis questions (1-2 pages)

Answer the 11 task analysis questions. Use examples from your interviews when applicable.

1. Who is going to use this system?

We confirmed our target audience to be people who have some interest in DJing, amateur DJs and some professional DJs. Each of our subjects expressed interest in Orquesta. The DJs thought mostly DJs or musicians would be interested in the learning aspect of Orquesta, while the younger subject thought a wider audience would be interested in its gaming aspect.

Our main audience appears to be those with no to moderate skill in DJing, with a strong interest in electronic music. These people come from diverse backgrounds with different degrees of education, but often well-versed in the use of a computer. One subject mentioned that DJ equipment is very expensive. It may be a good idea to target the product to people who lack the funds for professional equipment.

2. What tasks do they now perform?

Much of what DJs appear to do is setup work for the actual beatmixing. They spend a lot of time coming up with appropriate playlists and calculating the beats per minute of a track.

Beatmixing itself can be done either manually, by directly touching a vinyl record, completely computerized or a hybrid approach. Computerization offers a number of effects:

1. Looping tracks
2. Keeping the vocals audible
3. Playing tracks backwards
4. Adjusting the tempo over a wider range
5. Adjusting the tempo without making vocals inaudible
6. Marking a spot in a track to go back to

3. What tasks are desired?

The DJs mainly desired that the tasks be as similar as possible to the real thing, without some of the complication. They want a high degree of control over the outcome of the song, especially features such as being able to import new songs.

The younger player was adamant about interactivity. He is most interested in a game when it's fast-paced and has a degree of customization.

We received a number of suggestions for tasks and other features:

• Volume control
• Tempo control
• Choosing specific samples
• Importing new songs
• Webcam interface to put oneself in the game
• Cooperative mode, where multiple players act as a team
• Guided modes
• Goals to accomplish in songs

4. How are the tasks learned?

Most DJs learn through hands-on experience. Some are taught or read books to learn, but others mostly learn through trial and error. It appears important to have some sort of mentor or teacher to evaluate skill. But most important is experimenting, creating compositions and evaluating them. Perhaps the game could take the place of a true mentor.

5. Where are the tasks performed?

DJs often perform at clubs, parties or random events, though there is a great deal of preparation involved, done at home. Most practice is done outside a club, but it is a very different environment from a load, booming party. We should attempt to emulate this less-distracting environment.

6. What's the relationship between user & data?

The DJs express a great deal of creativity in their craft, and are somewhat protective of their creations; however, newer DJs would rather get their songs out to the public than guard their intellectual property. The issue is complex because sampling songs has questionable legality. For a game like this, most would prefer a more open model.

7. What other tools does the user have?

All of our target users would have access to the computer to run our software, but other users have more specific equipment. Cellphones are common, as are some game systems. DJs often have the real equipment or software, but using that equipment would limit the program's usefulness. Headphones could be of use. Often real DJs will listen to separate sounds in each ear as they prepare them to be played.

8. How do users communicate with each other?

DJs will often meet others through their craft. Some will DJ collaboratively, others will go to parties and listen to others then meet up with the DJs that sound good. A voting process may work for us. It appears that the DJ community likes to listen to the work of others. We should include the option to save finished songs.

9. How often are the tasks performed?

Professional DJs spent a lot of time DJing. Often, several hours a day alone with events every other week. The game may be casual for some, but those seriously interested may spend a great deal of time on our game.

10. What are the time constraints on the tasks?

DJing is either underconstrained or overconstrained. Songs are often put together live, so actions are constrained by the beat of the song. Switching between songs takes skill to set up properly and has to be done in an instant. Preparation for songs or those put together at home will take hours. The game should focus on the live aspect to focus on the fun part of the game. Controls must be streamlined to allow the player to work live.

11. What happens when things go wrong?

Accidents are commonplace in DJing, and crowds are unforgiving. Speakers blow out, needles break, drunks harass you. These have to be dealt with by only using the equipment you have. If a high or low speaker blows out, focus on the other range. If a needle breaks, go to computerized mode. The worst is when a song transition fails, often due to inexperience.

In the game, accounting these aspects could form an arcade mode. Most of the time, however, we should try to simplify the process so that the user can focus on creating the music.

Analysis of Tasks (10 pts)

List of tasks: 6 tasks your application will support; two each of easy, moderate, difficult. (1 page)

Choose 6 tasks (2 easy, 2 moderate, 2 difficult tasks) and describe them. These should be real world tasks that have details.

A game UI supports both in-game and out-of-game tasks. Out-of-game tasks include things like signing on, setting options, communicating with other players etc. In-game tasks include things like solving an in-game puzzle, beating an opponent in battle, acquiring a resource, or arranging a date between virtual characters. For serious games, application specific tasks could include taking a short quiz (perhaps disguised as a puzzle), completing a workout, or planning a healthy meal.

Your task list should normally include at least two out-of-game tasks and two in-game tasks. If this doesnt make sense for your game, explain why but still include 6 tasks.

You should choose good representative tasks that span a variety of different scenarios, instead of just being variations on a theme. Your project should not be trying to solve a problem that is too simple or too complicated. Suppose you are doing an auction website ala (ebay):

• Bad: Your tasks all revolve around making the checkout better. For example, an easy task is to checkout with one item, a medium task is to checkout with three items, and a hard task is to checkout with a different credit card then you normally use.
• Better: Your easy task is to find an item you are interested in purchasing. Your medium task is to place a bid on an item. Your difficult task is to set up a watchlist for a group of items you are interested in.

Learning to use Orquesta via Tutorial Mode (EASY)

Once the application has loaded, the user will select the option "Tutorial" indicating their wish to enter Tutorial Mode. From here, the user will watch a scripted run with tooltips, including all the necessary actions required to: start mixing, select individual tracks, and save a composition. This will demonstrate to new users the proper usage of the Orquesta.

Saving a composition (MEDIUM)

In this final sequence, upon clicking "Stop" the user is prompted with a save dialog. After clicking "yes" indicating they wish to save their composition, a familiar save dialog appears allowing the user to specify name and location of their composition for the local file-system.

Creating a composition (HARD)

Creating a composition will involve the use of most of the Orquesta interface. This can be described as a three-fold process: first the user must click "Start" to begin composing, second the user must *at least* click play and activate one track via key-press from the default set of tracks provided, and finally click "Stop" to halt the recording process.

Modifying the default set of instruments (HARD)

A predefined set of instruments will be available for the user to choose from. Each instrument will have its own unique sound (ring) to it, and the user will have the option to include different instruments when making his track. The user can make a track using at least one, or including all of the game’s instruments’ sounds. Additionally, the user is able to modify which instruments (or audio tracks) are used by clicking any of the drop-down menus in the primary mixing interface, and selecting from a comprehensive set of tracks. In this manner, the user is able to explore a variety of audio tracks enabling a multitude of compositions.

Importing a preexisting composition (EASY)

Upon clicking the "Import" button in the main menu, the user is able to select a '.orq' file from the local file-system to import into Orquesta. The user is now able view how the mix was created by watching the screen indicators correspond to visual cues the creator originally saw. In this manner, Orquesta is not only a player, but provides a means by which a user can learn how a particular mix was created.

Adjusting the tempo of an existing composition (MEDIUM)

The user will have the option to adjust the “speed” of the music. Suppose a user has already created a composition they like, but they would like to modify the tempo of the overall composition. With an existing composition, this can be acheived in three steps: first load an existing song from file via the "Import" option, next adjust tempo to desired setting, and finally click "play" to listen to the tempo-adjusted audio track. If the overall tempo is satisfactory, the user can choose to save this track as well.

Interface Design (20 pts)

• Interface design (several pages)
  • Functionality summary (what you can do with it)
  • User interface description and sketches (how you use it)
  • Three (3) scenarios of example tasks with sketches
  • Any additional sketches

The solution section should be the bulk of the write-up and take several pages. Make sure you consider the [ Form of UI ] that is most appropriate.

At least part of your game should have a conventional UI: a home screen, screens for entering player information, configuration options etc. You should include those sketches in your design.

Also include sketches of game screens and any on-screen control widgets that your game uses.

Many games will also use a direct mapping from the input device to game actions. Input devices include the keyboard, mouse, game controllers, cell phones and possibly other more exotic devices. These mappings are part of the UI design, in fact the main part since most game play uses them. You should describe the mappings you plan to use and the contexts where those mappings hold.

This is the first real glimpse we've seen of your interface, so we care about the amount of thought you've put into coming up with an interface paradigm which can realistically evolve into a useful final product. Of course, we also want to see a good spread of activities in the tasks that you choose. Back to the ebay example:

• Bad: Your storyboards involve a user logging into the auction site and choosing between two options: "change my password" and "search." Obviously, your final product will house a lot more complexity than just two options at the outset, so it would be wise to spend some more time thinking through the navigation.
• Also Bad: Two of your tasks involve changing your user password, and the third with setting other preferences. This is bad because not only are two of your tasks exploring one part of your interface, all three are presumably relatively unimportant to the larger idea of what your project will do.
• Better: One of the storyboards exhibits your auction site, after login, giving the user a well thought-out set of options about what to do next. The user clicks on one, and proceeds to perform some meaningful activity that you've designed, with the storyboard disclosing the decisions the user makes at each step. Here we have been given a good idea of how the larger framing of the interface will work, and seen the complexity involved with the task.

Functionality Summary

Give a rationale for your design ideas.

Based on your analysis and tasks, explain your proposed interface.

We based the design of Orquestra on a simplified version of real DJ software. Confronted with such a powerful program, a novice would be lost in the complexity. What we want the user to experience is the rush of beatmixing: laying down tracks, focusing on putting them together well, without having to worry about collecting samples and getting them set up properly. To let the user experience beatmixing, we've concentrated on streamlining the beatmixing part of the interface.

We want to build a game that allows for fast action. Most DJ tools are built for professional DJs and are therefore focused on what professionals want, including far too much detail for the types of skills we want to teach. The design we chose focuses on speeding up the approach. Samples are added and removed with keyboard keys, highly visible on the screen. The user still retains a high degree of customization, being allowed to change instruments, alter volume and tempos. The buttons and sliders use clear labels and familiar concepts such as a volume slider.

However, even these controls may seem a bit daunting at first. One tool we will provide is a tutorial mode to introduce the game. The user will be taken through a sequence of steps to make a simple song, introduced to all of the controls. Another affordance we will provide is tooltips that the user will see when the mouse hovers over a control. For advanced users, we will provide keyboard shortcuts to most of the controls, streamlining the game even more. We still support mouse usage to ease newer users into the game.

User Interface Description and Sketches

Describe in text and support your description with rough sketches of important screens.

This section should clearly indicate the functionality of our artifact and what the user interface will be like (described and sketched -- references the figures in your text).

Welcome Screen

On the Welcome Screen, the user will be able to start the game or a tutorial.

• Start: Starts the game by opening the “main” screen.
• Tutorial: Start the game in tutorial mode.
• Import: Import existing composition from local file-system.
• Credits: Displays version information and lists game contributors.

There may be an additional "Quit" button if it makes sense in the context. (For example, quitting a game does not make sense in Flash.)

Main Screen

On the Main Screen, the user interacts with the game. We group the controls into three areas:

• Instrument Panel to interact with the instruments.
• Tempo Adjustment to play with the tempo.
• Playback Control to start or stop the song.

Instrument Panel

The user can play the instruments or change their configuration.

• Instrument Selection: A drop-down menu will display a list of possible instruments. Each instrument outputs its sound in the form of a continuous beat.
• Volume Control (of each instrument): The user moves the volume bar to change the instrument’s sound volume. Moving the bar upwards will increase the volume, moving it downwards will decrease it.

• Toggle Instrument On / Off: The buttons under each volume bar indicate whether that particular sound is turned on or off. The keyboard can be used to toggle each sound to give the user a high degree of control over the timing.

Tempo Adjustment

• Tempo Adjustment: The tempo is adjusted using a scrollbar. Adjusting the bar to the left will decrease the tempo, and to the right will increase it.

Playback Control:

• Play Function: Clicking / pressing the play button, indicated by the rightwards arrow, will play the track.
• Pause Function: The pause function will instantly suspend playing and remember its position within the track, allowing the user to resume playback later on.
• Stop Function: The stop button, indicated by the square, will stop the track and reset the playback to the beginning. It is used to indicate the end of a song.

End of Song Screen

On the End of Song Screen, the user will have the option to save the track that was just played, or to exit the game.

• Yes / No: Decide whether to save a track to disk.
• Exit: Exit the game and return to the Welcome Screen.

Three scenarios of example tasks with sketches

You should then describe three scenarios of how someone would use it to accomplish three of the tasks above. Scenarios include the steps customers will go through to accomplish the task. You should include "storyboards" of the sequences described in your three scenarios.

You should include a sequence of screen shots or dialog segments your application will use to support 3 (one easy, one moderate, and one difficult) of the 6 tasks you chose earlier.

1. EASY: Learning to use Orquesta via Tutorial Mode.

• In this sequence, the user is able to utilize "Tutorial Mode" to view a demonstration of precisely how to interact with the Orquesta interface to create their own composition.

1. HARD: Creating a composition

• In this sequence, the user can select tracks that they would like to use to create the composition. With those tracks, they will be able to listen to various tracks, adjust volume levels and so forth so that they can create a musical composition. Finally, they will be able to save that composition.

1. MODERATE: Saving a composition

• In this final sequence, the user will be prompted with a save dialog upon clicking "Stop", then finally a familiar save dialog to specify name and location on the local file-system.

Analysis of Approach (5 pts)

Analysis of Approach (1 page). Explain the pros and cons of your approach and how is compares to alternative techniques.

Explain how your application takes advantage of the affordances of serious games. Discuss other potential solutions (e.g. non-game applications), and list the pros and cons of your approach.

Serious gaming applies game design to areas other than entertainment. By incorporating practical objectives into a game, we entice the casual user to play. We can educate users by integrating vocational skills, or mine users' knowledge from their actions in a game--the possibilities are endless. The serious game model works well because using Orquesta to mix beats is fun and inherently an educational process.

We have sketched Orquesta to be a simplified version of a disc jockey mixing application, with additional gaming elements to attract a wide array of users. While the purpose of Orquesta is to refine the user's beatmixing talent, we attempt to make this process an interactive one. This is achieved by mapping key presses to audio tracks in a composition. For example, holding the 'q' key will provide a bass drum track while releasing it will stop the playing of this track. This interactive element not only provides the same faculty of a traditional DJ application, but additionally maintains the attention of the user. For most DJ applications, audio tracks are pre-organized at set intervals within a composition. Although this assembly process requires the user's attention, there isn't a notion of intantaneous feedback. In almost any game, for educational purposes or purely for entertainment, this type of feedback is absolutely essential. By requiring user interaction and providing instant feedback, Orquesta is able to provide more of an immersive environment for the user to explore in comparison to traditional DJ applications.

Our design of Orquesta provide the user with utilities also included in popular DJ applications such as Mixxx and Serato Scratch Live. Both applications incorporate the ability to mix tracks from a variety of instruments, and exporting compositions on-the-fly. Additionally, both products have a more comprehensive tool-suite, with features that are more suited for a beat mixing in a live setting. Although this would seem to be an instant bonus for users of such applications, the interface itself is rather intimidating for the uninitiated. And for the novice user wanting to simply “play” with a beat mixing application, they don't want to concern themselves with a an ever increasing number of digital equalizer controls and BPM estimation utilities. As another disadvantage, although Mixxx is a free open-source application, Serato Scratch Live is not with the hefty price tag of $539.

As a consequence of the cost of proprietary software including their complicated interfaces, Orquesta is a better suited application for a broader audience. Our application provides a unique hands-on approach to beat mixing, with an interface that will not frighten or intimidate the novice crowd. After simply clicking “Start”, the user is propelled into an interface that simply requires a click and a few key presses to begin beat mixing. Although this interface is quite simplistic, features are included to entice the well versed disc jockey as well. Again, traditional DJ applications require a “setup phase,” while includes aligning tracks at various time-marks which evolve into a composition. Orquesta provides a similar faculty, and the compositions themselves can be as complicated as the user would like them to be. The catch is this complexity requires a proportional level of interaction from the user, making beat-mixing with Orquesta an equally (if not more so) challenging task. Audio track placements in traditional DJ applications translate into physical key-presses at key transition times in Orquesta. This provides experienced DJ's with an engaging means to refine their existing ability to identify transitions within a composition, thus enhancing their beat mixing skills.