FinalPrototype-Group:MechanicalSquirrel

From Cs160-sp08

Jump to: navigation, search

Contents

Team Members

  • User:Eric Cheung - Eric made changes to the code, wrote the report, and made the poster.
  • User:Alex Choy - Alex made changes to the code, wrote the report, and made the poster.
  • User:Hsiu-Fan Wang - Hsiu-Fan made changes to the code, added visual content, and made the presentation.
  • User:Glen Wong - Glen made changes to the code, wrote the report, added visual content, and made the poster.

Problem and Solution Overview

Many self-improvement systems and ideas exist now. However, they do not cater to every audience. Specifically, many "hardcore" computer game players lack the motivation and incentive to go outside. Our solution provides gamers with a real-world role-playing game in which gamers can augment their desire to play games with a desire to get out and do things outside. By offering gamers a quest and reward system, they can have the same sense of accomplishment and achievement they obtain with regular games, except in ways that can improve their lifestyle.

Target User Group

Our target user group is computer gamers who would like an increased incentive to go outside and do things. This user group generally spends most of its time indoors playing conventional games. They value the rewards/achievements they get from playing these games and wishes there was a similar system for doing things in the real world. These users have experience with mobile games and generally have their cell phones with them most of the time. They are familiar with the game mechanics typically included in most role-playing style games (e.g. creating a character, completing quests, etc.) and also enjoy customization aspects.

Tasks

  1. Creating a character (easy)
    • This entails the initial account creation and the editing of the avatar. Initial account creation involves specifying an email address, the phone number, and avatar gender. Afterwards, the user may select clothing - head, shirt, and pants - for their avatar with spinners beside the avatar image. The avatar will update automatically when a setting is changed.
    • We chose this task because every user must go through this task in order to play our game. It is also the first screen that users see, so it is important that it be accessible and easy to use and set the tone for the rest of our interface.
  2. Seeing a quest to completion (hard)
    • This involves first searching for a quest from the "Find New" tab in the Quests screen, viewing its details (objectives, map of objectives), then accepting it.
    • After accepting the quest, the user goes to the "map overview" screen and uses the directional pad to simulate movement and complete the quest
    • As mentioned in our group's individual pilot studies, we have combined all of the quest-related activities into 1 task and made this a hard task. This task is very important to our application as it basically involves all the core game play aspects.
  3. Arranging the room (medium)
    • The user will move around certain items in their room, replacing certain items with others. Optionally, the user can edit their avatar.
    • Also, as mentioned in our group's pilot studies, this task has been downgraded from medium to hard. We chose this task because it represents another important part of our game outside of the game play itself. Over the course of our user testing, we learned that our users like customization and this task allows them to customize both their avatar and room.

Design Evolution

Overview

Overall, we found that the low-fidelity prototype testing was the most important evaluation technique we used. It was the first opportunity we had to test the usability of our proposed interface with users. The low-fidelity user testing provided us with the most feedback and subsequent changes than the other evaluation techniques. By the time we tested with our pilot usability prototype, the problems we found were relatively minor, as most major problems had been fixed after the low-fidelity testing. The interactive/pilot usability prototype were very helpful in determining implementation problems and lapses, but the low fidelity prototype was most helpful in tweaking and improving our interface. Contextual inquiry was also helpful in getting us started and providing us with a general idea of what our application and interface should be like, but low fidelity testing gave us a more concrete example to test our users with.

Character Creation

  • Initial sketch/lo-fi prototype: For both our initial sketch (in the contextual inquiry) and our lo-fi prototype, the avatar editing part of character creation had 4 spinners on the screen, plus a box underneath the avatar for the character's name
  • Final prototype: From the interactive prototype on, we changed this design to reduce the number of spinners to 3 and removed the box below the character's name. From our lo-fi testing, we discovered that the box under the character's name would be very difficult to use considering that it was to the right of one of our spinners. Additionally, we found that we did not use the name anywhere else in our application. We realized while beginning to implement our interactive prototype that having too many spinners and buttons would make the screen very cluttered and decided to move the gender spinner to the previous screen. Finally, to stick with our overall application usage of the back button to go back between screens, we removed the explicit back button.
