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 lab-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.

Click on a page above for a specific section.

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.).

Implementation

Front End

We implemented the front end of our interface using Javascript and HTML/CSS. We relied heavily on two external libraries: Twitter Bootstrap and JQuery. In particular, we used Bootstrap features such as modal popups and tooltips, as well as built-in Bootstrap layout and styles in order to keep our interface consistent throughout all screens.

Back End

The back end of our interface was implemented using Parse. We decided to use Parse since we would not need to write any server-side code or maintain a database server – Parse handles all server-side code. Parse also has several very useful features including a built-in User class for managing user accounts, password reset, and everything associated with a secure user session. Parse also has a feature for dynamically sending emails to user-specified email addresses, which we found useful for implementing sharing scripts.

As mentioned above, we used the built-in Parse.User class to manage user sessions and secure login. In addition, we created a set of Parse classes in order to encapsulate interaction with the back end and separate it from our UI elements. The major classes we created were:

• Script: This is the main class holding all script data including the name, owner, and list of parameters and static text comprising the command
• UserScript: This class is used to implement sharing scripts. Whenever a script is shared with a particular user, an instance of UserScript is created.
• History: This class stores the script access history for each user. Whenever a user creates/edits a script or uses the script to generate a command, we add an instance of this class.
• Note: This class stores user-created notes on particular scripts.
• SavedScriptParams: This class stores the set of parameter values a user has saved for a particular run of a script.

Each class has instance-level methods to edit or delete a particular instance of the class, as well as class-level methods to create a new instance or select a set of objects matching certain criteria.

We implemented automated email sharing of scripts using Mailgun-Parse Cloud, which is another feature available through Parse. When the owner of a script decides to share it with others, they specify a set of email addresses, and a link containing the script id is automatically sent to those addresses. Any user with the link can then log into BioMate and access the script. We decided to add a “UserScript” instance at the point when the user logs in (rather than at the point the owner clicks "Share") to facilitate sharing, since the script owner may want to share the script with a panlist or with someone who does not yet have a BioMate account. Additionally, we have found that existing applications such as Google Docs already use this paradigm, and external consistency is a desirable feature.

Evaluation

We performed our user test by briefing each user with a scenario and asking them to perform certain tasks using our interface. We found our users in a biology lab at MIT that collaborates heavily with computational biologists, which we expect to be our target user population. In total we tested two lab-bench biologists from this lab, as well as one computational biologist also affiliated with the lab. Below is the briefing we gave our users:

Scenario for the lab bench biologist

Av has made a graphical interface on BioMate for you that will allow you to use the tophat/cufflinks script more easily (this is a script that members of the lab are already familiar with). The interface will allow you to specify what your inputs and options are, and then press a button to generate the correct command-line syntax for the tophat/cufflinks script, which you can then cut and paste into the terminal.

Tasks

1. Open your email and access the link from BioMate.
2. Find your way to the interface that Av made for you.
3. Generate a command for tophat/cufflinks. For the purpose of this user test, imagine you have an input file already on the server (stored in whatever location you like and named whatever you like). You want the job to execute relatively quickly, so use 7 processors instead of the default 4.
4. Imagine you cut and paste the command into the terminal, and the job is running. You would like to record the command you just launched for future reference. Make a note to document the command you launched and the date.
5. You would like to come back to this later. Save your parameter settings and log out.
6. A new day! Log back in and access the script again. This time, access it via your history.

Scenario for the the computational biologist

There is a utility called intersectBed on the server that can be used to intersect two files in the bed format. Command-line help for this command can be obtained by logging into the server and typing 'intersectBed'. A lab bench biologist would like to intersect two bed files on the server. Your task is to use BioMate to create an interface that will allow the lab bench biologist to specify the input files and the options. The lab bench biologist will then press a button labeled "generate command" to generate the correct command line syntax for the job they want to run.

Tasks

1. Create an account on BioMate and log in
2. Make a new interface for the intersectBed command. As a reminder, the syntax for intersectBed is:
   intersectBed [options] -a file1 -b file2
   You should support the following options (you can read about the options by typing intersectBed into the terminal):
   -u
   -wa
   -wb
   optionally writing the results (which by default appear in the terminal) to an output file. Because intersectBed does not support writing to an output file, you will have to do this using "> [name of output file]".
3. Inform the user that if one file is much bigger than the other, then the smaller file should be -b so as to optimize the running. Also warn the user not to have a very big file for -b as it would crash the server.
4. Save your creation
5. Find a way to view the script as it would appear to the lab bench biologist. Make any changes as you desire, then share the script with mars_ui_team@mit.edu.

Notes from Lab-Bench Biologist 1

