...
While proper labeling and the affordances of tabs of tabs help learnability, there is a lot of functionality on one screen, which may overwhelm users and hinder learnability. The ability to customize headers for the table of combos and, even more importantly, the ability to order combos by a particular header, needs to be displayed in a particularly obvious way, as these features can greatly aid users in their combo browsing. The ability to click anywhere on the row in order to navigate to a particular combo's page would also need to be obvious via immediate feedback from hovering over a row in the table with the mouse. The combo creation page has many externally consistent widgets, and the combo page itself is simplistically laid out, so most learnability issues will spawn from the main page which handles the data organization.
Efficiency:
While a hindrance to learnability, having a lot of functionality in one place enhances the efficiency of this design. This design caters heavily to the more experienced players, who would be more likely to want to track combos that they like and combos that they plan to learn in the future. The ability to favorite combos makes such combos easily accessible from a user's Favorite tab. The ability to customize headers and sort by any given header makes it easy for users to scan data based on the combo properties that matter most to them. For the combo creaters, the "My Combos" tab allows them to find and edit the combos that they have submitted easily. If the combo creater would like to clarify something about his combo in the discussion forum, or upload a tutorial video about his combo, it is accomplished quickly in this interface.
Safety:
Navigational safety is particularly good, as most information can be found on one page, so there is no need to wait for an entire refresh for many browsing functions. Most utility is a maximum of two pages of navigation away.
Forum posts made by a user will be simple to edit and delete (i.e., your post will be added to the feed immediately, and hovering over your own post will offer these two options to you.)
A combo submission safety issue (that is present in all three designs) is how to treat incorrect combo submissions. User interviews revealed that the need to mark combos as "deprecated" was something that was lacking in current forums, but we have not decided how to distinguish "deprecated" combos from "wrong" combos. Should combos that have a discussion thread consisting entirely of "This combo is wrong/useless" posts be automatically deleted or merely marked as wrong? If it is marked, should the mark be distinguishable from the "deprecated" mark? These are questions that we will have to consider in whichever design we choose to move forward with.
Design 2
The second design, geared towards mobile devices or devices with smaller screens lends itself towards simplicity in casual browsing and addition of new combos. Upon entering the app, the user is immediately presented with the option of either browsing or editing combos (the two clear task choices of Combopedia). When choosing to enter a combo, the user enters in most of the details of that combo on one screen and is then taken to a separate screen to enter in the combo itself, as combo entry can be more complicated to communicate than a simple text field or drop down menu. When choosing to browse for combos, the search is filtered first by character and then by combo type. The user is led to a list of combos which can be selected individually for more details. The individual combo page contains most combo information, with links to a demonstrative video and a discussion page.
...
It is simple to correct navigational mistakes in this interface, as there will be a back button in the same place on every page. Forum posts made by a user will be simple to edit and delete (i. e., your post will be added to the feed immediately, and hovering over your own post will offer these two options to you.) The highest safety risk is what will happen to user-submitted combos. The combo submission form will verify that all fields have been filled out, but we have not fully explored what will happen to the submitted combos in this design. We could allow the user who created the combo to delete it as they can delete their own forum posts (by hovering over it and being presented with the option to delete it via button touch.) A separate combo submission safety issue is how to treat incorrect combo submissions. User interviews revealed that the need to mark combos as "deprecated" was something that was lacking in current forums, but we have not decided how to distinguish "deprecated" combos from "wrong" combos. Should combos that have a discussion thread consisting entirely of "This combo is wrong/useless" posts be automatically deleted or merely marked as wrong? If it is marked, should the mark be distinguishable from the "deprecated" mark? These are questions that we will have to consider in whichever design we choose to move forward with.
Design 3
While a conventional table of combos allows the user to sort through the the combo space based on a single variable, a user may face more complex, multi-variable considerations when searching for combos. The third design presents a more graphical method of filtering and navigating the combo space. The interface presents three panes: two columns for filtering, and a third larger viewing area. The left most column holds all of the variables of a combo, such as the character, combo type, difficulty, xp, etc. The middle column holds the corresponding constraint on that variable; for example, the user can limit the space of combos to a single character by clicking on the appropriate cell and bringing up a drop-down menu of the available characters. The viewing area displays a list of combos fitting the constraints.
...