Refining for usability

		Print
		Email weblog link
		Discuss
		Blog this

Jono Bacon
Apr. 25, 2004 07:06 AM
Permalink

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, OpenOffice.org 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 freedesktop.org project.

Jono Bacon is an award-winning leading community manager, author and consultant, who has authored four books and acted as a consultant to a range of technology companies. Bacon's weblog (http://www.jonobacon.org/) is one of the widest read Open Source weblogs.

Sensible suggestions or random utterings? Chalk your thoughts below...
You must be logged in to the O'Reilly Network to post a comment.

Showing messages 1 through 6 of 6.

• minimalistic concept
  2004-04-29 10:53:24  20khz [Reply | View]
  
  
  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

• Converge to stable
  2004-04-28 22:31:32  *bsd [Reply | View]
  
  
  Quote:
  "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.
  
  
  
  
  

• Converge to stable
  2004-04-28 22:23:53  *bsd [Reply | View]
  
  
  Quote:
  "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!
  
  

• No problem
  2004-04-28 10:47:35  boud [Reply | View]
  
  
  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.

• GNOME already tried this
  2004-04-28 09:21:49  jdub [Reply | View]
  
  
  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'. :-)

• Twitchy Finger
  2004-04-28 08:30:24  lousyd [Reply | View]
  
  
  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.

---

Showing messages 1 through 6 of 6.

Return to weblogs.oreilly.com.