Why free software has poor usability, and how to improve it(mpt.net.nz)
mpt.net.nz
Why free software has poor usability, and how to improve it
http://www.mpt.net.nz/2012/06/why-free-software-has-poor-usability/
64 comments
I especially liked the pithy screenshot which espouses one of the most common errors on all platforms: Crap progress bars.
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.
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.
So many places to criticize the article, but the one that hit me the most was "Release Early, Release Often" being held up as counter to usability. My experience is the exact opposite; it's not until you've released that you actually know how people will use your product and often too much UX design up-front is just premature optimization.
That's true, but then you have to follow up with users and take careful notes.
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.
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.
Some aren't interested, I'm sure. But I think this is one area were better tools could help a lot.
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.
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.
He identifies that the incentives in the open source world are against usability, but then he goes on to suggest "solutions" that aren't compatible with those incentives either. It's like he's arguing against himself.
While the author talks about free software in general, it seems more to me that he really means Ubuntu and Unity and perhaps common desktop applications found in that "ecosystem". What's the usability of bash? GCC? Emacs? And perhaps more importantly, for whom is the usability measured? The linux-ecosystem is mostly used by programmers. It's natural that the user interfaces tend to reflect this. One of the main reasons i have linux on my computers is exactly this, I really don't want the user interfaces of Windows or OS X.
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.
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.
for whom is the usability measured
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.
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.
Sorry for the rant but posts like this piss me right off.
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.
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.
> 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.
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.
Open source projects are inhospitable to designers because they come in and arrogantly blast their opinion into an establishment. The establishment knows its userbase better than a designer will.
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.
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.
Wow - a very 'us and them', aggressive attitude you've got there.
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.
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.
You miss the point: success in the traditional form at least is 100% irrelevant.
Consider Linux, tex, emacs, vim, apache, mutt, x, postfix.
All successful, yet no traditional form of usability.
Consider Linux, tex, emacs, vim, apache, mutt, x, postfix.
All successful, yet no traditional form of usability.
Many of these are very usable for their target audience:
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.
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.
All those you mentioned are highly configurable and accessible through the command line interface. For the target audience, they are highly usable. 'Traditional' (if we speak of the same thing) does not care if your users are general users or engineers.
Regarding the us-and-them attitude, it's a vicious circle.
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.
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.
In my experience programmers are often the worst people for designing the interface to their own product. Their designs are based on their own mental model of the product, which is in turn based on how the product is engineered.
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.
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.
The thing is that most open source software was designed for use by engineers for engineers and doesn't have a success criteria other than 'makes problem disappear'.
formal usability testing is irrelevant on such things so stop muscling in your own concerns and slating them for a job done.
formal usability testing is irrelevant on such things so stop muscling in your own concerns and slating them for a job done.
How is that so? A pretty standard part of usability testing is say heuristic evaluation. You pick the heuristics applicable to the target audience - engineers, like be accessible through CLI. No response means the app executed without problems, man doc etc and test. Usability != pretty interface.
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.
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.
What about "makes problems disappear with a minimum of effort"?
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.
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.
I think there's more to it than that. The problem is, when you understand a piece of software well, you cannot, try as you might, put yourself in the position of someone who does not yet understand it. Developers who aren't aware of that are naturally going to be hostile to the suggestions of designers. Even as a developer who is aware of it, I have to force myself to listen sometimes to people who are telling me that some aspect of my app isn't as obvious to others as it is to me. I'm sure this experience is not unusual.
At which point I show the next person how I learned it. It's called training. The best way to do this is documentation.
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.
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.
"Usability nazis"? I'm afraid your choice of words is leading me to suspect that it's not the designers' arrogance that is the problem here.
It's not that they devalue training, it's just that they're realists. You seem to believe that people are willing to learn how to use software slowly over time but the reality is that when a user gets frustrated they simply stop using the product and find an alternative even if it lacks features.
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.
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.
which projects are you talking about?
> Also stop blogging and fix it if it's a problem
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.
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.
if he's partially responsible for the current Ubuntu desktop and the current Firefox, I stand by my comments.
Change over substance.
Change over substance.
You're assuming the gatekeeper of the fix is a perfect judge of usability, which may or may not be true.
There is no perfect judge of usability, even from supposed experts (an arrogant title which noone should hold).
The gatekeeper is entitled to his or her opinions. If you don't like them, fork it.
The gatekeeper is entitled to his or her opinions. If you don't like them, fork it.
Yeah, "usability expert" is not a pretty job title. I guess it means the person focuses on usability testing and is an expert in the user's domain.
This isnt as much about the misuse of the term design as you make it seem. The author is right that free software is generally not as well designed as its non-free counterparts. Most of the time bad design manifests itself as too much complexity, strangely organized settings menus, way too many settings to begin with. You seem to have this "screw the average user" mentality which I'm guessing comes from the fact that average folks don't tend to use free software (mostly referring to Linux the OS and Linux software but it does apply to other platforms some of the time too).
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.
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.
They just want to press button X and have action Y happen with the least possible friction in between.
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 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 also have that mentality of wanting no friction but I guess I was really saying that users like me and you can deal with it in most cases while the average people won't tolerate it.
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 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'm not sure if I have a higher tolerance for bad usability than other people, I find I am often more vocal complaining about it. Besides if you watch a highly non technical user use a computer they will often do things in incredibly inefficient ways and don't seem to worry about it too much.
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.
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.
>Over the past few years, usability of free software has improved slightly.
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.
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.
Really
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.
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.
My kids use Ubuntu, OS X, iOS, Android, and at school they even have Windows. They are as indifferent to the OS as we are to the vagaries of navigating various websites. They use Spotify and Chrome and play their Humble Bundle games. They are 7 and 10 and totally grok accessing an NFS filesystem over wireless and understand that if they can't access their music, it's probably because the wi-fi isn't connected.
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?
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?
>They are as indifferent to the OS as we are to the vagaries of navigating various websites.
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.
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.
Hmm... although I agree with many of the points I think it starts with a bad premise. First you have to prove that free software has poor usability, then you can try to understand it. Most of the free software I use has great usability in my opinion (except for GIMP), although some of them only have good usability for their target markets (e.g. zsh or bash).
The proposition "software X has comparatively bad usability" is expensive to provide additional evidence for. The existing evidence includes the typical experience of people new to FOSS using things like Emacs, VIM, Gnome or GIMP, a difficult-to-explain preference for proprietary software among professionals in various fields and among typical consumers, each person's individual experience, various critical analyses of free software by usability experts studying the problem, and sundry other evidence. If this isn't enough to convince you that free software broadly has comparatively poor usability, the odds of discovering additional evidence that would convince you is probably too slim to be worth the effort. But it's a premise many of us accept. For those among us who do, blog posts like this provide some insight.
The existing evidence includes the typical experience of people new to FOSS using things like Emacs, VIM, Gnome or GIMP...
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.
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.
Try to change font faces or default frame parameters on Emacs. You could describe that catastrophe as a high learning curve, but I think it's a usability problem. This is just one example.
OK, maybe you are right. I just never saw a critical analysis of free software by usability experts. I mean, I have seen analysis of some free software that has bad usability, but the premise "free software has poor usability" with some of the arguments used in the article, at least for me, implies that most free software has bad usability.
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.
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.
For me personally the biggest problem with free software (I mean linux here) is that there is not consistency. You can't design a program UI and expect it to fit in different desktop environments etc... there are no proper design guidelines imo.
I don't recall Windows being much more consistent, although I understand your point.
And keep in mind that on Linux/Unix, text streams are the universal (and generally consistent) interface.
And keep in mind that on Linux/Unix, text streams are the universal (and generally consistent) interface.
It was a good read, but it might as well have been titled: Why Afghanistan has poor Democracy uptake, and how to improve that.
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".
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".
This could be summed up in a single sentence.
Usability takes more time and effort, and authors of hard to use free software find the usability to be good enough for themselves.
Usability takes more time and effort, and authors of hard to use free software find the usability to be good enough for themselves.
If you think 'free software has poor usability' you've never tried commercial software.
Replace "commercial" with "enterprise" and I agree completely. Amazing how bad software that costs so much can be!
(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.)
(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.)
If you think commercial software has poor usability, you've never tried enterprise software.
A lot of commercial software has pretty good usability, especially when the company doing the software realizes usability = people like = less support costs.
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.
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.
I tried both Open Office and GIMP. Experience is vastly less polished than Pages or Photoshop. I'd even say Pixelmator is a much tighter approach than GIMP.
The author is oversimplifying a problem that should not be oversimplified. Usability is something that requires specific empirical evidence to examine, and no two pieces of software are alike. It's a metric that is perpetually evolving and incredibly complicated. It's not just good visual design, and it's not just a symptom of strict coding and architecture standards.
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.
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.
Interestingly, his older and popular (and I felt much better written) article on free software usability ( http://mpt.net.nz/archive/2008/08/01/free-software-usability ) seems to redirect to this one.
It seems that the "mpt" who owns that domain today and is responsible for this article is not the same as the "mpt" that wrote the original article [1].
[1] https://twitter.com/mpt/status/209033178705436672
[1] https://twitter.com/mpt/status/209033178705436672
Wow. That's kind of shady isn't it (for the new owner to write a similar article and then redirect the older one to the newer one)?
The term 'designer' is extremely vague and I have no idea what the author is referring to each time he uses it in the article. At first I thought he was using it as a nonsense umbrella term (similar to how words like 'scale' are used) but a few paragraphs later he says this:
> 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.
> 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.
Free software has been spectacularly successful at building significant parts of our current computing infrastructure: kernels, compilers, web servers, languages and so on. Many of the products that the author would consider as having good usability are a thin layer built on top of millions of man-hours of open source stuff. So maybe free software is not that good at generating interfaces for the masses. So what? Many of the solutions that the author points out translate into boring work. Why would we expect people to do boring work for free? How could that model ever be sustainable?
Perhaps this was a well-intentioned gesture, but it was carried out poorly. This reminded me of a great article on how to provide thoughtful and useful analysis. Perhaps read that instead:
"This is What Real Analysis Looks Like"
http://www.ryanholiday.net/this-is-what-real-analysis-looks-...
"This is What Real Analysis Looks Like"
http://www.ryanholiday.net/this-is-what-real-analysis-looks-...
It's much simpler than that. Free software is usually created to be used by the creator, so there is no incentive to make it intelligible to others. The author is correct about incentives but the best incentive is payment for the software. At that point it's no longer free.
I agree that traditionally the OSS community is not very welcoming to designers. I'd be interested in creating a website that engages designers and provides a platform for them to propose visual updates to existing free software. Is anyone else interested in this? Email me!
For anyone thinking they can improve open source software's usability, donate your time here: http://openusability.org/.
Mind you the project's goal is to make OSS usable by 'common computer users'.
Mind you the project's goal is to make OSS usable by 'common computer users'.
A pretty worthless article which makes a lot of false assumptions about the nature of free software.
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.