|<<>>|192 of 213 Show listMobile Mode

Rock star programmers

Published by marco on

Ronco Spray-On Usability (Daring Fireball) is an essay on software usability triggered by a column by the rambunctious “Eric S. Raymond”. The setup covers some of the background of Linux usability, but gets interesting near the middle, where he proposes that:

“The problem isn’t just that dear old A.T. [Aunt Tillie] can’t use desktop Linux — the problem is that even Linux geeks have trouble figuring it out.”

That indicates that people, Raymond included, who believe that Linux is a few hard nights of coding away from being a home operating system, are kidding themselves. If hardened techies like Raymond have to give up on connecting a network printer in Linux, then it’s orders of magnitude too hard or too undocumented or too detailed or whatever for most people to use.

Why is it so far away? There are a lot of opinions to the contrary saying that “the hard work of development is in building the underlying foundation, and that the easy part is writing a “GUI wrapper””, so how bad can it be? Fireball retorts:

“UI development is the hard part. And it’s not the last step, it’s the first step. In my estimation, the difference between:

“”

  • software that performs function X; and
  • software that performs function X, with an intuitive well-designed user interface

“isn’t just a little bit of extra work. It’s not even twice the work. It’s an entire order of magnitude more work.”

Just take a spin around the open source community and download some toys and utilities — heck, you can even hit some shareware and for-pay software too, it doesn’t matter — just gather a bunch of software. Now, install them and marvel at the extraordinarily bad, incompatible, irregular and non-standard user interfaces you have before you. It’s like Frankenstein’s monster in software. (That’s if you get it to run, compile or have documentation explaining which other software is required, or where it installed itself or how to use it.)

If writing a good user interface were simply a matter of concentrating, you’d think at least a few of these apps would have gotten it right. But most don’t, suggesting that designing a simple, intuitive UI that exposes the power of your application in an elegant way without confusing llamas isn’t quite as easy as falling out of bed.

There are a lot of successful open source projects, but if you look closely, they all fall into the category of server or developer tool or library. These types of code have “programming interfaces, not user interfaces”. (If you ask me, the paucity of good design extends to a lot of software interfaces too … the larger projects tend to be decent, but smaller projects don’t pay a lot of attention to API design either.)

So, while a decent portion of programmers are capable of designing APIs (software interfaces), most aren’t good UI designers and don’t care that much about it anyway (other than theme-switching and anal-retentive detail-adjusting in the desktop shell of choice ;-). In fact, “some people who are good UI designers aren’t programmers. But the rock stars are the guys who can do both, and they are few and far between.”

The article goes on to argue that the distributed nature of open source development works against creating any significantly cohesive user interface. At the same time, it also explains why documentation is always so lacking:

  1. Writing documentation is boring
  2. Why write documentation for a part that some other distributed member of the hive might see fit to change the next day?
  3. Technical documentation is also hard work, and requires talent to be done well.

In other words, maybe you should take predictions of Linux’ domination of the desktop with a grain of salt; good user interfaces that lead befuddled users to features they didn’t even know they needed don’t just pop out of a Jolt-induced weekend of coding. Good code takes time. Good UIs take just as much time. Good design is never easy, it’s not often fast and it’s almost never right the first time.