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.
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.
(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.
Personally, I find FBSD, Debian, Slackware, and the majority of GNU software to be quite usable. Of course, I don't expect everything to be zero effort, either. Anything worth doing takes a bit of effort. Speaking of which, tried Windows lately? Now to me, that's really hard to use! But then, I don't want to learn the "Windows way" of doing everything, as I fail to see the pay off in it.
Caveat Utilitor
My open source product is mine, to make whatever design decisions I want.
I tend towards the opinion that if someone wants to dictate usability terms to me, they better be prepared either to submit code, pay me, or to be blunt, get lost.
Personally, I like coding console apps. As far as usability goes, this is stone age stuff, but it works for me.
Quite a few people have talked about improving my application suite with 'pure virtual interfaces', or just packing it into a GUI app, but none have actually contributed functional code.
I much prefer to spend my time working deep in the algorithms of my software, because coding those is a pleasure for me. Anything else just doesn't hold my interest.
In the past 7 years, GNOME has done its best to address exactly that kind of criticism. Almost every single feature is scrutinized with usability in mind. GNOME has been removing more and more configuration options from the user interface in order to make things easier for the average user. In fact, they've done so much their best that the technical audiance, i.e. Slashdot/OSNews/Reddit, is constantly flaming them for removing config options. Yet this same audience is flaming them for not being usable.
Know your audience, as a product rarely pleases both techs and non-techs.
Furthermore, the problem with GNOME/KDE and any other *nix interface isn't the interface itself, it's the OS that it's trying to be a frontend for, which is very non-friendly to non-techs. If it's non-friendly for new users, there won't be a ground swell of acceptance for the program. Until that OS (and any other that may come on the horizon), and it's third party app programmers and designers truly understand this, the majority will regarded such items as "experimental". They have little time to deal with bugs and 1001 options (that's why they pay for folks to fix and maintain it for them).
So basically you admit that proprietary software has a business model more responsive to users' needs than open-source?
Not trolling, just trying to note the similarities between being paid to write a software project... and selling a software project to pay developers.