Page History

h1. *BioMate*

Lab-bench biologists find it difficult to use many existing tools for  their data analysis. These tools are generally command-line computer  programs written by computational biologists. Computational biologists  do not have time to create user-friendly interfaces for their programs,  and often find themselves spending a lot of time helping leb-bench  biologists run their programs. This creates a burden for all involved:  lab-bench biologists cannot move forward with their data analysis, and  computational biologists cannot move forward with their research.

{html}<MCE:STYLE mce_bogus="1"><#comment><><#comment><#comment></#comment></MCE:STYLE><STYLE mce_bogus="1"><!--
.pagetree2 a{font-size:16px; }
--></STYLE>{html}
{pagetree2:BioMate}


_Click on a page above for a specific section._


h2. Scenario

Our scenario involves a lab-bench biologist V. who seeks to run an experiment using a script written by X., a computational biologist.

# V. tells X. via e-mail that she needs to use a Monte Carlo simulation script which he wrote
# X. uses BioMate to create an interface for his Monte Carlo script.
# X. shares his script with V. on BioMate
# V. contacts X. again saying that she wants to be able to specify the number of iterations for his script
# X. edits his Monte Carlo script interface to provide the ability to modify the number of iterations
# V. accesses the updated script through BioMate and obtains the command she needs
# V. notices that 1000 iterations works well for her, so she makes a (personal) note on BioMate to remind her of this later. She saves the current configuration of this script in her history.
# Some time later, V. goes back to BioMate because she wants to run the Monte Carlo script on a different input file. She pulls up her history and views the Monte Carlo script which she previously saved. She edits the parameter she wants changed and uses the modified output provided.

h2. Individual Design Sketches

h3. Sumaiya

h5. Design 1

This design includes slightly customized homepages for our two user classes. The main tasks are organized in an action wheel. In the child pages all the options are made available in the form of a toolbar at the top. The interface for generating commands for lab-bench biologists is based on forms and scrollable panes, whereas, the interface for the computational biologists include tabbed panes and a summary panel to make their choices visible at all time.

!Sumaiya's design 1.png|thumbnail,border=1!

h5. Design 2

This design also shows customized homepages for each user class. The homepages have easily clickable big buttons for the major tasks. The child pages have traditional theme with navigation links on the left. The interfaces for both userclasses are form based but they use Ms Excel style tables to show lists, which may be useful when a computational biologist has tons of parameters to add for a script. The share option gives flexibility in sharing a script with persons both in contacts or not in contacts.


!Sumaiya's design 2.png|thumbnail,border=1!

h5. Design 3

This design is specially done for smartphone platform. The pages are not content heavy, the buttons are made big so that they can be clicked/touched easily. This interface acts in a slightly different way since, the lab-bench biologist now cannot copy paste the command directly into command line. So, the interface gives him the option to email the generated command to himself or save the command into notes. This interface lessens the burden of the computational biologist by asking for only the command format string and doing the whole task of UI generation in the backend, which of course limits flexibility in some cases.



!Sumaiya's design 3.png|thumbnail,border=1!

h3. Rebecca


h5. Design 1

This design shows how a computational biologist shares an update to one of his existing scripts. First the user right-clicks on the script and selects "Update". Then the user has the option of uploading a new script and/or editing the parameters. &nbsp;The list of parameters is pre-populated with the parameters from the previous version of the script. All fields are editable, and the user can choose to delete rows or add new rows. Finally, the user clicks "Share" to share his modifications with a lab-bench biologist.

!beccas_drawings 1.png|thumbnail,border=1!

h5. Design 2

This design shows how a lab-bench biologist sees that a new script has been shared with her. In this case, the user sees that one of the scripts shared by Z is new. Clicking on the folder, the user sees the list of scripts shared by Z with the newest script at the top. A star indicates that the script "cufflinks" has been recently added or modified. If the user clicks on cufflinks, she sees all the fields that can be edited to run this script. The fields are pre-populated with default values set by the computational biologist.

!beccas_drawings 2.png|thumbnail,border=1!

h5. Design 3

This design shows how a lab-bench biologist might see that a new script has been shared with her on her smartphone. First she gets a notification that a new script has been shared with her. Then she can go to the BioMate App, enter the parameters, and start a run of the script directly from her mobile phone.

!beccas_drawings 3.png|thumbnail,border=1!

h3. Avanti

h5. Design 1

h5. Design 2

h5. Design 3

h3. Michael

h5. Design 1

