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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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'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.
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.