• At first he thought his account had already been created, but then he figured out that he needed to go to “Create account”.
• Log-in didn't seem to work. He clicked on “Can't access account” and got an error saying the account didn't exist.
• He created another account with a different email address, which worked. (Perhaps there was an issue connecting with Parse the first time)
• He easily navigated to the "Use a Script" page to use the Tophat/Cufflinks script, as described in the briefing.
• The first thing he did was view the "Instructions". He said they took him a little while to understand and could be more informative.
• Then he clicked on "Load Parameters", and saw that the popup was blank.
• He looked over every tooltip first, and said they were generally unhelpful. Additionally, one of the tooltips overflowed because of a very long path name.
• He was not sure whether our interface would directly connect to the server to run the script, or just generate the command.
• He also misunderstood the input file parameter and thought we wanted him to create an input file. We told him to just pretend he already had a path to an input file he wanted to run.
• In order to find a sample file path, he ssh’d into the server and used “cd” to find the path to some input file.
• He figured out what the notes and saving parameters were for, and said they seemed useful.
• We asked him to take a look at his History from the home page. He said he found it a little confusing that the author was listed as Av, but it seemed useful.
• Some of his confusions were related to the fact that this was a test and the input/output files didn’t actually exist.
• Overall, he liked the interface and was excited to use it in the future.

Notes from Lab-Bench Biologist 2

• The email link took a little while to show up.
• She asked whether she already had an account
• She saw the notification of the shared script right after logging in, then clicked on "Use a Script" and selected the shared script correctly.
• She clicked on “Notes” first, which was blank
• Next she clicked on “Instructions”, and commented that there were “lots of instructions”. She did not read those completely.
• She gave the example path as input, indicating that example placeholder text is helpful.
• She correctly changed number of processors as specified in the briefing.
• She saved the generated command into her notes and successfully edited the note.
• She found the sign out button easily.
• She logged in again, and clicked on history to use the same script again, with no confusions.
• She did not use the tooltips because she was familiar with the parameters, but she said the tooltips are cool.
• She also mentioned that it’s clear which field the warning text refers to since it’s slightly closer to the field above rather than below 
• Overall she liked the interface and thought it was intuitive to use
• Any confusion she had she said was related to the fact that this was a test and not a real use case.

Notes from Computational Biologist 1

• He was familiar with the “intersectBED” script as specified in the briefing.
• He asked us if he already had an account with BioMate.
• He seemed a bit confused about what to put in “Alias” but figured out himself, and entered the same thing for Alias and User-friendly name
• He asked whether he can copy and paste within the command structure box.
• He clicked on “more info”, indicating that the more info button is sufficiently visible
• He copied and pasted the “input file” inside the table of the parameters, showing how the parameters table can be used for quickly updating parameters
• He did not use “Caveats” field, instead wrote warnings in the general instructions field
• At first he did not see the feedback from clicking "Save", but noticed it after saving a couple of times. He would like more visible feedback.
• The behavior of “Save As” was not what he expected. He clicked on “Save As” when he created a new script. (We expected the users to click on Save or Save and Share first.)
• Save As seems to be buggy. When the user clicked “Save As” before “Save”, sometimes none of the parameters were saved, and sometimes certain parameters or static text chunks were duplicated in strange places.
• He never used the “Use a Script” icon on the top navigation bar. He went to homepage each time and then clicked on "Use a Script"
• Did not notice that the label of a script on the Create/Edit page was editable.
• Asked, “is the only way to share a script through the Create/Edit page?” He might want to share his scripts from a list.
• He never made use of the warnings or tooltips for each parameter. He said these features seemed useful when we showed them to him, but it was not obvious from the interface what they were used for.

Usability Issues

Reflection

We found the spiral design process to be quite useful. In particular, the prototyping and user testing helped to improve our final design a lot. During paper prototyping, we did a couple of iterations and it was very easy to test the different design alternatives we had. We could incorporate suggestions from the users into our designs on the fly which was pretty useful. We felt more committed to our design once we built our computer prototype since it required a substantial amount of work to implement. But we did make revisions in our design based on the heuristic evaluations we received from our classmates.

Sometimes prototypes can oversimplify tasks and important implementation issues can be overlooked. For example, with the paper prototype we did not need to care about how the backend of the application was going to work, how we were going to save the information about users and scripts, how scripts would actually be shared etc. However, it took a substantial amount of work to implement the functionality for the final implementation.

If we were to do this project again, we would test the script sharing functionality more. We would prototype two alternatives - in app sharing vs. sharing via email (this is implemented in our current application) to see which one makes more sense for the target users. We might also like to test whether users would prefer their saved parameters to be associated with an historical run of the script rather than named saved parameters which need to be explicitly loaded. Finally, if we had more time, we would have liked to prototype different alternatives to all of the different text fields in the programmer interface (caveats, instructions, warnings, and tooltips).

And last but not the least, from the final user testing, we actually discovered how our assumptions about the behavior of “Save” and “Save As” differed from what the users expected. Our assumption was not consistent with the typical behavior of Save As in commonly used applications such as Microsoft Word. We should have been more careful about making our design consistent with users’ expectations.