OSS Usability Group Forming
cpfeifer writes "Tristan Louis has started a new group focusing on Usability in OSS products. Among the goals are: examining the state of he usability union in existing products, forming a set of standards and practices and PR for products that make usability strides. Also, check out the discussion on Metafilter."
Why does "free" software need a different set of UI guidelines from "open-source" software? Technically, the two are exactly the same. It is only philisophically (and sometimes legally) that they differ.
I can't say that I don't give a fuck. I've just run out of fuck to give.
Programs like X-CD-ROAST are nearly unusable without documentation on the side. The *acceptance* of GIMP and blender only has to do with the fact that they are the only free programs that do what it sets out to do.
Programs that copy or build upon existing usable programs tend to do really well at being accepted really fast in the OSS community. Check out XMMS, Evolution or Firebird. Are their interfaces usable? Are their power immediatly recognized by the end user? Yes.
Thanks to Kim Woelders, Enlightment now has code in CVS to make it work with GNOME 2, because sawfish and metacity are woefully inadequate (can't remember window states(position, desktop, etc), VIEWPORT functionality is largely gone (2D edge flipping, windows tiled across 2 viewports, etc). Yes, I know about the various configuration and code hacks, but even with them, neither one is as complete as Enlightenment for what I use). Of course, since Enlightenment wasn't designed with GNOME 2 in mind, certain things don't work as well as I'd like, but at least it's actually functional and doesn't try to restrain me like a parent wanting to put an active kid of ritalin. Further, after more than a year of being released, GNOME 2 doesn't even have a menu editor since they just decided to scrap the old one. To me, the GNOME 2 developers got so caught up with what "usability experts" said and their own egotistical desires (EVERYONE must use the desktop the way I want), that they forgot to actually make the thing functional.
Don't leave your mind so open that your brain falls out. Don't close it so much that you cut off the blood.
If you can configure something, don't do it in an environment variable. If you must, make sure that the program doesn't mysteriously break when someone tries to run it from a different account. Print out a message or something.
Put those configurations into a configuration file. And if that config file doesn't exist, have the program automatically write or suggest a configuration that should work out of the box.
example: A long time ago, Java wouldn't work unless you had a CLASSPATH set. You needed to set it to get to the classes that almost every Java program required. Later versions would automatically figure out the proper classpath from the executable path, and would run even if you didn't have a CLASSPATH variable set.
If tits were wings it'd be flying around.
Possibly the biggest thing that would improve usability, in my experience; When a user double-clicks an icon, make it DO SOMETHING immediately. Switch to an hourglass pointer or whatever, and keep it until the window actually opens. This is probably the only major issue my wife and kids have with Linux. They can't tell if the double-click did anything, so they doubleclick again until the windows(s) start opening.
455fe10422ca29c4933f95052b792ab2
You said:
...).
(6) User testing, user testing, user testing. Grab someone and ask them if your program is easy to use. Sit them down in front of it -- without a manual -- and ask them to do something that the program was designed to do. If they can do it, then the program has good design. If not, bad design. If they can't do it, or if it took them a long time, ask them what they would expect, or where your program was confusing.
That's just wrong. Really. Calculus is a great tool -- but its too complicated for a lot of people. Certain problems benefit.
Just because some people can't, or are unwilling, to learn doesn't mean that the thing must be "dumbed down".
Take the editor as an example. I am typing this into the Web Browser text box. "Passive memory" galore. Yet I feel uncomfortable. My usual editor is VIM. Oh boy, is it *hard* for someone to learn! But it is very usable and powerful. Yes, VIM could be "dumbed down" to be usuable; it would then be exactely what this text box is (how do I spell check my posting -- without leaving the browser, and then cutting and pasting? how do I
And why would I have context menus that I never use? VIMs job is to accept my commands and macros and do them with as little fuss as possible. The true test of a good UI is that it works over a long period of time. VI and EMACS have had a 20+ year history to verify the functionality of the interface. Yes, there have been changes and improvements, but VI and EMACS seem to have "won". There have been other attempts, but not many people use them anymore Remember the "WordStar Diamond"? How about the BRIEF HOME-HOME-HOME and END-END-END?. If these had been good ideas, they would have been incorporated into later products. Borland did keep the WordStar sequences alive for a while, but they are almost completely dead now.
So, don't worry about the UI. "Usability" is what actually lasts. And, with Open Source, the guts can be kept and the UI altered (or the other way around). And if an idea sticks around, it's good. May not appear "easy" at first, but people do come around.
Ratboy
Just another "Cubible(sic) Joe" 2 17 3061
90% of all desktop users are using MS. If they attempt to migrate to GNU/Linux and no key-combinations work as expected, they will not think the software is good.
90% of all consumers in the US eat greasy hamburgers and fries. But I don't see fine restaurants scrambling all over themselves in an attempt to reproduce that particular bland flavor of fries left too long under the heat lamp.
The point of your software is that users should be able to get used to it quickly.
Absolutely not! The point of my software is that users can be able to use it for a long time. Newbies become intermediate users who become experienced users who become experts. To ignore everyone but the greenhorn newbie is ludicrous.
If I can make my software intuitively easy for the new user while keeping it powerful and flexible enough for the expert user, I will do so. But it's rarely possible. So I choose to support my existing users instead of those demoing for the first time. I wish I could please everyone but I can't.
I do not believe in catering to the lowest common denominator. I have a much higher regard for my users than that. I will provide tutorials for my software. I will provide context sensitive help for all controls. I will attempt to discover what works for them and what does not. But I will not slap my more experienced users in the face just to please someone trying out my software for the first time.
My company makes premium medical ultrasound systems. We are the leaders in the world in this industry with approx 60% marketshare. But we recently got bought out by a huge multinational. Our "classic" platform is still number one in the market. Their "new" platform that was to replace ours is failing miserably.
Both platforms had teams of UI designers working on it. For the "classic" platform our UI designers expected the systems to be used by people trained in their use. After all, this is medical diagnostic equipment, not a word processor. We never expected that some greenhorn newbie would be using it. Much of the UI design was done not by copying another platform, but by creating mockups and actually seeing how people used them. An extraordinary amount of effort was taken into gathering use metrics. Because of this, the "classic" platform has received many UI awards and is the preferred UI of users.
On the other hand, the "new" platform is a joke. Just as much UI manpower was placed into it. But the UI emphasis was to make it easy for the newbie. The user interface was deliberately designed to resemble the Windows desktop, because that's what the users were supposedly used to. Too many controls on the keyboard was too confusing, they said, so the elminated most keys and replaced them with onscreen icons and a playstation-style control pad. It's absolutely unusable for its intended purpose. It does sell somewhat well in Europe, but the reason it does is because physicians and sonographers don't make purchasing decision in Europe like the do in North America. Instead hospital administrators or government bureaucrats do. And since the "new" interface is easy enough for the non-technical admin or bureaucrat to use, they like it. But the people who actually have to use the system can't stand it. Which is a shame because underneath the skin it really is a fine system.
A Government Is a Body of People, Usually Notably Ungoverned
Maybe for specialty software you have a point. But your entire case is just a situation of the user model.
By changing your program to a different UI, and eliminating useful key-combinations, you ignored your target audience's user-model, and this pissed them off. Naturally.
There is no reason why the vast majority of programs cannot be both easy to learn immediately, and very easy and fast to use for more advanced users.
The user interface was deliberately designed to resemble the Windows desktop, because that's what the users were supposedly used to. Too many controls on the keyboard was too confusing, they said, so the elminated most keys and replaced them with onscreen icons and a playstation-style control pad.
As I said above, they ignored the user-model for their target audience. This invariably leads to disaster.
There is no reason why you cannot have both onscreen icons/buttons so the program is easier to use for those just learning it, or casual users, and key-combinations so that people who do ultrasounds several times a day can blast through it quickly.
For doctors just learning to use your program, if they have to read the manual, then it will simply annoy and frustrate them. Quite frankly, they have enough to memorize already, enough stress.
A good thing to do would probably be to have a logical menu bleeding into the top of the screen, and perhaps a toolbar bleeding into one of the other edges, with the key-combination for each function to the left of it (if it's a menu item) or underneath it (if it's a button). This way, new users are automatically trained to be advanced users, simply by doing things the intuitive but slower way.
Your company, despite it's success, probably created a significant user-model problem. Because of it's 60% market share, you created a user model for a ultrasound. That user-model, however, was probably different than the user-model for Windows.
Thus, people using your program and switching between it and windows probably experienced the problems that come with switching between two user models. After using your ultrasound program and goign to windows, they may still be in "ultrasound mode". Key-combo Y pastes in Ultrasound, but that same key-combo does something else in windows. This is a frustrating annoyance for people who use programs with different key-bindings.
But to alleviate that problem, you have to go against the user-model you created, another problem. (of course, the real problem was dropping key-binding support all-together).
social sciences can never use experience to verify their statemen