PilotStudy-Group:一三三七-BillyGrissom
From CS 160 Fall 2008
Contents |
Introduction
Obesity is a trend that is becoming more and more common amongst people of this generation. Contributing to this phenomenon is the introduction of various games and electronic devices that seem to encourage players to stay in doors. Our project seeks to break this cycle.
Fit Wars is a game for the iPhone where the gameplay is controlled directly by player movement. Player’s walking corresponds to their in-game character’s movement. In addition to this in-game character’s actions are controlled by the player’s actions (i.e. jumping or spinning).
The purpose of this experiment is to better explore the functionality of Fit War’s interface and see how well user’s interact with an interactive prototype of the interface. Based off of the user’s reactions and responses we’ll be able to conclude what improvements and changes might need to be made before proceeding with the final implementation.
Implementation and Improvements
A number of things have been added to the prototype to make it interactive. First off, a lot of the hover elements have been removed form the interface. The reason being that we realized that although the hovering element was a nice feature, it is actually impossible to hover over elements on the iPhone. This is because the touch screen interface has no way of detecting said movement.
Nonetheless, the features the hovering elements provided is something that we thought was a nice addition to the interface. Although this implementation has no alternative, we’re currently researching ways to still have said functionality.
In addition to removing the hovering elements, the Game Settings page was implemented. This part of the interface allows users to configure the game’s settings. They can decide whether they want to turn the Game Music on or off, turn the announcer’s voice on or off, enable game sounds or not and finally decide whether they want to go for a more casual form of play.
The Casual mode enables users to play through the game without having to worry about the chance moments in the game. This feature was implemented based on the feedback we got from one of the users when experimenting with the Low-Fi prototype.
In casual mode players able to simply just run the course. Of course as a result they get less points and don’t get the title of defeating another player.
All of these settings are controlled via sliders that the user can use to switch the settings on and off. This provides a nice simple interface that provides a bit of a “wow” factor yet also is still really easy and intuitive to use.
In addition to this, the Game Settings page also features a Calibration section. This section lets the users calibrate their iPhone so that it more accurately measures their movements. All the users have to do is follow the instructions and simply walk until they hear a sound or have filled the calibration bar.
Finally, in addition to the UI changes and Game Settings page, the Manage Stats page has also been implemented. This section of the interface provides the user with information about their character, their equipment, their stats, and their ranking in comparison to others. The ranking is portrayed by a graph that shows where they stand in comparison to other users. The rankings are dependent on the overall distance ran by users.
Method
The participant I selected is a senior at Berkeley studying Micro Cellular Biology. She is a 21 year-old female Asian that enjoys casual runs and occasionally exercising at the RSF. I selected this participant because I felt like we haven’t had the chance to gain the opinion of a female in a stressful major at Berkeley. MCB is one of the most intense majors at Cal, and I felt like running is often a good way to reduce one’s stress. Perhaps when coupled with our game, the running can be even more fun. I felt that the input from this participant would be highly valued and provide a nice perspective on our interface.
The testing for this experiment was conducted at the user’s home. This was to ensure that the test was as convenient for them as possible and in an area they felt comfortable with. The user used my Mac Book Pro to run through the interface.
There were three scenarios the user had to run through. These scenarios are listed below:
Scenario 1 (Easy Tasks): For the most part this was pretty intuitive. The user was told to log in then find some stats…most of which were under the Manage Your Stats section. 1. Log into the Game. 2. Determine what your Distance Ranking in the game is. 3. Determine what equipment you currently have equipped. 4. Determine what the name is of the player you’ve fought the most.
Scenario 2 (Medium Tasks): For this section the user spent most of their time looking at messages, playing with the game settings, and setting their controls. 1. Check your messages. 2. Read any new messages and reply to them. 3. Configure your game settings. 4. Calibrate the controls.
Scenario 3 (Hard Tasks): This scenario was similar to the one we used in the Lo-Fi Prototype. Here the user was required to find a friend to battle and then play through a level in the game. 1. Find a player to battle. 2. Battle the player / complete their course. 3. Successfully complete the player’s course.
Before beginning the test I had the user confirm they did indeed want to do this and had them sign a consent form. At the beginning of the test I sat the user down and briefly explained what our project was about. I showed them screenshots of our interface and explained what the overall goal of the project was. After formal introductions were over the user sat down and went through the various tasks. In the mean time I sat on the side jotting notes and watching how the user would respond. Since the interface was well-built and very interactive, there was no reason for there to be a computer or assistant like in the lo-fi prototype. If the user had questions then they would often be able to find the solution through the interface.
After introducing the user to the interface I sat near them and took out my notebook. I observed their actions and jotted down the results as they worked through the interface. If they had any questions I left it to them and the interface as to where to go. If they got completely stumped then I would give them a few minutes, then finally explain to them what might be wrong. Luckily, that scenario didn’t really happen.
At the conclusion of each scenario I would congratulate the user for successfully getting through a set of tasks and then restart them at the main menu and began the next set. At the conclusion of the experiment I thanked them for their cooperation nd asked for any feedback they might have.
Test Measures
As the user progressed through the interface I took note of their expression and reactions to various interface elements. Through this I was able to see what excited them or possible made them confused. I also took into account any words the user would think aloud to herself (i.e. “Wow!” or “whaat?”). In addition to this I also took note of the movement of their hands o see whether they were idle or not while thinking of where to go next in the interface. Finally, I also took into account how much time they were taking to look through things and if there was anything that would seem stumped or confused about. Based off of these measurements I was able to tell what the user’s overall reaction was to various interface elements. Also, I would ask the user for feedback at the conclusion of each scenario.
Results
After the formal introductions, the user then began to conduct the first tasks. For the most part they had little problems and were able to navigate the interfaces with little problems. Upon competition of this scenario she continued to work with the second.
I noticed she had little problem logging in and thought the characters she were able to select were cute (chiefly the Panda). Once they clicked log in I realized she really began to get into the in-game music. It seems as if the music almost gave her this sense of excitement and she now looked excited to explore the interface.
The user had no problem finding the tasks in the first scenario. She was able to navigate the menus pretty intuitively as if it were all almost natural. I thought the removal of the hovering descriptions would make things a bit confusing but she seemed to have no problems getting through the menus.
One problem I did notice however was with the character select screen at the registration page. Although she did think it was cool I realized she clicked the character portrait a lot expecting that to be the way to confirm the registration. S he failed to see the register bottom at the bottom o the page.
In addition to this, the user also had trouble reading the graph that showed the stats. This seemed to be moreso because there was just too much information jammed in on the screen and the legend of the graph was a bit too small.
Upon completion of the first scenario, the user began working through the second scenario. For the most part the user navigated through everything fine and was able to find things ok.
Troubles, however, did arise at the message menu part of the interface. I noticed the user had trouble navigating through the messages and replying back. The user confused the New Message Button (which creates a new message) as being something that shows you the latest message. In the end they did find the new message, but I also realized the user had problems locating the reply button on the message interface. In addition to this it also seems that there was some bugs that arise with the message interface that caused something’s to act strangely.
Finally, the third scenario, although the hardest, seemed to provide little difficulty for the user. The user was able to battle the player fine and complete the course. Interestingly enough the user actually found the system to be quite entertaining and wanted to play the course again after testing it. The user had no problem running and emulating the jump command. Overall the user seemed to have a good time with the game.
Discussion
Testing procedure wise, I don’t think there is much that needs to be changed. Interface wise, however, I do think there’s a few things that might need to be worked out. Overall the user seemed very satisfied with the interface. She said that she felt it was very intuitive and generally quite user friendly. Nevertheless, her immediate reactions did show that there was a number of kinks that needed to be worked out. It seems that the Stats Page might need to be rearranged so that everything isn’t quite so packed in. Perhaps it’d be better to have multiple pages rather than just one.
In addition to this I think adjustments to the Message Screen are an absolute necessity. The user seemed to have the most difficulty here and it seemed like it needs to be made more clear where the divide between messages and buttons are.
In fact I feel like this is something that needs to be taken into consideration across all of the different screens/sections. A really good point the user suggested was that at times it was hard to distinguish the buttons from static text. I think it would probably be a good idea to go through the interface and assign all the buttons a new template that makes them stand out more. One thing that I thought would be an interesting (though drastic) change would be to change the way buttons are arranged on the sub sections. Right now they’re often scattered and look like pan text. It might be better to take use of the iPhone’s default menu template and use that to portray a menu for the buttons. Again though…this is just a thought. Another alternative might be to keep things the way they are and just have a line that separates the actual date form the menu items.
Another interesting point was that the user didn’t seem to like the white on black text. It seems that maybe having some sort of option that inverts the color scheme or something might be useful for some users…
Overall it seems that the user was defiantly very pleased with our interface and likes the idea of our project. It seems at this point we really just have to work out a number of bugs within the interface and make a couple of adjustments.
Appendices
Materials (all things you read --- demo script, instructions -- or handed to the participant -- task instructions) Raw data (i.e., entire merged critical incident logs)
