LoFi-Group:Group H

From CS 160 User Interfaces Sp10

Jump to: navigation, search

Contents

Introduction and Mission Statement

Traditional playing cards have been used to bring people together hundreds of years. Today, people are becoming more and more connected over the internet, from email to digital profiles. This application allows people to interact in this modern fashion, yet play traditional card games that before had to be done around a table. Conventional applications that emulate card games do not simulate the gestures of playing cards in a manner that corresponds to the physical game itself. However, the rationale behind the iCards app is to address this issue: this is an application where digital card interactions emulate real playing card interactions.

In order to develop the most effective user interface, an experiment must be conducted. This test will allow us to determine the efficacy of our current prototype, and form a variant that incorporates the results. The experiment will consist mostly of scenarios to exploit the required interactions in how players interact with a dealer, and how a dealer can control a game. These situations can give us insight into an effective design.

We the People of the Group H, in order to provide a network of portable card tables, promote usability, boster social activity among friends, and keep traditional card games in the modern technology timeline, are dedicated to developing a flexible, social, usable, and fun card game on the iPhone.

Group Members

  • Jessica Cen : Sketch artist, demo script writer, and Facilitator
  • Long Do : Computer, sketch artist, cameraman and video editor
  • Darren Kwong : Observer and data acquisition, results interpreter and sketch artist
  • Dan Lynch : Greeter, data acquisition, and video editor

Prototype

Our prototype was first sketched out with the computer mock-up generator (Fig. 1-9) and then constructed by paper. Our prototype used post-it notes for their stickiness as a means to be able to move things around easily. The video prototype (File:Group-h-low-fi-video.mp4) demonstrates the prototype. An overview of the prototype is given below, and details on tasks are described in the Video content and tasks performed section.

iPhone Frame

Fig. 1:The Menu screen is the first view that is shown when a user enters the app (but is not returning to a game, in which case it would go directly to fig. 8). The first button, "Tables", leads the user to the Tables view (fig. 5). The "Contacts" button takes the user to the screen with a list of contacts (fig. 2). There is a slider to set whether the user's status is online or offline; if the user is online, he can be invited to a table.

Fig. 2:The contacts screen shows the list of people who are currently online and offline, as well as a button to search for users. Touching any name will take the user to that name's status page (fig. 3). Hitting the button to search for users will go to fig. 4

Starting from the top and from left to right: Main Menu, Contacts screen, Search for users, Tables screen, Table settings screen, a user's status screen

Fig. 3: A person's status page has their name, level, money, and status. If the user is in a table, he can invite that person to his table if they are not in one already. If that person is online and is in a table and the user is not, he can request to join that person's table. Neither button will show if the person is offline.

Fig. 4: Search for Users is a page with a text field where the user can enter a person's name and the results will appear in the table view below. Hitting that name will take the user to that name's status page (fig. 3).

Define Gestures screen

Fig. 5: The Tables view shows all the tables currently being played. Tapping a table will have the user join the table if the table is not full (fig. 8). The user can create a table by hitting the upper right button, "Create Table" and be taken to the table set-up page (fig 6).

Fig. 6: The Table Settings screen lists the table type and name as text fields the user can enter so others can see in the Tables view (fig. 5). There is also a drop-down menu to select how many decks and number of players should the table have. There is a slider to control jokers in the deck, and a button to go to the Gestures page to set the gestures (fig. 7). There is a "Create Table" button that will take the user to the table view (fig. 8) without any gestures.

Left: Card Table Screen, Card Table Menu screen

Fig. 7: The Gestures page has two text field, each corresponding to a gesture. Whenever a user performs said gesture, the dialog box will show the player's name and the text associated with that gesture. There is a "Create Table" button that will then create a table and take the user to the table view (fig. 8).

