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

Compare with Current View Page History

« Previous Version 17 Next »

Design

Our final design focused on simplicity and learnability for lab-bench biologists and learnability and efficiency for computational biologists. One major design decision was whether to make two separate interfaces for the two user groups or to make a common interface for both. We decided to design a common interface because, the roles of our two user groups are not totally isolated and overlap in a number of tasks. We tried to make the most common task of a lab-bench biologist which is generating the command for using a script, simple, intuitive and learnable. On the other hand, we tried to design the task of creating or editing a script to be as efficient as possible since the computational biologists are efficient users of computers. We incorporated support for both keyboard and mouse actions throughout our interface (e.g. tabbing through fields, click vs enter etc.).

On the login page, we wanted to make the actions “Sign in” and “Create an account” more visible, so we used big blue buttons for them. We tried to make the placement of these buttons externally consistent with popular web applications like gmail.

The design of our landing page went through a number of revisions. The design considerations were - what actions to put in the action wheel, how the actions should be placed, how to remove ambiguity from the names of the actions, whether the labels of the actions should be hidden or displayed, what icons to use etc.

  • We decided to put the four actions in the action wheel which we found to be the most important ones based on our needfinding and user feedback from paper prototype test.
  • We placed the actions on a circular action wheel to get the advantage of proximity by Fitt’s law.
  • We followed the principle of “less is more” while choosing icons for actions.
  • We changed the name of the action “Run Script” to “Use a Script” because during paper prototype tests some users felt they would only click on a button labeled "Run Script" if the script had already been loaded. They also were confused about clicking on "Run Script" if they just wanted to access their previously saved settings for a script, and not necessarily run it.
  • We made the action buttons big and clearly labeled them so that users can get a sense of the purpose of each action right away just by looking at it. 

    We also made the “Sign out” button red with a commonly used icon and placed it at the top right corner so that, it is more visible to the users.

  • In our initial design we put only home and sign out buttons at the top navigation bar, so the user was forced to go back to home page if he wanted to perform a different action. Later we decided to include “Use a Script” and “Create/Edit a Script” actions on the top navigation bar since a computational biologist user might want to switch between them frequently. However, we did not include “Notes” and “History” because notes associated with a particular script is available on the script’s page and history is also available in the form of saved parameters.
  • The script names in the “select script” dropdown list appear in alphabetical order. We also decided to display the name of the author of a script if it was shared by someone else so that no ambiguity arises when scripts with same names but different authors exist.

  • The primary goal of a user on the page of particular script is to generate the command for using the script. So we made the “Generate Command” button big and blue.
  • The notes associated with a script is available on click on the notes button which is placed right under the name of the selected script, so that user doesn’t miss it. Also the history of runs for this particular script that the user saved is readily available on click on the “Load Parameters” button.
  • If there is a tooltip available for a particular field, a “?” icon is shown at the left of the label of that field. This setting of tooltips is quite common in web applications.
  • Warnings about different fields are shown just below the textbox associated with it. We use proximity of placement of warnings to textboxes and increased whitespace among two textboxes to give the user a sense of which warning is associated with which textbox.

When user presses the “Generate Command” button, an overlay is shown with the generated command. The user can save the generated command to his notes by hitting the “Save to Notes” button.

Note for a particular script is displayed in an editable textbox as an overlay. The user can edit inline and save right away.

Clicking on “Save Parameters” asks the user to provide a name for the configuration so that, he can load this configuration later. An alternative design may have been akin to how ms word works, in which a user would view all their save files for the script in
one place. Such an implementation would have allowed users to name their parameter settings while keeping the previous names in mind, thereby allowing them to develop naming conventions. However, we did not have time for this more complicated implementation.

Clickng "Load Parameters" allowed the user to select a previously saved parameter configuration. Note that saves within the last minute are displayed with the words "Just now", which we felt was more informative than just listing the time.

On the homepage, clicking on “My Notes” shows the user an overlay with a scrollable list with all his notes. Recently accessed notes appear on the top of the list. We also show the names of the script owners so that no ambiguity arises when two different owners have scripts with same name. The choice of overlay seemed more appropriate because it avoids unnecessary page switching.

Clicking on the “History” button on the homepage shows the user an overlay with a scrollable list of his ten most recently accessed scripts. If the user is also the owner of the script, then both “Edit” and “Use Script” options for that script is available in the list. The choice of overlay seemed more appropriate because it avoids unnecessary page switching.

As designed, the 'history' is populated only when a user pressed 'generate command', but the parameter settings that were used to generate the command are not saved. In retrospect, this would have been a good feature to implement, so we might consider incorporating it in the future.

  • No labels