GR6 - User Testing
Design
Entire stack selection
Prototype: double click
Final: click inside green circle that appears on stack
We originally thought that double clicking to select the entire stack would be a very useful feature for efficiency. However after the paper prototype and heuristic evaluation, we received criticism that this was not obvious and inconsistent functionality. Therefore, we decided to change our approach to focus on making this action more visible. Users now can select the entire stack by clicking on the green circle that appears on the stack. An alternative design we considered was adding a card fold tab to the stop of the stack (analogous to a page fold tab found in e-books).
[img: select-all.png]
Hover mouse icons
Prototype: none
Final: present
One critique we received from our Heuristic Evaluations was the lack of affordances showing interactivity. We decided to change the mouse cursor into a hand pointer when the mouse hovered a card to denote a clickable action.
Select part of stack [img: select-some.png]
Prototype: none
Final: present
This feature was added to give users more control over manipulating their deck. We hoped to increase visibility and feedback by showing the size of each stack.
Re-stacking cards
Prototype: none
Final: present
This feature was also added to give user more direct control when manipulating stacks on the table. We used a green highlight border to give feedback when a stack was dragged near another stack. An alternative design would have been having a dragged stack pre-snap onto the receiving stack when nearby.
[img: restack.png]
Right click select and menu
Prototype: pop-up menu
Final: select entire stack + pop-up menu
One major criticism we received during our Heuristic Evaluation was how right clicking on cards brought up a pop-up menu but did not select that card, leading to confusion. We fixed this and added the additional function of also selecting the entire stack for efficiency purposes.
Taking cards into own hand
Prototype: pop-up menu option
Final: drag and drop cards into own hand area
During our Heuristic Evaluations, we received complaints about how not obvious and tedious this feature was. We aimed to increase user freedom and control by making this feature drag and drop.
Play from hand
Prototype: double click on card in hand area
Final: drag and drop
We discovered this feature to be very limiting during Heuristic Evaluation because our first prototype only allowed playing one card at a time. To expand this feature, we allowed users to play multiple cards simultaneously. Also, for consistency, we made playing cards from the hand also drag and drop.
Selection box
Prototype: none
Final: present
We added this feature to the final version to enhance user control and efficiency. Users would be able to effectively group multiple stacks quicker. However, we observed that this function was rarely discovered and therefore rarely used during our User Testing.
Implementation
We implemented MetaDeck in Java, using primarily swing components for the front end. We used a standard client-server message protocol, and had a standard MVC architecture on the client side. The model contained all the data that was persistent in the game state, meaning that the different players' clients should have models that are eventually consistent with one another. The view contained the state that was specific to one client, such as the cards that player is currently selecting. Only that player can see the state contained in the view; it does not propagate to their other players' clients. The controller contains all the input listeners, and processes them, changing the model and view appropriately. On the server side, there is a lock for each stack of cards, ensuring that two clients cannot try to move the same cards at the same time. The server also contains its own model, which is necessary since new clients must be able to request the full game state from the server.
First, we describe the model. The model is essentially the same on the client side and the server side. In short, the model contains all the information needed for an observer to be able to kibitz. It is represented as a TableModel, along with a set of PlayerModels. The TableModel contains information about what is on the table, and the PlayerModel contains information about the players sitting at the table and the contents of their hands. The TableModel contains a list of CardStacks, which represent physical stacks of cards on the playing table. CardStacks are objects containing a list of Cards, as well as their x,y position on the table, and whether they are flipped up or down. Each Card represents a physical playing card, with a unique ID, as well as a number value and a suit value, or a joker value. The PlayerModel contains a unique player name/identifier, as well as a list of Cards. Overall, we tried to keep the model as straightforward and simple as possible.
Second, we describe the view. The view contains state about what the client is currently selecting, both for the table and for the hand. The view contains a TableSelection, which is a list of StackFragments. A StackFragment represents the top so many cards of a stack, possibly up to the whole stack. This restricts the allowed selection for the player, so for example, it is impossible for the player to select the second card in a stack without selecting the first card also. The view also contains a HandSelection, which is a set of cards in the player's hand. The HandSelection represents the cards that are visually positioned slightly above the other cards in the player's hand, so that the player can make any arbitrary selection from his hand. The view also contains the implementation of the painting. All of the necessary images are preloaded from image files are stored in memory. The painting is drawn in the standard swing hierarchical manner. The table painting is done in its own component, and each hand is painted in its own component. The chat and to-be-implemented scoreboard are painted in their own components.
Third, we describe the controller. The controller handles the interactions. The controller listens for mouse actions and mouse motion, and filters the events into their respective swing components. When the controller needs to change the model, it calls the appropriate functions in the model, and afterwards will update the view appropriately. Realistically though, the mouse will probably be moving across the screen all the time, and so the view will need to be continuously updated to make sure the usability affordances are accurate.
Finally, we describe the features and their implementations.
A very important notion is how users use the interface to manipulate stacks of cards. A user can drag a selected stack of cards in the standard manner, and while dragging, green circle affordances will show up on each stack, and they will give feedback when the dragged stack crosses over the other stack.
There are many ways to select a stack. While the mouse is hovering over stacks, we dynamically update the affordances on the stack to show what stack fragment will be selected if the user decides to click. We also show the size of the stacks, as well as the size of the stack fragment about to be selected, and the size of the dragged component. We try to draw the sizes slightly merged into the stack itself, to make it obvious which stack the number corresponds to. However, this sometimes decreases visibility of this data.
Right clicking on a stack brings up a popup menu originating at the mouse cursor. This menu contains the options flip, shuffle, and spread. These actions can all be performed on any TableSelection. Flipping multiple stacks will also orient them the same way. Shuffling multiple stacks shuffles each one independently, as does spreading multiple stacks. Spreading simply turns a stack of size x into x stacks of unit size, so that each of the unit stacks are visible.
Some implementation issues we have not had time to iron out yet.
For example, we always draw a stack the same way, and currently, our table size isn't very big, so it's possible that the cards will overflow out of the table. Our solution in this case is to contract the stack depth to make it stay within the bounds of the component, but we have not implemented this yet.
Also, most of our click listeners are on mouse presses instead of mouse clicks, so we have some issues with not being able to differentiate between a mouse press that was meant to just be a click, and a mouse press that was meant to just be a mouse press. This restricts the amount of options we have as events we can listen for, and decreases the usability. For example, in some occasions when we want to click on a stack fragment to select it, it will register as a mouse press and start dragging that stack fragment first. In the common use case, where the user wants to move the selected stack immediately, this is fine, but it can be frustrating at times for a user that just wants to select a stack fragment for whatever reason.
We have not had the time to make any fancy graphics, or anything involving animation, so some cool ideas we have of improving visibility have not been implemented. For example, we want to have an animation for shuffling to alert users that a stack has just been shuffled, but cannot think of an easy way to make such an animation.
Evaluation
Users
We chose users by asking friends who we played cards with regularly. They were a good representation of our target audience because these are technology-savvy college students who enjoy card games.
Briefing
We briefed our users by presenting them with the following scenario.
“Imagine that you and your friends have decided to play bridge using our application. You are
the dealer and so you have been tasked with shuffling and dealing the cards to all players. Afterwards, you will be asked to perform other types of playing actions, simulating as if you were in the middle of an actual game.”
No demo was used during our briefing.
Tasks
Stage 1: Dealing
- flip over deck
- shuffle
- deal 13 cards to each player
- take 13 into own hand
Stage 2: Playing
- play any 5 card poker hand
- reveal all cards in hand visibly (as if you were the dummy player)
Observations and fixes
1. No visible feedback for shuffle function when deck is flipped
Possible fix: Display a notification pop-up alerting the user that the cards have been shuffled. Alternatively, use an indicator icon to identify randomly shuffled stacks.
2. Hard to select a sub-stack using the trackpad
Observation: Because a trackpad offers less precision than a mouse, having the mouse pointer land on the exact pixel required to select the desired size sub-stack took many attempts.
Possible fix: Encourage users to use a mouse. Alternatively, decrease the mouse speed as it hovers over cards to give users more precision and control.
3. Tedious to play all cards from hand
Observation: Currently, all cards in the hand must be individually clicked once and then dragged onto the table.
Possible fix: Use a selection box that when encompasses the entire hand will select all of the cards in the hand.
4. Right click pop-up menu options not obvious
Observation: Majority of users did not think to use the right click button unless prompted.
Possible fix: Include help menu that makes users aware of this option.
5. No undo or restart game option
Observation: When users accidentally dragged the entire deck into own hand, it was more convenient to restart the application to reset the deck.
Possible fix: Implement an undo function or see possible fix for 3.
Reflection
Haitao's reflection
I felt that most of the feedback received through doing user tests matched my expectations of what the feedback would be. I guess the biggest disparity was that some people were not as familiar with some shortcuts and affordances which I thought would be effective. For instance, the type of click that people think to do did not match my expectations. It seems that people do not really think to try different types of clicks, preferring to just single left click on everything. However, this instance is meant to be used by people who want to play cards, and so we assume they have already tried other interfaces in the past and are familiar with the standard set of interactions in these online card game rule-based interfaces. The users that we tested on were not necessarily in this user class, so that may have caused some unexpected results.
In terms of milestones, we never really took the time to concentrate of some aspects of usability. We still don't have 100% functionality for our app, so we haven't really had the time to figure out some usability decisions. In particular, the client-server communication took longer than expected, since it was annoying and we didn't really want to do it. Also, some cool usability aspects we envisioned required too much graphical design, and we didn't have the time or expertise to do it. For our front end painting, we just drew lines, boxes, ovals, and preloaded images. The painting also seemed pretty inefficient, but I guess it turned out fast enough in the end. There isn't really any noticeable lagtime in our program.
I think we prototyped the right part of our app, specifically, the click-based interactions in our interface. We had to make some key changes early in our design process, and it probably saved us a lot of effort to make the changes early.
One problem our prototypes failed to capture is the lack of screen size in our program. There just is not enough room on the screen to manipulate the cards. In reality, the computer screen is a lot smaller than a table surface, so we have to do something to account for this different if we want to simulate actual cards. We did not think this would matter as much as it does, and now we still don't really have a good solution for this problem.
All in all, this was a fun project. I'll keep working on it, since it's not really usable yet. Maybe I'll need to do some more user tests before it ends up actually being usable.
Victor's reflection
Basically, throughout the process of doing this project, I realized that I like dick.