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.