LoFi-Group:一三三七
From CS 160 Fall 2008
Contents |
Introduction and Mission Statement
Fit Wars is a project being developed for UC Berkeley’s User Interface course (CS 160). Fit Wars is a program for the iPhone that builds upon the philosophy of serious games. Using the iPhone’s built-in accelerometer, we hope to measure the movement of the player and use their movement as input into our game.
The game provides a competitive atmosphere where users can either “battle” the computer or fight one another. Although battles look like battles on the screen, the outcomes of these battles largely depend on the distance a user has run as well as his/her ability to successfully react to various motions.
Mission Statement: Our ultimate goal is to help college students stay more in shape by providing them with a competitive game that requires them to physically get up and move in order to progress through the game.
The Team
- Billy Grissom created the low fidelity prototype of the User Interface and acted as the phone in the experiment. Also responsible for finding one of the users for our interface, generating the Consent Forms, and drafting the scenarios the users had to work through. In addition to this he contributed to the Introduction and Appendices section and put the final draft of the paper together.
- Saliem Than was responsible for finding one of the users and helped in the experimentation with said participant. Logged the participant’s moves and generated questions for the participant. In addition to this she also wrote up the prototype section of the paper.
- Jeffrey Rosen was responsible for finding one of the users and helped in logging the actions of the users in the experiments. Jeff also kept time of the users as they went through the scenarios. In addition to this he also composed the Method section of the paper.
- Alan McCreary thoroughly recorded many of the various users’ actions. He also generated many intriguing questions for users about their opinions regarding our interface. In addition to this Alan conducted the Results section part of the paper.
- Buda Chiou also recorded many of the users actions as they went through the experiment. He also took detailed notes regarding their opinions about the scenarios, interface, and overall project. In addition to this Buda created the Discussion part of the paper.
The Prototype
The Low-Fi prototype of our system is represented through a collection of white paper note cards. These cards are each half the size of a standard note card. We chose cards like these so that we could accurately represent the true size of an iPhone screen. The goal of these cards was not to make something flash, but instead create a number of successive screens that represented the menu and state of the phone's display correctly. Nevertheless, in addition to the standard black pen we did use red and blue pens to spice up the look a little.
Our end prototype consisted of over 50 different screens. The screens all fell into four different different sets which each consisted of different sub categories. The first level of cards simulated the screens the user would see when first opening up the application. This included screens such as the Log In Screen, Registering, and the Main Menu.
The second level of cards derive themselves from the Main Menu. These categories represent the pathways that a user will be able to take once they get to the main menu after they finish registering or logging in. They are essentially the submenus within menus.
The third set illustrate the screens a user might see if they were to choose the second level card categories of challenging a player or battling a computer.
The final fourth set of note cards are the screens a user might see as they were "fighting" the computer or another player.
Lastly, we have a misc. set of cards that represent the keyboard and visual feedback cues when a user chose to do something (ex. when the user bought a piece of equipment, there was a confirmation message, or when the user equip his character, there was a message note card confirming that he did that). These are essentially the pop up windows that overlay a given screen. These cards also include any of the built in iPhone features (i.e. the built-in iPhone keyboard).
Login Screen & Main Menu
We have three cards to illustrate the different screens here:
- Login Screen: The first screen has the title of our application at the top. There are two input boxes labeled email address and password. There is a check box to remember the user and there are buttons to either log in or register
- Register Screen: The second screen shows up if the user chooses to register. They will see a screen that has three input boxes for the user name, the password and email address. At the bottom there is a red arrow indicating that the user could scroll downwards, and once they do, they will see more input boxes asking for their gender, the name of a friend who referred them to the game, and a button to create an account.
- Main Menu: The screen they will see next (or if they had chosen to click on log in) will list their user name, a profile thumbnail image, the level they were currently at, the number of points they had, a number if they had any messages, and options to:
- Fight the CPU
- Fight another Player
- Point Management
- Check Stats
- Messages
Fight the Computer
If the user chooses to battle the computer a screen with 4 options will show up. Those 4 options are to:
- Continue the battle,
- Start a new battle
- Read the Tutorial
- Go back to the Main Menu.
In addition to this, we have a error card just in case the user chooses to continue a battle if they haven't started a battle yet. Otherwise, continuing a battle would drop you back into whatever battle you're currently in. If the user chooses to see the tutorial, a screen will show up and they can scroll through the tutorial. At the end of the tutorial (once they scrolled to the bottom), there is a button to go back and see the above set of options.
Fight Player
If the user chooses to fight another player a screen will show up with more options to either
- Auto Match
- Find a Player
- Go back to Main Menu
If they choose to find a player, the user will be presented with a keyboard and be able to type in the name of the player they're looking for. After that, a loading screen will show up with a random game tip. After the loading completes, a list of players found will show up with descriptions and profile images, and the user will be able to tap on a users profile to choose, then tap on a button to battle. There are also buttons to go back and start another search. AutoMatch essentially does the same thing, only it skips the keyboard part and instead finds an optimal match for the player.
Point Management
If the user chooses to go to point management from the first set of cards, the user will see their name, the level they are at, their profile image, and options to:
- View the equipment they have
- Buy weapons
- Buy armor
- Buy items
- Transfer points
- Go back to Main Menu
Buy armor/weapon/item all follow the same format for their interface. Thus, there is a certain set of screens collectively representing the interface for all of them. If the user were to choose to buy something, they will see a screen listing the items to scroll through and choose. They can also click on an item to see details on a particular item. So if they click on one of the items, they will then have the option to buy the item, or go back to the list of other items. If they buy something, a confirmation message will show up with the option to equip the user's character or to go back and buy more items.
If the user chooses instead to transfer points instead of buying an item, a confirmation screen will show up with options to confirm continuing transferring points or to go back to the previous screen.
If they choose to continue they will see a screen with the level they were at, the number of points they had, an input boxes for the amount they wish to transfer and a selection menu for a list of games they wish to have the points transferred to. Then there are buttons to transfer the points or to go back to the previous screen.
If the points transfer successfully a confirmation screen will come up if not, an error screen directing the user to a website will show up.
Checking Stats
If the user chooses to check their stats, a screen will show up with their profile image, name, points, number of steps, level they are at, the status of their defense and offense, and the options to view the equipment they had or to go back to the previous screen.
If they choose to see the equipment they had another screen will show up with options to see the weapons, armor or other items then had, with the option to go back.
If they choose to see an item, the item descriptions will show up with the option to go back.
If they want to change their item, then they will be presented with a list of items that they currently have in their inventory.
Messages
If the user chooses to check the messages they had from the home screen, they will see a screen to write a new message, to clear the messages they have, a list of messages to scroll through if they have any, and an option to go back a screen.
If they choose to write a new message a screen will show up with an address input box, a message input box and send and cancel buttons.
If they choose instead to clear the messages they have then a confirmation screen will show up with yes and no options.
Loading Screens
In various segments, the program will obviously require time to load some of the data. During these moments users will be presented with vairous loading screens. These screens will contain a random tip about the game as well as a bar that helps the user see the progress of the loading.
Playing the Game
Once the user picks a player or CPU to fight and is equipped, the user will see a screen with a progress bar at the bottom, a character running against a landscape background, and details about the course level at the top of the screen. (At this point the screen is set lengthwise, the iPhone screen is rotated 90 degrees). They will see different screens instructing them to jump spin or run, all the while they will hear this too, and they will get sound feedback for doing those things.
Once they successfully complete the course a confirmation screen will show the number of points they gained, with the option to continue on to another course, to shop for equipment or to head back to the main menu screen.
If they fail / lose, they will get a "game over" feedback screen with the option to try the course again, to shop or to go back to the main menu.
Overall System
The Method
Below you will find information regarding the various parts of the methods we used to achieve our tests.
The Participants
For this experiment, we found three participants to participate in our study. Each of these participants are shown below. For confidentiality reasons they well simply be referred to as Person 1, 2, and 3.
Person 1 was selected because she is involved in a lot of group activities. Given the nature of the game, we felt that she could give us a lot of insight into how the group aspect of the application could be improved. She is not an avid runner, so she would be using the game to get motivated, like many people in our target user group. She does not own an iPhone, which is useful for our testing to make sure that the game is as platform independent as possible.
Person 2 was selected because she is a runner. She is very athletic and was able to give us a lot of feedback from the perspective of someone who runs every day. It is interesting to make sure that our ideas are sound from someone who represents some of the later stages of the game.
Person 3 was selected because he owns an iPhone so he is familiar with how it works. We wanted to make sure that we didn't use any user interface elements that conflict with native iPhone applications. He works out regularly and plays video games a lot, but would like some more motivation to run, so he would be the perfect client for this application.
The Environment
We conducted the tests on a table with one interviewer simulating the UI for the interviewee and the other four members taking notes on the various outcomes. While the role of the computer/phone was always constant, the rest of the members switched between the other roles (i.e. greeter and facilitators) as we conducted the tests.
We did the tests on the large outdoor patio in the Free Speech Movement Café. Initially we were worried that the wind would blow our cards around, but luckily it was a calm day. We had a large table, and it was perfect because the interviewee could sit opposite from the interviewer and use the large table for the UI.
Although it might’ve seemed more sensible to do a test indoors, we selected an outdoor environment largely because of the nature of our program. Our program is geared towards active movement; which is often used in an outdoor environment or an active area. Since Free Speech is both outdoors and has a somewhat low-key yet vibrant atmosphere, we thought that it would be the perfect place to conduct our tests. In addition to this, since our application is based on motion, we wanted an area where the user would feel comfortable getting up and moving.
The Tasks
Each of our users were required to work through 3 different scenarios with our program. These scenarios ranged each expressed a different “difficult” level of the program. We selected these three scenarios because we thought they best demonstrated the various aspects of the program.
Task 1: Register an Account and Send a Message The point of this task was to get started in the application from a completely blank state. We were testing for any difficulties in registering a new account, logging in, and figuring out how to send a message to a friend. The user was required to get into the main menu and then send a message to their friend.
Task 2: Find Tutorial and Battle another Player This task tested the application's primary use case. Getting started on a run. We wanted to make sure that it was easy for first time users to figure out how to get to the tutorial to learn the rules and then play the game itself. The user was asked to read the tutorial and then battle the friend they previously sent a message to. In addition to reading the tutorial and initiating a battle with another player, the user also actually went through the games interface.
Task 3: Change armor and transfer points to a game This task tested the second part of the game. Once you have done enough battles you earn points and are able to perform various actions with them. This tests the ease of use for long-term players who use the game regularly. The user was required to purchase new armor and then equip it. In addition to this, the user was required to transfer their points to an existing game on their account.
The Procedure
We were able to simulate the interface of the iPhone and website surprisingly accurately with note cards. We had one portion of the table represent the user's iPhone. We put note cards down and had the user pretend that they were manipulating the iPhone's screen. Behind the scenes we had stacks of note cards that we could swap out to simulate the user's actions. These were kept out of the user’s view so that they couldn’t potentially “cheat” the system and look at screens they technically couldn’t see yet. We were able to simulate even complicated actions like scrolling by keeping the cards the same size and then replacing them according to where the user had scrolled to.
For the first task, we started the user on the main menu and basically told them what action we would like them to perform. In this case it was to register and send a message to another user. First, we instructed them to register. We presented them with the home screen card and explained a few basic iPhone tasks that were being represented with our note cards. For example, we explained what we wanted the user to do if they wanted to scroll, or if they wanted to click a button.
We watched what they did and they would tell us, "Ok, I am pressing the login box". We would then swap in the iPhone keyboard, without saying anything. They would then say, for example, "I typed in my email address and pressed OK". We would then take away the keyboard. We had many cards, so it was possible to simulate anything the user did; even functions that they weren’t required to do. They were organized, so we could swap them out rapidly to avoid any unnatural delays.
We were careful to be completely silent during the task so that we could create the most authentic experience possible. Sometimes they would ask for help, but we would just document their troubles and reassure them that it was not a test and that they are just helping us find the flaws in our UI.
Test Measures
To measure the results, we essentially had four people (the people who were not running the UI) take notes on everything that was happening. If the user was having trouble, we would note exactly where he or she was struggling. If they found something easy, we would note that that action was easy. We collected all of their feedback as it happened.
After each test, we asked for their explicit feedback to supplement the implicit feedback we had been gathering along the way. We also asked them for general suggestions to each part of the UI.
The Results
One type of problem testers found was misplaced buttons.
- The most significant problem testers had with the interface involves finding the tutorial. Two testers went through almost every item in the main menu before pressing the correct button, using a process of elimination to determine which button leads to a tutorial. In this prototype, we placed the tutorial link inside the “play against a CPU” screen, assuming that a beginning user would first test the program by playing against the CPU. The testers did not share this intuition, however, so they had a hard time finding the tutorial.
During the tests, all three of the testers brought up unclear aspects of the interface.
- When asked to register a username, one tester mistakenly tried to register a username and password by entering both in the login screen and pressing “register,” since it was not obvious that pressing the “register” button takes the user to a separate registration form.
- Another tester was confused by the screen that asks for the username of a referring friend, since she did not have a friend who referred her – this made her feel that she could not register.
- The “back” button on several of the screens concerned one user who was not sure whether the button takes the user back one page or back to the main menu.
- After purchasing new armor, a user was not sure whether to press “equip” or “go back”.
- When asked to transfer points to a game, it was not obvious to one user that one of the buttons would display a list of possible games.
- One button asks the user to “fight the CPU”. This button was unclear to one tester who did not know what CPU means.
- When asked to change armor, two of the testers had trouble remembering the correct button to press on the main menu. This indicates that the names of the buttons are not clear enough.
- Two testers suggested adding a confirmation screen after sending a message or transferring points.
The style of the actual gameplay also concerned some testers.
- Two of the testers expressed concern over the idea of looking at the phone while running, saying that it could be either dangerous or uncomfortable in the presence of others.
In general, the testers liked the idea behind the gameplay. They suggested that a more cartoon-like theme might be enjoyable. When asked about music, they indicated that background music would be a nice option.
Discussion
Tutorial Finding Problem(Severity Rate: 5): Originally we put the tutorial in "Fight CPU" because we assume users will start running right after they enter the game. However, when we do the evaluation, the task we ask evaluators to do is "find the tutorial." Therefore, they intuitively want to find the option "tutorial" from main menu, and they can't. What they do is they always ckeck "Point Management" at first and then check "Ckeck Stats", which means that they kind of expect tutorial should be in some game setting options instead of the game playing option. In fact, "Fight CPU" is the last option they check for tutorial. This expectation for evaluators comes from their experience of the general games, which usually put tutorial option in main menu. Although the tutorial finding problem was kind of caused by our task given, this result revealed that some people are more likely to look at the tutorial before they start playing the game. Therefore, we will combine "point management" and "ckeck stats" into one option since they seems more related according to evaluators reaction, and we will put "tutorial" option on main menu.
Register Confusion(Severity Rate: 3): The problem that user may press "log in" button for register is a common mistake that made by computer users. The reason is that when there are two button side by side on the screen, usually the button on the left is "cancel" button, so when users try to proceed the current task, they tend to press the button on the right. To slove this problem, most website will prompt user to register after they found the users who press login haven't register yet. Our solution is to put "register" button on somewhere that is more conspicuous place.
Referring Friend Confusion(Severity Rate: 2): Referring friend question is used for user to find their friend who also plays the game, but there is still a great possibility that users get the information of this game by other way. In this case users may confused by this question since people usually stunned by questions they don't know the answer. To slove this problem we will label the quesitons that users must answer and inform them which questions are optional.
Button Return Place Confusion(Severity Rate: 2): The design for back button followed up iphone design. Although this doesn't seem to be a big problem, to solve that we may add a button that allow users go back to main menu.
Equip Option Confusion(Severity Rate: 1): The "Equip" option is for users' convenience after they buy the desired armor. Since this may not be so common in most games, users may confused by the option. However, once they try it they will know what it means, and since this trying won't cause any loss for them, it's no big deal.
Points Transfering Confusion(Severity Rate: 3): Since the points transfering for games is new idea for games, users may not be used to perform this kind of task. However, the reason the evaluator confused by game selecting maybe because she didn't expect there are multiple games users can choose, or she thought the game points are shared by all games. For both case we may add some description on that page to explain what's going on.
Fight CPU Button Confusion(Severity Rate: 2): We expected that everyone should know what CPU means, and obviously we are wrong, so we might change "Fight CPU" to "Fight Computer," and there should be more people know what is "Computer"
Button Confusion for Change Armor(Severity Rate: 2): It's really hard to convince users which are button by paper prototype. For the real interface we will make buttons have special color or shape so that user can distinguish them from other parts of screen.
Conformation Request for Send Message and Transfering Points(Severity Rate: 4): Transferring points and sending message may be some serious decision made by user, so they want to see some conformation. We will make a transaction diagram before and after transfering for users to see the points distribution for their transaction so that they can see what's going on. For sending message, we will make the dialogue appears on the screen so that users can see what they have sent.
Users Suggestion: The theme we were considering are the cute style like cartoon or serious style like Warcraft, and our testers all suggest the former one, so we decide to choose the cartoon style. The sound is what we originally most concerned about, and that's also what users most concerned about, but we can't show it on paper prototype. What we tried to do is make a sound when user have to perform some special actions during running or have run certain distance. All testers suggest it would be great if we have background music, but the problem is the background music should be users' own music or music we made for the game. We may make users have the option to select which to be their background music for the game.
Appendix
Sample Consent Form
In order to preserve the confidentiality of our users, the real signed consent forms will not be posted on this page. Instead, they are attached to the official paper copy of this document.
The Walkthrough Script
Scenarios Users have to Go Through:
- Scenario 1: Log into the site and send a message to a friend. Your friend's name is DoucheBag.
- Scenario 2: Read the tutorial and then challenge your friend DoucheBag and complete his course.
- Scenario 3: Change the armor that you character has equipped and then transfer points to your game account.
Make sure to ask questions about what the user did after they're done.
Questions to ask afterwards:
- What did you like about the interface?
- What did you not like about the interface?
- What would you add to the interface if you could?
- What would you change about the main menu?
- Would you change the layout of any of the sub-menus?
- Did you think the loading screens tips were helpful?
- How do you feel about the battle system?
- What do you think about the idea of human characters?
- What do you think of the title? Do you think that there could be a less corny title?
- Anything else?
Experiment Notes
Tester 1
Task 1 – Register and send message to another user
- Liked the registration screen and the scrolling mechanism
- Commented that she'd like a confirmation notice after sending a message
- Also stated that she would like a screen displaying previously sent messages
Task 2 – Go to and read tutorial, battle against another player
- Had a very hard time finding the tutorial
- Went through several screens before finding it: point management, stat checking, messages, "fight another player", avatar
- Said that she would prefer audio to go along with the visual battle, since it would be inconvenient to stare at a phone throughout a run
- When asked about the left-to-right style of the gameplay, she said that a more "first person fighting" style would make it more exciting, since that makes it feel more like a competition
- When asked about the general theme of the game, she suggested that characters along the lines of Nintendo's Mii characters would be nice
Task 3 – Change armor and transfer points to a game
- At the main screen: after hesitating a little and then pressing the correct item on the menu, she said, "I should have remembered this button"
- Was able to purchase the armor pretty efficiently
- Slightly hesitant at the purchase confirmation screen: was a little confused by the "equip" button, and wasn't sure whether to press "equip" or "go back"
- Was able to transfer game points efficiently, but said that she would like a confirmation screen after the transfer
- Also suggested a point transfer log
- In general, she was concerned about getting lost among screens – what does the "back" button do at each screen: go one screen back, or go back to the main screen?
- Likes the point transfer idea a lot
- Is a little concerned about the requirement to jump during a run, since that might look weird in public
- When asked about music, she said she likes the idea of being able to choose her own music; she would like the game sound effects to be played over this music
- When asked about the "tips" screens, she said they're a good idea
Tester 2
Task 1 – Register and send message to another user
- At the login screen, he typed a username and password and immediately pressed the "register" button, even though the front screen's text fields are meant for already-registered users
- Said that he would like the username and password to be remembered by the application for future use
- Likes the scrolling message window
Task 2 – Go to and read tutorial, battle against another player
- Couldn't find the tutorial
- Went through many screens to find the tutorial: point management, stat check, view equipment, fight player, messages, and finally "fight cpu" (the correct button)
- There was no obvious way to get to the tutorial, so he essentially used a process of elimination
- Asked if he is supposed to look at the screen during the run – said that it seems pretty dangerous
- When asked about the text-only format of the tutorial, said that a few graphics might be useful
- When asked about the left-to-right gameplay during a run, he said that a hybrid between the left-to-right style and a Street Fighter-type style would be good
- Suggested that an overhead "map view" might be good as well
- When asked about having background music, he said that having an option of choosing background music would be convenient
- If there is music, he wants it to be uninterrupted – doesn't want the music to quiet down during sound effects
Task 3 – Change armor and transfer points to a game
- A little hesitant at the main screen
- Said, "I think it was 'check stats'..."
- Said he would like a confirmation screen after a point transfer
- Suggested that putting the "point transfer" option under the "stats" menu would be more appropriate
- Asked about the game in general, said he likes the "find player" option
- Suggested the idea of a "continue battle" option to continue a game against another player
- When asked about the general theme of the game, said that a cartoon-like theme would be better than a more "hardcore" theme
Tester 3
While registering L.J. thought the registration screen was a little confusing, she felt that the red arrows should be a little larger and that the header/title should stand out more.
When there was a screen that asked her for the name of a friend, she didn't know what to put, since she didn't have a friend who referred her to the game. Since she didn't have a friend who referred her, she felt that she couldn't register.
When set on the task to message a friend she asked about one of the buttons which asked her if she wanted to play against the cpu. She asked for the definition of a cpu. She then chose to fight the player right away. The paper mock ups assumed that she would buy armor first but she was expecting to buy the armor after she tapped on the fight player button. ..so we went back and she tapped on the button to buy armor.
When she got to the "store" (list of items to buy) and selected an item, a confirmation? menu came up. She wasn't sure what to do next and so Billy told her that she had to actually tap the box that came up to continue. She asked about viewing the number of points she had and the items she had. She thought it was funny that you would be walking and moving around in public "fighting" .
At the end of the couse, LJ decided to go back to the store. She then asked if she would have to buy some more things, is she could transfer points and about the point management screen.
On the last task of transferring points to a specific game, she stalled after seeing the menu and then she tapped on see stats. She didn't see any options for transferring points so she tapped back and she then saw the button for point management tapped it and then tapped on transfer points. The transfer screen had a select button for games she could select to transfer the points to. It wasn't readily obvious to her that the select button would show the list of games.
When she came to the screen that asked her to visit the website, she mentioned that she didn't like the idea of having to go to a website to do that.
She then suggested combining the check stats button with the points management button. That the point management screen could allow her to buy things and check her stats. She asked about the tutorial screen and found out that she could only access that if she had tapped on fight the cpu. She thought that it was a better idea if the link to the tutorial was directly accessible on the home page. She thought that the idea of sound feedback was a good idea.
When asked about the running screen and when asked about using a street fighter styled screen instead of that, she thought the street fighter styled screen would be mor entertaining. When asked if she would rather have a comunity of friends to fight and play against she said yes. When asked if she thought that would help fuel competition she said yes.
She mentioned that she wanted more information about how good a weapon was. She suggested listing the points for a weapon as opposed to an entire description.
As for the theme (medivael, pirates, ninjas, pokemon), she mentioned that having animals fighting against eachother, something imaginary and made up, and certainly not humans would make the game more entertaining and fun.
She asked if she could also change her profile picture.
Later after the interview/experiment, she called and suggested that the homepage shouldn't maybe have input boxes for an email address and name (which she thought were perhaps too big) and instead, the home page should just have a (the?) name instead with a button somewhere in the corner that lead to the registration page. She mentioned that that was the regular design heuristic that she encountered often.