This design presents a custom landing page for lab-bench biologists. The goal is an uncluttered and minimalistic interface to present the lab-bench biologist with three options to find a script with the system: the system can be searched, or the lab-bench biologist may select from among those scripts shared directly with them by a computational biologist or those recently viewed by them.

!maddox_sketch_1.jpg|thumbnail,border=1!

h5. Design 2

This design pertains to the script interface for the lab-bench biologist. Again, the goal was an uncluttered and minimalistic interface. To this end, we have the collection of notes for this script as well as the history of times the user came to this page presented as (initially collapsed) dialog options to the upper right of the main content window. We also present a collapsible side pane which can provide direct access to the content of the landing page without having to return there. Otherwise, the parameters/options for this script may be specified in a typical form-based fashion, but of note is that the displayed command is updated dynamically as the user selects options for the script.

!maddox_sketch_2.jpg|thumbnail,border=1!

h5. Design 3

This design presents the same page as in the design above, but on a mobile phone where screen real estate is much more scarce. To handle this, instead of JavaScript drop-down tables for the notes and command history, the lab-bench biologist is presented with links which create dialog pop-ups presenting the relevant information. This will obscure the contents of the screen, but since this information is generally not needed concurrently while making edits on a script, this is most likely acceptable. Similarly, the parameters/options for this script are not entered directly using check-boxes, radio buttons, and text fields, but instead with a similar pop-up to present the options and input more clearly to the user. Finally, the real-time updated command is horizontally-scrollable.

!maddox_sketch_3.jpg|thumbnail,border=1!

h2. Storyboard

h3. Design One

h4. Storyboard

[Design One Storyboard|BioMate Design 1 Storyboard]






h4.

h4. Design Overview

{color:black}Design{color} {color:black}One pr{color}{color:black}ovides{color} {color:black}specialized interfaces for each userclass. It uses a desktop metaphor{color} {color:black}with{color} {color:black}big icons for all the importa{color}{color:black}nt tasks{color} {color:black}which{color} {color:black}facilitate{color} {color:black}{_}learning by doin{_}{color}{color:black}{_}g{_}{color}{color:black}.{color} The design supports script level notes and history.&nbsp; It is very efficient for the computational biologists since, they need to type the command format string only, the task of interface generation is done by backend. Overall, Design One focuses on providing distinct user experiences for lab-bench biologists and computational biologists. This approach can be useful if their roles tend to overlap little or not at all.

h4. Usability Analysis


h5. _Learnability_

* This design leverages a traditional desktop metaphor to simplify the interface for lab-bench biologists as much as possible. Since lab-bench biologists would often come onto BioMate searching for a particular script, this metaphor parallels what one might expect when looking for a file on a desktop computer. In this case, maintaining metaphorical consistency should increase learnability for the lab-bench biologist.

* This design proposes an automatic command parser for the computational biologist to facilitate the creation of an interface for a script. Computational biologists are very familiar with the command line and would be therefore be comfortable presenting a command to the system in a way which specifies all the options and allowed values in a single line, as is often done in unix man pages. This external consistency should increase learnability for the computational biologist.

h5. _Efficiency_

* This design allows computational biologists to directly enter the command as it would be run in the command line and have the system perform parsing for them. This is extremely efficient for the computational biologist since they have already created the script to be run in the command line and are very familiar with the syntax for doing so.

* This interface is not as efficient for a lab-bench biologist, despite its learnability. The interface enables the lab-bench biologist not to bother about the exact location of the script to run since it is provided by the computational biologist. However, he still needs to provide correct location of input file, and the interface has no support for checking whether the given location is correct or not. If a lab-bench biologist does not recall which folder an input file is stored in, it could take them a while to find it. We would probably need to incorporate some keyboard shortcuts for this interface to be efficiently used by a lab-bench biologist "power user" with a lot of experience with the system.

h5. _Safety_

* The computational biologist could easily enter a typo in their command. Since the system itself has no _a priori_ knowledge of what certain commands should be, this introduces the possibility of creating a valid interface for a script which is in fact incorrect. It is therefore important that the computational biologist verify the parameters for his or her script before submitting them. However, enforcing this may be difficult with this streamlined approach. For example, we could present
* The design incorporates a preview pane for the computational biologist with the option of previewing the corresponding view of a script interface for the lab-bench biologist, hopefully reducing errors which might help them to locate any error in the generated interface.

