From Pulse

Pulse Paper Prototype

During our prototyping we hoped to solidify our designs while at the same time identifying and correcting any flaws that we encountered. We chose to create an oversized representation of our interface to achieve a better simulation and to allow for better observation. Had we kept the prototype the same size as an actual ipod touch/phone we would not have been able to effectively manipulate the quickly changing user interface. For the construction of the interface we used a frame made of foam core and several inserts made of paper and transparent film. We chose to use a frame because we reasoned that our application would have many different screens, and that having a permanent frame would help to simulate the process as a whole. We chose to user paper and film because we found that the different screens and overlays could be created and modified easily.

The major tasks we focused on in our simulation were accepting an invitation, creating a game, and playing the game offensively. Creating a game includes setting the game map, setting the game’s start/run time, inviting players, and selecting teams. Accepting an invitation involves getting a notification, launching the application, reviewing the games you have been invited to, and selecting a game you wish to play. Playing consists of using weapons and scoring by moving onto the hill area.

Pulse Video Prototype

The video prototype was very useful in placing our idea in a time perspective. Since we are creating a game, the physical time you’ll spend using our application is by far longer than a simple mobile app. Because, Pulse requires the player to physically go somewhere, the time issue is multiplied. From this video prototype We found out that our interface is pretty simple and solid in terms of creating a game and playing it. However, we were lacking information for the in-between space of creating or accepting and meeting for the actual game. We learned that our application must include a way to guide you to the required meeting point.

User Test

  1. Testing the current game – Our plan is to test the game interface indoors without the physical element. Users will be asked to create a Pulse game, define the settings of the game, and play. They will not be told by the testers what the objective of the game is, or how to play it. We believe that a good game interface would help the player learn the rules and objectives, even if they are not experienced. There is a help screen in the application that the users can pop up, which explains the objective of the game and icons. Ultimately, the user test would include testing the interaction between the physical and digital aspects of the game. However, the current stage of the game requires us to test the layout of the game setup and the ability of icons and symbols to communicate. So, we informed users that the icons would eventually be controlled by GPS signal, however that in the test they should point the icons toward their destinations.
    Questions we want to answer:
    How does a first-time user understand the game rules and mechanics?
    How intuitive is it to create the game with Pulse?
    Is the game fun to play on screen?
    Our setup was to provide a single player with an iPod Touch what was installed with Pulse.
    Then, we read them our written instructions (printed on questionnaire).
  2. revisions and changes:
    Changes implemented:
    -re-ordering the setup menu so to pipeline-it and add default values. This change dramatically reduces the time it takes to create a game. -moving the help screen to appear earlier in the game setup stages
    This revision helped the novice player understand the game before entering play.
    The game satisfied Nielson’s third heuristic(User Control and Freedome) with the help screen.
    -Eliminate waiting screen’s spinning clock when done waiting
    -make “my gps icon” prominent
    -label health elements
    -show feedback when my player has attacked opposing team member.
    Test users mentioned that they needed to know if their attacks were received.
    Initially this feedback was missing from our interface. Post testing, we are in the process of implementing the feedback feature where a player can see the damage on the opponent. This change would satisfy Nielson’s first heuristic(visibility of feedback), as well as narrow the Gulf of Evaluation.
  3. design reflections: The users are more eager to engage with the functional prototype than they were for the paper prototype. Our guess it that the application seems “real”, and they experience fewer obstacles in navigating the menu items. The paper protoype was not part a a bigger system (mobile OS). Therefore, some dead-end or similar problems were “solved” by re-starting the test. Having a functional prototype empowers the user to find a way out of our design flaws, giving us a better sense of their impact. Time was unmeasurable with the paper prototype, since what it took us to manipulate the prototype was significant and not regular. The functional prototype allows us to measure time in a more precise way, and time proved to be a very rich source of information. In our experiences as test users of other team’s interfaces, there was a sense of awe that came in reaction to knowing that the students made things work. And feeling this motivated us to try out the apps.

Pulse development

Up till now, we are fulfilling our proposed schedule and the interface is working as described below. Although we are working separately in each part of the project, we have managed to integrate it all into a satisfactory product so far.

In terms of interface, we’ve worked using the iphone existing interface as a base for our own interface. This way we: -Make the most out of the mental models existing in iphone users. -Don’t need to re-do any distance or size analysis, assuming that apple already did so. Therefore, it’ not up to us to concern about the size of a button to be accesible and easily clickable with the finger.

So, considering the iphone interface as a basic grid and even a palette suggestion (we used some of the iphone standard objects), we built our graphic design to both suggest the objective of our app (a sort of futuristic-bloody video game) and to harmonize with the iphone graphics that are to be present anyway in the screen (the clock, battery charge, next and done).