Initial/lo-fi version of avatar editing part of character creation
Initial/lo-fi version of avatar editing part of character creation
Final version of avatar editing part of character creation
Final version of avatar editing part of character creation

Home Screen

  • Initial sketch/lo-fi prototype: For both our initial sketch and our lo-fi prototype, the home screen navigation icon was in the form of a diamond, instead of a square.
  • Final prototype: After the lo-fi prototype, we learned that while most of our users figured out the navigation scheme from the home screen, they suggested that we should make the buttons in the shape of a square to more closely mirror the directional pad on the phone. In addition the home screen animates when it transitions to its children, amplifying the directional nature of the controls.
Initial/lo-fi version of home screen
Initial/lo-fi version of home screen
Final version of home screen
Final version of home screen

Quests

Quest tabs

  • Initial sketch/Lo-fi prototype: For both of these interface designs, the quest lists on each tab expanded to show the details of the currently selected quest. Also, the objectives for each quest were accompanied by check boxes, to show their completion status
  • Interactive prototype: Instead of the expanding list of quests with details in the lo-fi prototype (which some users found confusing and repetitive), the quests were presented in a simple list, with a one line description below each name so the user has a basic idea of what the quest entails. The user can get more information about a selected quest (like before) by pressing the center button of the phone. Additionally, we provided some on-screen hints to the user about when they should use the menu because our lo-fi users were often confused about when to use the menu.
  • Final prototype: One of the comments from the interactive prototype was that the tabs were too big and looked too much like buttons. For this version, we reduced the size of our tabs to a size more similar to that of our lo-fi prototype. We also added icons next to each tab. For the final version, we decided remove the menu option for a new search and instead have the user initiate a new search by pressing the back button from the search results screen to go back to the search box screen. This behavior was more intuitive not only for our users, but for us as well, as it follows from our previous usage of the back button. The help text has been modified accordingly
Initial/lo-fi version of quest screen
Initial/lo-fi version of quest screen
Interactive prototype version of quest screen
Interactive prototype version of quest screen
Final version of quest screen
Final version of quest screen

Quest details

  • Initial sketch/Lo-fi prototype: Our initial quest details screen had check boxes next to quest objectives and a box around the quest status.
  • Interactive prototype: On the quest details screen, the instructions on how to accept the quest were added at the bottom. We removed the box around the quest status so that the user did not think it is a button they could select. The quest status was moved to the bottom of the screen so that the user could still view it as they scrolled through the quest's details. Additionally, instead of having check boxes next to each quest objective to note their completion status, objectives were now split into 2 lists: completed and incomplete. Our lo-fi users were not sure what the check boxes meant.
  • Final prototype: The final version of the quest details has some minor changes. The instructions have been amended to include the map of quest objectives, as some of pilot usability users were not otherwise aware of this option. Also, the quest objectives have been modified to be more descriptive (instead of just go to latitude x and longitude y for z seconds)
Initial/lo-fi version of quest details
Initial/lo-fi version of quest details
Interactive prototype version of quest details
Interactive prototype version of quest details
Final version of quest details
Final version of quest details

Map of quest objectives

  • Pilot Usability prototype: This version of our application was the first time we implemented a map of the quest objectives. Originally, each quest objective was referenced by a number on the list on the left side of the screen. There was also a list of controls at the top of the screen.
  • Final prototype: Most of our pilot usability users did not read the controls at the top of the screen and assumed they should move around using the directional pad. We decided the safest thing to do was to follow our users' intuition and mirror the controls used in the Android maps application by using the directional pad to move around. We also moved the zooming control to the menu and now use the Android map zoom slider. This was done because our pilot usability users noticed that there was previously no visible indicator of how much the map was zoomed in. The list of objectives have been moved to a dialog, selectable from the menu, with a spinner.
Pilot usability version of map of quest objectives
Pilot usability version of map of quest objectives
Final version of map of quest objectives
Final version of map of quest objectives

