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...

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!

The colors are configurable (well, the background isn't but it's derived from the configurable OpenPGP colors), so if you don't like them change them.

And to answer your second question: Maybe, but I doubt it. Colors are a very simple and very easy to learn metaphor for good/valid (green) and bad/invalid (red). Moreover, the frames indicate in a very intuitive way which parts of the message are signed, i.e. are the attachments also signed or is just the message text signed.

Anyway, why don't you make a suggestion for a more decent way to show that the signature is valid?

I also think KDE needs to pay much more attention to usability. For example, the Konqueror and KGet toolbars need a major rework. They contain too many things that may confuse a normal user. I think they should only contain the things that are used more often. For example, who uses the Cervisia toolbar button in Konqueror? I'm sure less than 1% of its users. If that's accesible from the menus, then it should be removed.

A similar thing happens in KGet. It has the auto-off mode, auto-paste mode, auto-* mode buttons, while they are available from the Options menu. How often do people use it? Probably never. Removing them would make the toolbar easier to use and if someone wants to use that functionality it's still in the Options menu.

As you can see, it contains the location bar in the same place as the rest of the buttons, like Firefox does. It only has 6 buttons (from left to right): Up, Back, Forward, Home, Reload and Stop. Does someone really need something more than these? The rest of the options are still available from the menus, and I think this makes Konqueror much more easy to use.

You might want to note that Cervisia is only installed with the development packages; so the person installing the box clearly wanted development tools in there. For secretarial/light home use, the development packages wouldn't be there, and thus the Cervisia icon would be absent :)

In such a setup, cervisia should only be installed under the developer profile. The other profile should not even have it in their K Menu, or anywhere else.

KDE apps can easily be installed under multple prefixes. You can set multple directories in your KDEDIRS and when you start KDE it will "just work". So you set one global KDEDIRs, and then add the developer prefix tot he KDEDIRS of the developers.

The only thing this could be traced to is a bad sysadmin. There is nothing wrong with the cervisia icon being there.

I can't install one KDE application at a time using precompiled binaries, as nearly all distro use KDE's basic program tree.

When I install kdeaddons from FreeBSD's ports, it installs to /usr/local and not ~/ therefor every plugin for konq, kate, etc. are automatically activated right away. If I remove some of them manually afterwards, I risk upsetting the ports/package management systems. This isn't unique to FreeBSD - the only way to get around this is to build KDE outside of package management systems, but you cannot reasonably expect most-everyone to do this.

When I install kdeaddons, for exmaple, I'm doing it solely for html/css validators in konq and don't need all of the other plugins. The other plugins bloat the programs as there is no way to easily unload the un-needed plugins from memory, as a user.

What is really needed is a list of checkboxes for program extension plugins to enable/disable similar to the mime handling plugins for websites.
--
So bored? read my boring blog at http://tblog.ath.cx/troy

In almost any modern program if a feature is not used then it does not take up memory or cpu time. At worst on startup the program will check what features it has but it won't load them. The features just take up space on the disk and are loaded into memory on demand. There is no need to unload those things from ram since they are not in ram to begin with.

I really get annoyed seeing this kind of comment over and over again. Just like people that look at top and decide how much memory a program is using based on that. Everytime there is an article on slashdot talking about x idiots post about how it is bloated, slow etc etc. They are wrong and have been wrong for a very long time and a lot of profiling has been done to prove it. Even with all of that stuff posted they still post that crap every time. This is really no different. It has been discussed on dot.kde.org many times in the past and I suspect the same people will keep talking about it in the future.

The button for Cervisia is just an example. I think the best compromise would be making KDE have 2 working modes: basic and advanced. That could be configured in KControl, and I think it would be very easy to implement because you'd only need to load an XML file or another depending on the mode. The default would be "basic", because the advanced user is supposed to be capable of going to KControl and switching the mode, but the basic user might not know how to do it. In basic mode it would have the simplest toolbars, like in the screenshot. An usability study would have been aplied to them. The advanced mode would contain more objects, in a similar way like now. Anyway, it should still be coherent with the other programs.

Aaron, I saw on kfm-devel that you proposed to remove copy, cut paste, print and all that clutter from konqueror (FINALLY!). Any news on that? I saw that basically everyone agreed, but I can't find a cvs commit about it.. or maybe i just missed it

> because these buttons are very essential when using
> Konqueror as a file manager

well, it gos both ways. a print icon on the toolbar in file management is rather silly, but it makes decent enough sense in web browsing mode (at least, according to the usage study of web browser toolbars i did last year)

> And right now, Konqueror's view profiles don't allow
> you to have some toolbar buttons in one profile, and not in another.

i already pointed out on kfm-devel that konqueror allows you to do exactly this. 3.3 shipped with konq-simplebrowser.rc, in fact.

The keyboard shortcuts are far superior to the toolbar icons for quick access. For people who don't know the keyboard shortcuts, they can use the edit menu or right click menu, which has the added bonus of displaying the keyboard shortcuts so they can be learned, unlike the toolbar icons.

The menu items serve three purposes: they inform the user that these actions are possible, they show the keyboard shortcuts, and they fufill the user's expectation of copy and paste options in the edit/right click menu, which is standard for every application. The keyboard shortcuts serve one purpose: fast access. The toolbar icons are redundant. They show the user that those actions are possible, but the menu already does that (and for ubiquitous actions like copy and paste, it is hardly necessary anyway). They are not standard in file manager applications (see Windows XP Explorer, Mac OS X Finder). They are slightly faster than the edit menu, but are slower than the right-click menu and *much* slower than the keyboard shortcuts.

