RSSMatthew Paul Thomas "Why Free Software has poor usability, and how to improve it".... Interesting article via Tom-
When I wrote the first version of this article six years ago, I called it “Why Free Software usability tends to suck”. The best open source applications and operating systems are more usable now than they were then. But this is largely from slow incremental improvements, and low-level competition between projects and distributors. Major problems with the design process itself remain largely unfixed.Many of these problems are with volunteer software in general, not Free Software in particular. Hobbyist proprietary programs are often hard to use for many of the same reasons. But the easiest way of getting volunteers to contribute to a program is to make it open source. And while thousands of people are now employed in developing Free Software, most of its developers are volunteers. So it’s in Free Software that we see volunteer software’s usability problems most often.
That gives us a clue to our first two problems...
I hear this a lot, one example that a maker was struggling with the other day was Inkscape, folks love it but many complain about usability. It's a valuable tool for any maker, but many that I talk to end up using CorelDraw or Adobe Illustrator for their laser cut designs, etc.
I'd argue that a lot of the people complaining about "Free" software are missing the point that they have no training.
Programs like inkscape are very powerful - they have features that less than 1% of the user base will ever need. Yet anybody can download and install the program, then when they can't instantly start creating amazing works of vector art, they complain that the "usability" is terrible!
Most companies recognise that software tools are useless without the appropriate training. Typically the software vendors provide (or license out) software training and support following the sale of a software package.
Anyways this is just another aspect that I think the author has missed.
Reply to this comment
I'd argue that people find what they're used to to be most usable. I used inkscape before illustrator, and I have to say I find it so much easier to do anything in Inkscape. I'm surprised anyone finds it particularly difficult - it seems to me that it's almost as simple as can be without becoming restrictive and simplified.
And what about Word vs. OpenOffice? I try not to use either, but when I do I much prefer openoffice to the horrible Word ribbon.
Reply to this comment
I love open source software. At a distance. On remote servers accessed via the command line. Some kinds of free software has amazing usability. Gcc, postgres, ruby, rails, python … these are all amazingly fantastic pieces of software with great design and solid, consistent user experiences within their respective domains. But graphical user interfaces? Software people don't do GUIs.
Inkscape is Nyaarh! Nyaaaarh! Raaah! And so is QCad and Eagle. And it has nothing to do with what I grew up with or was trained in. I learned CAD with QCad, and it is still Nyaarrhgh! (I got to try out AutoCad and SolidWorks. Pure joy from the firste minute!) I taught myself to make PCBs on Eagle. It's usability is still soul-crushingly nyaaargharama to me! As I have vowed never to steal software again, there is admittedly substantial molar grinding going on in the workshop as I save tens of thousands of dollars.
I disagree that the problem is the complexity of the interfaces arising from rich functionality. It is the pointlessly convoluted inconsistencies (like having separate command for moving multiple and single objects in Eagle), and all those little things like always launching the open-dialog in the same folder - not in the last used folder - that constantly break the flow and adds up to major frustrations.
Personally I think this boils down to two things: Vision and
Great design requires a consistent, uncompromising vision. It doesn't have to be ingenious - it just has to be consistent and must be implemented in an uncompromising mannr. Democratic institutions, larger teams and amorphous informal assemblies are great at solving problems and building solutions incrementally patch by patch - but they don't really do design as such.
The other factor is the "market" for the project. In an economical perspective the open source project is not really dependent on its ability to attract end-users to thrive. Wide adoption may help in attracting deveoplers – but the sole determining factor for the lifecycle of an open source project is the quality and amount of developers it is able to attract. Its raw material and target audience, strictly speaking, is its developers. Only qualities as they affect the attraction to developers will determine which projects survive, and which will die. Naturally interesting (not nessescarily end-user-usable) projects survive.
A commercial project, on the other hand, can allocate development resources proportional to the amount of money it generates from end users. The market mechanism ensures that the needs of the end-user factors into the allocation of development resources.
Maybe keeping a tally of the amount of weekly-unique-users and man-hours invested by end-users in each open-source project would help open-source contributors focus more on the needs of the end-user and less on amassing cult-kudos?
Reply to this comment
Ironically, the page this links to exemplifies one of the other major problems in making Free software usable. After detailing several significant hurdles that keep open source teams from design greatness, the author (who wrote this essay almost exactly a year ago) concludes with this:
"That’s a long list of problems, but I think they’re all solvable. In the coming months I’ll discuss examples of each of the solutions, and what I’m doing personally to help make Free Software a success."
Hoping for some concrete ideas, I then looked at the rest of his blog - all two posts of it. There's nothing on the site after September 2008, as far as I can tell. This, too, is typical of open source projects: someone gets interested, does a drive-by commit of some good but imperfect code, then vanishes. Good open source projects are tightly run, so these random contributions eventually get refined, but this isn't a viable approach to usability, which needs to be uniform across the whole application. Of course, some projects don't even fix the internal bits properly, and just allow the random secretions of a thousand developers to accumulate over the years. The results of that can be downright horrifying (see: TikiWiki).
Reply to this comment