FinalPrototype-Group:O
From CS160 User Interfaces Fa06
Contents |
Team Members
- Alex Wallisch
- Implemented most of the functionality changes in the Upload File UI.
- Contributed to Tasks, Design Evolution, and Final Design sections of report.
- Jason Lee
- Greatly improved detection of Dots and Boxes games.
- Contributed to Design Evolution and Final Design sections of report.
- Michael Udaltsov
- Added animation pausing/stoping.
- Added configuration file for default save directory.
- Contributed to Design Evolution and Final Design sections of report.
- Sean Carr
- Changed menus in GAMESMAN.
- Contributed to Design Evolution, Target Users, Tasks, and Final Design sections of report.
Final Source Code ZIP
Problem and Solution Overview
Our project addresses two aspects of playing and analyzing two-player paper-based games such as Tic Tac Toe and Dots And Boxes. Currently, there exist at least two ways of playing these games: on paper and on a computer system, such as the GAMESMAN system, a product of the GamesCrafters research group on campus. Games played on paper are easily transportable, but for players who prefer to analyze different strategies, and learn from previous games, paper does not offer any kind of convenient or automatic analytical tools. Alternatively, the GAMESMAN system serves as an engine for solving, analyzing, and providing a perfect computer opponent for two player, finite, perfect information games such as Tic Tac Toe, Checkers, and many other games. While playing on the GAMESMAN system is good for analysis and strategy development, particularly through using the Visual Value History display, it is often inconvenient, since a computer is required to utilize this system and these tools. There is also a certain learning curve for the GAMESMAN software, which may prevent potential users from using it. The problem is that each of these systems offers several benefits, but also several drawbacks. We wish to recreate the easier and more user-friendly pen-and-paper interface for paper-based games, while still offering the powerful analytical tools of GAMESMAN. The solution is to utliize the affordances of the Anoto digital pen and paper system by recording the strokes of the pen used during gameplay and offering a user interface that can be used at a later time (when the pen is docked) to upload these ink strokes into a file format that will be recognizable by GAMESMAN, such that the analytical tools may be used. This solution offers a marriage between the ease and transportability of pen and paper with the powerful analytical tools of the GAMESMAN system.
Target User Group
The target user group is anyone who enjoys playing pen-and-paper based games of this variety (2 player, abstract strategy). Specifically within this group (which includes almost everybody), a product like this would appeal to and be targeted towards people who enjoy games like this and are also likely to use game analysis tools such as GAMESMAN. These people would be interested in either playing such games to win or in the mathmatics and science behind them, especially in the mathematics and science involved in winning strategies. People who participate actively in competitions/tournaments of these pen-and-paper based games would benefit greatly from a product such as this, as they would be able to see a post-game analysis of every move that was made. Very specifically, a product such as this would also be targeted towards users of the GamesCrafters system and researchers that have been involved with the GamesCrafters research group at some time, as these users would already be familiar with some of the interfaces involved with GamesCrafters and GAMESMAN.
Tasks
Starting, Playing, and Ending the Game (Easy)
The first task (easy task) that players were asked to do involved simply playing games of their choice based on the games that were implemented with the Anoto digital pen system (in this case, Tic-Tac-Toe or Dots and Boxes). One of our team members was selected to be the designated opponent for each participant. Participants were encouraged to play at least one game of each, but were free to select whichever game they wished to play and however many number of games they wished to play. While participants performed this task, we paid attention to the way they made their strokes with the pen and any potential "unexpected" strokes that could cause our stroke, board, and space recognition algorigthms to be thrown off (for example, lines that go into other spaces in Tic-Tac-Toe).
Uploading the Game (Medium)
The second task (medium task) that participants were asked to do involved uploading the games they played via the upload UI that we created. The main goal is to successfully navigate the UI to pick specific games and upload them into a format that can be read by GAMESMAN. After inserting the pen into the cradle, the software will automatically parse the pen data, then detect and separate each game, and then present the user with the Game Upload interface. It is up to the user to provide information via the upload UI, such as what type of game was played, what rule variants were used, and what is the filename that the file will be saved as. The user may choose to skip certain games, but those that are chosen will be recognized and saved out to a file that can be read by GAMESMAN. While participants performed this task, we paid attention to any questions or points of confusion that the participant had while working through the upload interface, as well as any mistakes the participant made while trying to upload games.
Loading the Game and Using the GAMESMAN System (Hard)
The third task (hard task) involved participants starting up GAMESMAN, loading a game that they saved, and using Visual Value History to examine the values of their moves and identify any critical moves in the game. Users must first launch the GAMESMAN application and pick the game they want to use. Then they must load a game file that was saved previously by the upload step. After loading the game, the user is able to see all the moves made in that game, undo and redo the moves, and view the Visual Value History. It's possible to see the eventual outcome of the game (Win/Lose/Draw) for every possible move, and the user can choose a different move at any point to see the mistakes and learn better strategies. We think that both new and experienced users with respect to using the GAMESMAN system will spend most of the time on this task. While participants performed this task, we paid attention to any questions or points of confusion that the participant had while trying to analyze their game with GAMESMAN, as well as any mistakes the particpant made while trying to load the game.
Rationale Behind the Tasks
The three tasks listed above were chosen because we feel that, taken all together, they provide a good representation of the typical interaction with our application. The task of playing the game on paper had the least to do with our interface, but it is the part of the application in which the user interacts with the digital pen. Because of this, we felt that leaving it out of our user testing would not give the user an accurate experience of using our application; they would be testing it out using pen data that they hadn't generated themselves, which would feel more like a test than an actual chance to use our interface.
The second task was chosen because it is the primary purpose of our application. The user starts out with the data from the pen strokes that they made while completing the previous task, and their goal is to wind up with several GAMESMAN save files. This requires the user to use almost every aspect of our interface, including selecting the game they played, describing the options, choosing a filename, and possibly marking some games not to be uploaded, depending on what actions occurred during the first test. We felt that this was the most important task involved in testing our interface, as the Upload File dialog box was the component that we had the most free rein to design and modify.
The final task was chosen to test whether the modifications our group made to GAMESMAN were sufficient to allow users to load games they had played on paper. While the interaction with GAMESMAN is the end goal of our project, it is the aspect over which we have the least control, as it is mostly maintained by a separate group. We nevertheless chose to include this task to determine whether users were able to successfully use GAMESMAN to manipulate the games that they had played and whether they had any feedback regarding either our modifications to GAMESMAN, or else changes to our upload file interface that would facilitate the use of GAMESMAN.
Design Evolution
At first glance, the final version of the Upload File interface is fairly similar to the initial design dating back to the low-fidelity prototype. However, as a result of user testing and feedback, many changes have been made to the final version, adding to the overall functionality and convenience of our product.
Our first design, the low-fidelity prototype was extremely minimalist, but set the tone for the overall direction in which our Upload File interface was to take. For this phase, we included only features that were absolutely necessary to the functionality of the interface. It consisted only of an image of the game that was being uploaded, a dropdown menu to allow the user to select which game they had been playing, a set of radio-button-controlled options (dependent on which game from the dropdown menu was selected), a textbox for entering a filename, and the navigation buttons, "Upload", "Skip", and "Finish". The initial testing was more-or-less successful, but it brought up a major issue with the design; users needed a way to navigate backward to revisit games they had already filled in details of. The lo-fi prototype testing also revealed other things that needed our attention, such as the need to clearly explain what each of the options were (in particular, the term "misere" and the Dots and Boxes option for board size) and the need to make sure that the user is not able to upload the game without first entering the necessary amount of information.
For the initial prototype, we implemented the interface and addressed the previously found problems. We replaced the "Skip" button with two navigation buttons marked "<- Previous" and "Next ->". Also, more clear explanations were given for each of the games' options (for Dots and Boxes, the text specifically asked the user how many squares tall and wide the board was) and the "Upload" button was set to be "grayed out" until the appropriate information was first filled in. This was presented as the Interactive Prototype version, after which a few more problems were identified and fixed. We added animation of the game in progress instead of just a static picture of the finished game. Also, a "Save As" button was added to allow choosing a destination folder and filename through a dialog box rather than typing it directly. These changes were completed and used in the Pilot Usability interviews.
Feedback received during the pilot usability tests uncovered some usability flaws. For one thing, while the animation could be controlled via a button below it that would toggle it from "play" to "stop", the default behavior of the interface was to show the animation on. This led some users to believe that they had to wait for the animation to finish before the game was done "loading." Since the animation on longer games of Dots And Boxes could take upwards of 30 seconds, this was seen as a must-fix issue, as it could potentially waste users' time.
A more serious error was the potential for confusion about the behavior of the buttons marked "Next ->" and "Upload". Each of the users who we interviewed during the pilot usability test made the same error with regards to these buttons: they all thought that clicking on "Next ->" would cause their data to be saved when, in fact, that button was the equivalent of "Skip" in the previous version of the interface. In order to upload a game, the user was required to click on the button marked "Upload", which would upload the game and then move onto the next one.
Yet another issue was the fact that, once a user navigated away from an individual game, the description they had provided for that game was lost; it was remembered by the system, but there was no way for the user to access it. This meant that if a user entered details for a game of Tic-Tac-Toe, then entered details for a game of Dots And Boxes, and then decided that they wanted to edit the information for the first game, they would have to re-enter the details from scratch. In fact, when going back to the Tic-Tac-Toe game, the options for Dots and Boxes would be displayed instead, potentially causing more confusion. The user can rectify this by simply changing the dropdown menu option from Dots and Boxes to Tic-Tac-Toe again, but we deemed that this would still be a somewhat confusing issue for users and that fixing it so that the appropriate options for each game would reappear when going back to a previous game would be a convenience worth striving for.
Finally, some users reported that they had overlooked the presence of the box in which to enter a filename for their game and had therefore been unsure of which game to load when attempting to open their saved game using GAMESMAN (the default names given to these games were of the form "game1.gcs", which was not particularly enlightening). These users said that they had seen a long string in the box, which had caused them to not recognize it as a place to enter a filename. Despite the fact that there was a button marked "Save As..." for browsing the filesystem, the users had not realized that they could choose the name and directory under which they wanted to save their game. Many users ignored the filename box because we had originally programmed it to show the entire pathname it would be saved under, which was too confusing for most of our test users to understand, so they simply chose to ignore it. Another smaller issue was that the default directory for saving was not the default directory from which GAMESMAN loads files from.
These issues were addressed in our final version of the interface. The animation issue was resolved by not showing the animation unless the user specifically clicks on a button marked "Play". Instead, the final frame of the animation (the finished game) is shown, similar to our very first design, and the user can click on "Play" to view the animation. Pause functionality was also added to the animation feature. In order to prevent users from making the Upload/Next error, the "Upload" button was removed entirely and a checkbox was added to replace it. In order to upload a game, the user ensures that this box is checked (it defaults to being checked, unless the user has not provided any details about the game) and then clicks "Next ->". The status of this checkbox, as well as all other details about a game, are remembered by the interface even if the user navigates away from the game and returns later. When the user has finished navigating through all of the games and is sure that all of the games that he or she wishes to upload have been properly checked off, the user can click on "Upload and Exit" in order to upload all the marked games. Finally, the long pathnames in the box at the bottom of the screen have been done away with; now, only the filename appears in the box. The directory appears below the box, and can be changed by using the filesystem browser accessible by clicking the "Browse" button. In addition, to add some more clarity to the file, the default filename for each game includes the game type, the number game it is, and the date (ie, Dots And Boxes_1_20061126.gcs). The ability to include the game type is due to a new feature that we included, in which the user interface is able to guess which game is being uploaded and chooses this as a default. Though it is not guaranteed to work 100% of the time, it adds an extra layer of convenience for the user, as well as aides in the naming of the default filename. We also changed the menus in GAMESMAN slightly so that they were less cluttered and better grouped. "Save Game" and "Load Game" were changed to "Save" and "Load" and moved over to be next to "New Game" .
The most valuable evaluation technique was the Pilot Usability Test, as it allowed users to experiment with an actual working prototype that would bear a similar resemblance to the final product, instead of a simple paper interface. It allowed users to work with an actual interface on a computer and be confused with real problems with the interface. With the Pilot Usability Test, there was a sense of working with a real product and that any problems that came up here were much more serious than the problems that came up with the Lo-Fi Prototype testing. Due to the nature of the Lo-Fi Prototype testing, it was easy to wave away some of the bigger problems that we may have overlooked simply because we thought that we would be able to fix it later. With the Pilot Usability Test, we were working with an actual tangible product, and that fact alone made our group take any usability problems a lot more seriously. In addition, because we had actually programmed several of these things ourselves, it was not an ideal representation of our product and was full of real problems and bugs (as opposed to the Lo-Fi Prototype, which was drawn to what we felt would be an ideal design at that point), so users were able to pick up on these more easily and explain to us why they felt something in our design needed fixing.
Screenshots of User Interface Changes
Sketches and Lo-Fi Prototype elements:
| Initial element sketches: | ||
 |  |  |
