Slashdot Mirror
OpenUsability and KDE: Cooperating on KPDF
sultanoslack writes "More from the world of usability in KDE -- there's an interview up where Albert Astals Cid, the KPDF maintainer, and Florian Grässle, a usability engineer from OpenUsability on working together to make KPDF more usable and some of the challenges in working together in a developer / usability engineer team. We've been seeing more from the OpenUsability folks lately, and they'll also be present doing a talk and staffing a booth this week at LinuxTag, Europe's largest Open Source conference." This interview-with-screenshots provides a neat look at the interaction of usability concerns and software development.
The OpenUsability group is exactly what is needed in the Linux/open source community right now. Standards on how software should be layed out and behave is one of the major setbacks in the open source community. It seems as if just about everyone has their own version and great idea on how an application should be layed out. This is one reason (just one) why Windows will continue to have an edge in the desktop market. On Windows you can open just about any application and already know how to use it (at least, at the most basic level). If you've used Microsoft Word then you've got a head start on knowing Internet Explorer, Notepad, and Calc.exe.
"...if people respected copyright more, like you guys do with the GPL so religiously, [the DMCA] wouldn't be necessary."
What's the difference between Linux & OS X? Usability. And that makes all the difference. HUGE difference. KDE is great, Konqueror is nothing short of amazing in its versatility, but the lack of polish can really hurt Linux distributions. Do you want to spend your days trying to figure out why your scanner suddenly doesn't work well under the new Mandrake/Fedora/SuSe or do you want to use your scanner? Usability is important--even for Geeks--because allows you to accomplish what you need/want to do. If you enjoy trying to fix things, that's great, but most people need their computers for work/play and don't have the time or inclination to troubleshoot their main desktop computer.
Eventhough this doesn't relate to GUI applications, just imagine:
/
:).
$ rm -fr
This will erase the whole tree! Type "Yes, I know" to continue: _
Even for correct input, an application should prevent you from making dangerous actions and things that, while for a computer are perfectly legal, might be an error from the human point of view.
The rm example is just an example. You have to take into account the type of users that are using your application, if they're experts or not, etc. Well, sometimes a little bit of error prevention from the application can save your ass
The problem is, half of those dialogs used GTK2's Yes/No buttons (red/green circle) and the other half used GNOME's yes/no buttons - green enter symbol and a red X. This is very inconsistent and confusing to the user.
...with the buttons "Yes" and "No". This sucks. You basically have to read the entire alert to even know what's being asked, and even then there's some ambiguity. Does "Yes" mean yes, I want to save disk space? Does "No" mean I don't care about my hard drive, and want pretty fonts?
Not nearly as confusing as why everyone insists on perpetuating the Yes/No/Cancel paradigm. I don't see why no one else is adopting the new Apple-style verb-based dialog buttons. For example, in a Linux install I might see:
"Your screen's fonts are of a really low resolution. Do you want to install 100 dpi X11 fonts? This will make the fonts look better, but you may want to not install the fonts to save disk space."
A vastly more usable dialog would have buttons labeled "Install Fonts" and "Don't Install Fonts." No ambiguity, and the dialog itself is much easier to recognize.
Safety features on command line tools might be nice, but it would be hard to incorporate that sort of thing in a UNIX environment where the tools are often being called from shell scripts and such. If simple command line utilities are going to try to keep me from shooting myself in the foot, I want a flag for releasing the safety.
/' will erase the whole tree, your permissions are seriously messed up.
P.S. If '$ rm -fr
Remember RFC 873!
The first thing and most important thing missing from kpdf is the chapters view. what do i do with some small thumbnails if I want to see the chapters to jump there quickly. yeah and references in the pdf, they should be usable in kpdf, because if you have a 200 page manual and you want to jump from the index to the chapter and it works in all other viewers but not in kpdf, than something is wrong here.
"Freiheit ist immer auch die Freiheit des Andersdenkenden" - Rosa Luxemburg, 1871 - 1919
First, errors typically mean that the user did not experience the expected outcome, and is not typically a judgemental statement. My unmderstanding of this is that a human will expect certain things, and will act based on past experience. For instance, on a web page certain colors have come to mean visited links, while others will attract attention. So, to maximize success, one want to follow existing guidelines and use colors so that the most often used content will be highlighted.
For the OS, this means that the user is able to do what he or she expects. For instance, if the OS brings an unrequested(by the user) inactive windows into focus or allowing dialog boxes from background processes to the foregroung will often lead to user error. The OS should therefore typically allow the user to work in the foreground application while attracting the user attention in a non-hostile way.
Other things quickly come to mind. The default box in an exit query should neither be save or discard, but cancel. We figured this out many years ago in vi. Autosave is fine, but it should not save over the actual file. Unlimited undo is a blessing. Having the menus in the same place and in the same order utilizes the human habit of repitition to maximize succes.
Like in any process much of the success of the human factor comes from the way of the design. All to often the designers will blame the user when it is really the incompentent design. A sucessful design makes the next logical step the path of least resistance. For most tasks, it should not require years of training to utilize the interface.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
Someone points out a usability problem with something and it gets modded as Troll. No wonder Linux/OSS usability is going nowhere!
Reverse chronology is a problem? Would you rather have to scroll through vast amounts of forum topics or emails or what have you to get to the most recent ones? No. I think chronological listing is a far worse option for such a thing.
Perhaps you should be arguing for a choice, not forcing forward chronology upon others.
Unless you're talking about within the forum topics themselves, in that case, that's plain strange, and I see where you're coming from!
What's wrong with it? It violates proper UI design!
A properly designed dialog box does not force the user to think about what the choices will actually do. Dialog boxes with a long string of ambiguous text and Yes/No buttons violate this concept, because the user has to read the text very carefully before he makes a choice. This forces the user to stop thinking about what he was trying to actually accomplish with the application in the first place and forces him to figure out what the developer actually meant. This leads to both mistakes and a loss in user productivity. If the buttons are clearly labelled with what the choice will actually do, the user is less prone to make a mistake.
Show me on the doll where his noodly appendage touched you.
It's not that the user shouldn't think about what the choices will do. Of course he should. That's the whole point of the box, to present options. (One of the repliers obviously misinterpeted your post in this way.) But the user shouldn't have to ever think about what the choices are, or have to stop to figure out how to properly interpret the text in the box. It's not about reading comprehension. It's about presenting a choice as clearly as possible. Verb-labeled buttons make the choices as stark as possible, so the user can spend his time weighing which choice is better, instead of working out what the heck the choices actually are.
Longer explanation of why Yes/No just never works well:
The box needs to be long enough to explain what it wants to do and why it wants to do it. For example, "Do you want to install 100 dpi X11 fonts?" makes absolutely no sense in isolation. Why is the computer asking me such an arcane question? You have to add the reason, like the GP did: "Your screen's fonts are of a really low resolution." For non-obvious questions like this, you also should explain why you might or might not want to choose either option: "Do you want to install 100 dpi X11 fonts? This will make the fonts look better, but you may want to not install the fonts to save disk space." Altogether, this makes a well-written and informative box, but it's long. Yes/No doesn't work after a paragraph. What part are you saying "Yes" to, anyway? But with verb-labeled buttons, it's instantly obvious. You can read and understand the text, and then don't need to waste any more time understanding which button does what. It's instantly, idiot-proofily obvious. That's good interface design. Yes/No works, barely, when the entire box is one statement, like "Do you want to save changes before quitting?" But even then, verb boxes are more efficient. With Yes/No, you need to read the whole thing very carefully, as carefully as the font example above, to make sure you aren't screwing yourself by instinctively pressing "Yes". If the buttons were labeled "Save" and "Don't Save", you can safely skim the box, recognize it's the same as always, and know that "Save" will do exactly that. Little things like that separate a good interface from an infuriating pile of slag.
It's not "dumbing down the UI", it's making the user's choices explicit to help him avoid mistakes. This should be the goal of all UIs. Think about it. Is it easier and less time consuming to use an unambiguous UI? Sure it is. Wouldn't you much rather use a simple to understand UI? Sure you would.
The user shouldn't have to figure out what the developer means by "Yes" or "No" in relation to the message in the box. Dialogs with a Yes/No choice are hostile to the user and time consuming for even expert users (i.e. you can't just click a button without checking if it's the correct one first even if you've encountered the dialog before). When the buttons explicitly tell the user what the choice is going to do, it is easy for the user to pick out the correct choice without having to think about whether "Yes" means one thing or another. Furthermore, when the choices are explicit, expert users can move through the dialog much easier.
Maybe an example would help. Consider if the following horribly screwed up message was displayed by a dialog box:
First imagine this message with buttons labelled "Yes" and "No", and then imagine it with buttons labelled, "Erase C" and "Don't Erase C".Do you see how it's explicitly obvious what is about to happen with the second set of buttons no matter how screwed up the message in the dialog box is? The user does not have to figure out what action the button is going to perform in relation to the message, because it's obvious.
Do you see that no matter how complicated the choices are, it's always easier for the user if the actions are explicitly labelled?
Show me on the doll where his noodly appendage touched you.
Except the "usability" rants get modded up to +5 Insightful, while the power user rants either get modded down, or get flamed down by "your attitude is exactly what I'm talking about"-zealots.