Main Navigation

Tim Lee is quite close to something very smart here, I think, and related to something I’ve been pondering for a while: why are so many open source software UIs typically bad?

Tim’s primary answer, I think, not wrong: good design generally results from having a strong vision of what good design for a particular piece of software should be. “Cult-like” may be overstating it, but good software does need a strong vision, and the holders of the vision need the means to get developers to buy into, execute on, and stick with that vision.

So Tim gets the answer right- but I think his framing of the question is actually a little off, in a way that merits discussion.

The first mistake Tim makes is that when he says “open UIs suck.” This is not false, but it is misleading. The more general rule is that most UIs suck; open UIs are just a subset of that. So implicitly contrasting open and non-open UIs is not necessarily very informative. Plenty of proprietary companies and proprietary design models create and implement lousy designs. Microsoft, of course, was historically the canonical example of this (though Office 2007 and Windows 7 are great strides in the right direction) but Android, which Tim picks a bit on, is perhaps an even better example- nothing about Android’s design and development process is open in any meaningful sense, and… the UI is pretty bad. So Tim’s post would have been much more useful as an analytical tool if he asked “why do most UIs suck?” and then concluded “lack of vision,” instead of asking “why do open UIs suck.”1

The second mistake Tim makes is the assumption that open projects can’t have strong, coherent vision- that “[t]he decentralized nature of open source development means that there’s always a bias toward feature bloat.” There is a long tradition of the benevolent but strong dictator who is willing to say no in open projects, and typically a strong correlation between that sort of leadership and technical success. (Linux without Linus would be Hurd.) It is true that historically these BDFLs have strong technology and implementation vision, but pretty poor UI design vision.2 There are a couple of reasons for this: hackers outnumber designers everywhere by a large number, not just in open source; hackers aren’t taught design principles in school; in the open source meritocracy, people who can implement almost always outrank people who can’t; and finally that many hackers just aren’t good at putting themselves in someone else’s shoes. But the fact that many BDFLs exist suggests that “open” doesn’t have to mean “no vision and leadership”- those can be compatible, just as “proprietary” and “essentially without vision or leadership” can also be compatible.

This isn’t to say that open development communities are going to suddenly become bastions of good design any time soon; they are more likely to be “bottom up” and therefore less vision-centered, for a number of reasons. Besides the problems I’ve already listed, there are also problems on the design side- several of the design texts I’ve read perpetuate an “us v. them” mentality about designers v. developers, and I’ve met several designers who buy deeply into that model. Anyone who is trained to believe that there must be antagonism between designers and developers won’t have the leadership skills to become a healthy BDFL; whereas they’ll be reasonably comfortable in a command-and-control traditional corporation (even if, as is often the case, salespeople and engineering in the end trump design.) There is also a platform competition problem- given that there is a (relatively) limited number of people who care about software design, and that those people exclusively use Macs, the application ecosystem around Macs is going to be better than other platforms (Linux, Android, Windows, etc.) because all the right people are already there. This is a very virtuous cycle for Apple, and a vicious one for most free platforms. But this isn’t really an open v. closed thing- this is a case of “one platform took a huge lead in usability and thereby attracted a critical mass of usability-oriented designers” rather than “open platforms can’t attract a critical mass of usability-oriented designers”. (Microsoft, RIM, and Palm are all proof points here- they had closed platforms whose applications mostly sucked.) Finally, of course, there isn’t just the problem of getting vision- there is the problem of execution. Manpower is always hard, especially when you can’t really fire people, but I think Firefox and GNOME (among other projects) have proven that you can motivate volunteers and companies to contribute to well-thought-out projects once a vision is articulated. It definitely isn’t easy, though!

Tim is not the first or the last person to say “open” when they mean “disorganized,” particularly in the context of UI. It is an easy mistake to make when, well, free software generally feels very rough compared to the alternatives. Free software communities that want to appeal to a broader set of people are going to have to do a better job of rising to the challenge of this problem, and create circumstances where designers not only feel welcome, but feel empowered to create a vision and feel supported in their implementation.