* The desktop metaphor provides safety for the lab-bench biologist because it is a familiar interface and reduces the probability of getting confused by what certain commands do, or accidentally clicking on the wrong link (by virtue of using icons).
* The lab-bench biologist's interface with a script updates the command line on-the-fly as parameters are being entered by the lab-bench biologist. This provides immediate feedback when they change parameters, and has the added bonus on educating the lab bench biologist about how the command line syntax is constructed. This feature could improve safety in cases where lab-bench biologists become sufficiently familiar with a script to recognize errors in the command, or when computational biologists go to test their interface for a script by previewing the view for lab-bench biologists.

h3. Design Two

h4. Storyboard

[Design Two Storyboard|BioMate Design 2 Storyboard]








h4. Analysis


Overall, Design Two focuses on providing a very streamlined, no-frills interface for both computational biologists and lab-bench biologists.

h5. _Learnability_

* The form-like interface leads to external consistency and is therefore more familiar and more easily learnable for both computational biologists and lab-bench biologists.
* Unlike Design 3, there is no step-by-step procedure associated with adding different parts of the command when sharing a new or updated script. Instead, the user must know to enter the whole command with \!\!<alias> for each of the parameters.&nbsp;This interface may be confusing at first.
* When adding parameters, certain options are grayed out depending on the category of a parameter. For example, 'required?' does not make sense for a boolean parameter. This is the downside of having a table in which all rows have the same fields.
* Lab-bench biologists and computational biologists log into the same interface. This could be confusing for lab-bench biologists who have no intention of ever creating their own program interface.
* The flip side of this is that a computational biologist may find it easier to run their own scripts with a GUI, so this could be a feature for someone who straddles both user classes.

h5. *{_}Efficiency{_}*

* Having all command parameters visible in one place makes adding a large number of parameters more efficient than design 3.
* The computational biologist specifies the command structure using a simple text field, so re-ordering parameters is very efficient
* The lab-bench biologist facing interface does not allow individual parameters to have their own notes or history. The notes are only at the level of the complete script. This could reduce efficiency since the lab-bench biologist would need to specify the field name if they are making a note about a particular field.
* This interface does not support 'contacts', which could reduce efficiency if a user cannot recall a person's email address.

h5. _Safety_

* Since the computational biologist specifies the command structure in a simple text field, they could easily have typos in their command. However, the names of the parameters must match the aliases of the supplied parameters, so there is some possibility of catching typos.
* If the computational biologist accidentally inputs whitespace under the 'prefix' field for a parameter, a warning can be displayed next to the parameter. As the parameter settings are always visible on the main screen, it is more likely that the computational biologist will notice the warning (in contrast with Design 3)

h3. Design Three

h4. Storyboard

[Design Three Storyboard|BioMate Design 3 Storyboard]









h4. Analysis


h5. _Learnability_

* The interface for building up a command using ‘chunks’ of static text, parameters and flags is novel and therefore has little external consistency, which hurts learnability.
* However, adding commands follows a workflow, which can increase learnability. Subsequent options are tailored to the previous options selected - so we don’t have the issue of greying out certain options that is faced by Design 2.
* Like design 2, lab bench biologists and computational biologists log into the same interface. This can impact learnability as lab bench biologists may be exposed to commands that they are not interested in.


h5. *{_}Efficiency{_}*



* The interface can be unwieldy for very long commands, as one cannot view all the features of every piece of the command in one place (one has to highlight a piece of the command to see the features associated with that piece).
* The lab-bench biologist facing part of the interface allows a separate command history for every individual parameter, which can be efficient if some parameters change often but other parameters are usually constant (meaning that one would only save the settings for the parameters that are usually fixed). It is also more efficient when one wants to try different combinations of parameters.
* However, the absence of a global save for all parameters (as in Design 2) means it can be tedious if you just want to rerun an old job (in design 3, the global save only applies to “settings” (or ‘flags’ for the programmer) which are the same as the booleans in design 2).
* Unlike Design 2, Design 3 offers support for the concept of “contacts”, which can aid efficiency if one cannot recall the email address of a person to share with. It is also more efficient if one wants to share the interface with multiple contacts at once.
* However, if the programmer only wants to share the interface with a single contact, it is less efficient as the programmer has to press “share” button twice (once on the main page and once on the sharing preview) in order to share a script with someone.

h5. _Safety_

* If a computational biologist accidentally inputs whitespace under the ‘prefix’ field for a parameter, this whitespace may go unnoticed and would cause problems in the syntax of the command line. A warning can be displayed if excess whitespace is found in these fields, but the computational biologist might not see the warning, especially since in this interface one has to highlight a parameter to get information on it.
* The syntax of the command is specified as the command is being constructed (contrast with Design 1 and 2, which specify the syntax in a text field that the computational biologist edits). This eliminates the issue of typos in the aliases which was faced by Design 2.