Fig. 8: The Table view shows other players by having arrows with their names and number of cards they have. The middle of the table is where the pot (money) is located, as well as cards that have been played. The bottom left is where the user's hand and poker chips are located. There is a deck shown for the dealer so he can deal cards. There is the dialog box to the bottom right for messaging others and showing gesture messages. There is a message button below to open up the keyboard to enter a message in the dialog box. There is also a menu button that will take the user to the "Menu" view (fig. 9).

Alerts, keyboard, and other misc. pop-up menus

Fig. 9: The Menu view shows two buttons. There is a button to leave the game which will take the user back to the Table's view (Fig. 5). The other button is to invite a contact, which take the user to his Contacts page (fig. 2) so he can invite someone to his table.

Gestures reserved for sending messages

As mentioned earlier, the following gestures can be used to send custom messages.

  • Double Tap
  • Swipe Horizontal

Some gestures are reserved for the actual card game interaction, that are never used for sending messages, these are listed below.

Gestures reserved for card interaction

  • One-finger vertical swipe up: Puts highlighted cards into the middle of table for all to see, puts entire hand if none highlighted
  • Two-finger vertical swipe down: collects all the cards in the middle of the table back into the deck and shuffles the deck
  • Single Tap: selects a card, puts it in the out queue
  • Swipe Vertical: throw cards in out queue onto the table. If no cards are in the queue, then the entire hand is thrown on the table.

This is a social application where users stay up-to-date on their friends' card games, providing text messages for invites, even when the app is not running. We understand that this may not emulate an real card game perfectly, because people cannot just get up from their seat and go at anytime. However, given the nature of the internet and networks, we have to accommodate the modern way of doing things. This type of transient behavior corresponds to the Internets early chat rooms, where users can come and go as they please. However, if you come to a table while it is in play, it is up to the dealer whether or not you will have to wait a round to start.

Video Prototype

The video prototype is available here: File:Group-h-low-fi-video.mp4

How it was made

The video prototype was made using our first paper-made low fidelity model and a Canon SD 870IS digital camera. We took clips of all the possible button actions on every interface screen with one of the scenarios that we had created in the contextual inquiry in mind. We acted the parts that required to put the video into context and we also shot a downwards view of the low-fi model representing our iPhone and used our hands to simulate a user interacting with our app.

Once we recorded all of the footage, we then uploaded into a computer and used Windows Live Movie Maker to cut the clips into the segments we needed. Those clips were then appended together to create a video of James, a user, using our app just as he would in the scenario.

We were going to use the SAM animation to create a stop motion video, but we realized that would require taking several shots of a hand moving ever so slightly and decided against it. By systematically going through every screen and recording every possible interaction, we were able to quickly cut clips together into a convincing video of a user using the application.

We recorded the narrative using a microphone while watching the video animation to keep the audio and video synced. This was done with a combination of the ProTools software and a laptop microphone. Then the audio tracks were layered in using the Windows Live Movie Maker.

The video was difficult in many ways. Even though we went through the scenarios many times before we started recording, there were many times where we wanted something slightly changed so we had to reshoot, or we just needed a scene that we had not taken into account. Luckily the digital camera was easy to set up and the GorillaPod tripod was very useful in getting at some tough angles.

New Techniques

Techniques in creating the video were described earlier, generally involving splicing and reusing a library of video segments.

Through a video demo, we were able to really visualize the app and have a more concrete picture of it between each member of the group. One thing we saw was that gestures would be very helpful because the screen's real estate was very cramped. We came up with some more techniques that we decided to incorporate into the app and some can be seen on the video, like the swiping upwards to show all your hand, or swiping with two fingers downwards to collect all the cards and shuffle them.

What was difficult

The transitions between each screen are a bit sudden but that is due to the fact that we were not able to fully animate transitions like we would in real life. Sadly, the video has black bars on either side during footage of using the iPhone app, but that was due to a hardware limitation caused by the digital camera being held on its side. Another negative caused by using real footage was that the hand that was interfacing with the screen had to moved offscreen after each button press to make it seem consistent. This meant that interfacing with the app in the video is slower than it would be in normal life since a user would not have to move his hand away after each button press.

