Why free software has poor usability, and how to improve it
mpt.net.nz
mpt.net.nz
A lot of the "solutions" are useless exhortations for other people to be more betterer. Hint: nobody really cares how the peanut gallery thinks they should be spending their free time.
The whole thing has a phasist orientation. Ah, the "designing stage". That's the three months of the open-source waterfall where the open-source business analysts gather requirements from the open-source stakeholders before handing over the open-source PRD to the open-source developers, right? As if.
Some of my favourite designs come from free software, and while some of his points do have validity there's a lot of amazing solutions out there.
The impression I get with many open source projects is that they just push out updates in a vacuum and aren't so interested in "regular" users feedback beyond bug reports and patches.
Getting good usage data is hard. Running a good user test is harder. It's my experience that if you connect developers up with good data, both qualitative and quantitative, many of them will start hacking the user experience with the same sort of relentless optimization that they bring to code quality and system performance.
I think there has to be a good solution in there somewhere. Maybe several.
Problems and solutions are described, but exactly _how_ to implement these solutions isn't stated very clearly, and I'd hesitate to call these suggestions "solutions" because, to be brutally honest, it's all empty talk.
Furthermore I feel like many of these solutions come at odds with the foss-culture in general. If I'm giving away my time and code for free, I really don't want a project manager or a designer to tell me what to do. I'm going to do what feels interesting, or I'm going to implement features that I need. If someone else can use my code too, then that's great. If not then that's ok too. To me it's strictly hobby basis. I don't get wages, and I don't have "customers". I'll contribute because it's fun or because I want to honor the idea that I should contribute back changes and improvements I've made to software that I got for free.
Of course, this could be very different if I were employed and paid to make software that coincidentally also was free, but I'm not. Maybe this blog post was aimed at Canonical and their employees, or the practices of big projects like GNOME. If so, then maybe he could have the decency to say so, instead of going about "solving" other peoples problems that aren't really there.
I think this is critical. A software product like Emacs would never have been produced as a consumer product for sale by a vendor. Emacs is the way it is because it was developed by and for the people who used it: coders. Not all "free" software is targeted at nor should it necessarily be usable by your mom (not a dig at your mom).
(From the article) Free software developers mostly develop software based on their own requirement and their definition of “good software”, and as a result, design software that is very complicated and “geeky”.
In many cases, this is as it should be, unless they are developing something specifically targeted at users from the "general public." However, where I do think some projects go off the rails is when they develop a UI that is either internally inconsistent, or so non-standard that even technically-minded users are frustrated by it.
Usability seems to mean low entry barrier and pretty looking these days rather than functionally elegant, normalised and reusable. Usability now means giving dumb people pretty looking things and not bothering to write a manual or relying on their understanding of the domain or having any compromises between the machine and the meat sack using it.
Also stop blogging and fix it if it's a problem - that's the joy of open source. If they don't want the 'fix', then its not a fix for the supposed problem or the problem didn't exist to start with.
A flaw of many open source software projects is that they tend to be inhospitable to designers coming in and attempting to contribute in a meaningful manner. Usability shouldn't just mean "dumbing things down", no, but if a program is well-designed then improving its accessibility to newcomers need not be at odds with elegant and efficient operation for more advanced users.
There are many projects where attempting to submit a patch that improved usability would be met on deaf ears, even if it was a change that solved a legitimate design problem or improved on a current solution, because the maintainers of the project have a mindset of "the design works for me, therefore it works for everyone". In this case, "fixing the problem" doesn't mean actively contributing to an open source project (since that in itself is the problem), it means attempting to change the approach people take to managing open source projects.
This article in particular is a messy jumble of ineffectual buzzwords, but there is a small nugget of truth buried in there.
The designers then crawl off and blog whinge about it.
Open source doesn't work the same as 'business' where change drives sales. That's the misunderstanding.
It's clear that for any app, site or OS to have mainstream success, it needs to have a well-designed interface, a good user experience. Apple, Google and others have all invested heavily here, and the big winners all have interfaces that are easy for a non-technical user to use.
If open source projects want to gain mainstream usage, they also need to invest in usability, and like any skill, there are people who have more ability and more experience. As these people are not necessarily programmers, it can be hard for them to contribute to open source processes that are centred around code contribution.
Consider Linux, tex, emacs, vim, apache, mutt, x, postfix.
All successful, yet no traditional form of usability.
Vim: adds such user-friendly features as syntax highlighting and WIMP while keeping an interface (vi) that is already well known to it's users, thus preventing them from having to learn a new set of commands from scratch
Emacs: Clearly the most programmable text-editor currently used. The ease of usability for extending it is the reason it is adopted.
mutt: synthesized interface from several already existing mail clients, most notably pine and elm
Apache: If you consider the user to be web developers, it (NCSA HTTPd which is what Apache grew out of) introduced CGI, which was a huge usability step for making dynamic web-pages.
Linux: Not sure. It's essentially a clone of SVR4; probably just the fact that among it's always had the best driver-support on commodity hardware is the win here.
Postfix: It's more usable than sendmail; not really a glowing review though.
X: Yeah, I can't think of a single good thing to say about X. I've heard that Motif was the "killer app" for it that kept it around, but I wasn't there so not sure.
A person who is a self-defined designer often means it in opposition to coding. That means that they've defined themselves as someone who can't get anything done on their own. That works in a corporate environment, because they can talk somebody into letting them boss around developers on the payroll.
However, that leads to weird power dynamics and resentment on both sides. It also creates a situation where are lot of developers are discouraged from thinking about design, meaning they appreciate it less.
Where I depart from your analysis is the notion that open source projects really want to gain mainstream usage. I'm sure many would say they do, but I doubt many actually care enough to do something about it.
I think this is only going to get better in ways that erase the corporate line between designer and developer. E.g., developers who have some design skills doing more open-source work. Or designers buckling down and learning to submit patches like everybody else. If usability is the itch they want to scratch, they shouldn't wait for somebody else.
Otherwise, I think designers have to limit themselves to producing research and inspiration. E.g., doing well-supported usability studies on a popular open-source apps. Or producing design treatments as in a positive, here's-one-way-you-could-do-it spirit.
Their intuitions of how end users will use a product is skewed by this same biased mental model. End users lack the in depth knowledge of how the product is constructed.
I've seen products I've built be run through formal user testing and A/B tests and the most important thing I learnt was that my intuition about user behavior is always wrong.
The truth is that a product needs both good engineering and good design to succeed. If it lacks either then it is going to fail. Engineers tend to be oblivious to bad design so if you are ignoring critiques then you are throwing away valuable data.
formal usability testing is irrelevant on such things so stop muscling in your own concerns and slating them for a job done.
In fact, sometimes you might not want a beautiful interface, because you want people to get the job done. I think the issue with the original article is that it paints broad suggestions so it is easy for me, you and everyone to argue their point.
It is true that powerful systems require some learning, but there also are a lot of things that programmer's would not have to learn if UIs were better.
As an example, consider the time wasted to learn the idiosyncrasies of the various Unix tools. Standardizing simple things such as the way to query a program's version (-v, -V, --version, probably others), or the features of the regular expression grammars of tools X, Y, and Z would have made live quite a bit better. And yes, it would break existing code, but sometimes, the price of change is worth it for the benefits it brings, accumulated over the years.
Usability nazis want people to be able to ride a bike after 5 seconds. They devalue learning and understanding most if the time rather than achieve an equilibrium.
One thing I think we're all confused about is our definitions of users and target audiences. Obviously the users of CLI programs and other "power user" software are willing to take the time to read the manual and educate themselves. Software for these users doesmt require the kind of attention to design the article talks about. Then there are the average users and software they use. Things like word processors, GUI file managers, etc. Those users need their hands held with "dumbed down" and "pretty/glossy" design. You can still provide complex and powerful features to them but you have to design their software in a way that makes their first introduction very easy to use. Meanwhile you can provide options within settings menus and customizable toolbars for the veterans who already know how to use such tools. It's the best of both worlds and everyone wins.
There's also some software that you'd think only power users would use but then someone comes along and makes it accessible to the average user in a way that's easy for them to get into while still useful for the power user. GitHub's GUI app is a great example of that. They took something that we all assume only programmers and savvy users would get and designed it in such a way that makes it easily accessible for total newbies. Because of that there now people you'd never think would use a VCS like Git making heavy use of it. People like writers, graphic designers, bloggers, scrapbookers, and all sorts of "average users" are now using the thing that we thought only the power user's would touch. The best part is that even those familiar with the command line use of Git now use it because it makes their life easier too! We can totally take a lesson from that and apply it to these tools that we think don't need better design.
In case you don't know who mpt is, he's actually one of a handful of people out there who is trying to fix these problems. He worked on usability for Mozilla for awhile, and now he works for Canonical. I used to work on the Ubuntu desktop experience team at Canonical, and I can attest (as much as my opinion is worth anything) that mpt was easily the most valuable person there in working towards usability. He's not one of the "make things look pretty" kind of designers, it's definitely one of the "functionally elegant" types. Part of his work is designing new Canonical-led features in Ubuntu, and part of it is proposing better interaction designs for apps that came from the community; some of that work is then coded by developers at Canonical, or by the upstream project maintainers, or random community developers, and sadly some of it is just put off or ignored. But the point is, he's the guy who is working to fix design problems.
I think the point of his post was to try to encourage more thought towards the design process by the open source development community, and maybe to encourage more non-developers to get more involved in the design process. He's only one guy, there's only so much he can re-design on his own. You know, days having limited hours and all. So if he spends a couple hours doing some "community outreach" type blog posts and manages to get even one other person to start working on interaction design then he has accomplished more with those couple hours than if he had used them redesigning a part of some app.
Change over substance.
The gatekeeper is entitled to his or her opinions. If you don't like them, fork it.
If you're making software for the power user set then the status quo is probably just fine but if the free/open source community really is committed to winning the hearts and minds of users of the standard platforms (Windows and Mac obviously) and really do want to get a bigger piece of the market share pie then developers will have to dumb things down a bit and simplify.
The attitude you seem to have towards users, calling them dumb people and meat stacks, is exactly the thing keeping those dumb meat stacks from using free software. Programmers also seem to hold a sort of bigot attitude toward designers which your comment also exemplifies. Functionality, elegance, resuability, and everything you mentioned are great and necessary but there's no reason it can't be prettied up a bit and simplified.
The bottom line is that if you're developing software for people just like you then you can ignore the dumb meat stacks and the pesky designers and still be successful but don't ever expect average users to educate themselves in order to use your software. They don't care about the limitations of technology and how everything works together nor do they care to learn. They just want to press button X and have action Y happen with the least possible friction in between. If button X doesn't get action Y to occur as fast or easily as they want then they're uninstalling your app. That is, unless uninstalling involves more than a click or two otherwise it'll just collect dust and consume disk space. Until you design and develop with dumb meat stacks in mind only programmers and power users will use your software.
Now im not saying this will be easy nor am I saying free software developer have to start doing this. After all, they work for free I'm their spare time and create amazing amazing products and alternatives to non-free software. What I am saying though is that this is the reality of dealing with users. It's not ideal and they certainly act like an entitled lot but it won't change especially now with the proliferation of prettified and dumbed down apps everywhere you turn.
I don't think that this is just an attitude for less technical users, I have the same attitude myself whether I am configuring an HTTP server or playing a video I want a low friction way to do this. I don't think that power users exactly seek out the hardest interfaces.
The problem is though that the highest friction way to do something is to not be able to do it at all and have to work around that. I think this is why there is much resistance to things like Unity on Ubuntu.
It's also worth bearing in mind that consistency is also important, so doing something like releasing an "easier" Window Manager that is a huge departure from what was there before will not necessarily be welcomed by users as much as you think.
Having said that , I don't think that usability is the #1 thing holding back FOSS desktop adoption. The biggest things are MS inertia and also compatibility, for example without Silverlight4 + DRM you can't use things like netflix which is going to really hurt adoption (although I'm not sure what could be easily done about this case).
I was mostly talking about keeping this in mind when developing new software. It definitely will be hard to make big departures from what's already in existence. It's not impossible though. You can always give users the option to add X toolbar to a window and choose which buttons appear by default and such.
Of course, these solutions don't lend themselves to all software and that's okay. What's really important is just to keep these ideas in mind and not write off design as just unnecessary ornamentation in the future. Obviously we have to be thoughtful about where these ideas would work best. The easiest way to do it is know your target users and design for the least common denominator among them. Your software can launch with a design meant for the least common denominator by default with options which can be displayed and remembered later for more advanced users. I can't repeat this enough though: this can only work on a case by case basis and by knowing your users. Remember too that incremental departures are swallowed much easier.
Design may not be the number one thing holding back FOSS adoption but it's high on the list I think. When the FOSS community can offer equal or better alternatives to what's out there, market share will skyrocket. I think Linux is pretty much there already. It has a few blemishes but the big thing is probably that normal folks are just scared to try it, won't go through the trouble of installing another OS over the one that came with their PC and the appalling lack of computers that come with Linux pre installed.
I think the key though is making it as difficult as possible to get stuck when trying to do a particular task. This is where consistency is hugely important, if most of your apps work approximately the same way (such as with Apple) and have predictable behavior this is hugely helpful to users.
There is also a lot of context to bear in mind when thinking about how easy something is to use and I think this is where it does a disservice to lump "non technical" users together.
For example , I grew up during the days of DOS so switching to a UNIX/BASH command line when I got older felt very natural to me. However I wouldn't want to put myself up against the average 15 year old of today when learning how to use the latest social network.
Regards FOSS applications, one thing to bear in mind is FOSS is by nature easier to port than proprietary software. Therefor most of the good Linux desktop apps are also available on Windows which in many ways actually damages Linux adoption.
For example I know plenty of Windows/Mac users who are using Firefox , VLC and Pidgin. There would not be a particularly big tangible benefit for them moving to Linux (apart from saving MS license money they already spent in the price of their PC). On the other hand it makes it easier in the sense that most of their familiar apps are already available.
Slightly? It has improved by leaps and bounds. I just switched from Mac OS X to using Ubuntu almost exclusively, and aside from a few bumps here and there, I have been very happy with it. That's a plunge I wouldn't have even considered three years ago.
The problem in free software is that 1) engineers don't have the needed mindset 2) resources are limited, of course 3) the developer usually does whatever is in his mind
Gnome is "usability" gone wild. Remove the steering wheel and pedals from the car so to make it "simpler". Good luck driving it anywhere
(Really, from my experience with Fedora 16, out of the box experience at first it's bad, then it gets worse when you see all the little details gone wrong)
And to help matters, they think PulseAudio is a good idea. PA is a broken answer in need of a response, really. And it definitely affects user experience.
One thing this does point out, though it might be a bit antithetical to many OSS devs, are there any open source usage stats packages that developers can build into their systems? Like Chrome uses?
Very cool, I've been wondering if and when this would happen. Modern OS's seem less and less different to younger and younger people.
Only picky techies and older generations seem to care about the differences these days, kids just dive right in and adapt.
Hopefully that trend continues, it's great for underdogs like FOSS.
Bad usability and a high learning curve are not the same thing. A high learning curve is what makes people "new to FOSS" have difficulty with emacs/vim, not a lack of usability.
And Gnome is also a bad example, since it is both usable and has a minimal learning curve. At my last job we set up a crowd of 30 fashionistas (no tech background whatsoever) using gnome with no real issues. Several of them also used inkscape with little difficulty.
I know GIMP, Emacs and VIM may be in that field (although I do not agree particularly with Emacs and VIM), but there are so many free software projects used everywhere, and these are just examples; you cannot generalize from that. There are also plenty of examples of free software with good usability, and I have never seen a broad study of different free software to study their poor usability.
And keep in mind that on Linux/Unix, text streams are the universal (and generally consistent) interface.
Basically, the author says, "update" the process that's responsible for the open-source world, into a more methodological corporate environment.
He doesn't realize it's a completly different world. In which the mentioned "fixes" are contradictory to it's sprit.
Developers want to spend 100% of their time just hacking away. They are not going to transform that into a 10% dev time and 90% "sit there doing UI and feedback studies, and nurture-the-community time".
Usability takes more time and effort, and authors of hard to use free software find the usability to be good enough for themselves.
(side note: I might have accidentally down-voted you as my hand brushed over the screen. If so, I apologize and hopefully someone will give you an up-vote for me to replace it.)
Now, for truly horrific usability, nothing beats enterprise software with those big money support contracts. Very much like American car companies in the 1970 / 80s which viewed service as a profit center.
The author does not provide much evidence for these solutions combating usability problems, but if they did, I would be much more willing to listen to their advice. I would have also liked to see specific examples of usability faults (not just software with poor aesthetics, which is another subjective metric that the author oversimplifies) and instances where these applied techniques were able to solve them. I commend the author's desire to face-off against a problem which is out there and prevalent in the FOSS world, but their claims need to be backed up before I could take them to heart.
> Similarly, there are only a few coders who are also good designers, but that is very rare because programming and human interface design is very special skills that each requires separate training and a different mindset.
Oh, so by design he means 'human interface design'. Yeah, no. Design is much more than just that - it is an umbrella term after all.
"This is What Real Analysis Looks Like"
http://www.ryanholiday.net/this-is-what-real-analysis-looks-...
Mind you the project's goal is to make OSS usable by 'common computer users'.