Project Home

Scenario

The MIT men's varsity volleyball team is 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 is designed mainly for a tablet. There is a diagram of the court that includes the players that are currently in the match or on bench. Their position on the court indicates from where they hit their last shot. When a new shot is made, the user can drag the appropriate player to the hitting location, double tap to select that player, draw a line indicating the direction of the shot, input more information about the shot, and submit. A table that keeps track of top players is dynamically maintained. Additionally, as the game progresses, a heat map will be drawn on the court to indicate the locations at which shots are frequently made. It was only drawn on one side for clarity.

This interface is designed for a small screen. There is not enough space to keep a large court with each player's position, so a small court is kept instead. When a player makes a shot, that player can be selected from the scroll menus for each time and information can be input about the shot. 

This interface is focused on improving efficiency by being able to record the information about one shot with a simple swipe. In the drawing, player 7 made a block touch that went out of bounds.

This interface seeks to provide as much context as possible for each recorded shot. The screen is taken up by a live video of the match. Whenever a shot is made, the recorder can tap on the location of the shot, input some more data about it, and submit it.

This interface tries to improve efficiency by allowing the recorder to input data through voice commands. On the screen, the best guess about what the voice command said will appear, and the user can make edits to it before submitting just in case the application did not correctly interpret what was said.

This interface attempts to take advantage of drawing as a potential input tool. Whenever a shot is made, the corresponding player can be selected from the numbered boxes, the direction of the shot can be drawn on the court, and more information about the shot, such as what type of shot it was, can be drawn into the drawing boxes. When a substitution is to be made, the user can long press on a player to reveal a pop up menu of players that could replace the outgoing player.

This interface focuses on allowing the user to efficiently input shot data while receiving visual feedback about what has been done. In the sketch, an ace is being input, as can be seen on the diagram at the top, and the menu at the bottom allows for selection of the player who made the shot. After this is done, more data about the shot, such as how much power went into it, can be input.

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”.

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 (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.

• 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.