Map overview

  • Pilot usability prototype: This version of our application was the also the first time we implemented the map overview screen. The initial implementation of this screen had controls listed at the top of the screen. The only thing the user could do was move around using the directional pad and complete quest objectives by going to them and staying for a certain amount of time.
  • Final prototype: We removed the control instructions at the top of the screen, as our users did not read the instructions before and the controls now follow those of the Android map application anyway. The zooming functionality has been moved to an Android zoom slider selectable from the menu. We have added a dialog option to menu that allows the user to center on their currently active quest objectives, sorted by their current distance to the user. This dialog provides real-time updates for the time left for each quest objective. Additionally, the dot of in-progress objectives changes from green to yellow to indicate to the user that a quest is currently in the process of being completed and the dot shrinks in size as the objective gets closer to completion. These changes were necessary because our pilot usability users had no way of determining how far along they were in the quest objective and how much longer they should wait.
Pilot usability version of map overview screen
Pilot usability version of map overview screen
Final version of map overview screen
Final version of map overview screen

You

Main "You" screen

  • Initial sketch/Lo-fi prototype: Our initial versions of the first "You" screen made a distinction between trophies and posters (posters being higher and trophies being lower). We also had the avatar on the left and the room on the right
  • Interactive prototype: There was now no distinction in the items available between trophies and posters, which was found to be unclear by our lo-fi users. Additionally, we swapped the positions of the avatar and the room to remain consistent with the position of the avatar during the character creation process.
  • Final prototype: Some of the pilot usability users were not sure about what they were supposed to do on the You screen, as it did not really look like a room. We have added a background to this screen to make it more clear that it is supposed to represent the user's room.
Initial version of main you screen
Initial version of main you screen
Interactive prototype version of main you screen
Interactive prototype version of main you screen
Final version of main you screen
Final version of main you screen

Editing the room

  • Initial sketch: Our initial version of this screen displayed 12 possible options for item replacement.
  • Lo-fi prototype: This was changed so that the user could view 4 items at a time when choosing which new item to replace their old item. It did not seem feasible to fit 12 items on half the screen and have them all still be relatively visible.
  • Final prototype: The user can see about 6 items at a time and can scroll through the possible items. Our lo-fi users wanted to make sure their trophies were easily selectable, especially their recently acquired ones. We have made the "room side" of the screen dimmer to emphasize which items the user can currently select. We have also made the items in the "item selection" side of the screen smaller than the items in the room to emphasize the distinction between the two sides. The smaller size also allows the user to see more than 4 items at a time. In addition, it is clear which position on the wall is being replaced during the trophy selection screen because it is highlighted.
Initial sketch of edit room screen
Initial sketch of edit room screen
Lo-fi prototype version of edit room screen
Lo-fi prototype version of edit room screen
Final prototype version of edit room screen
Final prototype version of edit room screen

Editing the avatar

  • Lo-fi prototype: This version did not have any save button to indicate that the user was done editing.
  • Final prototype: On the edit avatar screen, we added an explicit "save" button so that the user can explicitly save his or her changes (a requested feature from lo-fi users). Pressing back cancels the changes in case the user changes their mind. We have also moved the avatar to the right side of the screen to remain consistent with the initial avatar creation and the main you screen.
Lo-fi version of edit avatar
Lo-fi version of edit avatar
Final Prototype version of edit avatar
Final Prototype version of edit avatar

Other

  • One thing that was missing from all our prototypes prior to the pilot usability prototype was progress dialogs to indicate to the user that the application is contacting the server. These are very useful in letting the user know that the application is doing something and is not just frozen.
Example of progress dialog
Example of progress dialog
  • Additionally, as of the final prototype, when the user does not have internet access and tries an action that requires internet action, a dialog is brought up that alerts the user of the problem. From this dialog, the user can try the action again or cancel it.
Example of no internet connection dialog
Example of no internet connection dialog

Final Interface

Functionality/Design

Character/Account creation

The Character/Account creation is composed of two screens. The first screen allows the user to enter in their e-mail address and phone number. By default, the phone number of the phone the application is running on is automatically filled in. The user is also able to select the gender of their avatar on this screen. We chose to use edit texts for the e-mail and phone number because these were the most sensible choices for collecting information that can be highly variable. Selection of gender is provided by a two option spinner. The "next" button on the bottom allows the user to advance to the edit avatar screen. We chose to use the word "next" rather than something like "save" because we felt that it gives the user a clear idea that the character/account creation process is not yet complete and that more information will be collected. The edit avatar screen has three spinners on the left labeled head, shirt, and pants. On the right side of the screen is a picture of the avatar. As the user selects different items for head, shirt, and pants with the respective spinners, the avatar view on the right updates correspondingly. Because of this instant feedback, the user is easily able to see how his/her selection choices affect the look of his/her avatar.

