You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Design 1

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.

Learnability:

The streamlined design has very good learnability, as the user is only presented with a few, clearly labeled choices per screen.  The app has many universal widgets, such as drop down menus, text entry fields, and touchable buttons that bring you to new pages of the app.  Mobile and small screen interfaces force this implementation to remain a simple as possible, which means that the user is never overwhelmed by the functionality on any given page and can easily navigate to achieve his goals.

Efficiency:

The disadvantage of smaller screen sizes is that information must be spread out over multiple screens and the user's desired information may be a few screens away from their current one.  As currently designed, if one were in the discussion page of a particular combo and then were reminded of a new combo that they wanted to enter into the system, they would have to traverse the page hierarchy back to the root (the home page) before reaching the page where they could submit a combo.

One way to streamline combo browsing that isn't shown in the diagram but would be part of this design is the addition of a search bar for combos on both the "Combo Type" page and the "Combo List" page.  With this addition, the user wouldn't be forced to navigate to the "Combo List" page and then scroll for an indefinite amount of time to find a particular combo.  If the user already had a search query in mind, he could simply perform such a search after choosing a character, which would cut down on navigation time.

Safety:

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.

When the number of unconstrained variables reaches two or less, the viewing area can be toggled into a 2D plot with points representing combos. The user can then consider the tradeoffs of certain variables - for example, difficulty versus effectiveness of the combo. Clicking on an existing point (or row in the list view) replaces the viewing area with a separate combo information interface that describes the combo, presents both the text and graphical view of the combo, and allows the user to post comments or view videos.

The user can create a new combo through a button in the list view or by clicking on the graph. Clicking on the graph creates a new combo with the variables set to the position of the click, although these can be changed numerically afterwards. The combo editing interface is similar to the one in Design 1.

Learnability:
Because the interface is not as conventional as a spreadsheet-like interface, the interface may be difficult to learn, especially depending on how the constraint setting specifically works. Adding widgets with affordances to the second column and making the points on the plot look clickable may make the interface more understandable. Because the variables will be fixed in place and listed horizontally in the first column, the user may have a clearer understanding of all of the constrainable variables than if they were listed in columns.

Efficiency:
For large complex sets of combo choices, a graphical display like a plot with multiple variables can be more efficient for picking the optimal choice than a simple list.

Safety:
The biggest error the user could make is accidentally creating a new combo by clicking on the plot; however this is easily fixed through a cancel button.

  • No labels