Refining for usability

by Jono Bacon

As a user of free and open source software, I have a deep respect for all projects that work hard to produce free software. As a member of this community, I also feel that it is my responsibility to let these projects know when there is a bug or problem with the software; constructive criticism is often one of the biggest gifts you can give to a project, after all, we won't get anywhere if we keep telling ourselves how great we are. The purpose of this essay is to discuss a theoretical problem that has always faced free software, and is now beginning to materialise in some projects. The problem is that of refining our technology.

Contributors are the backbone of our community. We need hackers, documentation writers, sound engineers, usability testers, expo organisers, advocates and other generous participants. Without these people contributing, we would have no software, or we would have software that is significantly less feature laden and stable than we have now. The problem we are facing though is that every contributor who is getting involved with a free software project is essentially using their spare time and hard work to "scratch their own itch" and contribute the scratch to the project in question. This is not a problem per say, but the problem lies in the fact that not every personal contribution can be merged into the project. As an example, if someone wanted the clock in KDE/GNOME to be displayed in binary, they could write a patch and submit it to these projects. The patch may then be merged and added if it is good. Irrespective of the fact that 95% of the user-base may never use the feature, a patch is often rated on its technical quality and compliance; if it meets the grade it is often added.

We have a difficult decision to make here. Someone has contributed a patch that they have spent their time and effort creating, but the patch adds a feature that may detract from the general direction that the project is heading in. Do you allow the patch and possibly bloat the project up unnecessarily, or do you say no and possibly alienate a contributor? It is a difficult decision to make, and there is no clear option either way. One alternative is providing some kind of additional plugin system where these additional features can be added. This has occurred with various projects to a relative degree of success.

I think the most important aspect of running a free software project is having a sense of direction. Let us take GnomeMeeting as an example. It is quite clear from the direction of this project that there is a very definite and finite direction that the developers are pushing for. GnomeMeeting is aimed at being a light, easy to use, voice over IP application that allows you to talk with your friends and colleagues. In my experience of keeping a beady eye on the project, it seems that the direction has been rigorously followed. The result of this work is an application that is simple and easy to use.

Many would say that GnomeMeeting is a simple example; it has a fairly singular set of requirements and aims. Things get considerably more difficult to manage when you look at more expansive software projects such as KDE and GNOME. I have been involved with KDE to varying degrees over the past four or five years and I love the desktop and greatly admire the people who work on it. The one criticism I do have though is that the sense of direction in KDE seems to be flagging somewhat. As someone who cares about the direction of the project, it seems only right to share these views. The reason why I am writing this in my O'Reilly blog and not in a private email to the KDE developers is that I think some of these points can be heeded by other projects. These points are not only directed at KDE; various other projects may find this essay interesting.

The problem I have seen with KDE recently has been an overload of features that I suspect the target audience will not need. The term target audience is always an interesting concept to get clear in your head, and this concept gets considerably more difficult when you take into account the vast range of users that KDE has amassed. The problem with a project such as KDE and GNOME is that they are essentially trying to please all the users all of the time. These projects want to please those who want a simple to use desktop, those who want to configure everything imaginable, those who want to remove chunks of the desktop and many other weird and wonderful uses. The problem is that you really cannot please everyone all of the time.

Let me share an example. My dad is a Windows user. He needs his computer to write letters in Word, browse the Internet in Mozilla (I moved him over to Firefox, is next) and that is about it. My dad is very much a task-centric user. The OS and GUI to him is of unimportance; it is all strange magic that eventually gets him to the point where he is sat in front of Word - this is where he feels comfortable. The Windows control center scares him, he doesn't like options boxes, he doesn't care about themes - options are just things that may possibly break the system.

My dad is the kind of audience that I expect KDE to target. He is a novice computer user who just expects things to work. He doesn't care about half of the stuff that is present in KDE; he only needs the GUI to be able to manage his files and load his programs. The problem is that KDE is getting so feature laden that it is making the environment more complex to use. If I sat my dad in front of the KDE Control Center, I think he would give up straight away. The problem is not so much the way the KDE Control Center is designed; the tree topology works reasonably well, the problem is the sheer amount of stuff in there.

In some ways the GConf concept is a good one. Some features in GNOME may be so specific and advanced that the vast majority of people will not need to fiddle with them. The most common and basic options are available in the general configuration tools, but the more specific options are essentially stuffed somewhere in the background out of view. This is great because the target audience does not see them and is therefore not confused by them. The problem with this technique though is that you need to know obscure GConf keys to get lesser known options to work.

I feel the best option in a situation like this is to make the desktop and configuration available in a series of schemas. You could have an Easy schema that has the most common options available and removes choices that may be too advanced or are not needed by someone such as my dad. You can then have a Medium schema that satisfies those with a tweaking finger. The final option could be All, which is the current situation. The desktop would start initially in the Easy schema and if you need more options you simply change the schema. There should also be functionality to add and remove options and features from your chosen schema. This gives you the ability to tweak your desktop in the way you desire. As an example, if you don't use Konqueror, you should be able to remove its options from your schema.

