As recently announced, an effort has been started for closer cooperation between the KDE and GNOME usability teams. The effort was announced in a message sent to the
[email protected]
mailinglist that was created for this purpose.
Original announcement by Aaron J. Seigo:
Seth Nickell (GNOME Usability Project), Havoc Pennington (Free Desktop, GNOME), and JP Schnapper-Casteras (Free Desktop Accessibility Working Group) and myself have been discussing the possibility of co-locating the KDE and GNOME Human Interface Guides (HIGs).
The plan as discussed thus far is to have the two documents co-inhabit one XML
document. Within this document, each HIG will have its own sections as
appropriate and will remain available for separate viewing. The goal is to
have one URL (on www.FreeDesktop.org) and one document for developers to go
to for KDE and GNOME Human Interface Guidelines. We hope this site can
eventually house guidelines for multiple desktops and graphical toolkits.
The easier we can make it for developers to discover and follow such
guidelines the better it will be for Open Source desktops in general. Since
KDE apps are often run on GNOME and vice versa, developers should be able to
easily reference the guidelines for all the desktops they expect their app to
be run on.
Having a shared document will also allow us to start looking at commonalities
between the documents and perhaps create common chapters or sections on basic
guidelines and lessons that are desktop and toolkit-independent (e.g.,
accessibility and internationalization tips, general usability principles).
It will take some work to merge the documents, create a web site, and raise
awareness about the site for developers and people working on other non-KDE
non-GNOME HIGs. If you wish to join us in these efforts, please subscribe to
the [email protected] email list via the web interface at:
https://listman.redhat.com/mailman/listinfo/open-hci/
Best wishes to everyone!
Comments
there are a lot of misconceptions out there regarding KDE. such things happen. there was no good summary of information that addressed the most common misconceptions, so i put one together and called it "KDE Myths" because that is exactly what it addresses.
if people are free to spread innacuracies, i'm free to spread accuracy. it has nothing to do with paranoia or zealotry but a desire to have accuracte information in the hands of those who care.
if you can show me how this is a wrong thing, please do.
I guess there will be quite a lot of discussion regarding button order (Ok-Cancel versus Cancel-Ok)...
These shouldn't be any. Gnome 2's default is DUMB. It makes no sense whatsoever to lead people clicking on the wrong button:
a) for the first few months of migration to your architecture
b) whenever they use something else
It is too great a sin to change button ordering in a minor revision too. That is a big fuck-up, it will be hard to clean. But whatever it takes, the burden is Gnome devels'.
When your last architecture is mac there is no "clicking on the wrong button" problem. Mac has made this choice for a reason, so has gnome. Whether or not it's the correct alternative is another question.
It should be solved between kde and gnome. I don't care if kde or gnome "wins" this. As long as it's the same between them.
So, basically, it is right for some 4% of possible users, and wrong for about 92% of them.
> So, basically, it is right for some 4% of possible users, and wrong for about
> 92% of them.
Wrong. The button order can be right, or it can be wrong; it can't
be right for some users, and wrong for others.
Basically, Apple put a lot of research into determining the correct
order for buttons in a dialog. MS made the order different in Windows
in order to avoid being sued by Apple, even though their button order
was _wrong_ and decreased usability. KDE and Gnome1 copied MSW.
For Gnome2, the Gnome developers finally got around to reading some
literature on HCI, and fixed their button order. The KDE developers
should do the same.
This isn't about Gnome vs. KDE -- this is about good UI design vs
bad UI design.
> Wrong. The button order can be right, or it can be wrong; it can't
> be right for some users, and wrong for others.
Wrong, of course it can.
For example, if you are using a right-to-left locale, all of Apple's reasons for their button ordering work the other way.
So, what you may be trying to say is that they can not be right or wrong FOR THE REASON I GAVE. Which is an entirely different thing.
But since I replied to a post saying that if you came from a mac there was no "pressing wrong button problem", I only stated the obvious, that for about 23 times more people, THERE IS a "pressing the wrong button problem".
As for MS changing the button order to avoid a lawsuit... well, I find it quite farfetched. Do you have a reference?
A lot of this strikes me as rather trivial. It could be argued that it is good to have the buttons appear in different locations to prevent against habituation - so when a "You have unsaved data. Do you want to save it?" dialog box appears, the user doesn't automatically click on the "discard" or "no" or whatever button with no further thought and realise only a moment later that they have lost their data. Let's face it, losing data is a bit more of a hinderance to productivity than having to find the right button, and users will *always* make mistakes.
With the buttons in different places, users of both KDE and Gnome apps will have to look for the correct button, reducing the chance of not saving their data before quitting an application.
Having said all that, I think consistency between Gnome and KDE is a good thing, just so that both DE's get a fair chance when common inconsistencies in proprietary systems are cheerfully ignored. Remember that in hci (or chi!), most findings are counter-intuitive.
[quote]
A lot of this strikes me as rather trivial. It could be argued that it is good to have the buttons appear in different locations to prevent against habituation
[/quote]
*lol*, right on!
Another cool thing would be to maintain consistent button order but switch them around from time to time -- just for the heck of training new brain pathways.
Then of course, we could have *random* button orders for the truly adventurous.
Sounds like whats happens when you play with WinZip...
"For example, if you are using a right-to-left locale, all of Apple's reasons for their button ordering work the other way."
GTK+ 2.0 has this nice little feature of swapping the horizontal layout of all widgets for right-to-left locales.
> GTK+ 2.0 has this nice little feature of swapping the horizontal layout of all widgets for right-to-left locales.
As do Qt and KDE (try kwrite --reverse, for example).
I didn't new that, kwrite looks very strange, and strangely cool, this way :)
Thanks for the tip.
Wow, that looks so strange. If you'll excuse me, I have some new brain pathways to train now...
But is it automatic? Does the layout of all QT/KDE apps automatically get reversed when run under a certain locale?
Basically, yes, depepndent on the currently selected language -- in the language packs in kde-i18n, one of the things the translators specify is whether to use RTL or LTR ordering.
it would be rather useless if it didn't, hm?
hehe.. "let's put in this massive BiDi framework, but the not let it be turned on desktop-wide as a policy decision".. there is a method call that tells the program wether it is in LTR or RTL mode, and all the widgets/layouts listen to this.
even things like the window decorations get flipped... the keramik window deco actually flips the pixmaps so things look proper... it's really quite nice and been available for a while.
In that case you've answered the question about which button order is best. You should use the Gnome/Mac order since that will be the most natural for both LTR and RTL locations.
Uh, no. That is one factor. Another factor is what is not surprising the user.
Since KDE has used the current button order for about 4 years, and everyone that uses Windows has used that order for 9 years, and both together are:
100% of current KDE users
95% of possible future KDE users
it only makes sense that in order to change the button ordering, the change would have to provide a measurable improvement in the user experience that is larger than the annoyance it would produce.
Since no such measurings seem to be available, I see no reason to mess with status quo.
But, using this logic, you should also stick with the double click system that Windows uses.
Windows has both single and double click in the same interface. An inconsistency. KDE can improve that by removing one of the options (double click). There already is consistency with button ordering and the benefits of switching are slim to none, while introducing an 'getting used to period' of a number of weeks.
KDE has removed nothing. Using double clicks for icons is still an option within KDE and has been for a long time. There's probably no reason why button order couldn't be the same.
Only one thing, though... Why is it the only time the freedesktop.org project gets any work done on it, is when both groups are shamed by some event. This last one was almost certainly because of the RedHat 8.0 Bluecurve controversy. Is everyone so isolated in their own little Desktop Environment world that they are oblivious to everyone else?
Of course not, because I think single-click does provide a measurable improvement.
>You should use the Gnome/Mac order since that will be the most natural for both LTR and RTL locations.
No, that's according to some hand waving by Mac lovers. Changing button order would increase productivity by a factor of zero and would just annoy people for a time. I think people say it's better because when they finally get used to it, they are happy.
The button order probably doesn't have anything to do with locale (if that means language settings, BiDi or not). It has to do with whether the user is left handed or right handed. As a right-handed user, I tend to quickly fill up an options/prefs dialog and click OK. This means pulling the mouse downwards towards me. It tends to send the cursor towards bottom right, which is the right place for the OK button for right-handed users. For potentially dangerous options, it should be otherwise. This is totally the other way round for left-handed users.
--
Just my opinion
KDE team doesn't read so much litterature. They perhaps just listen to their users ?
I think it is much better than reading thousands of bok explaining that your eyes is more quick to look on top than on bottom, that the mouse is better on the bottom right, that moving mouse from left to right is more easy than bottom to top,...
I use KDE and use Gnome2 too (I have two machine with last versions of them in each one) and I am always confused by the order of the Gnome buttons :( Probably because I read text from left to right and so the left button is the first I read. So for me it is much better to put "OK" on the left.
If KDE adopt Gnome order I hope there will be a way to put them back in the Ok-Cancel order :)
Just listening to the user is not the answer either. You should do *both*: listen to the user *and* read litterature.
Reasons to read litterature too:
1) The user doesn't always know what he wants.
2) What the user *thinks* he want may not be what he really wants or the perfect solution. Humans are not aware of everything.
3) There are some things that can be done better, but the user is not (always) aware of them.
And the GNOME button layout is a bit confusing the first few weeks. But having used it for a while now, it really isn't that horrible.
and so those few weeks of annoyance resulted in having an interface decision that is livable? i'd rather avoid those few weeks if it isn't going to give me any real benefits. changes that don't provide real and noticeable improvement in usability but come at great retraining costs are hardly worth it, IMHO.
And you think those who decide what the user wants are right yes ? They could be as wrong as you - by saying the stuff in point 2)
No offense but 'Never change a running System' and KDE run's perfectly so far the wide acceptance of users aknowledge this.
They are not always right but neither are the users. For that reason, you should listen to users AND read litterature, make an idea and discuss it with others. ONLY listening to users or ONLY reading litterature are both bad.
Surely you already realize this, right?
sure. i at least certainly do, but the button ordering example is a
terrible one. using gnome2 default settings slowed me down, therefore
i switched back to kde. you think windows users are likely to go along
with it?, no way.
kde is about pleasing users _and_ showing them the right direction,
but going against the grain _isn't_ always the right thing and mac os
may has gotten some things right but this is just wrong.
the okay button is the most commonly used button of the two and the
mouse user in general centers on the middle of the dialog therefore
swapping the button positions will increase mouse movement and
make it thus very likely that the user will have much further to move.
there are far better ways of solving the rtl problem than making
everyone else suffer for it.
Alex
> Probably because I read text from left to right and so the left button is the first I read. So for me it is much better to put "OK" on the left.
Yes, all is said here, it is the natural answer, so it is the good choice... excepted in some countries where people read from right to left......
Besides my other comments to the original parent of this thread, I think it is potentially dangerous to put the OK button on the default spot since doing so leads to accidental pressing of it. For users who do not know how to undo changes to a document, for example, this can cause great unintended harm.
Such individuals would be more likely to erase documents, etc.
Remove last year to reply...
I've even heard the argument, that the eye will travel from the top-left to the bottom-right (in left2right reading countries) and mainly focus at the corners, and that you should therefor place the most frequently used button in the bottom right corner.
I have to disagree to this point, because once i see a row of buttons, i read this like text - that is left to right. This tendency totally overrules the "bottom right corner"-effect unless you've gotten used to having the unusual Cancel-OK order.
This is why i firmly believe that even people who are not used to computers at all, will look at the leftmost button first. And thus the OK button should be the leftmost button, due to it being the most frequently used one.
That's why i fully agree with Shift and Alain on this matter!
You're forgetting that things exist in the context. And the context is that most KDE users are used to the current layout, so switching it around will hurt existing users, since it'll break their habbits. The difference in usability has to be tremendously big to justify any change like that.
Oh, and is the Apple research published (and peer-reviewed) someplace?
> Oh, and is the Apple research published (and peer-reviewed) someplace?
i wish. AFAIK almost nobody openly publishes their usability research. sort of like when nobody published their source code in the software development world.
optimistically speaking, i think we may be seeing the start of "Open Source" usability. this may well have similar impacts on the usability industry that "Open Source" coding has had on the writing of source code.
BREAKTHROUGH RESEARCH REVEALS PROPER ORDER OF BUTTONS
I just finished a $2.5 million 3 year R&D project. The final result is that the "OK" button be placed on the bottom left of the window, and the "CANCEL" button on the bottom right.
This conclusion should be adopted by all Open Source dekstop projects because it costed 2.5 million dollars and lasted 3 years. If you disagree with this conclusion, you do not know enough about UI design to make a valid argument against this conclusion. This is the One True Way to put buttons on a window.
[/ihopeyouknowimmakingfunofyourassforbeingsofuckingclosedmindedandabrainwashedappledrone]
Thank you for your time.
Of course there can be a button order which is right for me and wrong for you.
Whatever button order I'm used to is right for me, and will of course be wrong for a long-term mac user.
The Gnome button order is very wrong for me, because I'm forced to use WinXP at college, and have a dual-boot system at home (which means I have an option to boot Win2K3, if I want to.. I don't).
Having to switch between two very different systems are very problematic, and annoying, which means lower productivity and a lot of frustration.
However, this is because I'm used to another button order. Anyway, changing button order should be easy to do. Besides that, the eye is in the lower left corner, when you get to the buttons, and not in the lower right corner. The eyes go from upper left to upper right, and from upper right to lower left, and from lower left to lower right....
So button order should be (from left to right in a LTR locale, like european languages): Yes No Cancel (unless you're coming from Mac-worldm and are used to the mirrored button order - in that case: Stick to that one).
And when that's finished we can start the discussion on whether OK is a sensible label, or whether it should reflect what action will be taken by clicking the button (ie label the buttons Print/Cancel rather OK/Cancel)
"Print/Cancel" is clearly superior but many developers seem not to realise this
i don't know off the top of my head what the gnome guidelines say, but the KDE guidelines do recommend descriptive labels vs "OK" / "Cancel"
http://developer.kde.org/documentation/standards/kde/style/dialogs/simpl...
Hmm. As a lot of people are pointing out, the button order thing is a thorny one, with some irreconcileable demands. On the one hand, there is a smallish but clear benefit to having the Apple/Gnome button order; on the other hand, people do _not_ want to relearn stuff, even when they ultimately benefit. A classic example of this is the Dvorak/qwerty issue. Granted, the relearning for using Dvorak is many times larger than for button order, but then, so are the potential benefits.
What Gnome and KDE (and every sensible desktop) do get right, on the other hand, is "make the save choice the default". I honestly never reflect on varying button order as I work on different desktops. Instead I rely on being able to just choose the marked one (or just press return) when I don't want something to happen, and choose the other (with mouse or TAB) when I do. As long as that principle is obeyed by developers, the order is no longer truly significant.
And don't forget that a different desktop looks and acts different in many ways, giving a clear contextual difference to a user, who can pretty easily learn different behaviors depending on the context/desktop. Having, as someone here suggested, a common desktop setting for stuff like button order, single/double click and so on would be great. Everybody wins.
/Janne
I've seen some research which claims the Dvorak layout does not improve speed. Others say it does... Sounds like the button question to me.
Remove last year to reply...
I've seen those too, and all of positive research too.
In the end, it took actually trying the layout for over a month solid to realise how much better it really is (at least for me). I'm not going back to Querty ;)
Dvorak was certainly biased in his research to prove the validity of his design, but the work he put into the design itself is top-notch imho.
A classic example of this is the Dvorak/qwerty issue. Granted, the relearning for using Dvorak is many times larger than for button order, but then, so are the potential benefits.
And do you think you would benefit from switching from Qwerty to Dvorak everytime you switch from a KDE app to a Gnome app ?
What's funny, though, is that you can't tab between buttons on MacOS X.
Usability, anyone?
Unfortunately, the research on this is still a little bit thin, either way, IMHO.
However, I believe it was wrong for GNOME to switch the button order in the 2.x series after already having done the opposite in 1.x.
This is bad consistency. It's like Microsoft suddenly deciding to move the Close button over to the left side (which happens to be where I like it ;). Mass demonstrations would follow.
Only if you are willing to significantly overhaul the UI is such a change as modifying the button order justified.
Remove the previous year to email me.
Buttons should make sense in the context they are used. "ok" and "cancel" are doing nothing so they should be renamed to whatever fits into the context. After this is done it won't really matter anymore in what order the buttons are since the user will be quicker at understanding the purpose of the buttons instead having to combine the abstract thinking of "ok" and "cancel" with the context related feeling of doing something dangerous. This feeling overcomes the user when he's unsure about something, and abstract "ok" and "cancel" buttons only give a feeling of security if they stay at the same place since the place actually implies which of both is more dangerous to use.
(blah blah and so on and so on)
I really think that this idea is overdone. There are disadvantages to having OK and Cancel, but there are also advantages. The disadvantage is that the buttons don't give you contextual info as to what exactly will be done. However, this should normally be done by the dialog as a whole.
The advantage, OTOH, is that "OK" and "Cancel" carry a lot of information because the user has seen them so many times before. Imagine if we _never_ used "OK" and "cancel". Then the user would have to read the dialog buttons and think about their meaning every time that we wanted to confirm or cancel a dialog! For example:
Print this file? [OK] [Cancel]
would become
Print this file? [Print] [Don't print]
and
Configure toolbars.....
[OK] [Apply] [Cancel]
becomes
Configure toolbars.....
[Reconfigure and close] [Reconfigure] [Don't reconfigure]
I really don't feel that these examples are adding anything. And they would take away the valuable association the user currently has: "OK" means confirm my choices in this dialog; "apply" means apply my choices without closing; "Cancel" means close this dialog without applying my choices. Even though I don't think "OK/apply/cancel" are very good choices of words ("Cancel" doesn't cancel once you have hit apply), this still works quite well across many contexts.
Dave
I just hope this development will be accepted in both communities. I is a Good Thing to have the choice between two desktops. but it's a bad thing if the choice of desktop rules the choice of applications. The ultimate goal would be component embedding between GNOME, KDE, and other Apps. Can we have gnumeric shets in OpenOffice text documents in KPresenter presentations, please?
Cheers
NO