Recently, our very own Fabrice Mous asked if I might write an article about usability and KDE development. At first I was hesitant, and not just because I have a lot more hacking to get done before KDE 3.4 is released (which is soon). I often get asked about usability and the Open Source process, and even I sometimes get tired of having the same old conversations over and over. I thought that this time it would be refreshing to ask someone else these questions and see what they had to say. So I arranged to meet up with several people on IRC who are involved in software usability and the KDE project. Here's what ensued...
.aseigoname { font-weight: bold; color: #000077; }
.aseigo { color: #000077; }
.janname { font-weight: bold; color: #01776D; }
.jan { color: #01776D; }
.ellenname { font-weight: bold; color: #670077; }
.ellen { color: #670077; }
.petername { font-weight: bold; color: #770049; }
.peter { color: #770049; }
.florianname { font-weight: bold; color: #017773; }
.florian { color: #017773; }
.jorgname { font-weight: bold; color: #772002; }
.jorg { color: #772002; }
.firesideheader { margin-top: 1em; }
Introductions...
Aaron:Hi everyone! Let's start with some introductions, including your name and what you do with regards to usability and KDE.
Ellen:I'm Ellen Reitmayr. and together with Jan Mühling I'm one of the maintainers of the new KDE Human Interface Guidelines
Aaron:And you run a usability firm in Germany, correct?
Jan:Yes, we run a usability firm in Germany. mostly, we do commercial stuff, like web, software, mobile, but if we have time, we spend it on Open Source projects, and mainly on KDE.
Ellen:We also run a project called OpenUsability where Open Source projects can host their software in order to get usability advice. There are a number of KDE projects hosted on OpenUsability, such as KDE PIM and Kivio.
Aaron:Aproximately how many projects in total are currently active on OpenUsability, and how many usability specialists are involved?
Jan:There are around 20 projects at the moment and perhaps 6 or 8 usability people.
Aaron:Such as yourselves ...
Ellen:Yes. This weekend, KDevelop also joined OpenUsability! 8-)
Aaron:Wow, that's a good start indeed! Who else is with us today?
Peter:I'm Peter Simonsson, and I develop Kivio (one of the applications working with OpenUsability) and Konversation. As for the usability part I mostly implement what the others tell me is good. =)
JörgI'm Joerg Hoh, and I hang around on the #kde-usability IRC channel, helped organize aKademy and am active on various KDE email lists.
Florian:I'm Florian, and I have been working for Relevantive for almost half a year and thus got in kontact with Jan, Ellen and KDE
OpenUsability.org
Aaron:It's funny you should write "in kontact", Florian, as a lot of usability work has been happening in the KDE PIM project, and i have to say that it's really starting to show in the quality of the user interface. Perhaps you could relate how it's been working out with the Kontact developers during the KDE 3.4 development cycle?
Ellen:Yes, for the KDE 3.4 release, Jan and Florian cleaned up some context menus, several of the dialogs and there is a new recipient area in the composer.
Jan:The feedback on OpenUsability shows that there is a strong interest in usability in KDE, and especially within the KDE PIM project
Aaron:How does the feedback cycle work between the usability professionals on OpenUsability and the KDE PIM developers?
Ellen:Well, we started doing some usability inspections of individual components. Based on that, we made suggestions on how to improve the usability of certain components, especially KMail. Of course, those suggestions have to be discussed - that's what we have the kdepim-usability mailing list for.
Aaron:What form do these suggestions take? Verbal descriptions, mock ups, diagrams? All of the above?
Ellen:Hm, that's still a problem. We mostly upload them to OpenUsability in PDF format, but we found that this format does not support discussions in a satisfying manner. The developers asked us to use plain text instead. But this does not support including mock-ups or screenshots. Therefore, we are working on an XML report format. The first version was released in October.
Jan:Florian is also developing a tool for card sorting, which is essential for getting proper menu names, hierachies and so on. He will make it available for use on OpenUsability.
Aaron:What exaclty is "card sorting"?
Florian:Card sorting is a means to gather information on where people expect menu entries in software, or navigation entries on websites.
Aaron:And how does it work exactly?
Florian:People are presented with cards that each have a term on them and a set of group names into which these cards should be sorted. You do this with several times with different people and, after some clustering, you get a pretty good impression about where people expect things.
Aaron:I see. So OpenUsability is not just engaging usability specialists and software developers in Open Source, it's actually creating tools and techniques that haven't previously existed, but which are sorely needed to do this work ...
Ellen:Yes, but as we lack developers for OpenUsability, there is still a lot of work to do. However, we are making progress, I think. :)
Made For Each Other
Jan:The basic idea of OpenUsability is to help developers get access to usability resources. These ressources are still lacking in Open Source development, because Open Source is attractive to developers but not yet for usability people. On the other side, usability people know very little about Open Source ... but if both can be brought together, we are very optimistic that a new way of developing Open Source can start.
Aaron:How does OpenUsability help make getting involved with Open Source projects more attractive for usability people?
Jan:As a maintainer or a developer, you can post your project on OpenUsability, thus saying: "I would like to invite you to help me improve the usability of my software." This is an important sigal, because Open Source is generally considered to be "rather interested in code". The next step is to find usability people to care for the usability part of Open Source. It seems to work ... there are more and more projects joining, and there are more usability people wanting to contribute
Aaron:Peter, as a developer, perhaps you could share some perspective from the other side of the fence here. how does something like OpenUsability change or alter the development process for you, and what sort of obstacles or challenges do you commonly see with regards to usability?
Peter:Hmm, well it hasn't changed my development process too much yet... that might be because I treat the usability inspection as a buglist.
Aaron:So it works well with the regular pace of development, if it's done during development as opposed to afterwards? This seems to be a common concern amongst developers that i speak with.. that it means huge changes and inconveniences in development
Jan:It does not necessarily have to change the development process. As a matter of fact, Open Source development is perfectly suited for integrating usability engineering principles: open communication, direct communication, "release early and often" (aka, rapid prototyping) ...
Peter:Yes, I don't see that any major changes have to be made to the development process.
Human Interface Guidelines (HIG)
Aaron:Earlier we talked about some tools coming out of OpenUsability... Along those lines, Ellen, you mentioned that you're one of the maintainers for a new set of Human Interface Guidelines (or HIG) for KDE. Now, KDE has had a fairly basic set of guidelines for quite some time...
Ellen:... yes, but there was a usability meeting at aKademy in August 2004 where we decided that a new set of guidelines is needed.
Aaron:Why was that, and what will this new set of guidelines offer?
Ellen:One reason was that we found the former guidelines lacked a number of topics as well as detailed instructions.
Jan:Since KDE still does not have enough usability resources, a HIG is a very good means to get a usage style and a consistency of usage. By defining rules and guidelines it can be assured that many usability issues are recognized and solved while doing the GUIs in the initial phase. Also, we can make developers more aware of usability issues, so that they can decide when user feedback is needed, for example.
Ellen:The goal of the new guidelines is that developers will know exactly how to implement a certain interface.
Aaron:Catching things early is certainly important as it saves a lot of repeated efforts...
Jan:Right, and it does not hurt much because in the beginning you can change things more easily without as much effort. The HIG will also be a sign to the world that KDE takes usability serious
Ellen:On the one hand, it means that more examples are required, and on the other hand we need quick references. I think one of the major problems of the GNOME HIG is that it is too excessive and therefore not readable.
Aaron:Yes, that's certainly an issue when it comes to Open Source developers, many of whom are doing this in their own spare time. Being able to quickly get answers and solutions is critical. I don't think we can expect developers to read a novel just to learn how to create a dialog properly.
Peter:I know I certainly wouldn't want to do that :)
Ellen:Yes, I think it is utopian to hope that developers will read a 500 page document. Therefore, the first thing we did was to come up with a format that allows the developer to scan important information, but also offers additional topics such as implementation notes, cross references and examples.
Aaron:Cool! It does seem odd to me that even though we have the tools to create navigationally rich content, most of the HIGs out there are massive, linear tomes. It's exciting to see these sorts of innovations occuring!
Ellen:Well, we might do a usabillity test with the usability guidelines in order to ensure they actually can be used in the proper way :)
Aaron:That makes perfect sense. Almost like an Escher drawing =)
Jörg:I think good examples in the HIG are going to be crucial.
Aaron:Why is that?
Jörg:Because then you can do a quick look and find out "how is this accomplished there". If you ask "Why should I do this?" then you really should read the styleguide (and often more literature :-)
Aaron:Knowing that many, if not most developers, will take the "copy and paste" route when it's available, it's easy to see how this approach will be valuable.
Jan:One main idea of the new HIG is to have a situation based structure: I am now needing this and that GUI, what should i consider?
Aaron:Now as i understand it, the target timeline is to have the HIG ready for the KDE 4.0 release, correct?
Ellen:Yes, that's what we are heading for.
Jan:Right, it's a huge project, but this is realistic
Aaron:It's still a ways off, which is good as there's likely a lot of work to do by the developers and usability people alike once the HIG has gone through draft revisions and is ready for Prime Time.
Jan:... and we now have the infrastructure to get all the contributors in the boat.
Aaron:At what point will contributors need to start "getting on the boat", to borrow your phrase? Once there is a draft available, or are there things KDE developers can start doing now?
Jan:The "real version" is living in cvs, but there are now some colaberation tools like mailing lists and a wiki. Many guidelines must be discussed, since it touches KDE very much. Also, there must be some testing done on these guidelines, to be sure that they actually help improve usability. KDE is a community, so we don't want to write something in the chamber, but together.
Aaron:And these discussions will take place on kde-usability-devel and kde-core-devel as necessary, I imagine?
Jan:Yes, in fact we are just about the point where we can start these discussions. The only thing will be to keep these discussions fruitful.
Looking Forward...
Aaron:I can't wait! Looking at Kontact in 3.4, it hasn't lost any functionality which seems to be a common worry for many KDE users and developers when speaking of usability. It has certainly gotten a lot more streamlined and easier to use, though. As we look to apply these same sorts of processes to more of KDE leading up to the 4.0 release in concert with the new HIG ....
Jan:With regards to Kontact and features, this is an eternal fight. But loads of functions does not necessarily lead to poor usability ...
Aaron:Ok, so let's put on our dreamer's glasses and speak of the future yet unseen. What sorts of developments, advancements and improvements do you expect to see, or want to see?
Jan:If KDE wants to apply usability, there is a way ... a rather easy way ... all we need is some initial examples of how it works, some positive stories, some developers who like to see their baby more usable, and then things will come.
Ellen:First of all, I'd like to see all of KDE more streamlined. There are still too many concepts confused with each other.
Aaron:Too many concepts confused with each other ... what do you mean by that?
Ellen:Different applications follow different usage concepts which causes inconsistency. A very simple example is the menu structure in Kontact. It was made up of a collection of individual applications, and each of them has slightly a different menu structure. For instance, there isn't a 'Find Contact' option in KAddressbook, but there is a 'Find' option in KMail.
Aaron:That makes lots of sense. Hopefully we'll see more global consistency in 4.0.
Jörg:We also should make the public make more aware of the topic of usability so everyone is looking forward to KDE 4. Then people will know "they take usability serious, I can file bug reports and they will get resolved."
Jan:Also, companies or public institutions need usable software. If they hear that KDE 4 is getting very usable, this may be one more reason to decide for KDE.
Ellen:We are working on it 8-)
Aaron:So in the end everyone wins. KDE developers get help with usability, existing KDE users get a better experience and the KDE user base grows.
Peter:Sure hope so :)
Aaron:I know that a lot of people are already looking forward to seeing advancements in the control center and Konqueror usabilty in 4.0. As a closing question, do you think that innovation in usability is realistic to expect from an open source project such as KDE?
Peter:I don't see why it shouldn't be possible.
Jan:I love to preach that Open Source is perfectly suited for innovation, especially with respect to usability. If you get developers convinced, you can change everything. Also, things can change much quicker than in traditional software development. I think that especially KDE has the perfect basic settings for usability. It's just a matter of will and of time. And it's fun ... ;-)
Aaron:Great... thanks everyone for the great discussion! See you soon on OpenUsability!
Comments
"there really are too many options, menu items and other wonderful stuff in a lot of apps."
When I first heard about Windows XP (they had the name wrong at the time, instead of 'Experience', I heard "Experienced") I thought they were going to make an OS that is more configurable, designed for people that want to be able to configure EVERY thing in the OS. When they released XP and I first saw it I thought "Wow!", simply cause it looked like you could actually skin the windows, even if it was a horribly skin (luna). After using it for about 10 seconds I realized it wasn't any more configurable than all the previous version. At the time I had never even seen a computer that wasn't running either Windows, Dos, or Mac OS.
When I started using Linux (I switched almost completely about 2 years ago in september) I used KDE. I LOVED how I could configure everything (even though I don't change about 99% of the options). Every time they release a new version of KDE I always like to go through the control center and look at EVERY option thats changed (its also a good way to see how KDE has changed in the new version).
As I've been using KDE for longer and longer I've slowly been changing more options which make me work faster. Like about 1 1/2 months ago I decided I should try to use tabs. Now I use tabs ALL the time. I never open a second Konqueror window unless I have more than about 10 tabs open in the first. Today I set Kopete's main window to be shaded and always on top, since I have a panel at the top right thats always on top (KNewsTicker :-D), I have a line of space about the size of a window's top border that is always empty unless. Now I just put my mouse in the top left area of the screen and Kopete's contact list open up, it save a good bit of space and makes it so I can get quick access to it.
> I'd like KDE to look more like the GUI in Sim City 4.
won't happen. we're talking "usable" not "appearing in the next William Shatner movie"
> KDE apps need a lot of cruft trimming from them.
yes. we're working on it.
I am looking forward to KDE 3.4... kind of. I am not new to KDE... I am use to the disorganized "start menu", the copy/paste toolbar options when you are surfing the internet with konqueror, the bloated applications...
Most of the problems in my opinion are with the actual software written for KDE... most notibly Konqueror. sigh.
I just wish the usability people would think WWOSXD.. What Would OS X Do?
I'd just hate to see KDE ending up being the Jack of all trades, and the King of none.
Or worse off, KDE becoming the King of a few trades... but each one being bloated to beat hell.
Regarding "What would OS/X do", my personal view is "too severely limit choices and flexibility in the name of limited usability improvements."
MacOS/X needs "advanced" buttons so badly it's just excruciating. So many of its most annoying features simply cannot be disabled (long delay on dock hide/show, window animations, etc) without unsupported 3rd party tools.
I think there's a reasonable approach to usability that retains configurability without bombarding the user with choices most won't care about. Providing simple dialogs that can be expanded to show more options is one of the most obvious approaches.
I share your experience with KDE, especially regarding Konqueror (which I just can't handle), but I diagree with your preferred approach to solving it.
I use beta1, but I can't see any improvements since KDE2.
Nearly all usability problems of KDE are very old.
Not only the apps have usability problems also the homepage.
I wanted to know what has changed between beta1 and beta2 and tried these pages:
http://www.kde.org/announcements/announce-3.4beta2.php
only 10% of this page are about beta2, but no detailed info.
http://www.kde.org/info/3.4beta2.php
only downloadlinks.
did you mean: "a number of the issues i've noticed in KDE since the KDE2 days remain." because there have been improvements.
this is a typical example of the sort of things that makes it really tempting for developers to say, "i don't want to deal with users anymore." hyperbole, unwillingness to grant any credit .... why would someone want to listen to that? it's discouraging!
in the IRC chat, you'll see that some of the usability improvements were mentioned (and even linked to so you can see them in your web browser!) and that a lot of the discussion was towards KDE4. but you seem to have missed that. the result is that some developers begin to question why they should bother speaking to users.
as a user of open source software you have the rather unusual situation of being able to communicate directly with the people creating this mass-market software. in fact, that is such a cool thing that companies such as Sun and Microsoft are trying to imitate it with their developer blogs. but when people treat that communication channel carelessly, well ... it becomes hard to keep it open and productive.
IMHO, communication between users and developers (either directly or through an intermediary) is vital to achieving the best software possible for a whole bunch of reasons. maybe take a moment to consider how the people on the receiving end of your communication might react to what's written. we're all part of a big team here, including the users, and better things happen when we work together =)
(i went from to in 4 short paragraphs? yikes!)
Every time someone makes a more general complaint about a free program developers start lamenting that users are ungrateful and things like that.
Users have two possibilities when they find a problem:
They can complain, or they can use another program.
It works this way with open source software, shareware or commercial software.
I complain, because I want that KDE has the best, and easiest to use programs.
users complain to me about all sorts of things all the time, no big deal and it's often how i notice a problem spot to begin with. but there's a difference between complaining and being ungratefully rude. a big difference.
moreover, i'd challenge the idea that the only resort for a user is to complain. how about "engage in conversation" as one obvious example? it's fairly easy to discuss things with someone when they are being reasonable and are open to exploration, even if the general topic is "your code sucks, dude!".
I don't know why I answer you, because you're clearly a troll. Anyways...
>I use beta1, but I can't see any improvements since KDE2.
>Nearly all usability problems of KDE are very old.
You're kidding right? Since the usability studies by Relevantive AG a lot has happened in KDE:
- http://www.kdedevelopers.org/node/view/809
- http://lists.kde.org/?l=kde-cvs&m=110701903725477&w=2
- http://lists.kde.org/?l=kde-cvs&m=102115386904118&w=2
- http://lists.kde.org/?l=kde-cvs&m=108541070113786&w=2
Just to name a few.
> Not only the apps have usability problems also the homepage.
Calling the non-existant changelog a usability problem shows that you know this >< much about it.
BTW do you prefer that the developer fix the bugs and implement your wishes? Or do you prefer that they write changelogs?
How about you sit down, go through the cvs digest and write one?
> lot has happened in KDE:
Sorry, but these are only minor improvements.
> shows that you know this >< much about it.
Usability is about effectiveness and efficiency.
Efficiency means in this case how much effort does it require to find out what has changed.
efficient way : changelog
inefficient way : go through the cvs digest, or download, compile and find out.
>Usability is about effectiveness and efficiency.
You make a real valid statement here, sadly none of your other writing reflects this. But it makes your claim about only minimal improvements since KDE 2 fall flat on it's face. The increased effectiveness and efficiency in the improvements to in KHTML alone, makes your statements false. Usability is much more than reducing the number of icons in toolbars, which for the most part are no more than cosmetics.
Why, as a normal user, do you want to know what has changed to begin with? You shouldn't notice any difference unless for the better in which case the change sjould feel "natural". And usability is not about propaganda last time I checked its definition. So what the heck does your crap about missing a changelog but not being willing to check CVS changes (which is the only way you see all actual changes) have to do with usability?
"On the other side, usability people know very little about Open Source"
The "they haven't discovered the joys of Open Source" belief. That's one possibility. Another possibility is that we usability people know plenty about Open Source.
We usability people know that Open Source is pretty much dominated by a unix programmer culture that refuses to change the way it does things, constantly undermining itself by a "backend-now, pasted-on frontend later" mentality.
We usability people know that for years Open Source has long considered the field of usability to be BS; we don't have enough fingers to count the number of times we've heard prominant kernel hackers say about usability people "I can't believe that some people actually get paid to criticize the work of others".
We usability people know that if we contribute at all to any Open Source project, we will always be doing "damage control" for projects that already exist and will be limited in the good we can do because so much code has already been written. We know that it is pointless to try to explain to unix hackers the need to design user interface and work out user interaction at the beginning of the development process before any code is written, as this seems to violate unix hackers' core belief systems.
We usability people know that our contributions will be considered less valuable and less important than technical contributions like code. We know that if we make such contributions, we will be constantly second-guessed in our decisions by unix hacker types who know nothing about our field.
We usability people know that Open Source has continously demeaned and belittled end-users, the people who we want want to help, by attributing their frustration due to usability problems as them "not wanting to learn" or "just being used Windows". We've seen 30 years of the unix culture's glorification of things that are difficult. And we've seen 10 years of Open Source saying "linux being hard to use is just a myth".
We usability people know that if we confront Open Source with its history of shoddy usability after hearing the above statement, we will be accused of "criticizing the work of volunteers" and will be told "quit whining about what you get for free". We know that we will be told to "go code it yourself". And we know that the second we turn our back to walk away in disgust, the same exact people who just told us all these things will say that Linux is perfectly ready for your grandmother to use, has been so for years, and any statement to the contrary is Microsoft FUD.
We usability people know that even if we did have the skills to "go code it ourselves", and we forked Open Source software and made changes that improve usability, it would do no good. We know that Open Source's software announcement site, Freshmeat, would declare our work as "merely a patch" because they consider UI changes to be less significant than code changes. Our modified version of the software would be suppressed and would never see the light of day. Meanwhile, hundreds of distributions of linux based on a few changes to the kernel code would be accepted, announced, and embraced. We know that the old Open Source double standard of code being more significant than UI still holds, and even if Open Source tells us "go code a better one yourself", it's not like they actually mean it.
We know that Open Source's for-profit companies will spend billions on buyouts of technical companies that make things like compilers but will spend little or nothing for a dedicated usability department.
I don't think that the problem is that we usability people know little about Open Source; I think the problem is that we know too much. Call me a troll if you want, but to say "usability people aren't participating because they don't know anything about Open Source" is ridiculous.
Ergonomica Auctorita Illico!
It doesn´t help that you are the most grandiloquent big-headed wannabe I have ever read. Go hack on "directory free kde". Got anything other than a search and replace done already?
Perhaps usability people are cool. You aren´t.
More about this guy at his page. Including him speaking of himself on the third person, and his "software":
http://ilan.clarux.com/software.html
neat. a fork of KDE over a single word ... "Directory" vs "Folder" ... a change that KDE also made, so one can just grab a regular KDE release instead of this fork.
As usual, AJS missed the point.
--
JRT
Go take a look at the work done by people like Aaron Seigo (http://aseigo.blogspot.com/). He's rewritten some of KDE's usability disasters to be really quite nice (Kicker comes to mind). KDE devs are open to changes for usability's sake, just not changes for changes sake.
heh. you disagree with a usability professional who (co-)runs their own successful usability company when they say that most usability people know very little about open source ... but then go on to prove them absolutely correct.
your notions of open source and the receptivity to usability efforts are dated. while your observations were rather accurate at the turn of the century, a lot has changed since then. you'll still find the odd antiusability open source developer out there, but in desktop projects they are no longer the norm.
so i'd like to suggest that it's time to get those chips of our shoulders and recognize that there is the opportunity and the desire within the open source community to make things better. this is why so much successful usability effort is to be seen these days across the pantheon of open source desktop software.
To an extent, I can see where you're coming from - some folks are quite hostile to usability related comments and suggestions. My experience suggests that they're in the majority, and most people care about these things.
However, I think that if you approach the issue poorly and with no diplomacy, you won't get a receptive response. Your post does not suggest that you'd be inclined toward dipomacy or tact.
I also see a serious disconnect between a common usability view of "remove all features not used by 90% of the user base" and the hacker "make it do everything" view. There is a middle ground, but few seem willing to work toward it - and the fault lies on BOTH sides.
Software can be provided with an interface that makes the common things easy to find, and the less common things availible if the user actually wants them. You don't have to take all the flexibility out, only place it better.
I'm currently a developer on a project that is making active usability improvements as part of its normal development process. My experience so far is that this is the norm, rather than the exception.
Usability is KDE's single greatest weakness, great to see it is being taken more seriously now!
Though I was hoping KDE 4 will go by the new KHIG, not just have one ready.
> Though I was hoping KDE 4 will go by the new KHIG, not just have one ready
rejoice, it will be going by the new HIG. there's little point in having a HIG unless it's deployed, and that is our goal for KDE 4.0 =)