This is by no means a perfect scheme and would need to be refined by people with some concrete usability experience, but this would at least improve the situation to make the desktop work in a way that is better aligned with the needs and experience of the user. The more advanced user can always make an easy desktop more advanced, but the less advanced user simply gets lost with an advanced desktop.

Just to re-iterate, I have a great deal of respect for the KDE and GNOME teams. I know many developers personally, and these comments are intended to hopefully make people think of another way of making things work. We are getting to a point with our software where the desktop is going to play a key and integral part to new users and businesses. This means not only refining the technology that we already have, but working together to meet the goals and ambitions of desktop integration with the project.

Sensible suggestions or random utterings? Chalk your thoughts below...


2004-04-28 08:30:24
Twitchy Finger
I have a twitchy finger. I'm an "advanced" user, but a lot of the stuff I really don't need to tweak, personally, and I often end up just messing something up. I'd like to have options available, but sufficiently out of sight.
2004-04-28 08:39:14
Twitchy Finger
I think this is the key. The more advanced things do need to be further out of sight. The problem is that too many options can confuse someone. It is all about a balance between the different types of user. this is where I feel a schema type of approach would be useful.
2004-04-28 09:21:49
GNOME already tried this
Dude, this path is well-beaten and understood to be a strategic failure. It was tried with Nautilus, but was removed (from the stable 1.x branch, no less), and there's many a discussion on the GNOME mailing lists documenting the pros and exhaustive cons of this approach. Fix the problem: Make your software 'just work'. :-)
2004-04-28 09:26:53
GNOME already tried this
... and lest we forget the wonderful Sawfish. Great window manager for window manager fetishists, but totally insane exponential interactions between the hundreds of exposed options, and user levels to boot. Impossible to support or fully understand.

Note also that GConf isn't GNOME's way of
"hiding options". Options in the GConf schema but not in the user interface are few and far between. We've actually taken most of that cruft out of the software itself, not just papered over it with a "dumbed-down" UI. GConf is just the mechanism behind it all.

2004-04-28 10:03:06
Twitchy Finger
Jono, this issue is what I am thought about, as well. And I've got the same idea as have 2 or 3 schemas/modes. In fact 2 modes would be easier to impelment and maintain. Finally since many of us had the same idea, it may be reasonable.

I'll try to test it one day, at least within Kexi Project.

Jaroslaw Staniek

2004-04-28 10:20:39
GNOME already tried this
When you say this approach has been tried and tested - do you mean the KDE way of shoving everything in the Control Center approach or the schema approach that I am suggesting? Sorry, I was a little unsure which approach you are referring to.
2004-04-28 10:33:08
Twitchy Finger
I have been lobbying for a particular way of fixing this for some time now. The way that I see would best fix the problem of hiding features from users is what can be found in the KDE print dialog. This is no Advanced settings dialog to alienate users from potentially great options, no user level stuff to insult the user's intelligence, it is simple a way to hide less often used options, so people like you and me with, as you put it, twitchy fingers don't happen to randomly fiddle with things that you should have really kept your hands off ;)

Not only is this good for usability, it is also something which will not need a change in the KDE APIs, as you can simply implement it into the programs individually and very simply, simply by copying the KDE Print dialog's way of doing it, which is very simple: One button to change the visibility of a container with extra options, which is off by default.

Just my ? .02 :)

..Dan // Leinir..

2004-04-28 10:33:09
GNOME already tried this
User levels, as you (amongst others) are suggesting.
2004-04-28 10:47:35
No problem
Your dad won't have any problems with KControl because he won't use it. He won't need it. He won't miss it. He will, in all probability, have a problem with certain glaring inconsistencies, like having a different key for 'previous message' in KMail and KNode, or having his distro popup Mozilla or Firefox instead of Konqueror (with its different way of doing anything), or he will notice that not every KDE app has a recent files menu entry -- but he won't notice KControl.

Complaining about configurability has become something of a fad in the last year or so, with discussions breaking out everywhere, from Slashdot to this place -- but in the end, it's not important for new users. New users care about good defaults (which is the distro's job), about consistency from one app to another and about not being made to feel like an idiot by the software they use.

2004-04-28 13:47:54
Twitchy Finger
The three levels of options is very good and being an advanced user of computer i am very much afraid to touch KDE control enter because of the vast number of options it throws at my face.
Some other suggestions would be
1)3 modes of options ( but 2 modes is good enough as 3 modes may confuse users)
2)The options are more technical in nature and wording may be improved and the options can be rephrased for easy understanding.
3)instead of a tree the normal icons used by gnome and windows would be better.
2004-04-28 15:06:11
No problem
I totally agree with you here. Average users do not fiddle with settings. Give them sane defaults, and they are happy. Average users only configure stuffs like wallpaper, winamp skin, and msn avatar, so that the desktop has its own identity. Other than that, they just want consistency from one app to another, as well as consistency from one computer to another.

There is no need to hide options from average users. For them, the options are already well hidden.

