...
- 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”.
SETistics does it best to interpret the Stat taker’s command and displays its interpretation, “Away 50, Block Attempt, Recovered” on screen and then responds verbally with its interpretation.
To the Stat Taker, it is as if he is taking the role of the “spotter” (currently, two people are necessary for taking stats; the spotter observes the game and speaks out events corresponding to statistics and the recorder physically writes down the statistic on a sheet of paper). The verbal response from SETistics mimics the way a “recorder” would respond when writing down a statistic.
The Stat taker is able to identify the error and correct it by selecting “Out of bounds” from the scrollable picker in the column where “Recovered” resides.
Finally, the Stat taker toggles the Record Button again to submit the statistic.
- 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. 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.
...