Jef's blog, 2013-03-19
Eleven years ago, Matthew Paul Thomas wrote a blog post and a follow-up listing a number of reasons why “Free Software usability tends to suck”, as well as an update six years later. [1]
Have things improved since then? In the absence of actual research, I can only recount my own experiences. I hope I won’t regurgitate too much of MPT’s writing.
In the open source projects I’ve been involved with (or stalked, really), developers vastly outnumber designers, if there are any designers at all. Although the term “open source” has become quite mainstream, thanks in part to services like GitHub, I think open source code appears to have more value to coders than to non-coders. This doesn’t mean designers are unable to understand or appreciate the principles behind free software, but clearly freedoms 1 and, therefore, 3 do not offer a direct practical benefit.
In the MediaGoblin project, this led to myself becoming a bottleneck for the developers. Having only one designer on the team, and an inexperienced part-time one at that, meant that progress slowed or, worse, a proper design process was abandoned.
On the bright side…
In my experience, designers are very much welcomed in many projects. I have never had to advocate for design myself.
However, what “design” means in this context is unclear. Especially graphic design is greatly appreciated, but I believe this may be because it is more obviously evident and less intrusive than for instance structural usability improvements.
Software, especially open source software, is grown instead of built. Small and seemingly harmless additions add up.
It is the designer’s job to develop and maintain a coherent vision (if this function is performed by a programmer in your project, that programmer is a designer as well). This quickly becomes a full-time task that does not lend itself well to division over multiple people.
This is the reason some projects appoint a benevolent dictator, a person who can provide the needed discipline. But this person still needs to know what’s best, which leads me to the following.
How can developers be sure a design change was really an improvement? There are no sales to count, and often not even download numbers because the software is delivered through repositories. This assumes, though, that wider distribution equals increased quality. Not having to aim for profit or a large user base could be an advantage, allowing developers to try risky experiments.
Another way to get an impression of success could be to rely on user feedback. But people tend to report back when something fails, not when a task is performed without hiccups. Add to this that people usually don’t know what they want and don’t like change in general, and this type of feedback does not seem very reliable either (nor motivating).
But can’t developers judge the quality of their projects themselves? They can, but it’s really hard to keep an objective view of your baby. Odds are you’re not part of the target audience, and you may in fact be the person furthest away from this audience because of your familiarity with the software.
Finally, anyone can pretend they know what’s best. It is hard to pretend you can code, or do graphic design, because you’ll quickly need to show concrete results. But how do you know you can trust someone’s advice when it comes to interaction design? Especially considering even experienced designers get things wrong all the time.
One solution to the above could be user testing. Though it has a tendency to lead to faster horses, it allows designers to catch errors, validate existing designs and gather data to base future decisions on.
You could argue that the reason many projects don’t do a lot of user testing is because it takes time and money. But time is one of the resources projects are willing to spend, and costs can be kept low. I do not believe that these things are preventing this from happening.
What I do believe is that it has to be done right. It’s not a case of a little research being better than no research, because incorrectly performed experiments can be damaging. Testing sessions themselves are not extremely hard to set up, but the execution of the test, analysis of the data and the eventual translation into a design all need to be done carefully and skillfully.
A quick bit about design software.
I don’t think this is about a lack of open source tools, but rather a lack of distributed design tools in general. The situation is definitely improving, with software such as Sparkleshare and LayerVault, but doing design remotely is still quite hard.
In open source projects, we try to cram high-bandwidth design work into tools made for text and code. And many of those tools aren’t fantastic for text in the first place.
I do not believe there is a reason why free software cannot be designed well. There is nothing inherent about freely licensed code that prevents it from being usable. The crux of the matter lies in the processes of open source software development, more specifically the distributed and non-commercial kind, which I believe amplify the usual challenges in software design.
And software design in general is not easy. As Havoc Pennington writes in a great response to MPT’s blog post, “consistently producing quality user interfaces is hard”. And to do so in a situation where there are few designers, who have to work separately using unsuitable tools, without proper research and no way of knowing whether they’re heading in the right direction, is a lot to ask.
I’d like to look at some of these things in more detail, because I think it’s a very interesting topic and one that’s worth investigating.
This post ended up a bit aimless, but it contains a lot of points I wanted to put out there. Let me know if what I’m saying makes sense.
[1] Be aware that the post has since been taken down. The original address now redirects to this post, which is a rewrite by somebody else. Comments that pointed out this fact were removed from the site.