From CS 160 Fall 2008

Group Ate's Interactive Prototype assignment.

Group Members, contributions

Jonathan Fong - Prototype report work: UI Overview, screenshot/figure referencing
Joshua Kwan - Visual C# Prototype Coding, layout
Kevin Lam - Powerpoint presentation design
Jacek Wnuk - Prototype graphical elements, sounds, cursor. Task & prototype overview descriptions, report work, Readme.
Nathan Yan - Prototype report work

Problem and solution overview (1 paragraph)

The main problem we see is that American kids aren't learning enough about eating in a formal setting as they grow up, yet this knowledge remains very important, at least for now. The overwhelming majority of people will attend wedding dinners, business lunches, and other fancy occasions at some point during their lifetime. To make up for the lack of education in that regard, we've designed a game that can at least help people become familiar with the behaviors deemed appropriate for formal dining occasions. The game aims to simulate a supervised dining experience where the player controls an avatar who is at a fancy dinner. The player is coached to behave correctly by an on-screen instructor who will voice his concerns to the player about how he or she is behaving, and the player will have a chance to correct it in order to prevent a faux pas during the meal. The game is controlled using the mouse and is built on the Flash platform.

Tasks (1/2 page)

These are the same tasks we used for our lo-fi prototype, though the pausing was replaced with Salt & Pepper passing (previously labeled as a Medium task under our Contextual Inquiry and Task Analysis, but downgraded to Easy on account of its easiness and higher level of interestingness than pausing).

Easy: Passing Salt or Bread around the table

Task summary: Every 30 seconds or so (this time depends on the stage the player is at), the player is presented with an arrow containing either a Salt & Pepper icon or a Bread icon, and must pass it using our input mechanism (the mouse).

The salt and pepper passing is mostly used during gameplay to up the difficulty by giving the player many things to think about. The process of actually passing the salt or bread, however, is very simple. Once the arrow with the Salt & Pepper or Bread icon appears, the user must simply click on the arrow within the time allotted. The arrow contains a timer (albeit unwritten in the prototype), and if said time counts goes down to zero, the instructor will become unhappy, and points will be taken off from the player's end score, but the arrow will disappear. If the player clicks it, a passing animation will take place, after which the player can continue with the rest of his challenges.

Medium: Successfully complete meal without distractions

Task summary: The player is presented with a plate of food and must eat it using the affordances provided by our input mechanism (the mouse.) Unlike the Hard version of this task, there are no additional distractions; the goal is simply to wolf down your food.

We intend to present this task in the form of a tutorial stage to get the user accustomed to the input scheme. To eat the food, the user must learn how to conceptually map the mouse buttons to the utensils in his/her avatar's hands. The right click button uses the knife in the right hand; the left click button uses the fork in the left hand. The player is presented with a simple steak. To successfully consume the steak without any errors, the player must repeat the following steps:

Use the fork to stab the steak (thus holding it in place). (left click)
Use the knife to cut a piece off the steak. (right click)
Use the fork to stab the piece of steak (left click)
Click on the avatar's mouth. (left click)
Repeat until steak has been entirely consumed.

During our lo-fi prototype evaluation, we discovered that once people understood the input scheme, this was relatively straightforward. But that was the entire problem; people didn't immediately catch on. People tried to click the fork and then the steak, which would result in an animation of the player's avatar stabbing the table. Or, they tried to drag the fork to the steak, which resulted in something similarly perplexing. Thus, in the real game, we will attempt to detect these common mistakes and pop up help bubbles to make it clear to the user what each mouse button does. As of now, however, the prototype does not have these.

Hard: Successfully complete meal while dealing with environmental challenges

The hard task has the same objective as the medium task: the user must consume all the food on their plate. However, the hard task also introduces various obstacles representing what a diner might encounter. Two obstacles we are including in this prototype are:

Posture

During the game, the user's in-game character will begin to develop a poor posture (slouch). The user will need to notice this (if the posture becomes very bad, the "instructor" may pop-up a dialog to tell the user explicitly) and correct the posture.

The control scheme for correcting posture is as follows:

User mouses over the in-game character's body. The cursor should change from the utensil icon used on the table to a "finger pointing hand" icon that indicates a click is possible.
The user can click any part of the character's body to fix the posture.
The instructor will indicate his approval if the player fixes the posture and continue nagging if the player does not.

Eating Pace

Another aspect of good dining etiquette is eating food at a similar pace as the rest of the table. The game interface will feature a "progress bar" for the amount of food that the character has eaten. If the user eats too fast, the instructor will pop-up a dialog to tell the user to slow down. If the user eats too slowly, he will not finish his meal, which will result in a poor end rating.