2004-04-28 17:04:25
Twitchy Finger
The problem is, there's no reason to even _have_ most of those advanced options. Why does the software need some hundreds of different behaviours (which even a small number of options will result in, given the possible combinations) ? The vast majority of options can just be cut out entirely. And that isn't "dumbing down." That's picking the one behaviour that works for everyone. You won't always be able to find that one behaviour in every case, but you can cut out the vast majority of crap out there.

You can also combine a lot of options. If you have ten options, but users almost always use only three particular combinations of those options, just make one option with three choices that selects among those three behaviours.

Another good idea is to share options where possible. Find a set of apps that all have a similar option to control a similar behaviour. Make that option something centrally configured across the whole desktop. Less total options, plus as a side benefit the desktop becomes easier to configure for both novices and power users.

Yet another idea is to identify when,where, and why particular options are used. For example, many options are things that are generally only configured once. Those options don't need to be in the same place as the options users might need to change two or three times a day. (i.e., don't put "show files as icons vs list" right next to "show hidden files" - the former a user picks once for their preferred style, the later needs to be changed a lot to filter out or display hidden files.)

KDE preferences could indeed use a lot of organizational love. The organization for most of those preferences is somewhere in /dev/null. They aren't needed. They're superfluous.

The "advanced" vs "novice" user debate is an entire myth. I'm a developer; I can work magic on code in over 20 languages to do all sorts of things. Most users can't even grok the basics of how a programming language works. Clearly I'm an advanced user of development tools. On the other hand, I fire up a word processor maybe twice a month, and I barely know how to use one. And when I do, I know the parts/features of the word processor I use like the back of my hand, and the other parts are completely alien to me. How do you decide what options are advanced and which aren't? You can't make it a desktop wide choice because users are advanced or novice in individual tasks, not with their entire computer. You can't even do it per-app because, again, it depends on which tasks in that app the user is advanced with. (I can use mail in Evolution very effectively, but I don't know jack about managing group calendars, organizing tasks, etc.)

This is one reason there are so many apps that do basically the same thing. Galeon vs Epiphany? Exact same thing, yet each is appealing to a totally different set of users. That's largely a single "option" that toggles between two different application behaviours; install Epiphany or install Galeon. KDE vs GNOME? I can make them act a lot like each other, but they're still different. If you don't like one, use the other. One single option that makes a world of difference. A lot of users love Midnight Commander. Does that mean Konquerer/Nautilus should have a ton of options to act just like MC, or like some hybrid that 3 users out of ten million prefer? No, it means the users that like MC should just use MC. Users that like whichever hybrid can use the file manager that mimics that hybrid. Try to make a file manager that works for everyone, everywhere, and you end up with a bloated confusing monstrosity that works decently for very few people. Not good.

2004-04-28 22:23:53
Converge to stable
"My dad is the kind of audience that I expect KDE to target. He is a novice computer user who just expects things to work."

That is the essence of the open source desktop's ills. It's not features or the lack thereof, it's unrefined software. Forget the feature flipping and converge to stability. Too much stuff stays broken for too long. It just has to work. The OS developers are so worried about appealing to the would be Microsoft converts that they ignore the people who have already made the switch. Make it UN*X like!

2004-04-28 22:31:32
Converge to stable
"My dad is the kind of audience that I expect KDE to target. He is a novice computer user who just expects things to work."

That is the essence of the open source desktop's ills. It's not features or the lack thereof, it's unrefined software. Forget the feature flipping and converge to stability. Too much stuff stays broken for too long. It just has to work. The OS developers are so worried about appealing to the would be Microsoft converts that they ignore the people who have already made the switch. Make it UN*X like!

Here is an example of what ails the Open source desktops:
devel1 devel2: I somehow doubt that the sucessor of arts will be simpler.
devel2 devel1: And how can you increase the complexity? Arts invented it's own IPC protocol for christs sake :-}
devel1 It needn't necessarily be more complex. I just doubt it will be simpler.
devel1 I'm convinced though it will be harder to port.
devel2 Why do you doubt that it will be simpler?
devel1 devel2: Because I don't see any of the sound zealots in KDE or Linux going for the simple.
devel2 devel1: What things do you have in mind? JACK?
devel1 They all want some massive uberframework that connects to everything and outperforms Windows.

2004-04-29 10:53:24
minimalistic concept
i personally like subj - do less things, but do them qulitatively.

kde32 is more faster than elder versions. this is a good way, and there are many possible optimizations left for kde33

2004-05-18 10:30:59
Twitchy Finger
Would this be kind of like the Profiles found in the Java environment relating to the versions of Java? You have the standard edition, the enterprise edition, the micro edition?

Or would this also be like the attributes set in X-Windows application environments with each attribute being a string made up of the application and the underlying attributes. But then this turns into a flat file, registry type of to you manipulate these things..?

2005-01-16 20:29:26
Twitchy Finger
Those options don't need to be in the same place as the options users might need to change two or three times a day. (i.e., don't put "show files as icons vs list" right next to "show hidden files" - the former a user picks once for their preferred style, the later needs to be changed a lot to filter out or display hidden files.)

This just shows how convoluted our interaction with computers has become. That someone would need to show and hide "hidden files" that many times a day. Those files are not really hidden then, are they.