What worked well

The ease of splicing a library of video segments worked well for saving shooting time. We were able to show a hand actually interacting with the screen using these video segments. The narration worked well given a good microphone and Windows Live Movie Maker’s ability to add in our own soundtrack. The combination of third person and first person views worked well to show off many of the smaller, yet thoughtful functions of our app, such as alerts when the app is running in the background, like when a user needs to make a call.

Video content and tasks performed

The video was a recreation of one of our scenarios from the Contexual Inquiry assignment. James, an avid poker player, was about to go to his friend’s house to play but was forced to stay at home. He and his friends decide to play online using iDeck instead. James creates a table, invites some friends, and starts playing with the people at his table. During the game, he decides to make a call, and because the app is still running in the background, James is able to get notifications about the game. The game allows him to be at a virtual card table when he is unable to physically be at one due to extenuating circumstances.

There were several tasks shown in the video. One easy task was to invite a friend who is online to a user’s current table and that can be seen starting at 1:55 (min:sec) where James invites Sally to his table. Another easy task that was demonstrated in the video was the ability to play a hand, which can be seen at 3:56, with James throwing away two cards and getting new ones. A medium task would be something like setting up a table. The video shows James creating his own table early on in the video at 0:44. Setting up a table requires a little bit of work so that is why it was considered a medium task. An example of a hard task would be being the dealer because one has to shuffle and deal the cards, as well as keep track of whose turn it is and alert them if they are not keeping up, and deciding who gets the pot at the end of each play and giving it to them. The video illustrates this at 2:48, with James being the dealer and directing the flow of the game for the rest of the video.

Method

To set up the experiment we first created a set of screens, views, widgets, and buttons using paper, post-it notes, rubber cement, scissors, and markers. We sketched out the different interfaces. Then, before we did the actual experiment, we went through example scenarios by ourselves in a pilot to make final tweaks such as adding back buttons in the navigation bar when appropriate. Then we went along with the user testing.

First, we contacted our previous interviewees from the last assignment to see if they would like to participate in another study. These individuals are in our target user group, card game enthusiasts. We thought it would be good to utilize our resources and use these individuals for another test. Only two of them were available during the time constraint, so we had to find another person. We were able to find an individual that plays poker with his friends on a regular basis.

The locations varied among the different people. For one group, the location was at a poker player's home where he hosts weekly poker games. Two test were done at local Berkeley coffee shops at a convienient time for the tester. These environments were determined to be representative of part of the range of expected usage environments.

We tested three main tasks of our application: the easy task is to join a table from a contact who is online, the moderate task is to create a table, and the hard task is being the dealer of a game. We chose these three represent the entire spectrum of difficulty. Being a dealer is not trivial, and joining a table should be easy.

The testing procedure is outlined in the Demo Script of the Appendix. began with a friendly greeting by our Greeter, and an explanation of what we are trying to accomplish. In addition, the Greeter carefully explains our consent form and asks them to sign it. Then, the Greeter introduces the tester to each of the team members, so that they are comfortable with everyone in the test. The Facilitator then takes over, and demonstrates the simple task of seeing who is online in the application. Next, the Facilitator lets the tester know that they can start using the interface and the Computer. The easy task is described and the user is required to complete the task without any assistance. The Observer then takes notes of anything that stands out. This included extended pauses and looks of confusion, issues trying to complete a task, and enthusiasm and success in completing a task. This is repeated for the moderate task and hard task. The participant is then debriefed.

Results

Through our experiment we found that our interface was in need of some major revisions. We found that our interface was missing major components such as an option which allows the user to switch between cards facing up or facing down. Although some of these features would be in the software when creating a menu, it was not always apparent when sketching the lo-fi widgets and views.

We found that indeed the difficulties of the three tasks we chose to test correlated to our original assessment. However, we found additional problems that were not originally thought of.