Overall objective: Keep instructor happy

This is the overarching superobjective reflected by your instructor's feedback area in the upper-right corner. Your performance on other tasks is reflected in this supertask (except for pausing the game, which does not and should not have any other effect on game play) - a poor job in eating food for whatever reason will result in a negative reaction from your instructor.

Revised interface design (1 page plus screenshots or scripts)

Changes as a result of low-fi testing and rationale behind the changes (refer to screenshots or scripts)

Between our initial low-fi prototype, and our interactive prototype, we recorded a few difficulties that arose in our low-fi test and made changes to our design in an effort to address them. These changes include:

Multiple cursor types ( Figures 4-5, 4-6, and 4-7). While the user has only a single input device (mouse), our game requires the use of three different control schemes - one to control the utensils, one to adjust posture, and another to select menus and options and such. This proved to be very confusing for most of our users, who took a while to discover that the control scheme had changed depending on which areas they moused over. In our Interactive Prototype, we've made custom cursors for each of the main situations, so that it will be readily apparent what the user can do with their next click.

Sketches or scripts for unimplemented portions of the interface

Color-Coded "Food Remaining" Bar

Pop-up dialog/instructions for control scheme

In our low-fi testing, several of the users had difficulty figuring out the control scheme for eating food with the utensils. Typically, they would try out several other typical control schemes (clicking and dragging utensils, clicking on utensils to "select" them). In our interactive prototype, we've implemented pop-up dialogs that explain the control scheme to the user, so that it is immediately apparent how to manipulate the game environment and the user can get started playing the game right away, instead of trying to figure out controls.

Storyboards of tasks (annotated screenshots or scripts)

Task 1: Passing Salt or Bread

Figure 1-1: Title Screen	Figure 1-2: Game begins	Figure 1-3: Player is asked to pass bread to the left	Figure 1-4: Player is asked to pass bread to the right	Figure 1-5: Player successfully passes the bread
Figure 1-6: Player does not pass the bread	Figure 1-7: Player is asked to pass bread and salt simultaneously

Task 2: Eating Food

Figure 2-1: Title Screen	Figure 2-2: The Game Begins	Figure 2-3: Fork is stuck in food	Figure 2-4: Knife is used to cut food	Figure 2-5: Fork is used to pick up food bit
Figure 2-6: Fork is used to bring food to mouth and eat, amount of food has decreased	Figure 2-7: The fork/knife cursor the mouse turns into while hovering over food

Task 3: Eating Food with Complications

Figure 3-1: Title Screen	Figure 3-2: The game begins	Figure 3-3: The player is eating too quickly	Figure 3-4: The player continues eating too quickly	Figure 3-5: The player stops eating too quickly
Figure 3-6: The player is notified he is slouching	Figure 3-7: If the player does not stop slouching, he gets a sterner warning	Figure 3-8: The player has successfully stopped slouching	Figure 3-9: A random scene in which the player must multitask

Prototype overview (2 pages)

Overview of the UI implemented

While we were not yet required to conduct heuristic evaluation testing on our interface, we believe strongly in the principles covered by Nielson's ten heuristics, and will use some of these heuristics to discuss our user interface.

General User-Interface Design

First, the general view of our interface is a third-person perspective of an avatar under the player's control (See Figure 4-0D). While the third person point-of-view in the system is very different from a first-person perspective in the real-world, we felt this would be the best visualization. After careful consideration, we concluded that the limited viewing angle of a first-person perspective, along with the awkwardness of implementing eye and head movement, would hinder the learning experience rather than add helpful realism. With our mission statement and goal of this game guiding us, we prioritized the better learning environment of the straightforward third-person perspective. While we have not conducted null-hypothesis testing to confirm this choice, the qualitative feedback that we received from our users during the Lo-Fidelity Prototype Testing supported this decision.

