Monday, March 24, 2008

Users and User Research

I'd like to second Celeste's recent posts about user-research. Having watched KDE development fairly closely for a couple of years now I agree that it is why, despite many man-hours of development, some projects just aren't as useful as they could be.

A classic example for me is the story of my first patch to KDE. KDE's education suite includes a tool called KMPlot which takes a mathematical expression and plots it as a graph. At secondary school my teachers used a similar program called OmniGraph heavily. Aside from looking and feeling somewhat dated it had a raft of minor irritations which could easily be fixed with access to the code.

I wanted something similar to help with assignments at home and I found KMPlot (KDE 3.4x). I fired it up and entered a simple equation:

y = sin(x)

I was met with a somewhat cryptic error. It turns out that KMPlot required equations to be defined as named functions ( name(x) = expression ). Children at secondary schools in England don't learn about these until A-Levels, 4 years after they start playing with graphs. Whoops! My first patch fixed this by accepting "y = expression" equations and then re-writing them internally.

A more signficant problem was the interface design. A common use of OmniGraph was for teachers to load it up on their PC in a classroom which was connected to a projector. They would then enter several related equations into OmniGraph and use laser-pointers, electronic white-board pens or wooden rulers to explain the relationships between the various equations and their graphs. This environment imposes a couple of major requirements:

  • Projected images generally have poor contrast. The equations therefore need to be displayed in a big colorful font so that they can be read at a distance by pupils in a classroom.

  • In order to compare multiple equations and their graphs, equations need to be displayed alongside their graphs.

In KDE 3.x KMPlot only showed the graphs in the main window. Equations were hidden in a separate window and were displayed only at ordinary text size. Not difficult to fix during the design stages but really hurts its use in a classroom environment. Happily KMPlot in KDE 4.x goes some way to addressing these problems - although the interface is not as clean and uncluttered as OmniGraph. On the plus side, the graph rendering is much more attractive in KMPlot.


Leo S said...

Its all about knowing the user. In your case, previous devs of KMPlot apparently didn't know about the potential users in the early grades, and didnt take them into account. I see this a lot, since I do research in accessibility issues, and there are so many papers written about accessibility software that was obviously designed by someone that's never worked with someone that has disabilities. Observing users and working with them is crucial to good design. Not beneficial, crucial.

Kevin Kofler said...

No named functions? Yet there's a sin(x) in the expression. So I guess sin(x) is introduced as something "magical"? IMHO it's not the software which was broken there...

Robert Knight said...

> So I guess sin(x) is introduced as
> something "magical"?

That might seem really obvious to you now but not to school children at the age of 13. I would also add that most of the graphs they are required to be able to draw and understand up to that point do not involve anything that "looks like" a function. Mostly linear or quadratic equations ( y = mx + c , y = ax^2 + by + c ).

You might disagree with the order in which children are taught concepts but that is the reality and if KDE doesn't meet teachers' needs then they will have to look elsewhere.

In any case, you miss the main point of my post. What I wanted to illustrate was that that developers and users had different expectations of how the software would work and the environment in which it would be used.