Setting up the email address and phone number
Setting up the email address and phone number
Editing the avatar
Editing the avatar

Quests

A quest consists of a series of objectives and reward(s) (which can be trophies or clothing items) to be obtained once those objectives are completed. Objectives generally involve going to a particular place for a certain amount of time. The Quests screen is composed of 3 tabs: active, completed, and find new. The user switches between these tabs to determine which kinds of quests they can view. Active refers to to the quests the user has accepted, but not fully completed yet. Completed refers to the quests for which the user has completed all the objectives. The user can search for new quests by keyword using the find new tab.

Active tab of quest screen
Active tab of quest screen
Completed tab of quest screen
Completed tab of quest screen
Find new tab of quest screen
Find new tab of quest screen

Viewing a quest's details brings up the quest details screen. The quest details screen provides the user with a list of details about the quest (title, description, objectives, and rewards). From this screen, if the quest has not already been accepted, the user can accept it. The user can also view the location of each quest objective on a map by selecting a menu option.

Quest details screen
Quest details screen

On the map of the quest objectives, the user can use the phone's directional pad to move the map and view the surrounding area. From the menu, the user can zoom the map and also use a dialog to center on specific map objectives. This dialog displays a spinner loaded with the quest's objective names. Below the spinner, the objective's description and status are displayed. When the user changes the item on the spinner, the map re-centers to the currently selected objective. The distance to the currently selected objective is always displayed at the bottom of the screen. The currently selected objective is denoted on the map by a circle around it and a line connecting the objective and the user's current location.

The Zoom slider to zoom the map
The Zoom slider to zoom the map
The dialog used to select an objective to focus on
The dialog used to select an objective to focus on

Map overview

The user uses this screen to actually complete quest objectives from quests he or she has accepted. To move around, the user uses the phone's directional pad and zooms the map using a zoom slider accessible from the menu. When the user gets close enough to a given quest objective, the objective's color changes from green to yellow. The size of the dot decreases as the quest objective gets closer to completion. The user can also bring up a dialog from the menu to provide real-time updates as to how much time is left to complete each objective. This list is sorted by distance to give the user easy access to nearby objectives. Once the user starts completion of a quest objective, they are free to use other applications on their phone until the objective is complete, as quest completion is done using a service and can be done outside of our application.

Main map overview screen
Main map overview screen
Objective status dialog in map overview
Objective status dialog in map overview

Friends

The friends list allows the user to view their friends' rooms. Here, friend is defined as a contact that has an account with our application. Pressing the center button on a selected friend brings up that user's room, in the same format as the user's own room. The only difference is that you cannot edit your friends' rooms.

Friends list
Friends list
Sample friend's room
Sample friend's room

You

The one action that you can do in this room is press the center button (or menu button) in order to access the menu, allowing you to edit your avatar or edit your room. Editing the avatar involves changing the head/shirt/pants items displayed on your avatar. Editing the room involves selecting which trophies you've earned from quests to be displayed in your room and be viewed by your friends. The edit avatar screen allows for the same functionality as in character/account creation. As can be seen in the trophy selection screen, you can navigate between one of the two grid views (while the other is grayed out). This makes it clear which trophies you can choose from, and separates the wall from the group of acquired and selectable trophies.

The You screen
The You screen
The edit avatar screen
The edit avatar screen
The edit room screen
The edit room screen
The trophy selection screen
The trophy selection screen

