LoFi-Group:Group Ate
From CS 160 Fall 2008
Group Ate's Low-Fidelity Prototype assignment.
Contents |
Group Members, contributions
- Jonathan Fong - 'observer': video documentation, test measures, procedure, tasks
- Joshua Kwan - interview management, part time greeter, environment description, prototype description and photos
- Kevin Lam - 'observer' role and note taking, mission statement, discussion
- Jacek Wnuk - photoshop mockups, lo-fi work, 'observer'/'computer' role, appendix work, prototype/mockup comparisons
- Nathan Yan - 'computer' and 'greeter' role, results, discussion
Introduction and Mission Statement (6 pts)
Growing up, many people's exposure to food is confined to what they experience eating at home or within their local community. As a result, many people are unfamiliar with foreign food culture and etiquette. In addition, today's fast-paced world that emphasizes a "casual" dining atmosphere (fast food, take-out, no sit-down dinners at home) has led to overall unfamiliarity with general food etiquette. Both issues can lead to significant consternation as diners realize they have no idea how to "eat properly" at foreign and/or sit-down restaurants to avoid social embarrassment! Our serious game project aims to fix this shortcoming using a stylized dining simulation, and our prototype investigates initial reactions to this sort of approach.
Mission Statement
Our goal is to educate users about proper dining etiquette as a first step towards the practice of socially accepted eating behavior in real world dining situations.
Prototype (12 pts)
Describe your prototype. Reference sketches of the interface screens in your description. Finally, submit a image file of the entire system with all of its elements laid out
Prototype Explanation & Mockup Comparison
The basic state of our prototype is represented by the "beginning" screen below. In a roughly clockwise fashion, starting from the "pause" button, the prototype features these interface elements:
- The Pause button. Mashing this button just ... pauses the game, as seen in the Paused screen.
- The mockup omitted this because it was assigned to be a keyboard function, though we deemed this more appropriate for the lo-fi prototype.
- The Eater. This is the representation of the person who eats the food. The Eater's state tells the user about his posture, and what utensils are being held in each hand. Additionally, the Eater can provide some animated feedback about how the user is doing; for example, if the user tries to shove the entire steak in his mouth, the Eater will gnash and dribble all over it trying to rip a piece out with his teeth. If a piece is cut and then eaten, light, silent chewing will be audible instead.
- This has been changed from the mockup's version to be more of a user interface element, most notably with regard to slouching. The mockup represents the posture by way of slider on a bar. This is now completely eliminated, replaced by the Eater's arms and head sliding down as you eat, eventually causing a warning from the Instructor, requiring the user to drag the body parts upwards to correct posture. Also, the eating mechanism has changed from clicking of food to control of both hands.
- The Instructor. This is the representation of the Eater's etiquette coach, who will tell you if you are doing OK or doing something wrong (e.g. eating too fast, slouching.) His mood is only described with a smiley face (although this could easily be replaced by a real face) and he will talk to you with little dialogue bubbles. The dialogue bubbles may include a time limit or time frame within which you must perform the task he specifies.
- User-interface-wise, this has changed only slightly from the mockup to the lo-fi stage. Conceptually it has changes quite a bit however. While the mockup's smiley represented the other members of the table and the dialog boxes merely boxes telling you you're doing something wrong, now the smiley is plainly your instructor and the dialog boxes represent your instructor's words to you throughout the course of the meal.
- Mouse instructions. This little pop-up will be displayed during the tutorial stages or during the later stages, if it is detected that the user has forgotten how to play the game properly (many Wii games use this idiom.) It tells the user what mouse button to use for each utensil, using pictures of both to promote association/retention.
- Due to the difference in the Eater's food interaction controls, this was not utilized in the mockup.
- The Food Remaining bar. This bar shows how much food in the current course is left to eat. It starts full, and the level ends when it is empty. The version shown in the prototype only has four bars, but obviously in the actual game it would take at least 15-20 bites to eat a steak. Additionally, we intend for the real version to also provide "pacing" information for the user. There will be an area of the bar shaded a different color to indicate how long someone eating at the proper speed will take, and the user can space out his or her bites to follow the optimal pacing.
- This has remained relatively constant from the mockup to the lo-fi prototype, save the label. The concept of the pacing would eliminate the need for a timer as in the prototype.
- The Food. This is the actual food being eaten during the level. It provides some of the same information as the food bar because you can estimate how much food is approximately left. Also, it provides feedback about the state of the food. You can stab it with the fork and slice it in the case of a steak. When that happens, they will be in two distinct pieces on the plate, and the small piece can be clicked and eaten.
- The Eater's food interaction controls are fundamentally different from that of the mockup, but the concept of the food slowly disappearing is the same.
Prototype Images
 Paused |
 Slouching challenge |
 Eating too fast challenge |
 Beginning the level |
 Halfway through eating |
 Paused (brightened) |
 Slouching challenge (brightened) |
 Eating too fast challenge (brightened) |
 Beginning the level (brightened) |
 Halfway through eating (brightened) |
 Paused (mockup) |
 Slouching challenge (mockup) |
 Eating too fast challenge (mockup) |
