Slashdot Mirror
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."
Just what OSS needs for general acceptance.
1.) Don't use Blender as a model.
2.) Putting vowels in command names can be helpful.
3.) If you're a Perl programmer - don't try to cram the whole UI into 2 lines of code just because you can.
One thing (in my experience) that turns people off open source software is that the interface is almost the same as their previous OS (Windows or Mac). However, one or two things different are minor annoyances that turn them off.
OTOH, having a completely different UI may be an improvement. The user doesn't have any expectations because it's completely different. Thus, they don't panic when a menu item is under a different menu, or a key has a different function.
This is just a thought. I haven't done any experimentation on giving newbies a completely different experience.
Note that I don't recommend abolishing windows, menus, etc. Just don't make it look the same as another system.
I can't say that I don't give a fuck. I've just run out of fuck to give.
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.
Follow the links to his papers on usability and you end up at his site.
On that site, he sets his links as bold, with no decoration, and the same color as the rest of the body text. Though, some subheaders are also bold (but not links). Therefore, you can't always tell that links are links, and some things that aren't you think might be.
This isn't exactly the type of thing you like to see inside of a paper explaining how to make usability better by keeping things familiar for the user.
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.
(1) Always use the 4 corners of the screen, as well as the screen sides. Don't ever place anything that's interactive just a pixel shy of the screen-edge.
(2) Form follows function, not vica-versa. Don't focus on making an "appealing" UI. Focus on making one that works very well for the tasks at hand.
(3) Passive memory, not active. People have a huge capacity for passive memory, and can remember things passively very quickly (that is, they recognize it upon seeing it). Users already have enough stuff to memorize, so don't make them memorize bizarre key-combinations.
(4) For a guide to a desktop, see here (explanation here), and here (explanation here).
(5) Remember to have strong software-support. The reason I like Gentoo so much is because of the helpful and friendly message boards, as well as the excellent documentation.
(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.
(7) Have context menu's for everything in your program with "send feedback on this". E.g., if someone right clicks on the menu-bar or a specific sub-menu, they send feedback on that. You thus instantly know what their feedback is about, and it makes it easy for them to send feedback.
(8) Actively seek out the opinions of those who download your program and use it. You can do this by creating a message board, newsgroup, etc, and specifically asking what they think about x, y, and z.
social sciences can never use experience to verify their statemen
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
I'm glad readability isn't an issue.
- dave f.
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
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.
Not at all. The reason the customers did not like the "new" interface was not because they were used to the "classic". They disliked it because it was an inefficient interface. The interface interrupted their workflow. It was easier to learn but harder to use. And usability is about "use".
Another analogy is WordPerfect versus MSWord. Back in the day WordPerfect was king. There were key combinations that did everything and the menu itself was very rarely used. Even when the graphical version of WordPerfect came about, the users in large part ignored the mouse and stuck to the keyboard. WordPerfect was efficient. So why did MSWord become king? Because there were more new users of word processors than old users during the entire decade of the nineties. The new breed of word processing professional is no where near as efficient as the old WordPerfect typist.
Usability isn't just about learning how to use the software, it's more about how efficient the software is to use. Please, make your software easy because I am a lazy person. But don't make it simple because I am not a simpleton.
For doctors just learning to use your program, if they have to read the manual, then it will simply annoy and frustrate them.
Sorry for the pause there, I was spewing Dr. Pepper out my nose...
What's more frustrating than the doctor having to read the manual, is for the doctor trying to perform twenty ultrasound exams on an unfamiliar system during a workday.
I'm sure it's frustrating for automobile mechanics to read their repair manuals. But guess what? They do it because they are professionals.
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).
You just described the "new" interface almost precisely. There aren't any "key-combinations" because you have to use an ultrasound with only one hand (the other holds the transducer), but we have the equivalent concept.
---
I will agree with you 100% that there should be a common menu structure and key-commands between all systems that have menus and keyboards. But so much stuff in the UI is ad-hoc and unrelated to menus and keyboards. Just because Microsoft does it and 90% of the users use Windows does not mean that it's usable.
A Government Is a Body of People, Usually Notably Ungoverned