...
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. 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.
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.
- Learnability: This interface was designed with efficiency as the primary consideration, so a few sacrifices had to be made in terms of learnability. It is pretty intuitive to press the current player and draw the trajectory on the onscreen volleyball court, but it will be difficult for users to remember the different types of drawings that they can make to input data about shots. In order to address this issue, users will be able to configure the system to change the default drawings if they feel that something else feels more natural for them. Also, it is not immediately obvious that a player must be long-pressed to input information about a substitution, and it is likely that this method will change in future iterations of the design.
- Efficiency: It is of paramount importance that this interface is efficient due to the fast pace of volleyball games. This design has the potential to be one of the most efficient because it only takes a few button presses and quick drawings to record a shot. These drawings are to be made extremely simple so that a recorder can input them in as little time as possible.
- Safety: Since the recorder will be inputting data at such a rapid pace, it is highly likely that errors will be made. If a wrong player is ever selected, the user can simply select another player. If the recorder makes a mistake while drawing, he can either clear the drawing or clear the icon that appeared in response to the drawing, depending on whether the system had already processed the drawing. As this design currently stands, however, there is no way to undo a statistic once it has already been submitted. One possible way of fixing this is to display the most recently entered shots and allow the recorder to edit any of them if a mistake was made.