InteractivePrototype-Group:Coach Class
From CS 160 User Interfaces Sp10
Contents |
Interactive Prototype of Coaches' Playbook
Project Files
- Source Code: File:Playbook.zip
- Demo Video: File:Coaches playbook interactive prototype demo.mov
Team Members
- Brian Chin - coded parts of the Game and Stats tabs, wrote portions of the document
- Jonathan Hirschberg - coded the Playbook tab (drawing plays, saving frames, playing back frames, editing frames, saving plays, loading saved plays), wrote portions of this document, took/uploaded screen shots of Playbook tab
- Jordan Klink - in charge of the presentation, helped code the Playbook tab, made images for the playbook tab, wrote portions of this document
- Alex Sydell - coded Notes tab, contributed to other code, wrote portions of this document, made video of prototype, took screenshots/photos, pushed the app onto our test device, set up a Subversion repository for the code
- Wei Wu - coded Game tab (roster entry, player picking, play success, play failure, substitution, parts of shots made), wrote portions of this document
Problem and Solution Overview
Our goal for the interactive prototype was to improve on our low-fidelity prototype by creating a higher-fidelity interface for our Coaches' Playbook application. We incorporated much of the feedback we received from user testing the low-fidelity prototype into this next iteration to improve the interface. The majority of the feedback was concerning creating and viewing plays as well as keeping track of in-game stats, and accordingly those were the areas that were the most modified. The Stats and Notes tabs remained mostly the same as in the prior iteration with the exception of a few small improvements, and we plan on adding more features to these areas in future iterations.
Tasks
The tasks we used for testing the new interface remained largely the same as for the low-fidelity user testing. We felt that these tasks covered the majority of our interface and the majority of the application's features.
Taking notes (easy)
Create and save a new note in which you say something about one of your players, such as that the player does not pass the ball enough. Then, pretend some time has passed and you want to read your note; find the note and read its contents.
Drawing a play (moderate)
Create a new play in which you move the players around from their default positions and draw one or more arrows. Then, save your new play. Pretend some time has passed and you are showing the play to your team; find the play and go through its steps as if demonstrating it to someone else.
Player stat tracking (hard)
Pretend you are coaching the Lakers and they are starting a game right now. Begin a new game in the app, and select a starting lineup of Kobe Bryant, Derek Fisher, Ron Artest, Pau Gasol, and Lamar Odom. Then, pretend that on the first play of the game Pau Gasol passed the ball to Kobe Bryant who scored a 2-pointer. Record this statistic for the current game.
Revised Interface Design
Playbook Tab
The most significant change in the Playbook tab from our paper prototype was getting rid of the dependence on modes when creating a play. Instead of having to toggle between one mode where you can only move the players and another mode where you can only draw paths, all of the functionality is implemented on a single drawing screen. In addition, originally our paper prototype only supported a single frame per play. However, we added support for multiple steps during play creation, where the user can draw out multiple frames and save them all to the same play. We placed this additional feature at the bottom of the screen, where the mode buttons used to be.
Lastly, there were also other minor changes that solely affected the user interface. This included: an additional edit button on the playbook screen, replacing the "playbook" button with a "done" button to take you back to the playbook screen, a different prompt that pops up when you save a play, an additional navigation bar in the view screen to step through multiple frames, and having the ball icon leave a trail of blue dots instead of a solid black line like the player icons have.
See below for screenshots demonstrating these changes.
Game Tab
First and foremost, we made sure that the missing "Done" button for picking players was added, and implemented an "Undo" feature by allowing the user to uncheck players that the they did not mean to check. The specific options on the Game Menu (see Choose Game Event screenshot below) were made clearer because instead of using abbreviations, we could type out entire terms on the buttons (i.e. "Rebounds" instead of "RB").
One aspect that we changed that was not specifically derived the Wizard of Oz testing was splitting up the "Shot" screen into two screens (see Shot Screen and Assits Screen screenshots below), one for tracking the player who made the shot, and another that follows for tracking the player who assisted with the shot (optional). In transferring the paper prototype into code, we realized that putting a table listing the players for the shot and the assist made the screen too cluttered. We wanted to avoid any screens that would require the user to scroll through the page since stats tracking during a game needs to be as fast as possible.
Actually coding on the iPhone allowed us to implement more error checking in our application than in the low-fidelity prototype. It also allowed us to represent the same tasks in more concise ways. For example, the substitutions screen essentially makes use of the "pick players" screen instead of prompting the user to select a player to sub out and a player to sub in. Instead, the user only has to check the 5 players he wants to be active in the game at any time. This allows the user to make multiple substitutions at once instead of clicking "Substitution" every time.
Stats Tab
The Stats tab has remained essentially unchanged. Some of the statistics that we originally planned to have in the tab have not been implemented yet due to time constraints. Also, this tab was not part of any of the tasks we had our users do when we conducted our interviews with the low fidelity prototype, so we have decided to keep it mostly unchanged.
Notes Tab
We did not significantly alter the Notes tab as a result of our low-fidelity user testing as no major concerns were brought up. The one important change was the inclusion of an edit button when viewing a note (see screenshot of Viewing a Note below), which we realized we left out of our low-fidelity prototype when a user wanted to edit a note during testing. Another minor change was to the layout and involved putting the information when viewing a note into a table view instead of a plain view with labels. This was done to stay more consistent with other areas of our application and to take advantage of the table view's built-in scrolling and layout functionality. Finally, another small change was putting notes' dates under the titles in the note list as that is the default, and thus expected, behavior of table cells in the iPhone OS.
Prototype Overview
Playbook Tab
Overview
The Playbook tab has three main parts: the play list screen (see List of Saved Plays screenshot below), the drawing screen (see creating and saving play screenshots below), and the viewing screen (see Viewing a Play screenshot below). On selection of the tab, the user is first presented with the play list screen, where the user can find his/her plays listed by name in a single, scrollable table. From here, a user can either hit the "new" button to go to the drawing screen and create a play, or can select a previously-made play from the table to go to the viewing screen and see how it looks. In the drawing screen, initially the players and ball icons are presented in a default layout near the bottom of the screen, and the user is allowed to denote the initial positions of the players for the play. This first step is then saved, and the user is then allowed to move the players/ball to new positions, drawing paths along their trails. The user can then either keep adding more steps to the play or hit the "save" button at any time to stop the creation process, where a prompt appears asking the user to name the play or hit "cancel" to keep creating. In the viewing screen, the initial position of the players are presented, and the user can use the buttons on the bottom navigation bar to step through and see all of the frames for that specific play. When finished viewing, the user can simply hit the "done" button to be taken back to the table screen.
What Was Left Out
Although essentially all of our desired functionality was implemented, there were three main features that we were not able to include. While viewing a play, the user does not have the ability to continue adding steps after the last step nor the ability to insert new frames or delete them. Lastly, we were not able to include full-scale animation, where clicking on the "next frame" button in the viewing screen would cause the markers to move along their drawn paths.
Wizard of Oz Techniques
No Wizard of Oz techniques were used in the Playbook tab as essentially all of the desired functionality for this tab was included in the interactive prototype.
Use of External Code
A significant portion of the code was based on a game previously made by one of our group members. Some of it was also based on the painting application made for individual programming assignment 3. Also, some parts of the code were based on online tutorials.
- Art178GameAssignment2-JonathanHirschberg
- plist persistent data storage for saved plays: iphonedevbook.com, chapter 11
- toolbar with navigation controller for drawing or viewing plays: http://www.iphonesdkarticles.com/2008/09/navigation-controller-uitoolbar.html, http://www.iphonedevsdk.com/forum/iphone-sdk-development/2071-hide-fade-out-toolbar.html
Game Tab
Overview
The logic of screens within the Game tab follows closely with the flow chart made during the low-fidelity prototype phase. The main screen consists of two buttons, New Game, and Edit Roster (see Game Screen screenshot below). If the user wants to start a New Game and the roster does not yet have five players on it, he will be prompted to first create/complete his roster (Editing the Roster screenshot below). Otherwise, he will be prompted to select five starting players to put in the game (Choosing Starters or Substitutions screenshot below). From there, the user can record shots, assists (within the shots screen), rebounds, fouls, successful and failed plays, and substitute players in and out of the game (see remaining Game Tab screenshots below). Substitutions are reflected in all of the other stats-recording screens, which always display an up-to-date list of current players in the game that stats can be applied to.
What Was Left Out
Some of the users that we interviewed had expressed that in the game screens a "Done" button would be redundant and that a back button would suffice. We have chosen to leave out their suggestions in our interactive prototype and continue with the design we had in our low-fidelity prototype. Our reasoning was that a back button could be used to go to the previous screen to change any errors that the user might have made on that screen, while a done button would permanently save the information. Also, this functionality would be most useful in the shot made and assists screens, which we have changed since testing our design with users. Originally, the user would choose both who made the shot, and who assisted on the same screen. However, due to technical limitations and user suggestions, we split that screen into two separate screens for the interactive prototype. In these screens, the user would first choose who made the shot. He would then be taken to the screen to choose who assisted. If the user made a mistake on who made the shot, he would be able to use the back button on the assist screen to choose the correct shooter, and nothing would be committed until pressing done on the assist screen.
Wizard of Oz Techniques
No Wizard of Oz techniques were used in the Game tab as all of the desired functionality was included in this interactive prototype.
Use of External Code
No external code was used in the Game tab, but the iPhone SDK was heavily referenced.
Stats Tab
Overview
The Stats tab allows a user to view statistics on particular players. The screens essentially mirror our design from the low fidelity prototype (see two screenshots below). First the user will be led to a page listing the team's entire roster. The user will then be able to select a player, which brings up another screen showing the statistics of that player.
What Was Left Out
Our application does collect information on play success and failure, but these are not currently displayed in the Stats tab, and were not included in our low fidelity prototype as well. Also, some of the statistics that we originally planned to display in the statistics screen have not been implemented yet due to time constraints.
Wizard of Oz Techniques
No Wizard of Oz techniques were used in the Stats tab as all the desired functionality was included in this interactive prototype.
Use of External Code
No external code was used in the Stats tab.
Notes Tab
Overview
The Notes tab contains three main views: one for listing all notes, one for viewing a note, and one for creating/editing a note (see screenshots below). The interface follows a common pattern in iPhone user interfaces, which can be seen in applications such as Contacts. The main view, where all notes are listed, shows their titles and dates, and allows deleting notes in the edit mode. The single note view shows what the user wrote in the note, along with a back button and an edit button. Finally, the create/edit view allows a user to add a note's text and title and save the note.
What Was Left Out
A new feature suggested in a few of our low-fidelity tests was the addition of folders to put notes in. While we liked this suggestion, we wanted to focus on improving the existing aspects of our application before adding new features and thus turned our attention to the playbook and game tabs instead. We intend to implement folders for notes in a future iteration of our application.
Another feature that we were considering was allowing users to set a date for notes instead of defaulting to the current date. While we may add this feature in the future, we again decided to not implement it in this iteration in favor of improving the other parts of the application because the amount of work to add it would be disproportionate to its benefits.
Wizard of Oz Techniques
No Wizard of Oz techniques were used in the Notes tab as all of the desired functionality was included in this interactive prototype.
Use of External Code
A short bit of code written by Apple in their UICatalog tutorial was used for displaying a text field in a table cell in the edit note view.
Other Credits
Two of the tab icons are from the http://glyphish.com/ icon set.
All of the images in the playbook tab were made by Jordan using Adobe Photoshop.