Tim doesn’t help his analytical problem here by not defining what he means by “open UIs”; given that he uses Droid as an example, what he is discussing are “source-available UIs” but given this tweet what he may mean to discuss is “UIs designed from the bottom up”, which are, I believe, a related but analytically distinct thing. [↩]

The best current example I can think of as a design BDFL is Jon McCann in the context of gnome-shell. [↩]

Good points. One thing that might be kind of specific to open UIs is the audience.

(When I say “open UI” I mean a UI that is developed as an open source project)

My impression is that open UIs tend to get much more pressure from techie users than the mainstreamers (the people who just want stuff to work, nothing else). Way more than usual. First, because the process is open and obviously more susceptible for input. And secondly, because most of the users of open UIs are computer-savvy (with a few exceptions of course).

The result is: the actual audience often doesn’t match the intended target audience. There’s a constant danger of entering a vicious (not virtuous) circle where your feedback loop is geared with the wrong audience.

Simply put: it’s a especially challenging task to maintain good open UIs for mainstreamers when most of your users are experts.

Lucas: well, yes and no; yes, that is definitely a problem (which I should have mentioned), but also no, in that this is not specific to open source. In proprietary software it is response to buyers, rather than users, is the variant you typically see; but has the same problems- you’re designing for someone who isn’t your actual user. This comes with the extra pressure of feature-creep in the next version: you’ve got to have something to sell to people, which is a pressure most open source mostly avoids.

The engineer-lead UI projects will continue to suck until even the most hardcore coders read and grok “The inmates are running the asylum”.

But to give an example of a nice open software with a nice UI – Chromium (Chrome) – of course, I must admin that they probably have some reasonable leadership coming from Google’s UX team, preventing the bloat, analysing primary tasks, etc. But then again – the developers involved probably have a deep dedication to build something great – not only just “something ‘open’ to stick it to the man”.

Have to back up Dominykas, I’m afraid. All true about “the inmates are running the asylum”.
If you’re building a great big new building, it’s the architects who are in charge of what happens. (They understand how to make the whole thing work for their end users.) Not the senior bricklayers (who don’t).
Similarly in Apple the Designers call the shots on the project.
In Open Source the bricklayers, I mean the software engineers, call the shots.
That’s by far the biggest reason for the disparity in UI usability, ISTM.

That’s a problem in most proprietary software too. It is true that engineers call the shots slightly less there, but only because frequently the marketers are calling the shots, which is not much different/better than when the engineers are calling the shots. Apple is the exception to the rule for all software, not an accurate representation of the average proprietary software project.

There is a problem in the scale of feedback which I’ll try to discuss tonight or tomorrow.

In my humble opinion, having applications like Glade being almost one man projects with no regular development tells it all.

Almost no effort is spent in improving graphical tools to builld the UIs and this means that mostly only techies can work on them and the effort to significantly modify a UI is very important. Also, interaction designers, artists or mere users that have experience in the problem domain are mostly out of the game without a lead programmer.

I hope CSS support for themeing improves things a bit, but we need much better tools too.

Besides that, it’s clear that having a vision is a must, but visions are progressively built by trial and error, experimentation, experience and the right tools make this easier.

One other dimension that didn’t get discussed is documentation, specifically Human Interface Guidelines. Maybe Apple’s are just better, or maybe they just take them more seriously. Either way, it’s probably just a side effect of being more design-directed from the top, but it also might be a useful vector for improvement that doesn’t require much rebalancing of the platform distributions of UI/UX people.

I think it just comes down to whether or not a project (open or closed) has a competent designer with influence over the big picture. Large companies tend to have them – they both understand that those skills are valuable, and can afford to pay for them.

Smaller companies and open-source projects may or may not appreciate the skills, but almost certainly can’t afford to hire them – they need to either develop the skills themselves, or find someone willing to work for free. And unfortunately, it’s a lot harder to find volunteer designers than coders…

I think it comes down to having a good plan an being able to execute on it. The practical difficulty (especially execution) is that there are a lot of tough choices to make and hard data on what is “right” often simply doesn’t exist. For example, even if you assemble a group of people who agree that minimal UI is desirable, odds are they’ll all disagree about which parts are the not-minimal pieces that can be cut (“not that! *I* use it!”). And then you need to have enough project support to trust the recommendations of your UI designers (in the face of the inevitable criticisms), and the wisdom to know which complaints can be ignored and which indicate real problems.