Most of the testers were able to finish their tasks. The third tester, however, had a difficult time getting to finish the first round of euchre because the deck contained cards that the game did not required. And even though the second tester was not happy that he couldn't see the other contacts' cards in his blackjack game, he still was able to finish the first round.

On the easy task, which is to join Sally's table, most of the testers went to the tables option first instead of looking for Sally's name in the contacts list and joining her table from there. Most of the users thought that somehow they will be able to tell where Sally is from the long list of tables. When they found out that was not possible, they realized that they had to go back to the main menu and look for another button to tap on the main menu. Since our main menu is small, they had no other choice but to tap on contacts and look for Sally's name.

On the moderate task, which is create a new table, most of the testers had no difficulty personalizing their own table according to their needs. The only problem most users had a hard time on was defining gestures. Two of the testers did not have a full understanding of what a gesture was and how it worked in their game interaction.

When testing being a dealer, we found that people had trouble recalling gestures that they defined when they created the table. Another thing the testers had difficulty with is how to start a new game from the newly created table. Most of the testers took a moment to think what to do when they were facing the blank table view.

Discussion

From this experiment, we noticed that our application and its interface needs a lot of improvement. We found out that we were missing a lot of options for the user to create a specific table that could meet their needs. Some options were creating private tables so the table creator can limit who joins, as well as being able to create custom decks. The most glaring mistake that we made was assuming the user would know what to do to start a game. The test users made several different attempts to start dealing a card or just playing a game in general and had to learn through trial and error, something we do not want. One solution would be to pop up a dialog box once the table is created where it says that first you need to invite contacts into the table and then deal the cards by swiping the finger from the deck to the contacts' name. Also we need to incorporate a help button in case the user is wondering how to do something like send a message to other contacts. A tutorial functionality was also another possible design choice that might be implemented in the next iteration.

Another thing we learned was that many of the gestures of the dealer were very repetitive. In our current prototype, a user who is a dealer has to deal to each person one card at a time, making the task very tedious. More than one user mentioned not wanting to have to constantly swipe 5 times to each person because in a game with a maximum of 5 people, the dealer would have to swipe 25 times. We also realized this when we were creating the video and pitched the idea of having the ability to include some function where it would deal to everyone at the table one card and the idea seemed to be an acceptable solution. We will most likely see how we will be able to incorporate this design choice into the next iteration.

Overall, from the experiment we couldn't find out how the user would react when someone goes from online to offline and vice versa. Therefore, the experiment didn't show us if the user was aware whether or not a particular contact was unavailable to interact with him/her and if that event would make his task as a dealer challenging.

In addition, the experiment was not able to provide real chat experience to the user with real contacts, which leaves us unsure if the chat system will be useful for the card game experience. Since we could only test one user at a time (due to the nature of the testing procedure and the fact that we only had one prototype), there was no way to see how well users could play and talk to each other in an effective and fun way.

Also from the experiment we couldn't find out if the user can successfully send a message, such as a simple instruction on how to play the card game and if the receiver is able to understand the message and use it for the benefit of his/her card game experience. If there is a way to have all users talk to each other at a table through some kind of video-conferencing and how effective it would be, the experiment could not have revealed it.

A list of heuristic and general problems found during user testing can be found in the appendix.

Appendix

List of incidents found in tests

Test #1

No help menu on table view - Severity: 5 Usability catastrophe: imperative to fix We definitely need to fix this problem, since the user finds it hard to remember which gestures he assigned when he first created the table. In addition, it took the user some time to find out how to deal the cards and was forced to double tap the screen in order to find out what it does. We must definitely fix this problem, since we must not let users do gestures that they don't know what they will do to their game process. This change would definitely change the design of the table view since we need to put the help menu in a place where the user will find it easily once he gets stuck.


