Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup
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}<STYLE>.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. access the update 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

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

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

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

h3. Avanti

h3. Michael

!maddox_sketch_1.jpg|thumbnail,border=1!

!maddox_sketch_2.jpg|thumbnail,border=1!

!maddox_sketch_3.jpg|thumbnail,border=1!

h2. Storyboard

h3. Design One

h4. Storyboard

[Design One Storyboard|BioMate Design 1 Storyboard]




h4. Analysis

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.

h5. _Learnability_

* Following the paradigm described above, 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.

* Furthermore, we propose 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 \*nix man pages. This external consistency should increase learnability for the computational biologist.

h5. _Efficiency_

* As mentioned above, 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.&nbsp;The down-side of this feature, however, is that it may be very difficult for us to implement a parser to determine which fields to present to the lab-bench biologist. It also encourages computational biologists to not bother with writing notes for each of their parameters since they can generate a working interface so quickly.

* This interface is not as efficient for a lab-bench biologist, despite its learnability. If a lab-bench biologist does not recall which folder a script 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 computational biologist with the option of previewing the corresponding view for the lab-bench biologist, hopefully reducing errors.

* The desktop metaphor provides a solid degree of safety for the lab-bench biologist because it is a familiar interface and reduces the probability of getting lostconfused in the systemby what certain commands do, or accidentally clicking on the wrong link (by virtue of using icons).
* Furthermore,The the lab-bench biologist's interface with a script providesupdates on-the-fly command feedback when they change the options orline on-the-fly as parameters forare abeing particularentered script. Of course,by the lab-bench biologist. biologistsThis wouldprovides generallyimmediate notfeedback bewhen ablethey tochange distinguishparameters, aand correnthas commandthe fromadded anbonus incorrecton commandeducating (the primary issue this system seeks to resolve\!), but thislab 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

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.