Method (12 pts)
Participants
Our experiment had three different participants.
- Morgan is a fourth year Cal student who we picked because he is a gamer who plays Warcraft III and other games for several hours a week regularly. We interviewed him first as a litmus test to see whether even a gamer would have trouble using our interface.
- We then picked two other people from the house who weren't gamers, one guy and one girl, Wylie (3rd year) and Elisa (2nd year.)
None of them are particularly interested in the topic of our game; again, our target audience is the average young adult.
Environment
The test environment was Josh's co-op room. Josh set up a square table in the middle of the room with chairs on two sides and a couch on another side. The participant would sit in one of the chairs and the "computer" would be to his right. A small cardboard partition separated the computer and the participant so he/she would not be able to look at the various parts of the UI laid out in front of the computer. Jonathan sat on the couch across from the subject and recorded video while Kevin was the note taker and question-asker; they shared the role of observer all throughout. Nathan and Josh traded off at being greeter, and Nathan and Jacek traded off on being the computer. Not all of us were active in each interview to prevent the participant from getting nervous.
Tasks
Roles
| Team-member | Session #1 | Session #2 | Session #3 |
|---|---|---|---|
| Jonathan | Observer: video recording | Observer: video recording | Observer: video recording |
| Joshua | Greeter/Facilitator | Greeter/Facilitator | Facilitator |
| Kevin | Observer/Interviewer | Observer/Interviewer | Observer/Interviewer |
| Jacek | (not present) | Observer/Facilitator | Computer |
| Nathan | Computer | Computer | Greeter/Facilitator |
Responsibilities
- Greeter
- Greets participant at the beginning of the session
- Introduces the project
- Describes the goal of the session
- Expresses appreciation to the particpant
- Facilitator
- Describes the consent form and acquires consent of the participant
- Gives details on the project
- Introduces the lo-fi interface
- Demonstrates how to navigate the lo-fi interface
- Presents the goals to the participant
- Observer
- Carefully watches the interaction between the interface and the participant
- Note-taking
- Notes successes in the interface
- Notes points where the participant struggles
- Video-recording
- Set-up and operate video recording equipment
- Capture and digitize video footage, edit and encode for web-uploading
- Computer
- Operates the lo-fi interface
- Improvises for unplanned actions
Procedure
- Greeter welcomes the participant (and thanks him/her for participating)
- Observer(s) begin note-taking and recording
- Participant reads and signs release form
- Greeter introduces the project and the team-members
- Computer and greeter introduce the interface, and give instructions on how to navigate the interface
- Greeter presents the first goal to the participant
- Participant attempts goal while observers take notes and record
- Repeat for second and third goals
- Participant interviewed on specific incidents and for general feedback on the interface
- Participant thanked again for participation
- Entire team discusses the session
- Repeat for next participant
Navigating the interface (as described and demonstrated by the greeter and computer)
- Use the index finger for the "left click" and the middle finger for the "right click"
- Pause between actions (to allow the "computer" to respond)
- Can move, drag, and click with the pointer
- Pink stickies will display the current cursor
Goals (as described to test participant)
- Pause and resume the game
- Complete/eat the food
- Complete/eat the food while overcoming dinner "challenges" (namely maintaining posture)
- Overall goal: keep instructor happy
Test Measures
- Understanding of interface
- Front facing character/avatar
- Right-hand/left-hand
- Dinner table
- "Food left" meter
- Intuitive controls
- Right-mouse-button-> Right hand
- Left-mouse-button-> Left hand
- Click to "stab"/"cut"
- Click and drag for posture correction
- Pause/unpause
- Accessibility
- Goal is clear
- Goal is achievable
- Help is available
- Potential for teaching etiquette principles
- Openness to the coach's instructions
- Feedback-> correction upon etiquette violation
- Interface reinforces real-life behavior
Results (12 pts)
Subject 1: Morgan (experienced gamer)
Task 1 (easy): Pausing, Resuming the game
Morgan was able to find the PAUSE button easily. After the PAUSE DIALOG appeared, he first tried to press the in-game PAUSE button again to resume, instead of pressing the CONTINUE button on the PAUSE DIALOG. After not receiving any response, he looked more closely at the PAUSE DIALOG and found the CONTINUE BUTTON.
Initial conclusion: The PAUSE DIALOG was somewhat small, and there was nothing to indicate that the initial PAUSE button was inactive. In-game, the PAUSE DIALOG will probably be much bigger, and the rest of the background will probably be darkened to indicative inactiveness, so this shouldn't be an issue.
Task 2 (medium): Eating
Morgan initially tried to click and "select" the utensils by clicking each hand, and then clicking a part of the interface to "use" the utensil. After this failed, he attempted to click and drag the utensils from each hand to the food. After both of these attempts failed, he was able to succesfully manipulate right and left clicks to control the utensils and cut/eat the food.
Initial conclusion: With no clear instructions, it was easy to see how a user could be confused by the control scheme. With the subsequent subjects, we added clear instructions on how to use the knife and fork utensils. After he figured out how to use the knife and fork, Morgan seemed to find using the fork to hold the steak and the knife to cut the steak, and clicking on the mouth to eat, a pretty intuitive process. In-game, I think a more instant and precise response would also make it more clear how the control scheme worked after a few erroneous clicks.
Task 3 (hard): Eating with obstacles
Morgan seemed confused by the "slow down" message. The initial slouching seemed to confuse the user ("What just happened to his head?). Once the dialog popped up that indicated the character was slouching, Morgan seemed to intuitively click and drag the body parts back to the correct place.
Initial conclusion: We didn't quite give any feedback beyond "slow down", so this was probably confusing to the user (how much should I slow down?). The initial slouching seemed to confuse the user, but Morgan seemed to grasp the concept easily once the dialog popped up that explained the user was slouching.
Subject 2: Elisa (novice)
Task 1 (easy): Pausing, Resuming the game
The user was easily able to pause and resume the game.
Initial conclusion: No issues/improvement needed here.
Task 2 (medium): Eating
The user first clicked on the utensils, which brought up a dialog box explaining how to use them. However, she seemed to forget after the dialog boxes went away, so we made a change with the design and left the dialog boxes there permanently. After the boxes were left permanently, the user seemed to grasp how to use the fork and eat the food. However, the user incorrectly attempted to cut the food without a fork to hold it (resulting in the food not being cut), and then incorrectly lifted the entire steak to the mouth to eat. The user did this throughout the entire task.
Initial conclusion: The user seemed to forget the information written on the popup dialogs after they disappeared, so the decision to leave them on the board permanently was a good one. The user didn't realize that the steak was not actually being cut, so a clearer indication is needed of what is happening to the steak when it's being cut without a fork to hold onto it. The user also didn't realize that she was lifting the entire steak to her mouth to eat. A more exaggerated eating animation would probably make this clear.
Task 3 (hard): Eating with obstacles
After the second task, we gave the user feedback via an example score/results screen that she was eating the steak very sloppily by lifting the whole thing up to her mouth. After this feedback, she grasped the concept of holding the steak with the fork and cutting it with the knife first almost immediately. When presented with the "eating too fast" obstacle, the user was confused but seemed to try to make slower movements for eating. The user was completely lost at the slouching obstacle. She initially tried pressing the pause button, hoping that it would offer some instructions (which it did not). She then repeatedly clicked the character's body parts, instead of dragging them, so this had no effect. The task ended when we gave up and we explained that she could use a click-and-drag control.
Initial conclusion: The control scheme for picking up the character's posture seemed utterly confusing to this user. Part of the issue may have been the low fidelity of our prototype - in an actual in-game scenario, the user may have clicked on the character's body and noticed that it would move with the mouse. Another solution we tried next was to offer a different cursor, changing from a simple generic pointer to a "grabby hand" to indicate that the parts could be clicked and dragged. In any case, the intuitiveness of the control scheme for the posture definitely warrants attention, and possibly a dedicated tutorial section
Subject 3: Wylie (novice)
Surprisingly, while Wylie is clearly not a gamer, he picked up on the interface very quickly... the best of all three.
Task 1 (easy): Pausing, Resuming the game
The user was easily able to pause and resume the game.
Initial conclusion: No issues/improvement needed here.
Task 2 (medium): Eating
The user was able to grasp the control scheme right away, and didn't have any problems.
Initial conclusion: No issues/improvement needed for this user.
Task 3 (hard): Eating with obstacles
The user did not seem to realize what the character was doing at first when it began slouching, but after the dialog box popped up, quickly began to click and drag the character back to the correct position.
Initial conclusion: The user seemed to grasp the control scheme here just fine.
Discussion (12 pts)
Discuss your results. What did you learn from the experiment? How will the results change the design of your interface? Was there anything that the experiment could not reveal?
The lofi experiments proved to be very revealing. By testing our interface with users, we were able to identify a number of shortcomings in our design as well as areas of improvement. We also asked our interviewees several questions at the end of their interviews to gather more feedback. The feedback we received was extremely helpful. In many cases, we were able to implement the suggestions immediately so that we could test the changes with the next interviewee. A summary of the lessons learned and the modifications we were able to make are detailed below.
Lessons Learned
What we learned from the experiments can be placed into two categories: what we learned about our interface and what we learned about lofi interviews.
Interface
- Good introduction to dining etiquette: To ensure our game is holding up to our mission statement, we asked each interviewee for his or her opinion on how well the game teaches players about dining etiquette. All three interviewees said the game gave a good introduction to posture control and eating behavior (i.e. proper ways to cut steak and eating pace). However, they would have liked to see more etiquette rules applied in the game, such as proper ways to drink soup and folding napkins. While some of those ideas were already on our to do list, a few were new suggestions. We took the criticisms seriously and hope to implement many of the suggested features in our final design.
- Clear layout of food and positioning of character: One of our main concerns was whether or not the eating process was clear. From the feedback we received, we learned that not only was it clear to the user the food had to be eaten by the character with the utensils at hand, the third person perspective gave the user a better sense of what was happening around the character.
LoFi Interviews
- Difficult to depict cursor changes: Cursor changes (i.e. from a pointer to a hand) are important signaling devices in computer programs. To replicate this feature in our experiment, we drew cursor icons on paper strips that we displayed and changed as the interviewees moved their hands around the interface. However, the real time response of a computer was hard to simulate in person so we were unable to capture the implications of having cursor changes.
- Important to show game instructions on paper: Because we were not allowed to narrate instructions to our interviewee's, we found that it was vital to display playing instructions on our interface much as we would have to do in a tutorial. Before we conducted the experiment, we assumed our interface was clear enough for the user to pick up on the game play. However, we soon found out that there were certain aspects of the game there weren't clear. We made the appropriate adjustments and saw significant improvements in our interviewees' understanding of the game play.
- Practice makes perfect: Before conducting the experiment with our interviewees, our team had a trial run to flush out all the problems and inconsistencies in the design. During our trial run, we came across several issues that we had to work out but the resolution of those issues ultimately led to a better interface. Additionally, our actual interviews ran smoother than we had expected since we were all familiar with both the interface and the interviewing process.
Changes to Interface
As we progressed through the experiments, we modified our interface based on our users’ feedback. Several changes were made immediately, while a few modifications remain "tabled" (so to speak) for future discussion.
Changes Made During the Interview
The changes described below were made between experiments. User reactions to these changes are noted where applicable.
- Instructions on using fork and knife: Because our first two interviewees found the application of the fork and knife confusing, we created dialogue boxes with instructions on how to use the utensils. Two boxes were made, one for the left hand and another for the right hand. We noted in the boxes that to use the utensils, the user would have to operate two buttons (or mouse clicks). Based on the user feedback, we found it was most helpful to have the instructions displayed at the beginning of the game or at least in the tutorial.
- Click and drag body parts to fix posture: Initially, we had the user click on the various body parts (i.e. head and arms) to correct the character's posture. However, through the interviews we saw that the users were inclined to drag the body parts as opposed to simply clicking on the parts.
- Changing cursors: The cursor was made to change from a utensil cursor when on the table area, to a "grabby hand" cursor (indicating click+drag ability) when hovering over the character's body, and a neutral pointer (indicating nothing to click) when in other areas. This should serve as an indicator to clue the user in on what can be done with the control scheme.
Proposed Changes
The following changes require more discussion within our group, but are noted here for completeness.
- Additional menu items: While our interface had a clear "Pause" button, no other options are visible on the screen. It is thus important for us to display other menu options (i.e. "Menu," "Exit," and/or "Directions") either on the screen itself or in the "Pause" menu. Our "Pause" menu current has the following options: "Resume," "Exit," and "Restart." These are important selection choices to have but it is not immediately clear that to get to these choices the user needs to click on the "Pause" button.
- Dotted lines for fixing posture: Per one of our interviewee's suggestions, we are considering adding dotted lines to frame the character's correct body position once he starts slouching. That is, the dotted lines will show where the character's body is supposed to be in relation to where it really is. This will hopefully make it clearer that the user needs to drag the body parts to fix the character's posture.
- Vegetarian version: For players who may be offended by large slabs of meat, we can include a vegetarian "option" on our game menu. As noted by one of our interviewee's, it would appeal to 1) users who are vegetarian and 2) parents who wish to train their children to vegetables. While this appears to be a great idea, our group needs to discuss this idea further. Our main consideration is whether or not we can implement this feature in the time we have to complete the game.
- Pacing meter: One of the confusing obstacles during the game was the pacing obstacle - users were told they were eating "too fast", but had no idea what to do after this, or how much to slow down. One solution would be to offer a "pacing meter" for the user, possibly integrated with the "food remaining" bar that would designate a pacing range that the user would need to remain between.
Things Our Experiment Could Not Reveal
A paper interface limited what we could show to our interviewees. Two of the features we were unable to test because of this restriction are detailed below.
- Users' response to cursor changes: As noted in the Lessons Learned section, we had a difficult time assessing the interviewees' responses to cursor changesm because we were unable to simulate the fast reaction time of a computer. We made every attempt to change our cursor icons as the players moved their fingers but more often than not the players moved their fingers too fast for our "computer" to swap the pieces.
- Clarity of character's eating behavior: As described in our interview notes, one of our interviewee's failed to notice that the character was eating his steak without cutting it into pieces. To prevent this scenario from taking place again, we found that it is important to clearly depicting the impact of the character's actions on his or her food. In the case of eating an uncut steak, we will need to clearly show an animation of the character taking a bite out of the steak or have the steak fall off the fork before it ever reaches the character's mouth. In short, we may need to exaggerate some of the actions.
Appendix (6 pts)
The appendix should include copies of all materials involved in the experiment. This includes your consent form, demo script, and any instructions or task descriptions you handed out or read out loud to your participants. Finally, it should include all the raw data you gathered during the experiment. Merge the critical incidents logged by the observers and list them here. The appendix materials and screenshots do not count in your 6-10 page total.
Consent Form
The consent form used at the location of the interviews is available in .pdf format here. Due to the videos being taken of the interview process, the interviewees were each notified individually prior to the signing of the contract that the third paragraph's anonymity clause still allows for the taking of the video.
 |
Interview Notes
Raw Data
The raw notes taken at the location of the interviews are available here.
Critical Incident Log
Pause & Resume
- None of the 3 had any difficulties pausing the game
- Morgan had a difficult time reading the text on the pause menu (probably just poor writing)
Eat Food
- Wasn’t obvious how to use the utensils until the dialogue boxes showed up
- Elissa confused about “food left” bar
- Elissa & Morgan ha some trouble figuring out how to use fork/knife or interface isn’t clear
- Elissa & Morgan didn't know the fork had to go in first, tried cutting
- Elissa also tried putting the entire steak in the person’s mouth
- Only learned this was incorrect after feedback screen at end
- Once the steak was cut, Wylie hesitated, afraid clicking on mouth would stab himself, the rest had no trouble
Eat Food with Distractions
- All 3 were confused about tilted head, had similar reactions
- Didn’t know what to do
- Continued eating
- Started to understand what was happening after the dialogue box appeared
- Elissa kept clicking on body parts but did not think to drag
- Morgan and Wylie dragged the head up successfully, but not without doubts
Video recordings of testing sessions
(viewable and downloadable through Google Video)
Participant #1 (20 mins)
Participant #2 (25 mins)
Participant #3 (13 mins)
