Scientific Software and UI Design

June 27th, 2008

A couple of articles came out recently regarding the quality of good UI design and since this is an area that I’m relatively passionate about, I couldn’t resist adding my voice to the mix.

Last year I did a presentation for a course I was taking on the state of user interface design in the realm of scientific software. My study was based on two papers:

Nielsen, J. and Landauer, T. K. 1993. A mathematical model of the finding of usability problems.1
Javahery, H., Seffah, A., and Radhakrishnan, T. 2004. Beyond power: making bioinformatics tools user-centered.2

To start out I asked those present to look at the user interface of a relatively popular and extremely powerful piece of software used for molecular docking. (which shall remain nameless). Those in attendance were relatively familiar with the subject matter that this software dealt with, and at least one was an expert in the field. I asked them how they would go about performing a few relatively simple tasks. No one could figure it out. The controls were non-intuitive and the interface didn’t adhere to any standard UI design principles.

I then showed them the interface to a relatively popular photo management program:

iPhotoUI.png

I then asked them how they would go about editing a photo or sending a photo to someone via email. Of course the answers where obvious to everyone. Now is this because the Apple engineers were geniuses and the scientific software developers weren’t? Of course not. You don’t write extremely powerful and useful scientific software by being dumb.

UI Design Research

In their research, Nielsen (considered by many to be the expert in usability testing), and Landauer found that you only need to test your user interface design with 5 users to find over 75% of usability problems. Just 5 users! So if it so easy to find problems in UI design, why do we still have such lousy user interfaces in scientific software? Nielsen and Landauer found that a simple model could quantify the cost to benefits ratio of usability testing. The potential payoffs are substantial:

cbRatio.png

The model basically figures in two factors:

  1. The cost of each test user
  2. The savings to be realized by improved usability (i.e. lower support costs, fewer incremental releases to fix UI problems, etc…)

Unfortunately this model breaks down in the realm of scientific software. Here is my hypothesis as to why that is and why it’s likely to continue if nothing changes:

Lee’s Scientific Software UI Hypothesis

A large portion of scientific tools have poor user interfaces due to a combination of the following factors:

  1. There is usually no funding for user interface testing.
  2. The fact is that most funding organizations aren’t interested in paying for usability testing. Consequently it doesn’t get done.

  3. Tool-based papers aren’t evaluated for good user interface design during peer review.
  4. Tool based papers (like other scientific papers) are evaluated for merit and accuracy (as they should be). They are not however evaluated based on UI design principles. Changing this alone would stop the deluge of poorly designed user interfaces in scientific software.

    (For those of you who aren’t familiar with this process, scientific papers (unlike highly-opinionated blog entries like this one) go through a process called peer-review where they are evaluated for their merit and accuracy. This (usually) helps to filter out work of lesser quality.)

  5. Most people writing these software tools either don’t know what good user interface design looks like or don’t care.
  6. In my experience I have found that there are usually two types of people designing scientific software in the life sciences field. CS grads who have lots of training in designing algorithms but usually no training in UI design, or life scientists who have neither.

    This may be an over generalization, but in my experience (and I’m a CS grad), CS grads don’t know how to design good user interfaces. It’s not our fault, these things simply aren’t taught in most CS curriculums. We can optimize O(logn^2) algorithms in our sleep but we often seem to have trouble with basic UI design principles. Either we don’t know about them or we don’t care enough to use them.

  7. There are no savings to be gained in improving the user interface.
  8. This is the big one. There is exactly one payoff for most people in the realm of scientific software (aside from altruistic ones of course), and that is publications. If I publish a paper based on a software tool with a really good and well tested UI design, it counts just as much for me as if I publish a paper based on a software tool designed by a bunch of blind monkeys. (No offense to blind monkeys intended).

Conclusion

So despite the fact that studies (peer reviewed studies mind you) have shown that only a very small number of testers are required to find usability problems, the cost to benefits ratio for scientific tools developers is still unfortunately too high to justify real user interface testing and until that changes we’re going to continue to be stuck with the quality of user interfaces that are currently typical of scientific tools.

  1. Nielsen, J. and Landauer, T. K. 1993. A mathematical model of the finding of usability problems. In Proceedings of the INTERACT ‘93 and CHI ‘93 Conference on Human Factors in Computing Systems (Amsterdam, The Netherlands, April 24 - 29, 1993). CHI ‘93. ACM, New York, NY, 206-213
  2. Javahery, H., Seffah, A., and Radhakrishnan, T. 2004. Beyond power: making bioinformatics tools user-centered. Commun. ACM 47, 11 (Nov. 2004), 58-63

3 Responses to “Scientific Software and UI Design”

  1. At

    I agree with all the points above. Concerning points 1,2,4 simply the model has to change, with funding agencies giving more weight to UIs; as they now in a multi-million $$ grant they require some standards for say the microarray data you generate or the procedures you follow generating them, they also have to require specific standards for the software (and not only standards for the UI, but also following software development practices such as documentation etc). Great part of the problem is that people deciding for bioinformatics grants in funding agencies or being PIs in funded projects have no idea on software development practices. On point 3, just think about the does-it-all graduate student that goes from the lab to grind tissue to the cube to write code (because most of the scientific software out there is one man’s story - or thesis). And for your comparison with the Apple software or any commercial software, I think it cannot stand cause there you have teams of people developing a single application, and each of the developers perfects his own little part of the software (well we have to give credit to the student which usually produces as much as 3x developers, but the final application goes over one man’s powers to achieve perfection). What I see for point 4, is that the problem is with how the whole academic system is structured, where the polished product is the paper and not the software.

  2. At

    Ntino,

    I agree with you on your depiction of the “does-it-all” graduate student, but there are plenty of examples of software created by just one person that works well AND looks good.

    I think the real problems is as you said, for most software created in an academic setting the polished product is the paper and not the software.

  3. At

    As an Industrial Design graduate turned software developer, I totally agree with your points.

    Apple is successful because they focus on industrial design which is a discipline that marries form *and* function. Both are equally important and failing at one is failing altogether.

    A problem I see in scientists is that they see designers (and the general public) as intellectual “lightweights” whose opinion is unimportant. Whenever I read comments on Slashdot about why another Apple product is inferior to Gimp/Inkscape/(insert any OSS Linux program), I know that some people will never get it.

    Yeah, they should definitely make this a new discipline, preferably as part of CS programs.

    - Nick -

Leave a Reply