...
For the initial prototypes, instead of creating a single, coherent interface for the entire application we sketched multiple possible interfaces for each of the small, specific tasks that would benefit the most from testing. We did this because we believed our most challenging issues were in the lower level interactions of inputting moves, instead of more macro-level navigation issues.
Graphical move input
We created three prototypes for inputting a single move graphically. The user was given a physical description of the intended move and would have to input that move into the interface.
Prototype 1 | Prototype 2 | Prototype 3 |
| | |
| | |
Toggle-able text buttons for each possible | A more graphical layout of toggle-able buttons | Designed with inputting joystick gestures in mind. |
Manipulating moves in a combo
We made three prototypes for the larger move-manipulation interface. Assuming that the graphical move input was a black-box, the user was given the keyboard description of the moves in the combo, would input them into the keyboard box, and was then asked to rearrange and delete some of the moves.
Prototype 1 | Prototype 2 | Prototype 3 |
| | |
| | |
The user can input using either the graphical mode with the left box | Essentially a rotation of the first prototype | Instead of both the keyboard and graphical views visible, these are |
Organizing / searching for combos
The interface for organizing and searching for combos was the spreadsheet like interface described in GR2. The user is able to click on the character tabs on the right side, and sort by clicking on the appropriate column headers.
...
Users had trouble understanding the first, table and text based move-entering prototype. Multiple testers with no fighting game experience didn't understand the idea of "quarter turns," and a tester with fighting game experience stated that he preferred the familiarity of an interface resembling a real game pad.
With the other two move-entering prototypes and both move rearrangement tasks, the main trouble users had was with the concept of multiple button moves and the use of the add button after each entering each move. Testers 2 and 3 both tried to input moves sequentially without pressing the Add button and had to change their conceptual model when only one, multi-button move resulted. Even after understanding that each of the buttons was a toggle, several users commented that pressing "Add" after each move was time consuming, especially because multi-button moves were not all that common.
Most users commented that the third move-input prototype was the visually most inviting because of its resemblence to a real fighting game controller, with one tester stating that the second move prototype was visually overwhelming because of the many buttons. However, the graphic of the joystick was not helpful. Tester 4, an experienced fighting game player, commented that he would have liked to drag the joystick graphic; users were confused because the graphic seemed to indicate an affordance for dragging, while the intent for the prototype was for users to click on the individual directions. Overall almost all testers found the move inputs to be conceptually confusing or annoyingly inefficient.
Most testers didn't have trouble figuring out the keyboard input task, although Tester 3 wasn't immediately able to find the keyboard input tab in the second move manipulation prototype. Users were annoyed again, however, with the need to press the "Add" button after each move. Because the keyboard input is faster than the button based input, some users suggested making it possible to input multiple moves in one line, maybe seperated by semicolons or commas. Users were able to rearrange and delete moves, although tester 2 stated that he would have preffered if the move icons were clearer about their deletion and rearrangement affordances.
The testers found the third sorting task to be relatively straightforward because of its similarity to conventional spreadsheet applications. While all users were able to arrive at the correct combo, they went about it in different ways. Tester 1, 3, and 5 did not notice the character tabs on the left, and either sorted the entire spreadsheet by character or needed prompting. Several testers never sorted by damage and instead selected the correct combo by inspecting the list.
Second iteration prototype:
For the second iteration, the interface was fleshed out so that the same interface could be used for all three tasks. The searching, sorting, and browsing interface remained essentially the same, except for a slight rearrangement of the character tabs on the side to make the tab-like nature of the widget and the hierarchical organization of combos more obvious.
...