In short, the toolbar icons for cut, copy, and paste are redundant, clutter up the interface unnecessarily, and should be removed.

Unfortunately from what I can tell 'normal' (i.e. people that wouldn't reading this site, or anything other site that you would see 'computer' in) don't look in the menus. They DO look at the toolbar's icons. Some things in the toobar are useful, like even though I try and use keyboard shortcuts as much as possibly (which makes 'normal' people say 'wtf?'), I still often use several things in the toolbar, depending on the application. Like in Konqueror I use Up, Back, Forward, Refresh, Stop, and Go; in Quanta I use Preview; in Kopete I use Close on the chat boxes; and in every program that has it (such as Quanta and Kopete) I use the spell check toolbar button.

Often if it involves an 'F<1-12>' key I won't use it (too hard to reach w/ other keys, and too hard to know which your clicking), though I think thats more so a problem with keyboard design.

For the most part I agree that some of the fat can be removed from the toolbars, but ALWAYS allow them to be re-added manually by the users (just change the default configuration).

The problem is, you have to decide if you are going to make a system for your "normal people" or for people that read this site. If we should make it for your "normal" people a lot of other functionality would have to go as well. E.g. such users rarely know how to handle multiple desktops, so that functionality is only in their way, how many would be able to set up a printer, How many would be able to use KMail.

If we just make some parts of KDE simpler we will end up with a system that nobody wants to use. Not your "normal" people, not the experts. The trick must be hit an equal balance between functions and simplicty and apply that throughout the whole system.

Right. But your "solution" would mean, that KDE (and the Linux Desktop) will stay forever in it's niche. "Nobody" is the vast majority of people, so it's rather needed to make KMail more usable for "nobody", which means less shortcuts, "better" buttons/toolbars/popupmenus - and an alternative "expert" mode.

E.g. the Windows interface model for idiots ..err beginners(!!) with different dialog elements, reachable via , , ..., , is time consuming, but simple. Even the most stupid guy will get it. In contrast, in KDE it's relatively easy to find a shortcut in one application, that has a different meaning in others.

In 2007, I still believe toolbar configurations should be saved with profiles.
If not, very confusing spending hours playing with (complex) toolbars, to finally discover it is not possible to have one real "file manager" profile, and another "Web browser" profile.
Still to be investigated......
Rgds.

> I think the best compromise would be making KDE have 2 working modes:
> basic and advanced.

This is a bad compromise and this proposal has been discussed often in the past. You are maybe an experienced user for some applications, but for many
other you can just be a total beginner. It is just not possible to determine
for each and every application whether you're an experienced user or a beginner.

Basically it is "I can do that do" programming with no thought to usability.

1) Redundant functionality: The location bar does (almost) the same function.
2) Clicking on the 'G' to get a drop down is not self-evident.
3) No direct indication changing the default search engine is how you change the Googlebar's search engine.
4) No option for multiple searches, which users will be expecting.
5) No easy way to get rid of it.

My suggestion dump the combo box and turn it into a drop down toolbar button, using the location bar to enter data. Icon indicates default search engine. Tooltip indicates purpose.

Also on the web shortcut dialog add two checkbox columns.
Column 1 "Add to Search button"
Column 2 "Add to Right Click Search"

Column 1 is how the above toolbar button is configured
Note: around six popular engines should be pre-selected.
Column 2 is to improve searching functionality directly from a web page.

Pros
- No change to present location search functionality
- One location to enter search data
- Can use shortcuts or search button on same data
- Drop down becomes "memory aid" for different searches
- Easy access to multiple search engines.
- Brings awareness to the fact web shortcuts even exist. (The hidden functionality of KDE)
- Being a toolbar button it can be easily removed.

You shouldn't put the "up" button in Konqueror in the top-left because people confuse it (in my experience) for the "back" button, which most browsers place there, and then panic by its strange behaviour. Other interfaces might not be perfect either, but you should design interfaces by taking a user's previous experiences into account and having the "up" button there is guarenteed to confuse a big percentage of users.

I'd guess I'm four then. And add in the fact that someting like 6-8 out of 10 KDE developers use it, and it's one of the useful power features making Konqueror unique among browsers. If you want to remove something from the browser profile, take the useless home button.

btw, while talking with Jan and Ellen earlier today they mentioned that OpenUsability.org really needs a PHP devel or two to help out with some customizations of the gforge software. if you're a web developer who'd like to help out Open Source, KDE and usability in general, here's a great way to do that! =)

I'd like KDE to look more like the GUI in Sim City 4. Yes I do!!! It's artistic, funky, cool and pleasant to look at.

KDE apps need a lot of cruft trimming from them. I know I'll get flamed to use GNOME, but there really are too many options, menu items and other wonderful stuff in a lot of apps. It's too confusing, makes it difficult to use IMO.

Hopefully these usability people will tackle the tough issues as well as the simple ones.

>I'd like KDE to look more like the GUI in Sim City 4. Yes I do!!! It's artistic, funky, cool and pleasant to look at

Since it's not very unlikely most developers don't have a clue how Sim City 4 looks like this may be a problem. Why don't you have a go yourself.
Perhaps starting with the window secorationhttp://www.usermode.org/docs/kwintheme.html

Or if you make some real nice mockups, perhaps you could recruit some developers over at KDE-Look.