No quickstart guide - Severity: 4 Major usability problem: important to fix The user was not sure how to join a table from an online contact. He tapped on the "table" button at the start menu and refused to join every table on the list one at a time just to see if his contact was there. A solution for this problem could be a quickstart guide on the home page, where the user can browse an FAQ and see if a problem and its solution is listed. The FAQ would tell him to look for his first contact by tapping on the "Contacts" button instead of looking by the table name. Another solution would be that the table list shows the name of some of the contacts playing in each table, so that the user might recognize one of the contacts and join his/her table if they like. This would certainly change the design of the interface because we will need to change the interface in a way that the user is able to reach more information on how to use the app without getting frustrated. We will need to design buttons with short labels and descriptive icons.


Test #2

When you start a card game you don't know what to do - Severity: 5 Usability catastrophe: imperative to fix The tester took some time to think what to do first when facing the empty table view screen. He realized he needed to invite people and once he invited people in, he had difficulty figuring out how to deal the cards. He first tapped the deck of cards and nothing happened. He then swiped his finger from the deck of cards to one of the contacts to deal one card to that contact. We will need to make the list of gestures visible and accessible so that it can be retrieved by the user when they are unsure on how to start.


Cards dealt needed to be faced up - Severity: 5 Usability catastrophe: imperative to fix Even though the contacts received the cards from the dealer, the dealer was not satisfied since he wanted to play blackjack casino style where he is able to see everyone's cards. The table view, however, only allows the users to see how many cards each contact has, but not which ones. For fixing this usability problem, we will need to add to the table settings a switch to turn the cards facing up option as on or off.


After dealing the cards, what to do next is unclear- Severity: 4 Major usability problem: important to fix The dealer was not sure if he or one of his contacts were to start playing. He then receives a message from one of his contacts asking him to "Hit" him. The dealer then dragged a card from the deck to him. The dealer then figured he wanted a card from the deck and so he drags one of the cards of the deck to himself. The main problem we are having here is that the user has to wait for other contacts feedback in order for him to make a move in the game. We would like the user to start playing with his hand as he normally would in real life. We can fix this problem by again making the list of possible gestures visible so that the user can start making a move without waiting for others.


Programming custom gestures is unclear - Severity: 3 Minor usability problem This tester had difficulties understanding what a gesture was. He was not very familiar with using an iPhone/iPod, so he left the gestures option incomplete. He only had the double tap gesture defined as "hit" but he didn't define any other gestures, which didn't allow him to do other moves during the game. We can fix this problem by not allowing the user to create a table without finishing defining a reasonable amount of gestures.

Test #3

Specifying custom decks of cards for certain games - Severity: 3 Minor usability problem

This tester wanted to play "Euchre," a card game where only some and not all the cards in the deck are played. We need to have an option in the create table screen where the user can specify which cards of the deck to play. We only have a switch that can include or remove the joker cards from the deck since most games don't play with the joker cards. This problem is not a very important problem to fix at the moment, since most of our target user group play the whole deck of cards.

General Incidents found

Most people went to tables first, not contacts to find Sally - Severity: 3 Minor usability problem

The testers were asked to join Sally's table, an online contact. From the main menu, two of our testers went to the table options first instead of going to the contacts option where they had to look for Sally's name and then join her table by tapping her name and tapping on the "join this player's table." The testers who went to the table option first had to look at the long list of available tables and realize after a while that there is no easy way to find out where Sally is. A solution for this is to show the name of at least two players in each table in the list. That way the user can join a known contact's table without knowing the name of the table in case he forgets.


Invite more than one person at once - Severity 2: Cosmetic problem

Most testers found the process of adding contacts to the table they just created tedious. We can fix this by displaying the list of contacts and having the user check the names of the contacts he wants to invite and then the user can tap a final button that invites all the selected contacts.

Demo Script

