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.
...
| Wiki Markup |
|---|
{html} |
...
<STYLE mce_bogus="1" |
...
> .pagetree2 a{font-size:16px; } |
...
</STYLE>{html} |
...
| Wiki Markup |
|---|
{pagetree2:BioMate} |
...
Click
...
on
...
a
...
page
...
above
...
for
...
a
...
specific
...
section.
General comments
Note on modified design objectives
We have modified our design objectives since GR1 so as to not address the objective of having lab bench biologists communicate the results of their analysis to computational biologists. This was done mostly out of feasibility concerns, as further needfinding revealed that email and instant messaging is the primary method of communicating results between biologists and lab-bench biologists, and we could not think of a system that we could realistically implement in addition to our other design goals which would serve better than email for communicating results. We considered the option of having lab-bench biologists upload the results of running a script to the system, but then ruled this out as the results of computations in the Boyer lab are usually too bulky for upload to be feasible.
Comment on safety regarding file paths
One shortcoming of our design is that it does not guarantee that the paths to files will be correct. In our needfinding, we found that lab bench biologists had a good grasp of relative vs. absolute paths and were meticulous about ensuring they were in the appropriate directory before supplying file paths, so the issue of checking file paths is not of high priority. However, it should be noted that the current command-line interface that lab bench biologists use does not inherently provide this safety guarantee either, and it is hoped that the computational biologist would program the script to fail gracefully if an incorrect file path is supplied. It is also hoped that in constructing the command, the computational biologist provides an absolute path to their script (so in our storyboards below, "montecarlo.pl" should really be "/home/Xing/montecarlo.pl").
Comment regarding SSH
It is true that our current design required lab bench biologists to SSH into a server themselves. However, most lab bench biologists at the Boyer lab use SecureCRT which can bookmark servers that have been SSH'd into in the past, meaning that once the lab bench biologist has successfully SSH'd into a server, they would not have to enter the SSH command into a terminal the next time they wish to log on. Thus, the task of SSH'ing into a server did not surface in our needfinding.
Comment regarding output in a terminal vs. output in a file
In the storyboard below, the output for montecarlo.pl appears in the terminal itself. It is true that this might confuse lab bench biologists who are expecting the output to appear in an output file. However, we think it is important to give computational biologists the freedom to have their output appear in either an outputfile or in the terminal, which is why we allow computational biologists to make Notes on their scripts which the lab bench biologist can then view (so, for example, a possible note on montecarlo.pl from a computational biologist might be 'the output for this command appears in the terminal window itself; contact me if you would like it to be written to a file').
Scenario
Our scenario involves a lab-bench biologist Vineeta who seeks to run an experiment using a script written by Xing, a computational biologist.
- Vineeta tells Xing that she needs some help analyzing her data, so Xing agreees to share a Monte Carlo simulation script with her that he wrote for this type of data analysis
- Xing uses BioMate to create an interface for his Monte Carlo script.
- Xing shares his script with Vineeta on BioMate
- Vineeta contacts Xing again saying that she wants to be able to specify the number of iterations for the simulation when running the script (she does this using email)
- Xing edits his Monte Carlo script interface to provide the ability to modify the number of iterations
- Vineeta accesses the updated script through BioMate and obtains the command she needs
- Vineeta 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, Vineeta 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.
Individual Design Sketches
Sumaiya
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.
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.
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.
Rebecca
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. 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.
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.
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.
Avanti
Design 1
This design reflects the programmer-facing portion of the UI. It involves constructing the command line using "chunks" of the command at a time, and is inspiration for the programmer-facing part of storyboard 3.
Design 2
This design reflects the lab-bench-biologist-facing portion of the UI. It separates the required parameters, optional parameters and the flags, and provides an autocomplete-based history for ever individual parameter. It also allows one to save a combination of flags or save all the parameter settings as a whole.
Design 3
This design depicts the login screen and the landing page for an interface designed to be used on a mobile. Buttons are large and clickable, and relatively few options are presented on a given page.
Michael
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.
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.
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.
Storyboard
Design One
Storyboard
Design Overview
Design One provides specialized interfaces for each userclass. It uses a desktop metaphor with big icons for all the important tasks which facilitate learning by doing. The design supports script level notes and history. 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. The on-the-fly updating of command line can increase the learning curve of the lab-bench biologists and the preview of script interface might help computational biologists to locate any error at the script interface generation phase.
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.
Usability Analysis
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.
- 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.
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.
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.
- 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 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 on-the-fly updating of the command line feature could improve safety in cases where lab-bench biologists become sufficiently familiar with a script to recognize errors in the command.
Design Two
Storyboard
Design Overview
Design Two provides a common interface for both computational biologists and lab-bench biologists. It presents a personalized, ready-to-use list of scripts in a table format reminiscent of Dropbox, so the interface is easily learnable. It supports script-level notes and history. Sharing of notes and feedback is done via email. Computational biologists need to fill in a table of parameters to generate the script, which is useful when the script has lots of parameters.
Overall, Design Two focuses on providing a very streamlined, no-frills interface for both computational biologists and lab-bench biologists.
Usability Analysis
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. 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.
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.
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)
- There are some safety issues with requiring the lab-bench biologist to copy and paste the command into their terminal. For example, if they only specified a relative path for input and output files when constructing the command, then it matters which directory they run from on the terminal.
Design Three
Storyboard
Design Overview
Design Three uses a common action wheel for both the user classes containing clearly visible buttons for important tasks. This design enables computational biologist to generate the script interface without providing the command format. Script interface generation is directed by a series of steps which can be learned by doing easily. This design supports parameter level notes and history and sharing of notes and feedback among users via contacts and messaging system. The design also illustrates the autocomplete from history feature explicitly.
Overall Design Three focuses on providing a more interactive and efficient to use interface for both the user classes.
Usability Analysis
Learnability
- The action wheel with big buttons makes the tasks easily visible to the users which increases the scope for learning by doing.
- The interface for building up a command using ‘chunks’ of static text, parameters and flags is novel and therefore has little external consistency, which might hurt 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.
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.
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.