Experience Prototype and Demo Plans
By the end of the second milestone we had completed our formative study and used the results from that study to generate three design concepts for augmenting the bar experience. For this milestone, we significantly refined the concept for one of the three designs—using interactive tabletops for playing games at the bar. We then developed and ran a series of experience prototyping tests, in which a total of six participants used our prototype under different scenarios. Following those tests, we generated several conceptual variations based on the original design. We then selected the most effective variation and created polished storyboards and mockups depicting how the design works. Finally, we generated a plan for the upcoming project demo, in which we will show a higher-fidelity prototype.
Overview of Refined Concept
The Overarching System
Following milestone two, we took our concept of interactive tabletop games and fleshed it out, remaking it as the focal point of our design. The storyboard sketches below show how the primary interaction we tested works. Patrons arrive at the bar and are taken to their table as is typical of many bars. One person in the party is given a moderator token, which allows him to control game selection. As people approach their table, the table automatically recognizes the users and presents them with their point totals from the previous visit. By playing games and ordering drinks, users earn more points. Those points push them closer to earning a free drink.
Accompanying this design, we also conceptualized a series of games this system could include. From three initial concepts, we selected one to include in our user enactments. The three original concepts were:
- A tower defense game in which users phones acted as their bases. Opponents would send enemies toward a phone that was placed on the table. Objects like drink glasses could be treated as movable barriers that players could place in front of a line of oncoming enemies, forcing those enemies to change their route.
- A jigsaw puzzle game that would pull a picture from the phone of someone at the table and turn it into a puzzle.
- A top-down platformer in which players explore a map and collect a certain number of resources to take to a predetermined end point. The terrain of the map is automatically generated based on the photos on players’ phones. If a user has photos of a trip to the beach, say, then his terrain will be sandy beaches with nearby water. Various types of terrain come with various obstacles like impassable rivers, chasms, sheer cliffs, and more. Power ups are available to pick up when exploring the map. Some grant a player a one-time special ability like a double-jump; others may stun an opponent temporarily. Again, drink glasses can be used to interact with characters in the game. By placing a glass on top of an opponent’s character, that character becomes trapped.
The goal in designing these three games was to include a breadth of interaction—one competitive, one cooperative and casual, and one loosely competitive but with opportunities for adding cooperative elements. For simplicity’s sake, we chose only the final game, dubbed “Bar Hopper”, to explore further. We felt this game represented our best shot at showcasing an interactive experience.
A Noteworthy Challenge
A key challenge in designing this concept was ensuring that the gaming experience was engaging enough to give a sense of what this overall system could be without becoming such a focus of the system that the overarching concept was lost on users (particularly for testing purposes). If brought to market, the particular games included with this system would be many and varied. We chose Bar Hopper because we believed it to be an engaging game. We also wanted to highlight the ability to interact with in-bar objects like drink glasses, as this enhances the overall ubicomp experience and helps, we hope, to blur the line between social engagement in the bar and social engagement in the game.
For our experience prototype we decided to test a low fidelity version of our interactive tabletop game Bar Hopper in a simulated bar environment. The game was map was created from paper and included rivers, mountains, forests, and flatlands. Game characters were made out of Legos. Dimmed lights and background music were used to simulate a bar environment. We were interested in testing the effects of various aspects of system proactivity (intrusiveness of the table, social engagement outside of the game, game control of breaks) and game type on the bar experience for the user. The scenarios that resulted from these criteria can be found in Table 1.
A list of the nine scenarios that we tested during the enactments can be seen here (PDF).
We conducted our user enactments in two locations; the User Experience Lab and the SI Masters’ Student Lounge, both in North Quad. These locations were chosen for their ability to simulate the lighting and sounds levels of a bar. We conducted two user enactments in the User Experience Lab and one in the SI Masters’ Student Lounge based on the availability of the rooms during our scheduled enactment times.
When participants entered the room they were asked to read and sign a consent form (PDF) indicating they were willing participants and consenting to have photographs and/or video records of their sessions. They were then given a brief overview of what would be asked of them during the enactment. After answering any questions they had, our group member playing the waiter led the study participants to their table. Depending on the test scenario participants were greeted by one of two table tops:
- Simulating near field communication between the table and the participant’s cell phone, the table recognized the approaching user and greeted them with display of their profile including name, photo, and previously accumulated points.
- A blank table with a start button located in the center.
The waiter then took the participants’ drink orders and gave them appropriate direction based on their table—either giving them instructions on how to start the table and select a game or how to select a game from their displayed profiles. The waiter also explained how to use the moderator token.
At this point the waiter left to get the participants’ drinks and the moderator stepped in to explain the game mechanics. Because of the limitations of our paper prototypes we asked the participants move to an adjacent table on which the game was setup, instructing them to pretend they were at the same table and that the initial table display had merely faded to the game display. Once seated at this new table the moderator explained the rules of the game.
- Map terrain was created from photos stored on the participants’ phones. In order to simulate this we provided each participant with a stack of photos that corresponded to map terrain and asked them to pretend the photos were stored on their phones
- Characters each had a special power based on his or her home terrain
- Beach Terrain – character could swim
- Flatland Terrain – character could sprint for short distances
- Forest Terrain – character could walk through forest fires
- Mountain Terrain – character could climb up/rappel down steep surfaces
- Characters could move continuously but only in horizontal or vertical paths
- Participants were asked to move their character at a slow, steady pace
- The participants’ goal was to collect resources (white legos) and take them to a designated temple
- In competitive game play each participant needed to collect 3 resources and take them to a temple directly across the map; each character had a unique temple to reach; in this scenario there was a scarcity of resources—7 total resources were available for all three players to collect
- In cooperative game play, the participants needed to work together to collect all the resources and deliver them to a master temple at the center of the map
- Monsters (two wind-up toys) roamed around the board and participants lost a resource if they were run into by a monster
- Natural disasters based on the terrain could happen randomly (simulated by the moderator) and if a character was in the area he or she lost one resource
- Participants could use their drink glasses to trap other characters or monsters; there was no limit to the number of times a participant could trap characters or the length of time each trap lasted
- Power-ups were scattered around the board and could be collected and used when needed; power ups were returned to the map after being used
- Burrowing (green m&m) – allowed the holder to dig out from under a glass
- Double Jump (red m&m) – allowed the user to jump over wide rivers and chasms
After the instructions were explained and questions were answered, the moderator explained the rules for the round of game play. Each group of participants played three rounds of the game. Each game was either:
And the round ended when:
- One player reached his or her temple with the correct number of resources
- Resources on the board were depleted
- Rounds are continuous; when a player reaches their temple their resources are redistributed on the board and they begin again.
At the end of each round either:
- The game enforced a five minute break
- The game allowed the players to decide whether to continue immediately or take a break
- Game play was continuous and there was no break
In rounds that ended with a break, players were each shown personalized game results, including how many points they had earned and how close they were to a free drink.
Following the user enactment, we conducted post-test interviews (PDF) with both participants at the same time. We felt group interviews would allow them to build off of each other’s responses and better reflect on their experiences. The post-test interview questions can be found here. Following each post-test interview the group met and discussed important takeaways from the session.
Details about the team member roles and scripts can be accessed here (PDF).
We took feedback from our user enactments and organized into the following categories:
- interactions with the table,
- interactions with other players,
- interactions with the wait-staff,
- interactions with objects,
- privacy concerns, and
- the Game itself.
Interactions with the Table
Participants were excited about the idea of an interactive table and offered several suggestions for its improvement. We received positive feedback for the visualization of points needed to reach their next free drink. Participants also liked that the table recognized when they moved to a new seat, adjusting their personal display appropriately.
Beginning with the first interaction with the table, several users asked if the table would provide instructions for how to use it. Given this feedback, future iterations of our table will include instructions for getting started. Participants also asked if they would be able to order drinks from the table, with one participant appropriately pointing out: “With such a high-tech table why do I need a waitress to order my drinks?” If brought to market, it would be essential for this system to include an in-table menu much the like the one we proposed in the earlier design phases of this project. Given that such a feature is now outside of the scope of our project, we will only give a brief overview of the menu system, largely “black boxing” that feature in future versions.
Interactions with Other Players
We received mixed feedback on players’ ability to converse outside of the game while playing the game. On the positive side, participants felt the game provided a good conversation starter, especially when first arriving at the bar, a period of adjustment one participant described as a little “awkward.” Features such as the game terrain being derived from players’ personal photos were well received. On the negative side, participants found that if they were involved in the game they had difficulty following conversation. Conversely, if they were trying to converse they had trouble paying attention to the game. One participant lamented, “If I have to run away from a monster I have to focus.” Participants suggested allowing individuals to pause individual characters in the game to ease the ability to carry on conversations without forcing the entire group to quit playing.
Interactions with the Wait-staff
Participants found that gameplay also made interactions with the server difficult. They said they found it challenging to look at the menu and converse with the waiter while playing. One participant explained it in terms of social norms saying she was engaged in the game but “felt like I was being rude if I turned the waiter away because I often didn’t touch my drink for a long time while playing.” Adding an individual pause mechanism for each player and allowing them to order their drinks through the table menu will help to alleviate this tension.
Interactions with Objects
We were very excited about our idea of using in-bar objects, specifically drink glasses, to interact with gameplay. Unfortunately, our participants, while liking the idea in theory, did not share our enthusiasm in practice. Some participants were worried that they might get their glass confused with other people’s if they moved them across the table. To address this concern we are adding a feature that allows the table to track and identify a glass, giving it a colored ring on the table that would move along with the glass.
Almost all participants were expressed that allowing people to use their glasses to trap other players an unlimited number of times for an unlimited amount of time adversely affected gameplay. Given the universality of this concern we decided to limit glass trapping to the user’s home territory. Additionally the amount of time a glass can trap an opponent will be limited to correspond with the amount of the drink that had been consumed. This also helps encourage more drink consumption and eliminates some of the concern over forgetting to drink.
Study participants had two main concerns regarding privacy. First, with regard to their profiles, many participants disliked the idea of integration with Facebook or another social media account. As one participant put it, referring to a general concern with sharing information with Facebook, “I like to know where my information is.” Participants continued to express distrust with the way social media sites might pass their information on to third parties. Another important point centered on the compartmentalization of information that users automatically engage in. One participant noted that her Facebook profile is set up for a specific purpose—one that is likely to differ significantly from the purpose of an in-bar profile. While some users did not have an objection to social media integration, we received enough negative feedback to add an option allowing users to create a profile specifically for use in the bar in addition to allowing sign in via Facebook, as is common on many websites. It is worth noting that our use of Facebook photos for this test was somewhat arbitrary. Our goal was to personalize the experience. The use of Facebook, in particular, was not a driving factor behind this design; we merely had access to those participants’ photos and chose them for ease of implementation.
The second privacy concern centered on the type of information that could be displayed on the table. Participants said there were situations in which they might not want gameplay statistics displayed that would allow one group of friends to know that they had been out with another group of friends. While a limitation of our paper prototype was that all users could see one another’s profiles, in an autostereoscopic display, which our design below describes, profile data could be displayed at an angle such that only the owner could view it.
The Game Itself
We were given relatively positive feedback on the actual game. Participants felt the length of the game was appropriate. From their feedback, we were able to eliminate a couple of the variations we tested. One variation for the end of the game allowed game play to continue indefinitely by replacing the winning player’s resources in the game map. Participants did not like this. One indicated, “I felt like I had to quit and that makes me feel bad.” Thus, we decided to eliminate this ending in the design proposal. Participants also indicated that they would like a variety of games to play depending on who they were at the bar with. While we will continue to test only one game because of time constraints, an ideal version of this table would have multiple versions.
Based on the insights and findings from our enactments we generated some new ideas and features that both refine and enhance the core concept. Several findings are very important and yielded more discussion and brainstorming. The finding on the interaction with the bar staff led to the variation of how the system is activated and introduced. The findings on privacy concerns created the variation of authorization. The finding on post-game breaks led to variations of how the game ends.
To assess these variations, we drew on the criteria outlined in the project brief and also defined our own dimensions based on the research up to this point. The four dimensions are:
- privacy, and
We used these criteria to analyze and evaluate the variations we developed as a group and agreed upon the version we would like to develop further. Table 2, below, shows the steps of interacting with the table system. The primary version of the system was our starting point; from, that, we generated the variations touch on above. The comments explain why we chose one version over the others based on the criteria. Versions highlighted in red were selected for the final concept proposal.
What follows is a description of how this system will work, accompanied by storyboards depicting the various interactions and mockups showing specific screens on the table.
The table display contains two broad areas: the center of the table, which contains a list of games to choose from, and a portion of the table located directly in front of each user that displays information relevant to only that person—name, profile photo, points earned, and progress toward a free or discounted drink.
Users can tap their point total to see a detailed breakdown of which points were earned for purchasing drinks and which points were earned for playing games—including which actions in which games led to earning points.
The personalized display also contains a control panel with the following buttons:
- Exit the Game/Logout
- In game, the button returns to the homescreen
- From the homescreen, the button logs a user out
The Moderator Token and Gameplay
Upon being seated, each table is provided with a moderator token. The system recognizes which person has the token and can automatically detect if it is passed to someone else. The table indicates who the moderator is with a symbol that all players can easily see. The moderator can:
- Select a game from a list at the center of the table by dragging a game to his or her portion of the display panel
- Choose to replay a completed game or return to the homescreen to select a new game
Once the token is passed to another person, each person’s portion of the display changes to reflect the switch.
Earning Free/Discounted Drinks
By purchasing drinks and playing games, users accumulate points. Each point brings a user one step closer to earning a free or discounted drink.
At any time, an individual can pause the game by tapping the pause button on his or her personal display.
There is no group pause. If all members want to pause the game, each person must do so individually. This ensures that if even one person wants to continue playing, he or she may do so.
Viewing the Menu/Ordering Drinks
At any time, a user can tap his or her personal menu button to pull up a digital menu. If a game is being played, that player’s game is automatically paused.
From the menu, a user can tap a drink to view additional information, and tap an order button to place an order. The menu also displays points earned from purchasing a drink.
Because the ordering process is largely outside the scope of this project, we have not elaborated on this portion of the system. Impressive examples, such as Microsoft’s Surface, already handle the interaction of ordering and paying for drinks quite smoothly. That system would make a good model for this portion of the interaction.
Logging out can occur in one of two ways:
- Tapping the logout button from the homescreen display
- Leaving the bar
Because the bar can communicate with customers’ phones through NFC technology, the table will recognize when a person leaves with his or her phone. Since many patrons smoke or occasionally step outside for fresh air, the perimeter at which the bar recognizes a user’s phone will be extended several feet outdoors. This should minimize accidental log-outs. When such log-outs do mistakenly occur, the problem is negligible because the login process is as simple as waving a phone.
New Users—The Signup Process
New users naturally have a different experience when using our system. When being seated for the first time, the table presents the patron with a dialog asking if he or she would like to signup. The person can choose to connect via Facebook or setup a dedicated profile for the bar. Connecting to Facebook will pull the user’s name and profile photo from the system. The system will then ask the user if he or she wants to enable auto-login and if he or she would like to include an email address for receiving information about specials. No information is sent back to Facebook.
By selecting the dedicated profile setup, the new user quickly enters his or her name and selects a profile photo (from his or her phone) or avatar (from a pre-defined set of icons). The user is then presented with the same auto-login and email options described above.
How Information Flows through the System
There are several components to this system that relate to information storage, access, and exchange. All profile information, including points earned, progress toward a free drink, games played, and game history are stored in a cloud-based service. A user’s phone pulls that information from the cloud to his or her personal device. The phone then acts as the gatekeeper for the system. A user must authorize the table for access to the information that is stored on his or her phone. As games played, point totals, and other measures are updated while a user is at the bar, that information is sent back to the user’s phone and subsequently to the cloud. The bar server only stores aggregated, anonymized data to ensure privacy.
The mockup below shows the table concepts in a bar setting.
The storyboards below show the primary interactions users can have with the system.
This mockup shows what the Bar Hopper game might look like. Each player has several buttons in front of themselves. Descriptions of the on-screen items can be viewed below.
- Control Panel is a part of the graphical user interface of the smart table which allows users to view and manipulate basic system settings and controls. Each player has a control panel with the following elements:
- Temple is positioned directly across from each player and is used to guide the direction in which game characters move across the table . The first player who reaches his/her designated temple wins the game.
- Power-Ups are objects that instantly benefit or add extra abilities to the game characters. (swim, fly, double jump ect)
- Natural Resources are the objects to be collected by the game characters before reaching the temple. A minimum of three natural resources must be collected before a game character wins or reaches its temple.
- Natural Disasters are random events or disasters that instantly subtract points from game characters who are unable to escape the natural disaster.
- Enemies/ Monsters are characters who steal points from other characters upon encounter.
- Terrain is the environment of the game. In this case, we have mountains. The terrain is based of players phone pictures.
- Game Character is an avatar representing players.
- Interactive Object is an item placed on the table such as a glass or plate. Objects become part of the game and are used to create obstacles for other game characters.
- Pressing the Menu button displays a menu on the screen
- The user can then browse drinks and place an order from the table
The technologies we are suggesting to implement this system have already been in existence for some time. However, some of the technologies are still in its infancy and are barely being used by consumers, mainly due to the expenses. The most advanced technology we are considering here is the touch display, which has to seamlessly integrate with the bar environment. The components of the system are described in the following sections:
Autostereoscopic Display Surface with Capacitive Touch
Our design includes The autostereoscopic screens uses parallax barriers to display 3D images with partial or complete depth perception. Such technologies already exist in some of the glasses-free 3D televisions. Recently, LG has released two versions of full 3D phone, one of which is the Optimus 3D. The use of such technology in a mobile phone gives us hint that more people will have access to autostereoscopic displays in the near future.
Capacitive touch screens are widely being used on phones now a days. They are still expensive for using in large screen. People have already implemented touch technology in large screens. For example, the photo below shows a large Android phone in the Googleplex.
Web servers or “Cloud” servers are being used widely for more than a decade for storing game data and profile information. We will be syncing the game progress, points and purchases in the cloud servers. This will ensure that the phone, table and bar management server have the updated information.
Near Field Communication (NFC)
The near field communication is a technology for mobile devices to communicate with each other in close proximity. The technology uses radio frequency to transfer data between the devices. In our system, we are planning to use NFC tags (with no power of its own) in the glasses to find their position. That data is then used to create obstacles for avatars. We are assuming that the phones in the near future. In that case the table would be able to automatically communicate with the phone and recognize gestures. There would be an array of NFC readers in the table’s surface. Location of the phone and glasses will be determined by triangulating the signals from respective devices. The technology is already in use and its sister technology Radio-frequency identification (RFID) is already being used widely and can be implemented at a very low cost.
Our demo seeks to showcase a higher fidelity prototype that we will allow users to interact with in a scripted setting. Our plan for that demo follows.
Our primary goal is to simulate the core experience of interacting with the table—signing in, viewing point totals, and having a moderator select a game. Because playing games is such a core component of this overarching experience, the demo will include a higher-fidelity version of the game tested in this milestone. The script will also account for ending the game and having users log out of the system.
This simulation will make use of a projector to display the system and game on a normal table. We will develop an animation that includes primarily pre-rendered scenes that team members will feign interacting with, timing our taps on the table with the animation. However, the demo will also include a dynamic bit of animation. An audience participant will be selected to interact with the table. A nearby team member will watch the participant and mirror his or her actions on a laptop keyboard connected to the projector. That laptop will control how the actions on the screen unfold. Other teammates will log points as the players collect them. This will allow for the points displayed at the end of the game to accurately reflect what the players earned during the demo.
This should prove to be a pretty high-fidelity demo. Realistically, the only major improvement that could be made is making the entire system interactive. That would essentially involve developing the entire software setup described in the system proposal above. Even a pared down version would prove pretty daunting given the time frame. Most of the technology described in this proposal is available today, but it is quite costly. Implementing NFC technology, large-scale touch surfaces, and autostereoscopic imaging is far too expensive for prototyping purposes. Indeed, even several years from now, such expenses will likely be prohibitively high for most prototyping scenarios—certainly in a classroom setting.
There are also some notable impacts the demo will have on the overall experience. For one, having only one audience participant lessens the social aspect of the experience; this is important given that this socialization is at the heart of the entire concept. Additionally, having team members observe the participant in order to mirror his or her actions could create a sense of being watched, again making the experience feel somewhat less realistic. Finally, the setting itself will have an impact on the experience. A classroom environment is almost certainly quite different from a bar environment. Some measures can be taken to remedy this, such as dimming the lights or playing music. Even given these drawbacks, we are confident this demo will accurately convey much of the experience we are conceptualizing.
At this point in the project, we have finalized our design concept, a gaming platform that encourages socialization in a bar setting. Our emphasis is on the features and components of the overarching system and the way users interact with it. Although specific games are not our primary focus, the system necessarily depends on games for crafting a truly great experience. Even a flawless platform will fail if the games on that platform are not well designed—thus the attention we placed on making Bar Hopper a unique, engaging experience.
While this milestone answered many questions we had, there are a few matters about which we are not certain. First, we are unsure if the privacy concerns voiced by experience prototype participants will be common among users of this system. However, we adjusted the system to be much more privacy-conscious; the final proposal should adequately satisfy even the most privacy-sensitive users. A larger uncertainty centers on not having games for the system. As was mentioned above, games are key to the success of this experience. It is well outside the scope of this project to design a complete series of games, though doing so would round out the experience substantially. This uncertainty is inevitable, but we feel we have reasonably accounted for much of it by designing one game with a basic set of mechanics that showcase the type of interactions games on this platform might use.
This milestone was really helpful in collecting findings from users, generating new ideas, and refining the concept we already had.