Greeter: Welcome to our card game application for the iPhone/iPod called iDeck. iDeck is an application that will allow you to play with friends in a virtual world without being in the same physical room. You as an experienced card game player will go through this application and tell us what you think about it; if it satisfies most of your expected needs when playing on a real table. Right now your are facing the main menu of the app, and from this you can go and create a table or join an existing table. While the rest of the team finishes setting up the testing prototype, you can start reading the consent form and sign it.

[Hands the consent form to the tester]

Now our team facilitator will explain how this testing application works and after showing a short demo, he will ask you to complete three tasks.


Facilitator: So now we are facing the main menu, where it shows your profile. You are able to see how much money you have in the game and what is your current win/loss ratio. This switch at the bottom of the screen is to set your status either to online or offline [taps the switch to show how to change from online to offline and vice versa].

I will now show you how to see which of your contacts are online. First we tap on the "Contacts" button [taps "Contacts" button and switches to the contacts view]. And now we can see two lists: the first list is where your online contacts are and the other one is where you can find your offline contacts. We can go back to the main menu using this "Back" button on the Navigation toolbar [taps the "Back" button].

Now I will ask you to complete three tasks. I encourage you to think out loud and express any of your thoughts during the whole test. You are allowed to do any iPhone/iPod gestures such as single tapping, double tapping, and sliding one or multiple fingers. The computer here will respond appropriately to your gestures. There might be gestures which are undefined, and in that case, you will not see any response by the computer. You might want to try a different gesture and see if that has a desired effect on the test. None of the team members will be able to help or speak to you. You might at some time feel stuck, but you are encouraged to do your best. Please do not worry if you feel that you are "failing" the test. This interface is on trial, not you. So if you fail to understand something or you can't complete one of the tasks, that's a sign of trouble with the design, not a lack of intelligence on your part.

During the test, the observer will take notes quietly on any relevant reaction you have on the interface. At the end of the test, we will have a debriefing session to ask some questions and gather any of your impressions.

Now that we are in the main menu, your first task will be to join a table from one of your online contacts, Sally. Please start.

[After the user completes first task] You are now in the main menu again. Your second task is to create your own table.

[After the user completes the second task, keep the table view open] Now that you have just created your table, is time to begin playing! Your third task will be play as the dealer in your table. You will need to have some people in your table to play and also you will be in charge of dealing the cards and control the flow of the game. Your task will be completed as soon as you finish playing the first round.

[After the user completes third task] You have now completed the test. What did you think about it? Any comments, questions, impressions?

[Take 10 minutes to do a debriefing session]

[After the debriefing session] Thank you for your time, we really appreciate it. Your results will help us improve our interface and create the best card game experience.


Consent Form

You are invited to participate in a study of the user interface design for a playing card iPhone application. We hope to learn about any usability problems encountered trying to accomplish tasks with the interface. You were selected as a possible participant in this study because we believe you fit in our target user group of card enthusiasts.


If you decide to participate, we will conduct an experiment as follows. First, we will demonstrate basic interaction with the interface and perform a simple task. After the demonstration, we will ask you to complete three separate tasks. For each task, we will first describe the task, and then ask you to complete it. However, we will not explain how to complete the task. The total time for the experiment is expected to be about 20 minutes.


Any information that is obtained in connection with this study and that can be identified with you will remain confidential and will be disclosed only with your permission. Your decision whether or not to participate will not prejudice your future relation with us. If you decide to participate, you are free to discontinue participation at any time without prejudice. If you have any questions, please do not hesitate to contact us. If you have any additional questions later, please contact us at [removed for privacy].


_____________________________________________________________________________________

You are making a decision whether or not to participate. Your signature indicates that you have read the information provided in this form and have decided to participate. You may withdraw at any time without penalty or loss of benefits to which you may be entitled after signing this form should you choose to discontinue participation in this study.


________________________________________

Signature and Date


________________________________________

Signature of Investigator

Logs

Log 1