Implementation details

  • Overview/Difficulties: Initially, the process of implementing our application was very difficult as we all had to learn the ins and outs of the Android SDK. The lack of documentation for some parts and the fact that there are still bugs in the SDK (specifically regarding the tabs) made the process a little more difficult than it could have been. In particular, it was hard to learn how the view system worked to switch between views and to make sure that everything displayed correctly. Integrating the server accesses/storage was also difficult in the beginning given the relative slowness of the emulator and the frequency of the "Android application is not responding" error message. We eventually figured out that in order to make things run more smoothly, we should locally cache or save as many things as possible (Quest/Item objects, item pictures) to minimize the amount of data we need to pull from the server.
  • Server: The server is responsible for holding most of the data items (items, quests, user data) and quest search. The data is stored in XML format and this data is parsed on the phone. Item pictures are also stored on the server and saved on the phone's file system the first time they are accessed.
  • Character/Account creation: The character/account creation process consists of two screens. The first screen is a simple layout where the user is able to enter in his/her e-mail, phone number, and choose his/her desired avatar gender. The second screen allows the user to customize his/her avatar. The avatar is displayed with a custom layout called AvatarLayout. Three spinners on the left allow the user to customize the appearance of his/her avatar. All avatar customization data is saved to the server when the user hits the save button.
  • Quests: In order to override the default large tab view, each tab is implemented using a custom view that is smaller. When the user accepts a quest, it is stored both in a database on the phone and on the server. Quest objective status is designed to be stored only in a database on the phone, so as to not overuse the server. Quest search is done by querying the server with the search terms the user has entered. It searches both the quest descriptions and the quest keywords (which include location information)
  • Map overview: The map overview screen is implemented using multiple threads and a service (basically a background process that runs independently from our application). One thread is used to constantly update the quest objective status dialog so that the user has real-time updates on how much more time a quest objective needs until completion. The service used for monitoring quest objective status is started when the application is started. It has one "checker" thread that checks every 500 ms if the user is near any incomplete quest objectives. If so, this thread starts a new "objective" thread that decrements the time left for the given quest objective every second. If the user moves too far away from the objective, the "checker" thread tells the "objective" thread to stop running and it resets the time required for the objective. If the user completes the objective, the "objective" thread pops up a toast to indicate this completion, also notifying the user if the entire quest that this objective corresponded to is completed. It also updates the quest objective's status in the database and, if the quest was completed, the quest's status on the server.
  • Friends: The friends screen is implemented by pulling a list of all the contacts the user has on his or her phone. For each phone number, the server is queried to as to whether there is an account with the same phone number. If so, the user's room is loaded into a list. For the list of friends, the name given is the name the user has given the contact on his or her phone.
  • You: The room was made using a relative layout and grid view. This was one of the more difficult things to implement here because it was hard to make the screen half a grid view and half the Avatar View. In this Activity, we take advantage of the AvatarLayout that we made by simply calling functions that display the avatar. Additionally, we have added a background to this room to give it a more "roomy" feel. Items objects are locally cached after they're first read to minimize the number of times we have to query the server.
    • Editing the room involves a separate Activity to choose what to replace and to choose which trophy to place in the room. We disable one half of the screen (when selecting the room position and new trophy) in each Activity and mark which position is being replaced when selecting a trophy.
    • Editing the avatar involves an activity that is similar to the "edit avatar" part of character/account creation. Because the two functions are similar and essentially identical, we ended up using the old Activity to edit the avatar, returning back to the main "You" screen after saving the changes.

What was left unimplemented

What was left out and why

  • A few issues that people raised during the pilot usability studies and from the presentation were not addressed. This is because these were mainly cosmetic issues that were specific to one user/person and were not found to be a problem for other users. For example, one user from the pilot usability studies mentioned changing the ordering of the quest tabs. This was a minor feature and was not changed because only one user found this to be a slight problem. So, instead of changing problems that are specific to one user, we changed issues that were brought up multiple times (such as the confusing controls on the map of objectives screen and the lack of room background).
  • Additionally, given how much data is being stored on the server, we have decided to require an internet connection for our application to function. However, as mentioned previously, the application will display a dialog to alert the user of this requirement.
  • User authentication is not implemented yet to prevent users from creating duplicate accounts. While security would be a nice thing to have, we don't really have enough users to have strict anti-cheat measures in place.
    • Also, the server data is not secure right now; anybody can edit the data that is on there, provided they know the URL of the server.

Wizard of Oz techniques

  • Since we do not have actual hardware to run our application on, we do not have access to actual GPS data. Instead of restricting the user to using canned location data, we allow the user to simulate movement using the phone's directional pad on the map overview screen.

Appendix



[add comment]
Personal tools