Scenario
The MIT men's varsity volleyball team has a big game coming up against Harvard. We have statistics regarding each team and these allow the MIT coaches to develop some strategies. However, previously unobserved tendencies are likely to arise during the match. Assistant coaches need to efficiently record what is going on during the game and analyze this data so that the coach can make important tactical decisions. They will use SETistics, which will allow them to effectively maintain and visualize gameplay data. This is an extremely valuable resource as the coaches decide what strategic shifts they should make during the game in order to maximize chances of winning. After the match is over, the recorded statistics may be used to develop tactics for future playis playing against Harvard. Our assistant coaches are on the sidelines recording everything that happens in the game. They need to be able to do this efficiently because of the fast pace of a volleyball match. For example, during one volley, they might need to record that an MIT player on the back-left corner of the court set a ball to another MIT player on the front-middle of the court, who then powerfully spiked the ball into the back-right corner of Harvard's side of the court. Using SETistics will allow them to record this information as efficiently as possible.
A rough timeline for this scenario includes inputting, reviewing/editing, and submitting the information for the current volley.
Design Sketches
One possibility for stat recording is to build a command line tool. Once users know how it works, they can be extremely fast at inputting data. As shown in the picture, there are commands to start recording for a new game, to add the information about a shot, and to view the highest scoring players. In a real version, there would also be commands to undo and to view aggregate stats over many games.
...
This interface focuses on a fusion between a command line approach and a drawing approach. Information about shots can be input into the text field at the bottom and their direction can be drawn onto the onscreen court. After shots are input into the system, they go into one of the rows on the right side of the screen. If an error was made, the user can cancel that entry and redo it. Furthermore, a video of the game is being kept, as shown in the top left corner of the screen. This allows for each shot that is input to be mapped to a portion of the video, which allows users to better contextualize the recorded statistics.
Storyboard Designs 
The game is underway and the next serve goes to MIT’s number 50. As soon as the ball leaves his hands, the recorder is already halfway done recording the hit, entering the command representing the unsuccessful serve out of the court’s bounds on Harvard’s end. As soon as he begins typing, the controller interprets his instruction, updating the display of the translated command into its real-time visualization next to the command prompt (displayed in the crossed boxes). Finishing his command, he presses enter to add the translated statistic to the command stack and starts preparing for the next serve. An issue has come up, however: in the process of inserting commands the user didn’t realize that Harvard’s server was the player responsible for serving the previous out of bounds case. Thanks to the slightly delayed display of the game (as recorded via the user’s external camera) the user notices the discrepancy and presses the F4 key to edit the corresponding value in the command stack. As soon as he hits enter, focus returns back to the command prompt, allowing him continue tying efficiently and record the stats.
- Learnability: While this design excels in its efficiency, it lacks in its learnability. The learning curve for understanding and recalling each of the commands is high, requiring the user to have an extensive knowledge about volleyball and a strong familiarity with the interface and its commands. To address this, an Information section is to be included, providing a tutorial on how to use the interface and documentation of the commands and their parameters.
- Efficiency: In designing these interfaces it is crucial that they be efficient given the pace of the game. This design has the potential to be one of the most efficient and is based on current implementations. As a command interface, this design focuses on cutting the time it takes to record a play, abbreviating statistics such as “kill” or “block” with one or two letter representations.
- Safety: Given the amount of statistics being recorded at such a high pace, the possibility of the user making mistakes is unavoidable. This design attempts to apply preventative safety measures by displaying the translation of the command in real time to the right of the command line (circled images displaying a visual representation of what has been typed). In the instance that a mistake is made despite this the user has one of two options: they can press a function key/double click on a cell to edit it with minimal loss of efficiency, or they can click on the cell to mark it as incorrect. In the instance that the user misses a necessary stat, they can use video footage as a reference to what recently occurred.
As the game starts, the Stat taker gets prepares by opening up his phone’s SETistics app. Midway through a point, Harvard’s number 12 goes for a block, but the ball grazes his/her hand and goes out of play. Just as this happens, our Stat taker toggles the Record Button and begins speaking the statistics command “Away 50, Block Attempt, Out of Bounds”.
...
- Learnability: The learnability of this interface is high as it uses the metaphor of the actual communication between a “spotter” and “recorder”. While the best interpretation is selected by SETistics, it selects it in a picker that visibly shows other options. A picker is widely used in many applications, so external consistency should point the Stat Taker towards scrolling to the appropriate selection when an error in interpretation occurs.
- Efficiency: There is a definite trade-off in efficiency. On one hand, this interface reduces the number of Stat takers from two to one. On the other hand, it depends on the speed at which the Stat Taker’s phone/tablet can interpret commands. We hope that on average the interface will perform well enough to require few error corrections, which would increase the efficiency by allowing the Stat Taker to rapidly enter statistic after statistic without needing to stop and correct multiple errors.
- Safety: There is also a trade-off with safety. The Stat Taker is alerted to errors in the current statistic (and since the interface does not experience slips when speaking, unlike an actual “recorder”, errors will be reported at 100% accuracy) and is able to correct them by editing the selections in the picker. However, currently there is no way to go back and edit or delete already existing statistics.
MIT's player 1 just hit a powerful crosscourt spike and Harvard's player 98 was totally helpless. The stat recorder selects player 1 to indicate that a shot by that player will be entered. Then, the recorder can draw the ball's trajectory on the onscreen court and make other drawings on the pad in the top right corner to indicate, that this shot was a spike hit with considerable power that landed on the ground before any of Harvard's players could get their hands on it. As these data points are entered, icons appear in the top left corner to indicate the features of the shot that is currently being input. If a mistake is made while drawing, the recorder can easily clear out either the current drawing or one of the already processed icons (displayed as crossed boxes). At the end of this point, the Harvard coach decides to take out player 98 from the game because he is performing poorly. Long-pressing on his square brings up a menu where the recorder can select the player that will be replacing player 98 on the court.
...