Second, the game scenario and the user interface make use of an "etiquette coach" to provide feedback to the user. (Please note that we are not referring to feedback of the system state/status -- as described in Nielson's H2-1 heuristic: Visibility of system state -- but feedback on player performance.) We designed our interface under the premise that users value immediate feedback when learning. We reached this conclusion after observing in our Contextual Inquiry and Task Analysis , task learning improved when feedback was available and the serious game platform was highly suited for immediate feedback. Also, in our Lo-Fidelity Prototype Testing, we saw that better feedback on the player's performance would have prevented a task from being completed incorrectly and a critical incident. Because, feedback on player performance was clearly important, so we implemented the coach with both icon and text elements (see Figure 4-0CB), which will be discussed in greater detail below.

Lastly, few of the "administrative" components of the game have been implemented in this prototype thus far -- namely an options menu and the help interface. When full-implemented, though any menu is first accessed by pausing the game. While it would be more direct to have a help button on the main interface to access a help dialog, we felt our game was simple enough to justify a tradeoff. Assuming a tutorial level would teach the user how to navigate the interface and controls, and that in-game tool-tips are available, the need to access a help dialog becomes rare. Thus, a help button would add clutter to the game interface, reducing recognition and reaction times for more important interface elements. While Nielson's "help and documentation" heuristic (H2-10) might argue for the help button anyway, we also designed the interface such that the only obvious system/administrative button is the pause button (see Figure 4-A), so the user has only one clear choice. This design is also seen often for many other games with simple interfaces, so we are in fact preserving Nielson's "Consistency and Standards" heuristic (H2-4).

Specific Interface Elements and Graphical Affordances

The etiquette coach, as represented by the smiley face and speech bubble at the top of the screen (Figure 4-0CB). The smiley face icon can either be happy, neutral, or unhappy. This provides the player with a way to quickly see how he/she is performing. The reaction time is minimal for the player to glance at the face and recognize the "expression" depicted. The speech bubble provides a means to praise the player when he/she is doing well (positive reinforcement) (e.g. Figure 1-5), and guidance on how to improve when the player is performing poorly (e.g. Figure 3-3). Our Contextual Inquiry and Task Analysis interviews showed users trust authority figures and/or "experts", so the instructions, tips, and guidance provided in this area will use that tone (e.g. the "coach" will not be overly-friendly or act as a peer of the user would act).
The cursor gives specific affordances on what actions are available, depending on the game state and location of the cursor.
- Fork and Knife (Figure 4-5) - used to indicate eating-related options are available
- Hand (Figure 4-6) - used to indicate something is grabbable. In future iterations, the animation of the cursor itself will give feedback that that something has been "grabbed."
- Regular mouse icon (Figure 4-7) - used for all other situations, typically for administrative tasks (menus, setting options), whereas the previous two icons provide in-game affordances. An exception currently is the "pass the X" task in the gameplay. We recognize that the cursor does not give affordance to the fact that the arrow itself, as seen in Figure 1-3, 1-4, and 1-7 should be clicked to complete the task.
The timer at the bottom-right corner of the interface is a countdown until the level ends due to running out of time (Figure 4-0F). The fact that the timer counts down gives the affordance that gameplay is not open-ended. However, the goal is not to complete the level/tasks in the shortest amount of time, because this represents that the player is "eating too fast" (Figure 3-4). As discussed below, the "Food Remaining" bar (when fully-implemented) gives more specific information to the player about pacing.
The Food Remaining bar at the bottom of the screen represents how much food is left for the avatar (Figure 4-0G). This gives direct feedback to the player about how much progress has been made. For example, after successfully eating one bite, the Food Remaining bar in Figure 2-6 has decreased (compared to its previous position in Figure 2-5). As implemented, the bar makes larges discrete jumps for every bite of the food consumed; this is a rough implementation and as the interface is further developed and more code written, the bar will decrease in smaller increments.

Audio Affordances

To reinforce the action taking place visually, audio is also played back to the user whenever the user commits an action. Especially given the lack of animation in this rough prototype, audio cues help to clue the user in on what is going on, and also indicate when they have made an invalid choice.

Stabbing fork into food...
Cutting...
Eating...
Passing requested...
Invalid click/selection...

Controls

The interaction with the interface is through mouse clicks. (See also: the "Controls" section of the Readme file).

When "eating" the left mouse click represents executing an action with the avatar's left hand and vice versa. This control mode is afforded by the fork and knife cursor shown in (Figure 4-5).
To manipulate the posture of the avatar, the user omnipotently wields the "hand" to correct the avatar slouching position (Figure 4-6). This is done with the left-click, as this is the natural button for selection tasks (versus the right-click, which has a standard use for bringing-up contextual menus). As discussed below, the intended implementation is for the player to click and drag the avatar. In this prototype, however, posture is correct with a single-click (i.e. dragging is no supported).
For all other uses, the cursor is a regular mouse pointer (Figure 4-7). The left-click can be used to click on the pause button and navigate menus. By standard and practice, contextual menus are rarely used in simple interfaces/games such as ours; we follow this standard, and so there is minimal possibility for confusion in this regard.

What was left out and why

Help interface

While we intend to eventually have a help interface, the goal of our design is to make the interface simple and intuitive enough that a dedicated help interface is not really needed. The finished game will feature a tutorial level and pop-up dialog boxes which will explain the game's control scheme, which should serve the role of teaching users how to play the game.

Through the help/menu interface, the user would be able to access these tutorials and pop-up dialogs. The help interface can also be used to provide more thorough explanations of the goal of the game, as well as dining etiquette challenges in the game and how they apply to real life.

Color-Coded Food Remaining Bar

Originally the game was going to feature a color-coded "Food Remaining" bar in which the green section of the bar slowly goes down with time, and the blue marker marks your progress on eating the food. Anywhere in the red is bad, either you're eating too slowly and will not finish your food unless you hurry up, or you're eating too quickly and will get style points taken off. This was not included for the sake of time, though it is an idea we have intended to implement ever since we thought of it directly after the lo-fi prototype testing. The timer and food-bar combination in our Interactive Prototype was the same one we came up with in the mockup and the same one we actually tested in the Lo-Fi Prototype. This idea came from that, and we plan to implement it in the future.

Animations

Due to time constraints, we were not able to implement any animation. This does not affect the functionality of the game in any way, as our control scheme is mostly click-based. While this prototype leaves something to be desired in final polish and user immersion, or main goal was to create a working prototype and interface to further test and refine, so including the visual effects are secondary at this point.

The prototype does provide visual feedback on every significant event; that is, when you stick the fork in the meat, we see a fork in the meat, and when you pick it up, we see this, but we do not see, for instance, the hand reaching over and stabbing the meat. The only animation completed is the animation of the character chewing his food piece upon eating it, which we deemed was important enough simply for the player to know he has performed the correct action. The rest we deemed to be non-vital to the understanding of the game structure and task management.

Menu interface

While the game currently features a rudimentary pause button, the game will also eventually implement an actual menu, which would provide the user with access to help documents/tutorials, as well as setup/configuration options (game settings like sound volume, and saving/loading of user profiles.

Score feedback

The only "scoring" system currently in place is a timer which times how long the user takes to finish the food, and an overall rating for the user. Our eventual goal is to create a full-fledged scoring system that can track and display all the dining factors, including eating speed, posture, and other table manners, and give a "score" to the user as a means of feedback for dining etiquette that they need to keep in mind while eating. At this stage of development, we are simply implementing the functionality of a handful of the planned obstacles, so feedback for only the couple of obstacles that currently exist wouldn't quite be as informative.

Posture Click-Dragging

According to the way we did our lo-fi prototype, our idea for the posture-fixing component was:

User mouses over the in-game character's body. The cursor should change from the utensil icon used on the table to a "grabby hand" icon that indicates a click-and-drag is possible.
The user can click and drag any part of the character's body to a different position.
There will be an "ideal posture" character outline - the body parts must be dragged to restore this position.
Some kind of indicator (sound?) should be given when the character's posture has been restored.

However, we chose not to do this because we deemed it too different a control scheme from the rest of the game. In addition, fixing posture is a relatively simple act in real life, and as a result we decided to make it simpler in the game, as we wanted to shift the focus back onto the eating experience and away from a difficult and confusing posture-fixing interface.

Due to time contraints and limitation in the platform we were using (Visual C#), we have not yet been able to implement our intended control scheme for correcting posture, which was to click and drag the character to the correct position. Currently, the user simply clicks on the character to restore posture. While this experience is not as fun or immersive, for now it still achieves our intended goal of getting users to consider the different aspects of dining etiquette, since the character will slouch often and require the constant attention of the user to fix the issue.

Help-Bubbles

In the lo-fi prototype we used help-bubbles to help explain the mouse controls used for eating. We also considered using a tutorial stage instead. This is not implemented in the prototype, however, due to time constraints. The user, for now, is expected to read the readme to understand the controls. However, in the finished product, we will no longer rely on the Readme .

Any wizard of oz techniques that are required to make it work

Our interactive prototype does not require the use of any wizard of oz techniques, other than a little imagination due to the animations not being in the game yet.

Prototype screenshots or scripts (as many as needed)

Readme

Here is our Readme for the Interactive Prototype Project.

Screenshots

Reference Shot

Figure 4-0: Interface, with annotations to reference interface elements

(Please refer to the UI Overview for a detailed description)

Extra shots of functionality besides assigned tasks

Figure 4-1: Title Screen	Figure 4-2: layer clicks "Pause" button, pausing the game	Figure 4-3: Player completed stage having performed well	Figure 4-4: Player completed stage having performed poorly	Figure 4-5: The fork/knife cursor
Figure 4-6: The hand cursor	Figure 4-7: The regular mouse cursor

Deliverables

Image:FormalLogic-bin-beta1.zip

http://bid.berkeley.edu/cs160-fall08/images/3/3b/FormalLogic-bin-beta1.zip

Presentation Slides: Media:Group_Ate_Interactive_Prototype_Presentationv2.pdf

InteractivePrototype-Group:Group Ate