24 September 2006


Complex Systems and Their Usability

When I grabbed my writing pad to jot down some notes during one of the talks yesterday, I came across notes from an elective course on sustainability I followed last October, which featured a talk on industrial ecology and complex systems by Igor Nikolic. Having heard Aaron's keynote on the KDE community being a dynamic movement, this sparked some thought I'd like to share. Be warned, it is quite a long thought, with lots of loose ends...
As a side note, you can find Igor's complete talk here, some of his definitions will be used in this post - I encourage you to read the rest of his slides as well.
There are of course a lot of definitions of the word "system", but a quite fitting one for this purpose is an interacting group. As Igor was talking about complex systems in particular, I should include the definition of "complexity" as well: a certain system property, being the inability of any formalism to fully describe the system. In other words, one way of looking at the system is not enough. This applies quite well to KDE: as Aaron said, it's not easy to describe KDE in general without mentioning at least a number of activities or key ideas. Of course, Aaron's term of choice ("community") is a reasonably well-fitting name, but it's very broad itself. This will most likely hold for many similar projects.
There are lots of other system properties and I want to mention a couple here. The first is adaptiveness, the idea that a system has a tendency to change towards a fit state. What state exactly, can (and probably will) change from time to time, so a proper adaptive system is changing continuously.
The second one is instability. This might seem like a negative property, but is actually a very important one. Basically, instability means that when an action is taken within the system, the resulting situation is different depending on the specific time and place that action is done. This boils down to the butterfly effect.
Next, related to instability, we have context-dependency. It is not only what is done that affects the system, it is also the "when" and "where" that are important. Or to put it differently, not every action makes sense in every situation.
The last property I'd like to include here is self-similarity: different problems are often approached and solved in a common way. We can see this in KDE where more and more code is going into libraries, which is then used in totally different applications which just wrap their specific needs around it.
Now, leaving the theoretical stuff, a couple of questions which I came up with. For example, take adaptiveness. In my opinion the KDE project is quite adaptive. Goals and applications are changing, we are getting really well organised, and last but not least, more and more attention is being paid to usability and accessibility. A very good thing, but still there are some issues to be resolved there.
For example, imagine an application that is starting to become mature - let's call it KPainter, just to give it a name. It has a group of users, which are more or less used to its interface and behaviour. Its developers want KPainter to follow the rest of KDE, which means some of the very specific behaviour and interface has to be changed. Just changing stuff is not really an option since this may scare users away, and will most likely only have KPainter roughly comply with the rest.
This is were usability and guidelines come in and this is where the real thought lies that I mentioned at the start of this post. How can we adapt KPainter to comply with our ideals on usability and user interfaces, while keeping the original behaviour and codebase? Of course we want to make sure that the people currently using KPainter will keep using it in the next, adapted version. On the other hand, we want to gain as many users as possible with our next version.
Basically, this is an issue with every highly dynamic system (what I consider KDE to be). However, an extra complication in our case might be that we are a very broad project with a lot of interdependent and changing subprojects, so there is quite a lot of group dynamics involved as well. I will leave discussing that part to experts in that field, though, and concentrate on user interface thoughts here.
Back to KPainter: we want to improve its usability without degrading user experience for those people that just want to work with it as it used to be. This is difficult matter, since it involves knowing what your users want (and who your users are, cf. Ellen Reitmayr's talk) and being aware of how your program is perceived. This means a lot of work which normal developers usually do not do, either because of time constraints or because they are not familiar with the concepts needed. It looks like it is time to reinforce the usability group...
To wrap things up a bit: yes, I am aware that this post is vague and it might make more sense when I give it some more thought. I'm planning to talk to some people during aKademy, and might post a followup later. For now, it seems that I've just pointed out that KDE is doing great, but that we might need to pay more attention to getting our usability and UI research done... I'll go into details later, this post is way too long already anyway :)

Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?