Celebrating one month of KDE 3.3 out in the wild, userinstinct put together a usability review with user testing. "Based on feedback from our test group, the default settings for a number of KDE parameters differ from what is usually expected and desired by users. Providing better defaults would reduce the time users spend looking for configuration settings and would provide a better "out-of-the-box" experience."
Dot Categories:
Comments
Really nice read. KDE is *this close* to be just absolutely amazing. All it needs is to hide advanced options and reorganize options in menues and toolbars with one idea in mind: NOT overwhelm the user. The Konqueror Settings Dialog is a good example. It is just way too cluttered.
I love the way they handle these issues on Mac OS (for what I peeped other people using it). I also like the simplicity of XFCE-4. It replaced GNOME as a secondary desktop on my machines. It really is a pleasure to use (although it lacks most of the KDE features, but it's worth a look).
All in all, KDE is an outstanding DE. But if I were to vote for one direction of improvement, it would be usability, in the sense discussed in the article. Simplicity in the design, and sensible default values.
A little time ago I read here in the dot that a few professional usability experts joined the project ? This will be terrific. Are hey working for Novell ?
> A little time ago I read here in the dot that a few professional usability experts joined the project ? This will be terrific. Are hey working for Novell ?
Yup, the lead usability guy at SUSE, Dr. Siegfried Olschner, spends half of his time in writing the new human interface guidelines for KDE. I think Novell has a couple other people in their suse usability group working mostly on KDE-related suff as well. Other people would know more, of course.
The OpenUsability folks work mostly at relevantive, a usability firm in Germany.
Is this SUSE guy backed by the KDE core developers?
I think should be annoying if Novell force his work into KDE.
After all, one reason most of us use KDE and do not use Gnome is that all this nice and smart guys are in charge and corporations can provide resources but do not steer the project vision and direction.
Very sad if we have our own "KoneME" in a year or two.
Besides this concerns, I want to rise find a different (but connected, and larguely discussed already) question:
Is KDE willing to ease things for new users from the Windows world in spite of fellow user (KDE 1.0 myself) who likes KDE as it is, who likes its defaults and the clever way it is constructed? Should their developers simply drop their vision about how things should work because most people is not used to this and do not care if there are better things to do this? This happens already. I love the original vision of Konqui, but if I have to customize it from scratch, I already have to set MIMEs to open into Konq all the way despite the fact this is a strong paradigm in its design!
I hope the answer could be a very KDE-like one: A new step in the customizing wizard, asking for sensible defaults for (at least) die-hard KDE users, for Windows users, for Mac users, and for Gnome users.
> Is this SUSE guy backed by the KDE core developers?
yes. he gave a good presentation at aKademy, discussed a lot of usability related things with various people and was invited to join in on our guidelines rewrite. he requested and was given the go-ahead to do so by his SUSE/Novell managers, which is really cool on their part. he's now working alongside the rest of the guideline writers to help make it a success.
> Is KDE willing to ease things for new users from the Windows
> world in spite of fellow user (KDE 1.0 myself) who likes KDE
> as it is, who likes its defaults and the clever way it is
> constructed? Should their developers simply drop their
> vision about how things should work because most people
> is not used to this and do not care if there are better
> things to do this?
speaking only from my own personal perspective, i don't think these two goals are at logger-heads. we can make KDE a comfortable place for newcomers and retain our vision. we don't have to become a clone to become usable and adopted. we do have to become more usable to be more widely adopted, however, just as we need more capabilities/features to be more widely adopted.
some of the reasons Konqi doesn't reach its full potential is not so much because it needs to be tailored to new user expectations, but rather because of usability problems that create collateral damage effects. for instance, right now when you view a file in Konqi, how do you move to edit it? it's not apparent to the user, so we need to open it in a new window by default more often. this is completely solvable, however, and it will be one day =)
many other similar issues exist. as we improve the ergonomics and interaction mechanisms in KDE, we will actually be able to promote our vision more clearly and effectively.
erm, i think it's "half a day a week", not half his time ;-) still, it's awesome and i personally really appreciate his and SUSE/Novell's commitment in this regard. Siggie is a great guy, and he's brilliant to boot. like a lot of the people in KDE, it seems =)
People really should not comment on OS X unless they've actually used it for some time. It is really not the shining example of usability everyone holds it for. Some niggles I have found over a year and a half of OS X usage:
* Inconsistent design and use philosophies between apps derived from the Next heritage (Mail) and apps derived from OS 9 (iTunes).
* Inconsistent look & feel (brushed metal, Cocoa, Carbon -- won't complain about the legacy OS 9 apps or the X11 apps)
* It's hard to discover the "advanced" options. No Mac user I know knows you can switch between documents in the same application with apple-tilde, and everyone is delighted to hear about it. I only knew because I've read the OS X HIG from cover to cover.
* The new finder is completely unpredictable in when it will show itself in which way.
* The font rendering is really quite bad, compared to Freetype.
* OS X has no package management, meaning it can be hard to uninstall software that doesn't keep to the everything-in-one folder concept. There are a myriad ways of installing software, too.
Of course, there are good points, too, like the quality of iTunes or iPhoto. But in the end, in my experience, OS X isn't much better than KDE as a Unix shell.
Exactly. I tried MacOSX too and found it terrible that you can choose between 2 minimize-animations but cannot switch off minimize animations. So it slows you down all the time.
But that's not the point. The point is that Apple isn't good as usability or ergonomy (they aren't. Just look at the "puck-mouse") they are good at marketing. (way better than Microsoft, BTW) If it's from Apple, it "must be" easy, intuitive and user-friendly.
Apple has had a good usability back in the days of Mac OS 7 (including hard user interfaces: keyboard and mouse). This is what Gnome tries to copy / build on today.
while this is quite true, the desktop computing world has moved on and is almost nothing like it was back then. our interfaces must evolve in response to the growing amount of data, number of sources and diversity of interaction requirements involved in a modern computing/communication environment.
True..
Also while back computers were limited in processing power, so you couldn't multitask as easily as you can now, so the UI must adapt to allow efficient multitasking for the user..
On this topic, my pet peeve is that "Splashscreen should DIE", they steal the focus (prevent multitasking), some can removed by clicking on it, some can't which is even more annoying.
If you activated by mistake an app or you change your mind, there is no way to close the app because splash screen can't be closed nor minimised..
IMHO "splash Window" would be *MUCH* better: I call splash window the same thing as a splash screen but embedded inside a window frame with the normal minimize/close button.
Now this is more an OOo problem than a KDE problem fortunately..
Except, of course, in the Kontact App...
Kontact loads quite fast for me in the 3.3 series !
kontact --nosplash
> On this topic, my pet peeve is that "Splashscreen should DIE",
>
> Now this is more an OOo problem than a KDE problem fortunately..
Wow, there's a blast from the past. I'd forgotten just how annoying the open office splash was. Anyway, you don't need to suffer unless you really want to:
http://ui.openoffice.org/howto/
That said, this definitely falls within the realm of sane defaults, and I agree that "Splashscreen should DIE" is a sane default.
Hopefully the Kontact splash will be disable-able at some stage, but at least like all KDE splash screens you just have to click on it to make the damn thing go away.
> People really should not comment on OS X unless they've actually
> used it for some time. It is really not the shining example of
> usability everyone holds it for.
Point well taken :-) Ant thanks for sharing your experience. But I still think that a quick impression to a new interface is important. I have shared work with Mac OS X users, where we sit in front of their laptop, and we collaborate on research. And the interface does look clean, context menues seem reasonable, etc. You are not presented with lists of dozens options. Just a few, well thought options. I am not saying we have to go OS X. Or that everything they do in terms of usability is just perfect.
However, companies like Mac and the Redmond monopolists do invest a lot of money on usability, and they come up with software that doesn't scare a user with no technical inclination. And we can learn a few tricks from peeping at their UI's eveyonce in a while.
We are getting better in the FS world. Some Linux distros are making things look more end-user friendly. KDE is helping a lot. But there is still a gap to cross unless we want to mostly target techies.
A point in case: Configuration layout in Konqueror (KDE 3.2.3). Imagine a non-techie. Someone who just wants to search the web and manage files. She/he opens "Konqueror -> Settings": 17 freaking option categories. Seventeen. Names like "crypto", "stylesheets", "Proxy". This is not end-user friendly. Don't get me wrong. I love to fool around with these options. But an end user freaks out. Just because they don't care. The same way I don't care about lawyer-talk, fashion and so many other things.
But what if you opened "Konqueror -> Settings" and you had 2 options:
"configure file management" or "Configure web browsing". Maybe a third category for common options. And then within "Configure web browsing", just a few understandable categories. "Look and Feel", "Plugins", "Pop-up blocker", "Advanced Options". I think that this is the sort of approach the article is trying to encourage. And I think it is the way to go.
In the meantime, I choose to use Mandrake linux with KDE as a default DE, and my whole family does. Things are good, they just could be better :-)
Cheers !
"A point in case: Configuration layout in Konqueror (KDE 3.2.3). Imagine a non-techie. Someone who just wants to search the web and manage files. She/he opens "Konqueror -> Settings": 17 freaking option categories. Seventeen. Names like "crypto", "stylesheets", "Proxy". This is not end-user friendly."
I know quite a couple of people like that. And guess what, it's completely irrelevant how many options are there because they never see them because they never change the defaults in the first place.
"But what if you opened "Konqueror -> Settings" and you had 2 options:
"configure file management" or "Configure web browsing". Maybe a third category for common options. And then within "Configure web browsing", just a few understandable categories. "Look and Feel", "Plugins", "Pop-up blocker", "Advanced Options". I think that this is the sort of approach the article is trying to encourage. And I think it is the way to go."
So instead of a couple of options you want to have more options (= when you split up everything in "normal" and "advanced" you have twice as much and put the whole thing in a tree instead of a flat structure. It's got a lot more complicated.
Human beings are not computers. It takes extra processing for them to ignore irrelevent information. Say someone opens up a control panel with 17 options, vs one with 5. If something only has 5 options, the user can take it in at a glance, and immediately find the one she wants. If it has 17, she has to scan through each one (and make a decision about whether it's the one she wants or not), before getting to the one she wants. Humans are built to recognize and process small sets quickly. That's why you can easily group things in threes or fours, but not in tens. If you ignore this "feature" of the brain, the speed at which your UI can work suffers.
So which 5?
I recently installed firefox, replacing mozilla on my linux box. My wife prefers mozilla to konqueror because it prints legibly.
Right off, she asked where is the print icon on the toolbar?
This move to minimizing the user interface reminds me of 'nouveau cuisine', where you sit at an expensive establishment, the plate comes with a couple of slivers of carrots and a tiny piece of fish, all presented elegantly. Everyone talks about how wonderful the meal was, how exquisite the service. And on the way home you pick up a pizza because you are still hungry.
Derek
You should have just told her to use File -> Print. That's what the menu is there for --- it's a canonical listing of all of a program's features. A toolbar is just an optimization. Specifically, it is one whose usefulness is couched in two principles:
1) Human beings are good at processing small sets, with the maximum number for comfortable recall being 5-7 (from psychological studies).
2) Human beings are good at recognizing distinctive visual objects.
If your toolbar contains elements that cause it to violate (1) or (2), then it is no longer useful as an optimization.
Given a large sample population of users, you can develop a rank-ordering of how often each icon is used. The decision of what to put into the toolbar, then, becomes a matter of filling the toolbar in rank-order, subject to the constraints of number and distinctiveness.
Things should be in the toolbar because they are used often, not because people expect them to be there. People will learn, with use, to know where to expect things. They cannot learn to deal with more items at a glance than their brain allows.
PS> It is interesting to consider an example of an application where (1) and (2) cannot be fulfilled easily. In that case, a toolbar really isn't very usefull at all. Consider the user-interface of Softimage XSI (which many consider to be the most productive 3D modeler in existance). There aren't really any main toolbars like what you'll see in Maya. Instead, the "toolbars", are just sets of buttons with text-labels. They are more of an extension to the main menu than anything else. The reasoning is that there are too many options to present a scanable toolbar with visually distinct icons. Trying to make a toolbar out of those would just lead to the user linearly scanning a list of cryptic icons (*cough* Maya *cough*), which is slower than using a menubar of text labels.
No you got it wrong.
Mozilla had a print button on the toolbar. Firefox doesn't.
Somebody optimized things alright. Someone decided that there shouldn't be any more than some imaginary number of icons, so they optimized away something that is useful. And used. And requires training to show another way.
You suggest using the menu. You suggest I show her how to do something she knows how to do with another way because it isn't appropriate somehow.
What if there are 6 common uses of a piece of software, where theory suggests that 5 is optimum? Where does usability change from trying to help users into attempting to influence the way they use the tools?
Derek
The toolbar in an application serves two purposes:
1. (most important) It removes the overhead of pulling down a menu for items that are used very frequently (more than once per session). Printing definitely does not fall into this category for the average web user. (For exceptional cases, the toolbars are editable).
2. (less important) It guides the user by showing them the *few* most relevant and important actions they can perform at any time. Printing is an action that might fall into this category, but most users will expect that they can print web pages, and when they want to print they will specifically search for the print option, so they do not need to be reminded that it exists by a toolbar button. The number of icons on the toolbar should be kept VERY SMALL to avoid cluttering the interface and intimidating new users. (see the user comments on Konqueror's interface from this study...) So it still seems to me that the print button should not be on the toolbar.
So there are good usability arguments for not having the print icon on the toolbar. However, since the print icon has been there in previous browsers, we also have to consider the impact that removing it will have on those users. This is where usability testing is needed, to tell: 1. how many users will be affected, and 2. how severe the effect will be. In the case of the print icon, though, I think I can predict the outcome: users will easily find the standard print menu option in its standard place in Firefox's menus. Thus, Firefox was justified in removing the print icon.
Often people use bogus "usability" arguments in attempts to push their interface ideas on other people. However, that doesn't mean that doing things in the name of usability is always bad. In this case, it is likely that the users really are better served by removing the print button. (to be absolutely sure requires extensive user testing).
You know, for me, I think the key is, simplicity in the way you suggest, but also a very intuitive customization process. You say only exceptional cases might need to edit the toolbar, but the fact is, everyone is an exceptional case in some feature or another. Maybe not printing, or whatever, but maybe some other thing. So intuitive editing of toolbars and interface in general should be there. Like dragging the "Print..." option right off the menu and putting it in the toolbar. (or dragging the whole menu and dropping it as a toolbar). Not hiding the "Edit the toolbar" feature somewhere in the menus (there's nothing wrong with having it in there as well of course, EVERY feature that an app can do should be represented somewhere on the menu -- people use them as documentation for an app). Grabbing things with the mouse and putting them where you want should be a universal, system-wide feature that works with EVERYTHING. That way the user can just expect that when the drag something around it's going to do something rational with it.
It's not a hard limit. That's why I said 5-7. That means that 8 could be okay, 15 is probably bad. It's not some imaginary number, you can crack open any psychology textbook and find it. A printer icon in the toolbar is *not* useful. It takes up to a minute to complete a print-out. You can't possibly use the print feature often enough to warrent it being in the toolbar instead of the menu. A "go to google" icon would probably be much more efficient.
Where does usability change from trying to help users into attempting to influence the way they use the tools?
I find this statement hilarious. Usability should be about influencing the way they use the tools. The tools should be used as efficiently as possible, and the interface should be designed so that the easiest thing to do is use the interface efficiently. Look at it this way: if somebody types improperly, shouldn't you "influence" them to type using the proper form? Further, when your reluctance to influence the user causes you to make a toolbar with 15 entries, then not only do you not encourage them to use the application efficiently, you prevent everyone else from using the application efficiently.
PS> To follow up my other comment, let me clarify the thing about the rank-ordering. People will often say "yeah, 90% of users use only 10%, but it's a different 10%." It is highly unlikely this is the case. If such a statement were true in other fields, industrial design would become nearly impossible. There are lot's of assumptions every designer and engineer makes about the users using his products, and the fact that most of us find our cars comfortable to sit in and use (for example), is a testament to the level of homogeneity of peoples' behaviors. Now, the analogy is a bit off, because computers themselves are multi-purpose tools while cars are special-purpose tools, but applications themselves are essentially special-purpose tools, so it's close.
I really doubt most of people find all cars comfortable to sit in and use right after changing a model or manufacturer, it's always a question of adaption and taste as well as both the object's aand the user's flexibility. With computers it's one level worse since it's even more abtract and the expectation can only be related to prior experience (using KDE as an absolute beginner is easier than after switching system).
That's not really the point. The point is that industrial design (cars, etc) has to take into account a huge range of user preferences and behaviors. If all behaviors and preferences were equally likely (which is implied by the "each user uses a different 10%") then industrial design would be impossible. You couldn't physically design a car to take all those things into account. In reality, people's behaviors and preferences tend to fall into clumps, with surprising homogeneity within clumps. That allows industrial designers to to design for a few combinations of behaviors, and it works quite well in practice.
Odd you mention cars.
I drive an early 90's subaru, and a ford ranger pickup.
One is standard transmission, the other automatic. One has the wipers on the left of the column, the other on the right.
I am always getting things mixed up.
Homogeneity is due to our ability to learn, rather than any natural reflexes.
Industrial design has more to do with keeping the product simple and economical to produce. Or marketing. The goal of most human interface design is to remove unnecessary options so that processes are repeatable and predictable.
I hope this isn't the goal of the usability effort.
Derek
I think you've missed the point about this whole usability issue. If you look in most modern cars they have a steering wheel (rather than many other possible alternatives). In addition, in most cars the ignition is in exactly the same place and by god you'll curse if you climb in a different car and you cannot find the windscreen wiper control.
The point is that most people expect to find things in certain places. In addition there is the HSE aspect (you probably want to avoid constantly clicking on the mouse) and if you have used some poorly designed Windows you'll know what I mean...
Now I'm with you when you say that configurability does not need to be sacrificed. But when I've talked to usability consultants in the past I've never heard "you should remove this". However, we did get plenty of advice like 90% of users found this confusing perhaps if you organize like this it will be less confusing.
You can then right-click when your mouse is in the toolbar, click on "Customize" and drag&drop your print icon where you want it to be.
I prefer to have few icons in my toolbar (I use print once or twice each month, so in the file menu is the correct place for that option; but I used "open a new tab" very often so put it there) and be able to have the URL adress box in the same bar in order to avoid loosing place.
Having less options by default and be bale to add them is better than having lots of icons by default and be able to remove them.
That's my thought (and only mine :)
The problem with usability studies is that they take beginners, put them for 30 minutes in front of the system and derive the conclusions out of that 30 minutes.
The problem with following that advice is that you get a system that is great for the first 30 minutes of computer usage, but which will suck for **YEARS** of computer usage that follow.
Browser-tabs are an excellent example. Did anybody use browser-tabs in their first 30 minutes of browsing the web? No, almost certainly not. In a usability study, browser-tabs would be categorized as completely useless and would land on the "remove-because-too-complicated"-list. Another example would be multiple desktops and yet another would be keyboard shortcuts. (Nobody uses keyboard shortcuts in the first 30 minutes of use - THEY MUST BE USELESS!)
While I agree that defaults should be targetted at beginners **when possible** (= without removing or destroying useful features), it's just stupid to remove options and settings.
For what it's worth, I think the KDE-way of usability (watching bugs.kde.org for wishlist items and implementing the good ones) is way superior to any "usability study".
About tabbed interfaces, you may like to read what happened with the usability studies when Microsoft started experimenting with them:
http://www.joelonsoftware.com/printerFriendly/uibook/fog0000000249.html
Nice and very interesting read.
Thanks for the link.
Not necessarily gospel, but certainly an informative read.
>The problem with following that advice is that you get a system that is great
>for the first 30 minutes of computer usage, but which will suck for **YEARS**
>of computer usage that follow.
I completely agree. Hope the KDE usability experts will take in consideration not only the user's "first impact" with KDE but also its daily usage (which IMHO is far more important).
>>The problem with following that advice is that you get a system that is great
>>for the first 30 minutes of computer usage, but which will suck for **YEARS**
>>of computer usage that follow.
>I completely agree. Hope the KDE usability experts will take in
>consideration not only the user's "first impact" with KDE but
>also its daily usage (which IMHO is far more important).
I would agree if the conditions were mutually exclusive. But I don't think this is the case. A cleaner, leaner interface would benefit everyone. Unless you take some of the options and features off the picture. But the idea is not to do that. The idea is to present information to the user in a cleaner way. Advanced options and tools should be always accessible for whoever is interested on exploring them.
The trick is prioritize. If 90% of the users use 10% of the options most of the time, make sure these 10% options are highly visible. And the rest are acessible but not on the way.
"I would agree if the conditions were mutually exclusive. But I don't think this is the case. A cleaner, leaner interface would benefit everyone. Unless you take some of the options and features off the picture. But the idea is not to do that. The idea is to present information to the user in a cleaner way. Advanced options and tools should be always accessible for whoever is interested on exploring them. "
Well, I'd say it depends a lot of the feature wether it's mutually exclusive or not. In lots of cases, both can be achieved (and that's of course great) but in other cases you will have to decide between short-term and long-term usability.
There is a probability of 0% that 90% of the users use exactly the same 10% of options, rather they may each use a different set of 10%, so such an approach is complete humbug.
As I said elsewhere --- if this pessimistic idea was true, industrial design would be impossible. If you consider the set of options and actions 90% of users use, there is going to be a large amount of overlap between these sets. It's not going to be exact, but there will be lot's of overlap. Since KDE is configurable, it makes sense to take the intersection of these sets, and let users add the few that are missing from the default configuration, instead of taking the union and making each user live with the behaviors of every other user.
Of course, because there is a big confusion about learn and use.
Of course, we all know (and sometimes love) lots of tools that are easy to use after you use them along a few years (decades?).
Of course, thinking about promoting these as mainstream tools is nonsense, KDE should be replaced with terminal windows and a nice bunch of guru software.
But thinking that something is good if the user can figure it out by himself when you make him sit and ask him to achieve tasks with no further clue is nonsense as well. Lots of nice features simply will not be so obvious nor attractive at first sight.
You did not obviously bother to read the articles since none of the users were beginners:
User #1
Occupation: VP Software Development
Education: Bachelor of Science in Electrical Engineering
OS Experience: Mostly Windows, some Linux, TRS-80
Hobbies: Games, Web Development
User #2
Occupation: Information Technology
Education: Masters in Geology, Geography
OS Experience: Exclusively Windows
Hobbies: Computer Games, Perl Programming
User #3
Occupation: Director of Development
Education: Master of Science in Aerospace Engineering
OS Experience: Mostly Windows and Macintosh, some SCO Unix
Hobbies: Games, Graphics, Coding in ASP
...
Even if those people were beginners, it is a stated goal of KDE to address the beginners as well as the advanced users, so the result of a study of beginners behaviour in front of KDE is very important.
> it's just stupid to remove options and settings.
It is much more complicated than that. Sometimes it is stupid, sometimes not. Most of the time, improving usability goes far beyound adding and cutting options.
> I think the KDE-way of usability (watching bugs.kde.org for wishlist items and
> implementing the good ones) is way superior to any "usability study"
Luckily, the KDE approach of usability is a lot more intelligent than "study the wishlist item". For example, they also use the thing called brain to improve uability of applications.
The users were not beginners as such, but they were beginners in the KDE environment. I very much agree that these first impressions, although important, can never be an argument to make usage for advanced users more complicated.
AFAIK all were new to KDE, so they were "beginners"
" it's just stupid to remove options and settings."
Well, not really. There are some configuration-tasks that users do over and over again. Some options are hardly ever touched, if at all. When user is doing those everyday-tasks, those rarely used options get in the way. Of course, the user will learn (with time) where the options he needs are. But it doesn't have to be that way!
How should it be then? It should be dead simple for the user where the options he needs are. And they should not be hidden amongst dozens of other options. The GUI should just present the top 10% of most used options (I pulled that percentage from my ass, but you get the idea), while the rest of the options (that are not used that often) are hidden from the user. I bet that that 10% would cover about 90% of the options the user REALLY needs. Rest are just icing on the cake. It would make configuring the UI alot smoother and simpler, and it would clean up the configuration-UI ALOT!
How could that be done. Well, we all know how Gnome-folks did it: With Gconf. That is one way of doing it. Unfortunately I don't have a solution to offer.
You clearly don't know much about how *good* usability tests are conducted. Good tests don't simply "take beginners" - good tests involve representative users. So, if a system is designed for expert users, then it should be tested with experts. Many systems have a mix of skill levels in their user groups, and so good tests will involve a mix of user types. Air Traffic Control systems are usability tested with expert users...at least we hope ATC systems are used by experts. :)
while many of the talk backs here are rather focused on the empty half of the glass, it's nice to read the number of positive comments from the testees, none of whome had used KDE before. a new environment is almost always uncomfortable at first, and yet we still got compliments.
i wouldn't recommend testing with contrib'd packages (which is what these packages were, for Slackware), and a number of the apps used (and failed with, at times) were not KDE apps.
in general, i'm rather encouraged by the article. we're making good strides forward ("This is UNIX? I like it. I'd use it."), and our weak points are being found for us to fix.
> while many of the talk backs here are rather focused on the empty
> half of the glass, it's nice to read the number of positive comments
> from the testees, none of whome had used KDE before.
True. I guess it is just becaause we all feel like making suggestions for improvement, but you are right.
I fell myself in love with KDE a while ago, with the 2.* series. The reason I loved it (and I still do) was in great part _consistency_ in the interface. Want Help ? "Help -> Handbook". Need to configure ? "Settings -> Configure". Interprocess communication works beautifully. You are browsing pics in Digikam, select a few, right-click, choose "email pictures", you are asked what size you want them, that's it. Component model (KPart) the same thing. All this power in the kdelibs makes KDE quite a pleasure to use (and to program for, for the little bit I experimented).
The "empty half of the glass" in the usability front has to do to a great extent with issues you have to address from the UI design philosophy, and this is an area where great improvements can still be made. The number of posts in this article talkback is a measure of the importance of this subject.
Just don't make it too usable as GNOME is. KDE currently is really great. Perhaps some reshuffling of features around in the next version, to give features people use most the best presentation. (Even I have to agree that the toolbars do have quite a bit of buttons, and arguably too many.)
Just don't make it another GNOME.
I think people are taking the GNOME HIG work, and the GNOME ideological "no new features" work, and lumping them together. I think that's unfair to the GNOME HIG work. I recently spent a week trying out FC3-Test2, and have to say HIG-compliant apps are generally very elegantly designed and highly usable. I don't think you can fault GNOME for that. The problem with GNOME is not that they laid down some well-established UI principles, nor that they designed apps with an eye towards elegance. The problem is that they cut out too many features in the process, many of which they didn't have to. You could get to a pleasing level of minimality without throwing away all the features they did.
Paul Graham argues that you need many features to keep the power users happy. However he says it's very important that you have SANE defaults to keep the rest pacified.