Slashdot Mirror
How To Fix the Poor Usability of Free Software
flosofl writes "Matthew Paul Thomas has an entry on his blog called Why Free Software Has Poor Usability, And How To Improve It. While this advice is helpful and may indeed lead to improvements in many open source programs, the guidelines may be much more difficult for smaller projects. From the entry, 'Free Software has a long and healthy tradition of "show me the code." But when someone points out a usability issue, this tradition turns into "patches welcome," which is unhelpful since most designers aren't programmers. And it's not obvious how else usability specialists should help out.'" Thomas has been developing the ideas in this essay for years. The critique is comprehensive, listing 15 challenges in the way software projects, and in particular free software projects, are structured, with suggestions for improving each one.
Perhaps this article signifies the movement that has occurred with open source software. Whilst I'm sure it's been around a long while, there has been a huge increase in what's available in the last few years. Open Source software is maturing as most things do when they get older.
I'm happy with the 'get it working first - then make it pretty' approach taken by most.
The Mothership
I'm going to take issue with this. Basically you're saying if you can't do X, then your critique is useless. Just because you can't sing doesn't mean you can't critique other people's singing. Just because you don't know how to make a car doesn't mean you can't critique that horrible dashboard layout.
Okay, I know these are unpopular things to say, but I feel they need saying. These are just my opinions.
(1) "Usability" is in the mind of the user. If you learned how to use some other system first and now expect that any other way of doing
things isn't "usable" enough, that's just plain old resistance to change. It says more about you than it does about the usability of the software in question.
It seems you've never used emacs, little one.
And no, it doesn't say more about me than the software if I find that almost all GUIs in Linux are shit and that the command line is more usable.
(2) "Designers" who can't code have absolutely no business "working" in software. If you think you really know how an interface should work and look, then learn to code it. Otherwise, you're just a critic of the kind that the NYT doesn't hire.
"Right."
And neither have "coders" who can't "design" something the "average" "user" "thinks" is "usable" .
(2) "Designers" who can't code have absolutely no business "working" in software. If you think you really know how an interface should work and look, then learn to code it. Otherwise, you're just a critic of the kind that the NYT doesn't hire.
Why should software be different from any other industry? Just because the barrier to entry is, in your opinion, lower? The people who design houses don't build them. Sure, they need a solid foundation in what can and can't be done, but architects and interior designers work to a mutually beneficial end with builders, carpenters and plumbers, etc.
(1) "Usability" is in the mind of the user. If you learned how to use some other system first and now expect that any other way of doing
things isn't "usable" enough, that's just plain old resistance to change. It says more about you than it does about the usability of the
software in question.
You are a good example of the "works for me" mentality in the open source software community. "If it works for me, then it must work for anybody else, and if it doesn't, it's their fault".
(2) "Designers" who can't code have absolutely no business "working" in software. If you think you really know how an interface should
work and look, then learn to code it. Otherwise, you're just a critic of the kind that the NYT doesn't hire.
I'm sorry, what? Did you just say that if designers can't code, they shouldn't contribute? I thought this open source stuff was about the fact everybody could contribute to the program if they wanted, but apparently I thought wrong. Apparently only uber-geeks with a masterful command programming knowledge can work to improve open source software.
Design is important. Not everybody wants to learn the idiosyncrasies of software; they want it to "just work". The moment everybody thinks that way is the moment open source software gets better.
(2) People who can't cook have no business eating food and complaining when it makes them puke.
Why does my post history abruptly stop? I want to laugh at the stupid things I posted as a kid.
I am a UI designer by trade, and many is the time I have thought about wading in to a F/LOSS project in order to improve the usability of the interface (last one I considered was IPCop). While I agree with most of TFA, it doesn't seem to emphasise the real point for me, which is that UI design for free software requires radically different skills *from the designer* to that which are necessary in the commercial world.
Because people are so tolerant of awful UI, good UI designers are all about persuasion, charm, leadership and inclusiveness without losing focus. To achieve this commercially is not easy, but at least somebody has hired you in an expectation that you will do this work. Grabbing a bunch of elite coders and trying to persuade them to change their stuff is a massive challenge, even if you have VoIP, virtual whiteboards, etc. I would not expect maintainers to understand, appreciate or tolerate my intervention, mainly down to the reasons the article cites, and I'm not sure I'd be able to persuade them otherwise. Usability is not obvious and often requires a leap of faith, an abandonment of the wrong kind of complexity, and very often a lot of pain.
Still, the more we have these discussions, the better, and I hope the article gets read by a lot of Slashdotters for that reason.
"And the meaning of words; when they cease to function; when will it start worrying you?"
Humans have overall tendencies in what they find easier and harder to use. For example most people find it much harder to memorize lines of commands than to look through a set of icons, hence one of the reasons why GUIs are popular. There's real empirical research that has been done on this, some by psychologists, some by companies like Apple. While you may fall outside the norms for various reasons, that doesn't mean they don't exist.
You also need to be careful in thinking that because you've taken the time to learn something, that means that it is easy. For example I drive a manual transmission vehicle. I have no problems doing so, it is second nature to me, no more problematic than an automatic. However, I am not going to say it is as easy. I remember a rather frustrating learning period when I was getting used to the feel of a clutch and how to shift. It is easy now, but only because I have a lot of experience. It is NOT an easier way of doing things.
I find this kind of thing fairly prevalent in the OSS world. You'll need to do something and someone will say "It's easy!" and then give a couple commands to run. To them, it does seem easy, because they've trained themselves on it, however that isn't. To a new user that's very hard and uninviting.
Ignoring this issue doesn't help free software. Telling people "It is just as easy you just have to learn it," when it isn't doesn't help, they'll just ignore you. The author is trying to say that OSS people need to stop with this attitude that it is just as usable, or that usability doesn't matter to popularity. If you want OSS to start to become the dominant way of doing software, you have to make it as easy to use for the non-technical masses as possible.
There seems to be a whole movement who's against the "patches welcome" statement. I fail to understand this.
I'm an open source developer. Look at it from my point of view. I've written software that people find useful. It's not perfect, but it's useful. Then, one day, someone criticizes my software:
Person X: [...] this and this sucks [...]
Me: patches are welcome
Person X: what? what an unhelpful response! no wonder open source sucks, and you suck too!
Now, tell me. I have a job. I maintain this software in my free time. Why should I devote that time to you, for free, instead of, say, hanging out with friends or seeing a movie? You're not paying me for this software. You probably would go away if I ask you to hire me. What exactly do I owe you? I already made the source code available. Why do you criticize me for not working for you for free? Why don't you do it yourself, or hire someone to do it for you? If you can't do either of those, why don't you contribute documentation, mockups, or something else that's not technical but is still useful? Do you expect a baker to give bread to you for free when you criticize his breads for not being tasty enough?
Your high horse is showing. :) If you don't like my GPL'd interface, you are free to design one of your own and hire someone else to code it for you, if necessary. FOSS does not mean, "anything you want, gratis!". It means if you don't like something you have the freedom to change it. I have little respect for those who use the word "free" as an excuse to try to hold up developers with their limitless opinion-based suggestions. Some projects are very open to user suggestions, others are very tied to following a well-defined vision. Neither model is "incorrect". No-one is forcing anyone to use any GPL software "as-is", that's the whole point. It's not so you can get your way while contributing nothing but opinions. Though occasionally you may get lucky like that. :)
Caveat Utilitor
The command line in Unix is more "usable" because it is older, more mature,
has more features and flexibility, and is more easily extensible. I can
augment a GUI with a few lines of shell scripting with considerably less
effort than it would take to "fix" the given GUI application.
I can make some shell script both easier and simpler than just about
any GUI application and tailor it to my own needs so that it most
closely meets my needs (and thus meets my own personal notion of
"intuitive").
That said, there are still Unix/Linux GUI applications that are
more functional, simpler and easier than their Windows/Mac
counterparts that we're supposed to be cloning. The "chasing
tail lights" criticism is a very good one in this respect because
sometimes neither of the allegedly "better" platforms do it right
or better.
At this point, it's no longer a given that the Mac or Windows version
of some GUI for some sort of app is any better.
Improvement of Linux GUI's should not be limited by what Mac or Windows
applications do or what design dogmas they follow.
A Pirate and a Puritan look the same on a balance sheet.
OpenUsability
I used to work at the company which started it. It's a platform for free software developers to meet usability specialists, and so far it's coming quite good. The KDE 4 HIG was designed by us ("us" as i still used to work there at the time this was done), and the people working there are certainly bright minded people, but there's always friction at the implementation front. In my experience it's not neccessarily easy to convince a developer that a given usability decision is the right one, even if someone with a background in usability makes the proposal.
Power corrupts the few, while weakness corrupts the many.
EXACTLY! I can learn a programming language and write a program that does precisely what I want it to do. But that takes a vast investment of time to have a tool which does instantly what I need done. Perfect for people like programmers who might do one thing over and over and over and over... but not so hot for someone who just wants to do something once every 3 months.
The bane of the command line program is this: ">"
I sit there and stare at the little arrow. I want to copy a file. But all I can see is ">" What does ">" mean? Maybe I should type in what I want to do "CopyFile"... "command unknown". Great... well I'm out of ideas. Yes the interface might be faster... if you don't have to open a MAN file every 10 minutes because you forgot if it was cpyfile or copyfile or cpyfle or copy_file or copy-file or... whatever. The point is. Command lines are like code. They will do exactly what you want them to do once you know the magic incantantation with the right pronunciation. But if you know what you want to do but have never used the software before you're SOL. This is why I love node based tools. When I'm learning a new programming language I have no idea what classes and functions exist. I might even know the exact tool I need "I need to find the position in a string where "hello" is found". But translating that into a class name is a game witchcraft and endless help document scimming until you happen to find an arbitrary function name which does it.
GUIs show me my choices. Yes they show me my choices every single time. But I like to know what it is I can do. A BAD gui doesn't show me my opportunities. It buries it in a menu which is as bad as burying it in a command line command somewhere. But even a GUI is better than a command line while learning because when you finally do find the command you want to do... you can act on it instantly! No closing the MAN file reciting "'copyfile 'filename' -f -s-t-u #silent *underhanded" in your head hoping you don't forget it before you type it in.
Again many developer tools can operate on command line because the functionality barely changes from version to version. In all of the software I use every release adds hundreds of new features I need to learn and I need real time feedback on changes I make... I can't wait to execute a command to see if it's right.
Take SQL as a perfect example of a command line tool. SQL has barely changed in its command structure in 15 years. Of course you're super fast at writing complex SQL scripts that deliver exactly the information you need! You've been practicing those exact same commands for 15 years! What if SQL radically changed every few months? And what if instead of only a few dozen commands chained together it was 10,000 tools and settings in a single application? You cany very quickly get to the point in most software where it is simply impossible to use it as a command line tool and expect a user to use it without a MAN file permanantly open next to it.
I've spent 3 years learning MaxScript for instance for 3DsMax. Which is its command line toolset. It can take me a week to create a script which I can do in 20 seconds using the GUI. Once I write the script it might take an artist half a second but even I completely forget the name of a function I wrote earlier in the morning "What was it again? GetObjectIDFromDatabase or was it getObjectfromDatabase... what was the order of the function calls again? What was the name of that function which... I wrote it myself! And I still have to refer to my own help file to remember what the name of 90% of my commands are. It's unreasonable to expect someone to remember the command names and possible flags for 200 functions... and that's a primitive script. And even if I did expect someone to memorize all 200 commands... they would just have to memorize another 200 the next month when another tool is added to the toolset... and another 200 the next month after that... and another 200 the month after that.
It absolutely amazes me how many people like yourself get modded +5, Insightful in every single discussion like this, when you're all dead wrong. It amazes me how you think you're being logical and can go to incredibly great lengths to justify the continuing elitism of "if you don't know how to build the car you have no business driving it" kind of attitudes, which is exactly what you're espousing. Did you build your own car? Do you know how every single piece of it works? Can you recreate it from scratch? If not, shut your stupid pie hole.
This idea that you have to be the world's foremost expert in a particular field in order to be allowed to open your mouth is just so unbelievably ridiculous that I can't understand how it keeps being perpetuated so strongly even on a site that is supposed to be full of relatively intelligent people.
You're all constantly using obscure corner cases to try and demonstrate that any end user who ever criticizes the work of a "coder" is an idiot and wrong in all cases simply because they don't understand the precious code. Sure, users often misunderstand what the actual issue is with a program that's not working for them, so what? The fact remains that there is an issue, and blaming the user every single time solves nothing.
The longer attitudes like this get perpetuated, the longer most open source software will remain the underdog that most non-coders won't touch with a ten foot pole because it's so baffling or aggravating to use. What all you elite coders need to come to grips with is that you are too close to the code. You understand the code too well and it blinds you to the real life usability problems. You don't realize how much your knowledge of the code warps the way you see the interface. You have to learn to forget what you know about the guts of the software and look at it with fresh eyes, like any new user does.
The real question here: If you aren't making the software for people who don't know how to code, what are you doing putting a GUI on it in the first place? That is after all the entire purpose of a GUI in most cases, is it not? To make software accessible to and usable by people who don't know how to write the code themselves?
Jeebus cripes, folks. Get over yourselves. Stick to writing command-line stuff if you don't want to respond to interface criticism or suggestions like a reasonable human being.
Oh, and stop using Firefox as if it shows how great all open source code is. It's one application that has been worked on by teams of very talented people for several years and is supported by a business. Of course it's one of the best, but 99% of the open source software world falls a few miles short of that. Face up to that fact and you'll be better for it.