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.
They did all the work already.
AFAIK, it's no different than M$ using Apple's ideas for windows... (Even the courts agreed on that!)
I'm entirely for making things more usable for the purpose of expanding OSS' user base, but we can't forsake the power users to do it, otherwise, the people most likely to contribute (either via code or helping others) won't.
Don't leave your mind so open that your brain falls out. Don't close it so much that you cut off the blood.
that this usability group for open source software is a great idea. I wish there was something similar for free software, which I am sort of into. Great news, though, I am sure everyone will agree with me.
Karma: Positive (probably because of superiour intellect)
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.
Not once in my life have I ever thought anything along the lines of "What OSS needs for general acceptance is a usability group."
The problem I see is that you get self-proclaimed usability experts such as Eugenia at OSNews who think that their complaints are in the interest of usability when they are in fact just being anal, or coders who think they're doing usability a service by doing all sorts of crazy things (cf Havoc Pennington, who is a fantastic programmer, and his campaign as a self-proclaimed usability expert to see how few options he can get gnome programs to present to the user). These people don't have any idea what usability actually means. Not that I have a grand set of interface guidelines or anything, but usability has a lot more to do with annoyances like the farce which was the RH8 menu mess than with dialogs having "OK/cancel" where they 'should' have "yes/no", or whether dialog buttons are inconsistent across the system as to being truly rectangular or having rounded corners.
I find Jakob Nielsen to be an excellent source for scientifically valid usability information. In other words, his advice is based on actual research, not just whatever his cat Mittens told him (anyone know this reference?)
(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
#9: Make users feel like you pay attention to their suggestions and act on it. No-one's going to bother submitting feedback if the developer doesn't use it.
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
Who knew that the best way to do usability testing was to get slashdotted :)
:)
The problem should now be fixed.
As far as being a usability expert, I don't make that claim. I'm not but I hope that together, we can do something about usability in OSS software
TNL
Check out http://www.tnl.net/blog
Is another usability group, so they can compete.
I'm glad readability isn't an issue.
- dave f.
In retrospect, I think I was a bit too harsh with my "his cat Mittens" comment. My apologies to Mr. Louis.
The links are decorated with a dashed line. It is hard to see (and ugly), but there is a decoration.
Jilles
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
No problem... It was to be expected :) After all, I shouldn't try to do something like this when my own site has its own usability problems...
:)
BTW, if anyone finds any other usability issues with TNL.net, don't hesitate to point them out. Might as well improve my own site in the process
TNL
Check out http://www.tnl.net/blog
This change was added after the orginal post. See above.
I'll try to make it prettier... This was a quick fix :)
Check out http://www.tnl.net/blog
When asking for comments on your program, ask the most obnoxious, rude, blunt, asshole you can find, preferrably one who hates you. They will more than likely be very blunt and brutal about anything they think is wrong with your program.
Do not ask friends, family, or anyone who is very polite and shy for constructive criticism. They are likely to go easy on you.
social sciences can never use experience to verify their statemen
Dork. One would think that if "philisophy" were so important to you, you'd at least know how to spell it. Speaks volumes about the relative merits of a Mensa membership, indeed... in fact, two of the biggest idiots I know IRL are the local Mensa secretary and CFO. I scored 157 on the Mensa test and refused to join, in the fear that a Mensa membership card would turn me into another clueless asshat.
Both forms are correct. You would know that if you were in Mensa. Otherwise you just sound like an a-hole.
copy, cut, paste, and undo will finally be the same on everything.
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.
It doesn't matter whether it's hard for them to use because of lack familiarity or just absolutely poor design. The point of your software is that users should be able to get used to it quickly.
It's called the user model. The user model is always right, period. If you are going to switch from the user model to something else, your something else better be at least 100% better. Otherwise, it's not worth the initial cost. Users will never take a second look at it.
The whole point of a GUI is that things should be intuitive. How would you expect to draw something free-form? Probably a pencil for a thin line, and a paintbrush for thicker "painting" strokes.
See Joel on Software, and User Interface Design for Programmers (this is a particularly good read, which *nix developers are direly in need of):
Chapster 1: Controlling Your Environment Makes You Happy
Chapster 2: Figuring Out What They Expected
In short, your program is easy to use (and learn) if it behaves exactly like the user thought it would. The simple fact is, users are not very patient (most of them). And they sure as hell don't read the fucking manual. Why should they? It's a waste of time. When you buy a car, do you read the entire manual before using the car? Do you even read the manual at all, unless you absolutely have to? If they can't figure out how to use your program just by sitting in front of it, then they probably aren't going to bother ever using it again.
Face it. First impressions matter, right or wrong. Maybe Netscape's CTRL+[ really is a better way to go back when browsing the web, as opposed to Internet Explorer's ALT+= (left arrow), once users have associated that key-combo with back. But the problem is that 90% of all users think that ALT+= means back. By changing that, you are pissing them off. This makes them frustrated, and the 15 other "little improvements" of your program will piss them off even more. Which means they won't user your product -- "this fucking sucks", is surely what they will say. And, if you analyze it, ALT+[ isn't necessarily better anyways. Though that key-combo may be eassier to ready, the keys are closer to other keys, so it's easier to make mistakes; furthermore, it is not intuitive. An arrow is intutive for "go in that direction". Brackets are in no way intuitive for that.
When doing user-testing, you do not correct for various factors. You do not say, "oh, well, he's a life-time PC user, or a life-time Mac user, so I should give him or her time to "get used to" my program, then see how well he or she does". In real life, users don't want to "become familiar with your new way". Think about how arrogant it is of you to ask that of them. The user does not want to get used to "your better way" of doing things. Worse yet, they really don't want to get used to your "just as good way" of doing things. What if a car-company made a car with a wheel that operated like the joystock on an airplane...turning it left really turns your car right, and turning it right really turns your car left? Or what if they put the brake pedal to the right of the accelerator? I hope you get the point. Users aren't going to stick with your program if it's hard for them to learn. They will dump it, and use something that's easier for them to learn, irrelevant of the trivial improvements your program may have once they get "familiar with it".
The thing to do is always match the user model. That probably means doing what MS for many things, unless your new way of doing things offers at least a 100% improvement (e.g., having a universal menu-bar at the very top of the screen like Mac would be good, as would bleeding other stuff into the four corners, and screen edges).
social sciences can never use experience to verify their statemen
I can never get GIMP to do what I want. I'm most frustrated about editable text in pictures. Maybe I don't understand the GIMP's way of doing things and I'm "a bear of Very Small Brain"[TM], but I've given up trying to use the GIMP. The Chewbacca Defense makes more sense to me.
Personally, I think PaintShop Pro and Ulead GIF Animator have a far more intuitive design.
With Ulead, at least, there's a smooth transition between using it as a paint program, using it as multi-layer paint program, and using it as an animator. You don't have to learn everything at once.
As for the Multi-window versus single window argument, why not use the GNOME approach. MDI in GNOME comes in the form of tabs that can be detached and reattached. If single-window apps are your preference, just leave things in tab mode. If you like multi-window apps, simply detach them. Best of all, you can choose a hybrid model of tabbing related views and detaching unrelated views.