GR6 - User Testing
Design
We knew from the very beginning that one major challenge for our project was visibility. Without written instructions, it would be very hard for users to discover how to use our applications. Therefore, as we iterated our design, we attempted to add more and more appropriate affordances. Below, we describe the evolution of a few key features.
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).unmigrated-wiki-markup
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.
Note: Our screenshots were mysteriously unable to capture the mouse hover cursor changes that take place.
Select part of stack
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.Wiki Markup
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.unmigrated-wiki-markup
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.
...
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.
Reflection
Harrison's reflection
Basically, throughout the process of doing this project, I affirmed my belief that Victor J Wang likes dick.
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
Perhaps the biggest lesson I learned during the iterative design process was that it is very easy to forget that “you are not the user”. Features that we thought would be beneficial to usability actually turned out to be a hindrance to the user experience. For instance, our quick stack selection feature actually caused confusion and frustration because there was a disconnect between the model of the interaction and the model in the user’s head. Other aspects of the design that we overlooked also contributed negatively to the usability. For example, during our prototype, we simply forgot to implement card boundaries on the table. We did not think too much of this but this turned out to have a huge impact on the usability of the application because it made errors irreversible.
One realization I made was that for users to really enjoy using a product, the core features must be extremely simple and easy to use. A series of small feature victories is much more effective in gaining positive user support and traction as opposed to a single extravagant feature.
The second biggest lesson I learned was that from a design perspective, making things visible is hard. Having the right affordances can go a long way and I’ve noticed that the best affordances are the ones that are hardly noticed. The most effective technique here is to reuse as many affordances as possible and be consistent with other commonly used applications. This is the by far the best way for users to learn the application.
Overall, I found this project to be extremely educational to learning about usability. If I had to redo anything, I would actually incorporate even more user testing and use more test subjects per testBasically, throughout the process of doing this project, I realized that I like dick.