Say what? This is software development we’re talking about. Middle managers + ‘visionaries’ almost invariably get precedence over highly-skilled technical implementers. I don’t understand where this statement is coming from at all.

I think you may have missed on fundamental fact that Tim *completely* ignored: there are many amazingly excellent free software UIs. He can get to this fundamental misconception because of the idea that UIs are somehow monolithically “good” or “bad”. I actually switched to GNU/Linux, in 1992, because the UI was the best available. I’ve tried briefly other UIs, and none of them are better — for the type of user I am: a hacker-mindset who wants single key strokes fully programmable in every application I use. Free Software excels at this sort of user interface.

This is precisely because the majority of people in the communities are those types of users. The only logical conclusion one can make, therefore, is that clearly Free Software communities don’t have enough members from the general population who aren’t these types of users. There is no reason not to believe when Free Software communities become more diverse, UIs that are excellent for other types of users will emerge.

[…] programs have excellent UIs,but I agree they're tuned for type of user I am. Reply to @tieguy blog: ur1.ca/2dadsIMO most established !FaiF programs have excellent UIs,but I agree they're tuned for type of user I […]

I think Bradley get the right point. I don’t understand when some say that I’m not the intended audience of the system i have choosen.

I came from windows to archlinux + awesome wm after i gave a try to many other OSes, distrib flavors and windows managers.
So now if the average user start to like tiled WMs awesome have to drop me has a target audience in favor of those less skilled users?
I must be punished for being savvy?

I’m ok to say that there is a big need for improvement in open UIs. But when designers come and tell that people that where there must be expropiated for the reason of being “too savvy” / “no the target” / “WFT else”, I know that we will not be able to agree anytime soon.

Stop treat us as no-target-because-they-stupid-people-who-took-the-time-to-choose-and-learn-something and there will be more good interaction between designers and devs.

When at work I’m being told almost everyday that I’m not the target, I don’t feel any motivation in implementing carefully the PSD of the moron treating me like a non-existant person.
So do not try to correct the open design problem by offending thoses who give life to your ideas.

Antoine, I’m sorry that it is demotivating for you to be told “you are not the main audience”. But really, you must know that you’re not. I’m a designer, and I’m not the main audience either: I’m designing for the 90% of the population who are far below me (yes, even *me*) in their technological ability. (And far, *far* below you.) That is motivating to me, not demotivating.

How could there be one UI, one UX, that somehow works really well for you, the uber-superuser, and also works really well for normal people (who are technologically clueless beyond your imagination)?

(*How* clueless are they? Well, Google say that less than one in twelve even know what a *browser* is:
tinyurl.com/whatisabrowser – but of course, it’s our duty to know our market, so I’m sure you knew that already.)

I apologise to you if designers have suggested that you are a “moron” over this, but all of us, together, are (or should be) trying to design and implement things that work for normal people, who do not understand 10% of what I understand, or 1% of what you understand. People who don’t know what a “browser” is.

(Just like 90% of drivers (like me) don’t know what a carburettor is – nor should they have to.)

So please don’t just try to do things that you think are cool, that you understand and that you like and you want, and hope that a veneer of “usability” will somehow make your uber-tech-savvy world OK for the rest of the world – it really won’t at all.

[…] The first mistake Tim makes is that when he says “open UIs suck.” This is not false, but it is misleading. The more general rule is that most UIs suck; open UIs are just a subset of that. So implicitly contrasting open and non-open UIs is not necessarily very informative. Plenty of proprietary companies and proprietary design models create and implement lousy designs. Microsoft, of course, was historically the canonical example of this (though Office 2007 and Windows 7 are great strides in the right direction) but Android, which Tim picks a bit on, is perhaps an even better example- nothing about Android’s design and development process is open in any meaningful sense, and… the UI is pretty bad. So Tim’s post would have been much more useful as an analytical tool if he asked “why do most UIs suck?” and then concluded “lack of vision,” instead of asking “why do open UIs suck.”1 […]