TAK+-+Design

Original Designs:

Victor's Design: Paper, Balsamiq

Mark's Design: Paper, Balsamiq

Michael's Design: Paper, Balsamiq

Meeting Overview:

A typical user of our software needs to be able to sign in and out, sign up, search for commands, add commands, and edit previously existing commands. We've been using a piece of software called Pivotal Tracker to keep track of these requirements and make sure we're including them in our plans for the site.



Our mock-ups involved these capabilities in different formats with different interfaces, though for the most part, the basic structure of site use was the same in all of them (we had a rough design drawn up from fairly early on in the project, so this may, unfortunately, have engendered a higher level of similarity between our designs than we might have otherwise had). We our interface ideas for our final mock-up: some menus items were added, simplified, or rearranged. We decided it made more sense not to have sign-in page, but a dropdown. We decided to consolidate all header/footer menu items into a sign-in header menu and an "everything else" footer menu. We decided, after some discussion, to go with separate basic and advanced search methods. Our primary goal in al decisions was to allow the user to search as specifically as possible while maintaining a dead simple interface so that any user of any level of knowledge could potentially use it.

We are still considering the potential costs and benefits of involving software and operating system versions (i.e. OS 10.7 vs. just OSX tagged with 10.7) as a basic search term. It allows for a search to be more specific, particularly useful if many shortcuts are changed or added between different versions of a piece of software, but it also adds complexity to the interface, and can be accomplished (albeit more crudely) with tagging. Whether or not to include explicit version searches, and whether to include them explicitly in all of the places they might be used or not, is an ongoing question that may only be resolvable once we have a somewhat working prototype we can use to see how often that functionality is really necessary, and how easily it can be done with tagging.

Overall, given that most of our interfaces had similar basic structure, this was a process of refinement rather than overhaul of preexisting ideas, and that process went relatively smoothly, though there are a few questions left to answer further down the line.

Final Design and Walkthrough:

A user navigating to The Any Key is immediately presented with a simple search bar, reflecting what we expect the most common user task will be.

To search TAK's command database, the user types the name of a command, and possibly additional clarifying keywords, and presses return or enter. (This is analogous to a more general-purpose search engine, and so we expect it should be intuitive.) For example, a search might be "Desaturate CS5" or "Blender Bake" or "Screenshot Mac". The need to intelligently parse the user's input makes this design somewhat ambitious.

The advanced search screen provides a more specific alternative to the basic search interface, allowing the user to explicitly enter in any details they have on the command they're looking for. If the Operating System combo box is filled with an OS already in TAK's database, the version field could populate automatically with the versions known. The version box for a selected program would behave the same way.

This sort of search results window will be presented after either an advanced or basic search, and presents most of the advanced search options for refining the search criteria. To refine a search, the user would enter additional information into the Search Details form, which will be pre-populated with the search criteria that produced this page, and press return or enter. As TAK is supporting users who are trying to improve their productivity with keyboard shortcuts, the search details form will be entirely keyboard-navigable and operable. This may require that the combo boxes for operating system, program, and their respective version boxes be able to autocomplete by matching partial input to known possible values.



This screen displays details about a particular command entry, showing all data we have on it, and would be navigated to by clicking on one of the command entry boxes on a search results menu. At this point, we are limiting our design to what we think is the bare essential data on each command, but may add further details at a later stage. Users have an easily-visible edit button, which will take them to a command-editing screen very similar to the command-adding screen. (Neither are pictured in this design, as we chose to focus on what we expect are the most common use cases for TAK). We expect that users will need to sign in to edit or add commands to our database, allowing easier revision-tracking and reducing vandalism potential. Rather than making a distinct sign-up or sign-in page, these elements are, in this design, overlays that pop up over the current page when the corresponding button is clicked, or a user clicks on an edit or add button without already being logged in. For simplicity, we are not at this time expecting to allow unregistered users to create or modify command entries.

A Use Story: A user searches for a keyboard shortcut in their favorite video-editing software, but TAK returns no results for their search. After locating the information in the program's manual, the user returns to TAK and clicks the "Add A Command" link present at the bottom of ever page, sending them to the screen below, which they use to enter the command for other users to find.