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.
<MCE:STYLE></MCE:STYLE><STYLE mce_bogus="1"><!--
.pagetree2 a
--></STYLE>
Click on a page above for a specific section.
Paper Prototyping
Prototype Photos
|
|
|
|
|
|
|
|
|
|
|
|
Briefing
Lab-Bench Biologist
You are a lab-bench biologist. You frequently collaborate with a computational biologist in another lab who writes scripts to analyze the data that you have generated in your lab. Sometimes you want to be able to run these scripts yourself because you want to analyze many different datasets and don’t want to bother your collaborator each time you have some new data. The problem is that you are not comfortable using a command-line interface, but your collaborator does not have time to create a fancy GUI for you to run each of their scripts.
We have provided a tool here that allows your collaborator to easily create a GUI for their script and share it with you. You will use the GUI to input the parameters that you want to run the script with. After specifying the parameters, you will be able to press a button to generate the correct command-line syntax for running the script, which you will then cut and paste into the terminal to run.
Compuational Biologist
You are a computational biologist. You frequently collaborate with lab-bench biologists in another lab and write scripts to analyze the data that they have generated in their lab. Sometimes your collaborators want to be able to run these scripts themselves because they may want to analyze many different datasets and don’t want to bother you each time they have some new data. The problem is that your collaborators are not comfortable using a command-line interface, but you do not have time to create a fancy GUI for them to run each of your scripts.
We have provided a tool here that allows you to specify the command-line structure of your script and generate a user-friendly GUI for your biologists. The biologists will use the GUI to input the parameters they want to run the script with. After specifying the parameters, the biologists will be able to press a button to generate the correct command-line syntax for using your script, which they will then cut and paste into the terminal to run.
Scenario Tasks
Lab-Bench Biologist
- You would like to run a simulation using a Monte Carlo script which has been written for you. First, find the interface for that script.
- Now, make a note for yourself saying that you are going to try running the script on the file ‘abc.txt’ in your home directory.
- Next, generate the command for the script which prints verbose output to the terminal, runs for 2000 iterations, and is run on the file ‘abc.txt.’
- You realize that the command as generated above causes the script to run for too long. Make a note for yourself saying that 2000 iterations takes too long. Also include the command you just used.
- You are leaving for the day, but would like to return to work on this tomorrow. Save your current configuration so you don’t have to input all the settings you currently have all over again when you come back.
- It’s a new day! Now, go back to the Monte Carlo script interface, but this time generate the command which does the same thing as you did yesterday except runs the script for only 100 iterations.
Computational Biologist
- Create a new interface for a Monte Carlo script you have written.
- Build the interface for the command ‘perl /home/X/montecarlo.pl [-v] <INPUT_FILE> | less’, where “-v” is a flag for verbosity and “<INPUT_FILE>” is a required parameter and specifies the file path. Make sure that the lab-bench biologist knows that this path is absolute.
- Edit the Monte Carlo script interface you just created to add an optional parameter which will allow the lab-bench biologist to specify the number of iterations the script runs for. The flag for this is “-n” and the default value should be 100.
- Make sure the lab-bench biologist is aware that this command will print its output to the terminal. Also, it should be suggested to not run the simulation for more than 10,000 iterations. Finally, add a description explaining what a Monte Carlo simulation does, and leave your contact information for the lab-bench biologist in case they require clarifications.
- Share the Monte Carlo script interface you have created with your collaborator “V”.
Observations: Monday's User Testing Session (Round 1)
Takeaways
- Most users do not notice the help buttons until they are really stuck, and sometimes not even then. Important help information should be displayed up-front.
- The interface for computational biologists is extremely hard to figure out if you don’t see the tooltips, but the task flows smoothly after the help buttons are found.
- The most helpful parts of the help buttons for the computational biologists are the examples.
- The ‘drag and drop’ in the interface for computational biologists constructing the command structure has a visible affordance.
- A ‘save as’ option for the computational biologist might be nice.
- Most users do not notice the “Browse” button if they already have a file name in mind.
- The “Notes” button on the lab-bench biologist interface could be made more noticeable.
- The people testing the lab-bench biologist interface had a very easy time. However, our scenario may have been too simple.
User Testing Descriptions
User 1 (Role: Computational Biologist)
Observations
- The name “Add/Edit Script” was effective for creating a GUI for a script, user clicked it appropriately.
- Could guess correctly the purpose of “Add Text” and “Add Parameters” button in the “Command Structure” panel
- Only noticed the “?” (help button) in front of “Alias” when unsure about the meaning, found the help message confusing, asked for clarification.
- Was confused by the “| less” part of the command we presented as part of the sample task, thought of it as a parameter first and clicked on “Add Parameters” button.
- Set the type of inputfile to “string” (we had expected the type to be set to “file”).
- Asked, “What happens when you double click on the parts in the command structure?”. This feature was not implemented for the prototype. But we plan to give the user ability to modify that part when it is double clicked.
- Was confused whether clicking “Save” will automatically save the GUI since there was no feedback (this was an error of the computer forgetting to write “saved @timestamp” onto the screen)
Feedback
- Make the help message clearer (was adjusted on the fly).
- When type “Boolean” is selected the “default” should change to drop down list since it has only two choices (our failure to do this was a computer error).
- Give feedback after clicking “Save”.
User 2 (Role: Lab-bench Biologist)
Observations
- Was clear about the goal, clicked on “Run a Script” button appropriately.
- When the GUI for “monte carlo script” was shown, was overwhelmed by the things and temporarily forgot about the task.
- Took a while to notice the “Notes” button. Once noticed, clicked correctly on it to see the notes associated with the script.
- Did not pay attention to the “Browse” button in front of the “input file” field. Typed the name of the input file instead.
Feedback
- Liked the wheel and icons in the welcome screen.
- Found the interface intuitive and quite easy to use.
User 3 (Role: Computational Biologist)
Observations
- First thought the “Construct Command” panel as a textbox and tried to type the sample command in it.
- Did not find it obvious to click on “?” for help. Wanted to see examples of what is “text” and what is “parameters”.
- Was confused about what to put in the “Prefix” field. Did not click on help. Put “-n” first, then changed it to “-100” then looked at the “Default” field and figured out what is the correct thing to do.
- Was confused about what to put in the “Alias” field. After spending some time finally clicked on “?” and found the help message helpful.
- Was not sure whether a flag is a “parameter” or “text”. First looked at help for “Add Text”, then for “Add Parameters” and figured out what to do.
- Was unsure about the type of a flag, clicked on help and was able to figure it out.
- When presented with the task of reordering the parameters, the user’s first attempt was to click on the part in the “Command Structure” panel and drag it. The user was pleasantly surprised by the fact that the parts are actually draggable.
Feedback
- Make the help icon more visible.
- Give examples of what is text and what is parameter in the context of this interface.
User 4 (Role: Lab-bench Biologist)
Observations
- Did not notice “Browse” button for input file. Typed “input.txt” into the textbox.
- When told to make notes about “1000 iterations”, remembered seeing the “notes” button in the “monte carlo” interface and could locate it appropriately.
Feedback
- Found it intuitive to use the interface.
User 5 (Role: Computational Biologist)
Observations
- Faced no trouble finding the “Add/Edit Script” button.
- Noticed the “more” button next to the instructions.
- Was confused whether to put “-” before a prefix, looked up help for examples.
- Was not sure what to put as “Prefix” for input file, looked for help.
- Found the task of dragging the parts in the command structure panel and reordering them intuitive.
Feedback
- Found the help messages wordy. The examples should be clearly visible.
- There should be a “Save As” option so that the computational biologist can create slightly different GUIs for same script.
Changes for Round 2
Changes to the interface that allows computational biologists to create a GUI
We realized users did not notice the question marks next to the fields, and thus tried to use the interface without any tooltip help (which was very difficult). We therefore made the following changes:
- Examples are now visible next to all the appropriate fields (previously, the user had to click on the question mark next to a field to get a tooltip about the field which included an example).
- The question marks (which provide tooltips) next to the fields are now in a different colour. This also applies to the interface for lab bench biologists who are running a script.
In response to a user suggesting that a “save as” option might be nice (to save slightly modified versions of a script):
- We added a “save as” button to the interface.
To improve the safety of the design by explicitly encouraging programmers to describe the caveats of the interface:
- We introduced a field labeled “caveats” and modified our test to encourage the computational biologist to supply information appropriate for a “caveats” field.
An additional safety concern was that lab-bench biologists who mount drives to the server might browse for a file on the server through their mounted drive, and thus obtain a path to a file on the server that is only meaningful in the context of a mounted drive, and not when a job is being submitted to the server directly (as is usually the case). To solve this:
- We omitted the “file” parameter type; all “files” are now strings. It is not possible to browse for a file to obtain the file path.
Changes to the interface that allow lab-bench biologists to use a GUI
Our previous test for lab-bench biologists went very smoothly and did not test very complicated tasks. We thus decided to make the scenario for lab-bench biologists more complicated so that we would get more valuable feedback. We modified our scenario as follows:
In our first iteration, a user would click on “Notes” and would be presented both with “Programmer notes” (effectively instructions for running the script) and “My notes”. In retrospect, it was not obvious that clicking on “Notes” would provide both instructions for running the script and a place to take personal notes. The Notes button was also too small. We therefore made the following changes:
- The “Notes” button was replaced with “My Notes”, it was made bigger, and clicking on it only provided the user with the notes they had taken for the script.
- Underneath the “Notes” button, there was a “Caveats/Instructions” button (note: we got rid of this button after it failed miserably in a subsequent user test; see below). Clicking on this button provided the user with what was formerly under “Programmer Notes” . The programmer’s notes were now divided into “caveats” and “instructions”.
We included important information for running the script under “caveats/instructions”, and tested whether lab-bench biologists were likely to click on this button to obtain the relevant information. - When we performed our first test of this interface on a lab-bench biologist, we found that the biologist did not notice the button at all, even after being prompted, in part because it wasn’t aligned with the “My Notes” button above it. The biologist also said he was unlikely to click on such a button. We thus decided to make information on caveats more prominent in the following ways:
- For every input field, we decided we would display caveats pertaining to the field in red (eg: “file paths must be absolute”). This would also require modifying the interface for computational biologists to include describing caveats for every individual field.
- We also decided to display caveats pertaining to the whole script in red at the top, with a button for “More”. Pressing ‘more’ would bring up the caveats that pertained to the script as a whole.
- The caveats/instructions button was now just “instructions” and aligned well with the “My Notes” button above it. Clicking on instructions still brought up a page that had both the caveats and the instructions listed.
- The popup after pressing “Generate command” now contains a “Copy to Clipboard” button.
- If a lab-bench biologist presses “save to notes” on the “generate command” popup, they are taken to their notes page and can actually see that the command has been inserted into their notes. They are then free to provide surrounding annotation for the command. This was done to improve feedback for the ‘save to notes’ command and to also improve its usefulness since one rarely saves a raw command without surrounding information on what the command did.