The only deflection of this norm(apart from the game screen, obviously) is the entry screen, with the “create” and “view invites” buttons. We intended to give a clear signal of being starting our application.

In what changes are concerned, we incorporated all the setup variables of the game into a single screen (this is a change from the paper prototype),since before we didn’t gave any feedback about the settings already set in the game creation, which may have caused confusions or distortions of the intentions of the user. Out of the same problem, we now know too that it would be useful to incorporate an “edit game settings” control that does not deletes the game, but we will not try to incorporate this into this version of the app.

For next week, we will finalize the integration of both coding and graphic work, as reported in the schedule.

Pulse Paper Prototype

During our prototyping we hoped to solidify our designs while at the same time identifying and correcting any flaws that we encountered. We chose to create an oversized representation of our interface to achieve a better simulation and to allow for better observation. Had we kept the prototype the same size as an actual ipod touch/phone we would not have been able to effectively manipulate the quickly changing user interface. For the construction of the interface we used a frame made of foam core and several inserts made of paper and transparent film. We chose to use a frame because we reasoned that our application would have many different screens, and that having a permanent frame would help to simulate the process as a whole. We chose to user paper and film because we found that the different screens and overlays could be created and modified easily.

The major tasks we focused on in our simulation were accepting an invitation, creating a game, and playing the game offensively. Creating a game includes setting the game map, setting the game’s start/run time, inviting players, and selecting teams. Accepting an invitation involves getting a notification, launching the application, reviewing the games you have been invited to, and selecting a game you wish to play. Playing consists of using weapons and scoring by moving onto the hill area.

We tried to make our interface as intuitive as possible. We took great care into our design so that new users could quickly start and accept invitations easily. Thus when we tested our interface we did so in two ways. First we tested the design on one of our own so that we might identify any glaring mistakes. After the initial run we then employed an outside user to use the interface. The process used for both users remained unchanged. During both processes the observers made notes about the challenges the users ran into as well as what questions were asked when they ran into any problems.

In both cases there was minimal instruction allowing the user to scroll through options as they saw fit. First they were presented with a typical ipod touch/phone menu screen. Among the various logos was our own application. Once the user touched the icon for our game they were taken to a screen where they could choose one of two options, Create and Invites. If the user selected Invites they were taken to a second screen that showed the user a game map and gave them information about the game itself such as who made it, and how long the game would last. The user was also presented with the option to accept. At the bottom of the screen appeared tabs that the user could press to see any of the other invites. If the user selected any of the games to play they were then taken to the battle screen.

Creating a game
If the user selected the create option they were then taken to a map screen. Here the user could edit the map’s location by moving their finger in any direction. When the user selected an area they could then set up team bases. At this point the user was presented with red and blue dots. When the user touched a dot and dragged their finger on one side of the field an outline appeared (drawn in wet erase marker) signifying that team’s base. This was done with both colors at which point the user could select the map create button solidifying their selections. Next the user was presented with several options including setting the game’s start time, selecting the game’s run time, and choosing players to invite. Once the options were selected the user was taken to a screen where they could monitor who has accepted and who has declined. At any point the user could select start game. Next the user could choose which players would belong to each team by moving a player icon on their respected camps. Once this task was completed the game would wait until all players reached their base at which point the game would start.

Playing the game
The battle screen contained an overhead view of the game area and showed the location of all players who were playing. The player also had information about their current health and inventory on the screen. Health was represented by a green bar that was depleted or filled depending on if the user was damaged or healed respectively. If the player acquired any weapons the corresponding icon would also appear on their screen. These icon could then be touched to deploy the item instantly. Finally, at the top of the screen was a bar that contained both blue and red. This bar was used to visually illustrate the current score. If for example the red team accumulated time their color would start to dominate the bar pushing the opposing blue team away. For illustration purposes the user just had to indicate where they wanted to move to and the wizard would move their piece to the required location. Had this been a real game the user would have had to physically move to the location they wished. The movement of the other players were illustrated by dragging pieces of metal across the game screen using magnets. The game ended once the specified time expired at which point the user was presented with the outcome of the game. The game also ended when the user wished to stop.

Findings

The animated portions of the prototype are difficult to demonstrate. Our current methods of showing animations are: using icons connected to strips of paper that the wizard could pull and push, drawing with a marker on transparency, using a magnet to move a metal icon around. While these were fun to work with, considering other methods of simulating animation would make the user trials go smoother.

Pulse

Game Description:
Pulse is an augmented reality video game for the ipod/ipod touch created in the winter quarter of 2008. In pulse a player’s movements in the real world are transferred to pulse’s virtual battlefield. In this way, a simple game of capture the flag is enhanced to include components of videogames such as weapons and health.

Video of the Paper Prototype

Team members: Kate Swanson, Minjeong Kim