| Computer-drawn elements for printing: | ||
 |  |  |
Computer GUI prototypes:
| Initial Prototype: |  |  | |
|---|---|---|---|
| Pilot Study Prototype: |  |  |  |
| Final Prototype: |  |  |  |
Final Interface
Final UI Design
The final version of our user interface supports all of the features that were covered by our initial proposal. Our product combines the convenience of playing these pen-and-paper-based games on pen and paper with the advantages of analyzing these games with the powerful analysis tools provided by the GAMESMAN system. The user begins simply by playing games with the Anoto Digital Pen and Paper system as if they were playing them with a regular pen on a regular piece of paper. The user can play as many games as he or she wishes and docks the pen when he or she is finished playing and wishes to upload the games onto the computer. The application can be configured to launch automatically upon docking the pen, and it immediately presents the user with the opportunity to upload any of the games that they played.
The program is able to split the strokes into individual games based on how close the strokes are. For each game, the user can select options to describe the conditions and rules of the game and ultimately decide whether or not to upload it. The user selects the game type from a drop-down menu and chooses the individual rules and conditions that were used during that particular game. In addition, the interface itself can intelligently guess which game the user played by examining the strokes used to draw the board. If the game was played using any options that are not immediately recognized by our interface, the user can manually select them in a normal fashion. The user can also play an animation of the strokes for each game, which would help to remember each individual game better when uploading multiple games at once. Uploading games is done by marking a checkbox on each game labeled "Include this game in upload". After looking through all games, the user can click "Upload and Exit" to upload all the games with the checkbox marked. The user can also choose not to upload a game by unchecking the box (by default, it is checked). The user may also enter a filename and choose the directory in which to save the file under (the default filename for each game is based on the game type the interface guesses it is, the number game it is in the upload queue, and the date).
After they finish specifying details the user may click a button marked "Next" to move to the next game. If they wish to return to this game later to edit some more details, they may return using the "Back" button. Whenever they return to a game that they have previously examined, the details they had specified previously will be remembered by the interface and redisplayed. When the user is finished, they may click on a button marked "Upload and Exit" to upload all games they have viewed thus far. Any games they did not explicitly visit will not be uploaded. Thus if the user knows that all the games after a certain number are not worth uploading, they can simply stop looking at games at that point and exit, automatically dropping that games that they did not look at.
The animation feature has three states: stopped, playing, and paused. Every game initially begins in the stopped state, displaying the finished game. If the user wishes to animate the game in order to view the order in which strokes were made, they can click the "Play" button. The strokes are drawn based on the timestamps recorded by the pen, three times faster than normal speed, to make the animation faster. If there are significant delays between strokes, a shorter delay is used instead. Pausing the animation would keep the current animation frame static, until Play or Stop is pressed. Play would resume from the current frame, and Stop would go to the final frame of the finished game.
Once the user is finished, they may open the files they have uploaded in GAMESMAN. When they do so, the game moves they uploaded are briefly animated in GAMESMAN. Then, the user may examine the game with Visual Value History to determine the quality of the players' moves and determine any "turning points" or critical moves in the game. They may also click on an individual move in this diagram to "rewind" the game state to this move. They can then replay the game starting from this position using the facilities of GAMESMAN. Using GAMESMAN, the user can discover valuable information about the strategy he employed during their games and tweak them in order to improve their understanding of how the game works and their winning strategy.
The first screenshot for Final Prototype (above) shows the interface for uploading a game of Tic-Tac-Toe. The left half shows an image of the game. The animation is stopped, so the final state of the game is shown. The right half allows the user to specify details about the game and the options. For Tic-Tac-Toe, the only options to choose from in Tic-Tac-Toe are whether 3-in-a-row wins (Standard) or loses (Misere). In this particular game, the user has chosen not to upload the game, so the "Include this game in upload" box is unchecked. Because the game will not be uploaded, the box where the user enters a filename and the button they may use to browse the filesystem are disabled. The second screenshot shows the interface for uploading a game of Dots and Boxes. In this case, the animation is in progress, so the Play button has been changed to Pause, and a partial view of the game is shown. The additional board size options (1, 2, or 3 squares wide/high) are shown on the right.
Implementation
The interface for uploading games was implemented in Java. The interface was built using Swing, while the ink-handling segments were written independently. Initially, the R3 toolkit was used to provide some of the functionality necessary for this interface. However, since R3 is dependent on a later version of Java than many of the machines we were using had access to, and we were only using a small subset of R3, we rewrote the Ink and related classes. We removed any unnecessary features and added more features that were needed for our code.
Because the software for the Anoto digital pen works only on Windows and GAMESMAN requires a UNIX-like environment, there was initially some ambiguity regarding how to merge the two. Eventually, we reached a solution by which the pen software calls our Java uploader. The uploader then executes a script which launches Cygwin (a UNIX-like environment for windows), which then launches GAMESMAN within that.
What Was Left Out
Most of the features that were initially proposed made their way into the final version of our interface. The primary limitation is that only two games are supported. Although we initially considered several games, we decided that adding more than these two games to the system would require more time than was available for this project. Tic-Tac-Toe and Dots And Boxes were decided upon because they are some of the most well-known pen-and-paper games. Tic-Tac-Toe is furthermore one of the flagship games of GAMESMAN. Dots And Boxes, while not as ubiquitous, is a surprisingly interesting game, even at sizes small enough to be solved by GAMESMAN.
There were a few details initially suggested, such as automatically detecting the size of a Dots And Boxes board without user input, that were not incorporated into the final version. However, for the most part, the interface is fully functional. No "wizard-of-oz" techniques are necessary to produce a fully operating application.