Easy task: join a table from an online contact:

  • Taps the "Tables" button on the home page
  • Confused to see a long list of tables and refuses to join every table to look for Sally, so he taps the back button
  • Taps the "Contacts" button
  • Looks for "Sally" on the list of contacts who are online
  • Taps on "Sally" and then taps on the "join this contact's table" button
  • Finishes the task


Moderate task: create a new table

  • Taps on the "Tables" button on the home page
  • On the "table type" field he types "poker"
  • On the "Table Name" he types "poker tables but before that he takes at least 15 seconds to think what name to type
  • On the number of players he chooses 4 from the picker
  • On the number of decks he chooses 2
  • Leaves the Joker option as off
  • When choosing the gestures, he pauses to think how many different gestures poker has
  • Chooses the double tap gesture as raise
  • Chooses the horizontal swipe as fold
  • Taps on "Create Table" button and now is faced with the table view of his newly created table
  • End of task


Difficult task: play as the dealer

  • Taps on the menu button on the table view.
  • Chooses the "Invite" option.
  • Looks through contacts. Looks if Sally is online to invite her to join his table.
  • Wonders if he can invite contacts who are offline. Tries to tap on George, who is offline, but nothing happens. He figures that offline friends can't join table.
  • Invites 3 friends one by one by picking them from the online contacts list.
  • Does not like going through the invitation procedure for each single contact.
  • Claims that it is necessary that the interface should give him feedback of whether the invitation was sent successfully or not and if the player is already in the table
  • Takes some time to figure out how to start dealing the cards. Worries that his contacts are impatient to him.
  • Observes what each of his contacts do in their turns
  • Claims that a help button is necessary to tell him how to do the interactions with other people and the cards on the deck because he doesn't remember which gestures he choose when he created the table.

Log 2

Easy task

  • Join sally’s table? Where’s sally?
  • Tapped on "Tables"
  • Couldn’t find it
  • Went to "Contacts"
  • Tapped on "Sally"
  • Asked Sally to join table


Moderate task

  • Tables > Create Table
  • Table Type - BlackJack
  • Table Name - D's blackjack table
  • 5 players
  • "What are gestures?" - Taps on "Gestures"
  • Double-tap = hit
  • "I don’t know what this is for" (gestures) - a bit confused about it
  • Tapped "Create Table"
  • forgot number of decks
  • 4 decks for table

(Perhaps we should have default names/values)


Hard task

  • In table view
  • "What am I supposed to do?"
  • Click on menu – should have menu view show up as default
  • Confused – invited player just showed up. "What are we supposed to do?" Not enough feedback on what you’re supposed to do.
  • Tapped the deck of cards and nothing happened. Looks confused.
  • Swiped card from deck and saw it move and said “ohhhh”
  • Blackjack issue – need to see other players’ hands/cards
  • Clicked on user’s icon/arrow

Depending on game, need option of showing other players’ hands/cards; face up or face down option

Log 3

Modified – defaults in fields – hit and stay


Easy Task

  • Went straight to "Contacts" to join Sally’s table


Moderate Task

  • Table Type - Euchre
  • Table Name - Euchre table
  • 4 players
  • 1 deck
  • "How do I make the deck so it only has certain cards on it?"
  • On the fly mod – specify only 9’s through A’s
  • Defined gesture: double tap – your turn
  • Defined gesture: horizontal swipe – eurchre


Hard Task

  • Invite multiple users at the same time?
  • double tap on deck – what does that do?
  • started swiping cards out to other users
  • no feedback on how many cards have been dealt

Question: How to set up account?

List of incidents observed

List of incidents found on Test #1

  • No help menu on table view
  • No quickstart guide
  • Want to invite more than one person at once

List of incidents found on Test #2

  • When you start a card game you don't know what to do
  • Cards dealt needed to be faced up
  • After dealing the cards, what to do next is unclear
  • Programming custom gestures is unclear

List of incidents found on Test #3

  • Specifying custom decks of cards for certain games
  • Want to invite more than one person at once


[add comment]
Personal tools