Programmer Michael Thomas revisits an old theme: Why Free Software has poor usability, and how to improve it. This was a theme I heard a few times at OSCON as well. Thomas unfortunately gives no space to respond, but his loss is my gain. (Specifically, I gain a blog post on the theme).

Thomas lists 15 reasons for poor usability in FOSS (Free and Open Source Software) programs, most of which can be boiled down to: “designers don’t contribute to FOSS projects” or “programmers are smarter than interfaces and therefore don’t value good ones.” I think he’s right. I also think there’s an important meta-explanation that he kind of dances around:

Interface design is not much like programming.

If FOSS project owners are serious about improving the usability of their projects, I think they need to focus less on grafting interface design tasks into an ecosystem optimized for programming, and focus more on altering the ecosystem to favor interface design. I think breaking down how interface design is not like programming reveals a few potential courses of action for reforming FOSS ecosystems.

1. Interface design is a Gestalt task.

A truly beautiful interface is seamless and uniform. It requires seeing forests more than trees; it may even require envisioning a total view of the entire experience. There is almost no way to “jump in and help out” on an interface design in a meaningful way. Successful projects with many interface designers typically have a small number of lead designers (usually: n = 1) who delegate tasks to junior designers. The beautiful Gestalt is the result, not of democracy and open collaboration, but ruthless tastemaking. Good senior interface designers elicit and accept feedback, and work closely with users and programs in a spirit of collaboration. But in the end, they are willing to unilaterally kill bad ideas and advance good ones. The fundamental nature of good taste is its exclusivity.

My remaining points can all be viewed as corollaries of the theory “interface design is a Gestalt task.”

2. Interface design is not as much fun as programming.

I’ll explore this in more detail in my next three points, but let me dip into anecdote a little here. Of the hats I wear (graphic designer, interface designer, web developer), the only task I prefer to do in my free time is development. I get a happy charge out of starting up MacVim that I just don’t get from starting up Illustrator. I read books on programming when I’m on the crapper. Every designer who works even a little bit with code must, at some point in his or her career, be forcibly kept away from doing yet more code, because it’s so tempting to dink with the code instead of the pixels, even when we’re fucking up the code and making more work for the better developers downstream. Many designers love to spend their free time pushing pixels, of course, but the artsy ones tend to do actual art: painting or woodworking or sculpture or such. The nerdy ones spend their free time writing recursive draw routines in Flash, or making CSS Zen Garden designs. In other words: coding.

Occasionally I’m pressed by a layperson to describe how difficult graphic or interface design is. Usually I fall back on this analogy: “executing a design feels a lot like writing a term paper.” (The bigger the project, the bigger the term paper.) That’s how much fun it is. If you think writing term papers in college was fun, you might like interface design.

3. Interface design offers no “aha” moment

Everyone who has ever written a Hello World program knows what I mean here. We get a little charge when something you built — no matter how trivial — actually works. There is no moment like this for interface design. Interface design is a long process of slow improvement. The design might be better at the end of the day than it was at the beginning, but there was never a moment during the day when you flipped a switch and the UI compiled. The quality of the interface is purely a function of the amount of time you put into it — no shortcuts, no macros, no aha moment, no unit tests to pass, no checksums to verify. Most UI designs are “done” when you hit the deadline to hand it off to the development team.

4. Interface design offers very little glory.

A competent interface design, like the graphic design of the phone book, is invisible. The harder you work at it, the more invisible it becomes. A few interface designs — Panic’s Coda, or Omnigraffle come to mind — have a sparkly beauty or particular twist that really stands out, but most “good” interfaces simply (and properly) fade into the wallpaper.

5. Interface design artifacts aren’t functional.

Some of the best UI designs I’ve ever seen were committed on whiteboards or sketchpads. In the majority of cases, the UI designer produces a Visio document or Photoshop file. The product isn’t functional because there’s nothing to click.

Really tricky designers might use Interface Builder, or Tk, or HTML prototypes, or similar code tools to build a kind of Potemkin Village interface: the taps are all there, but they aren’t connected to any plumbing. You can turn a tap but nothing will come out. Nobody uses the “Interface Design” as anything other than a blueprint to build something else.

A person can gain great satisfaction from blueprinting a garage, I’m sure, but it’s a totally different pleasure than building a garage and then parking your car in it.

6. Interface design tasks scale poorly.

This is not strictly true, as I noted above. Experienced senior UI designers are adept at delegating tasks to junior designers. But the key word here is “delegate”. I can think of few things more counter to the FOSS ethic than the arbitrary elevation of a single person to the status of “senior” anything. But when it comes to good interface design ... there it is. If you break apart UI design tasks without a master vision, the result tends more often to be disjointed and fragmentary — the exact opposite of a usable or beautiful user interface.

The kinds of problems that get solved by UI design are of a different order than those solved by programming. I can write a script that wraps lines in a file with HTML paragraph tags. Then I can add a function to create bullet lists. Then I can add a function to format headers. I can keep adding layers of functionality to my script until it becomes an entire piece of software. From a tiny acorn came HTMLFormatomatic4000, or whatever.

In fact, I would extend this point to read: as a general rule, the more designers who work on a user interface, the worse it will be. Too many cooks really can spoil the soup.

7. Job demand for interface designers is higher.

I don’t mean to imply that interface designers are better compensated (because it’s probably not true). But I do mean that, if I have a few spare cycles, someone is almost always willing to pay me for those cycles. I might find a FOSS project about which I’m passionate enough to donate those cycles, but that poor project is always going to be competing against filthy filthy lucre. For a task I don’t find as much fun as programming. On a project where designers may be treated with active contempt as “decorators” or “icon designers.” And which probably has no resources to buy me, for example, an Adobe Creative Suite license, a new quad core Mac Pro and a 22" monitor.

I have no doubt that FOSS projects fight for developer resources in the same way. I’m sure most developers worth their salt could fill their weekends with freelance work the way most designers I know do. I can’t much speculate why they don’t. I guess I’d theorize that FOSS projects actually do provide a fungible benefit to programmers. If I contribute code to a well-regarded FOSS project, my nameshare rises and my ability to get paid for my expertise on that software would also rise. I’m having trouble seeing how contributing interface designs can provide the same benefits.

How to Improve Free Software Interface Design

I think understanding the nature of UI/usability design as a Gestalt task is key to improving free software interfaces. Make your project’s ecosystem more amenable to seeing and driving the Big Picture, and you’ll attract more interest from A-List designers. And I think you’ll improve your result. I’m still chewing over how to do this, but a few reforms spring to mind.

1. Restrict UI participation in your project

Thomas and others, used to a FOSS ecosystem where More Developers = More Participation = Better Feature, miss the allure and challenge of working on the Big Picture. When the picture is big, the glory is restricted. You can probably name the director of 2001: A Space Odyssey, but can you name the editor? Directors make their careers by not sharing. (When you consider the unfun, unglorious nature of UI design, maybe you’ll gain a little appreciation for why so many designers act like prima donnas. It’s because they are constantly beset with criticism for a task that compares with writing term papers in its pleasurability. Their only nonmonetary compensation is sole glory — best to hog as much of it as possible, by fending off all feedback if necessary. I don’t care to do business this way but I understand why many designers do.)

2. Invite designers to your project

The easiest way to shift a focus to the Big Picture is to invite a select few individual designers to work on your project, and guarantee that they’ll hold the reigns of the interface. If they need help, let them invite their own collaborators (or junior designers). This flies in the face of the Free Software ethic, I know, but remember that while your Interface Guru has veto power over all interface decisions, the community ultimately has veto power over the product. Other designers are welcome to volunteer their efforts, but if your selected designers say they can’t use them, remember the maxim about cooks and soups.

3. Compensate your interface designers

Maybe not with money, but certainly with resources, and definitely with accolades. Prominently feature the contributions of your UI designers on your project website (you do have a project website, don’t you? And no, SourceForge and Google Code don’t count.) Designers, much like developers, attract work through their reputations. What are you doing to massage your designers’ reputations?

4. Assign your designers a programmer au pair

Many excellent designers know (and care) very little about the housekeeping tasks of programming. They might, in fact, be wiz coders but they never use source control and don’t know how to build an executable. Merging forks, installing MacPorts, or editing makefiles will confuse them, and steer their focus away from the interface Gestalt toward the programming equivalent of dishwashing. Programmers are used to doing their own dishes and forget that these are actually complicated tasks that bear little relationship to what you want your interface designers actually doing with their donated time: designing interfaces. Volunteer to help them with these tasks to keep them focused on the things you need them to do.

Afterword

I know I’m hardly the first person to think this stuff through. John Gruber’s 2004 article Ronco Spray-On Usability is a classic, written in response to Eric Raymond’s The Luxury of Ignorance: An Open-Source Horror Story. David Nichols and Michael Twidale wrote probably the most thorough analysis in 2003, and I borrow many of their themes here. The OpenUsability project in many ways arrived at exactly the opposite conclusions I propose here. Celeste Lynn Paul offers another set of suggestions and provides a little historical context.

The writing on 大黑狗 tends toward the personal and away from the professional. When I write about my job, it’s usually in a “funny thing that happened at work” kind of way. I’m not a pontificatiforous person when it comes to my job. They pay me to push pixels so I push the pixels, and I try to do it with integrity and enjoyment. But as I dig more and more into the FOSS world — I’m running Ubuntu on all my Macs now, and I’ve switched to MacVim fulltime, for example — I’m consistently horrified by the lack of attention paid to interfaces. The FOSS A-listers get this, they know there’s a problem, and they talk about fixing it. But I think they miss that design (graphic, interface, whatever) operates on a totally different paradigm.

I don’t write on 大黑狗 for traffic or fame or money. I literally write it for my friends and family. I would love love love if this post got a little traction in the FOSS community. If you agree, or disagree, or have something to add, or know of similar comments elsewhere ... fire away. But in about two weeks of reading about FOSS usability, I’ve yet to see anyone come out and say it as bald as this: interface design isn’t actually much like programming. The root of the FOSS usability problem is expecting the opposite.

Sometimes I say things like “web design isn’t like digging ditches.” Meaning: more time ≠ better design The past week at Mercy Corps has proven that sometimes, web design is like digging ditches. Fresh on the heels of Cyclone Nargis, we’ve been fundraising for a response to the earthquake in southwest China. That’s meant a constant stream of creative: web pages, banners, logos ... and every minute I’m not pumping out creative is another minute we’re not raising money for our program partners in China.

I spent a portion of my weekend sorting and cleaning some of my old bike tools. Mixed in with which were the bare core of my archaeological field kit. Said discovery occasioned me to reflect on a life I used to have: I used to be an archaeologist.

I left that life behind nine years ago. After seven years of chasing work around the country, I wanted to put myself into a place first, and a job second. That’s when I took up the website-making stuff.

When people learn about this past life, they wonder either or both of two things:

1. Why I ever left it for web design
2. How my archaeological work prepared me conceptually for web design

The answer to the first question is easy: because it’s so much easier to find jobs designing websites. This is not, for me, a matter of income: I could (and did) happily live on my archaeologist salary. No, what makes website design a better career is that no one, ever, has said to me “you’re lucky even to have a job.” I think I heard this phrase, or variations thereof, from nearly all of my archaeology bosses, even the good ones whom I liked and who valued my abilities. The sad fact of having a job title like “archaeologist” is that the supply of people with that title far outstrips the demand.

The answer to the second question is also easy, but most people don’t like to hear it. So I don’t tell them. I think studying anthropology excellently prepared me for heavy-duty brain work, as I’ve written about previously. (Grad school also gave me another headstart on web design, but the reason was historical. I started grad school in 1995 when the web was young and unfettered high-speed Internet access kind of tricky to come by. By virtue of my status as a grad student at the University of Oregon, I had time-share access to Unix web servers, and fast ethernet.) But really, I’d have had (most of) this preparation if I’d have gone straight from my undergraduate degree, through grad school, and into the non-anthropology workforce. It has more to do with the great ability of a liberal education to prepare a person for nothing and everything all at once, provided that person is actually paying attention.

One perceptive person once deduced that archaeology — especially geoarchaeology, which I was pretty good at — conditioned the mind to think four-dimensionally, which was useful lateral training for work with computers. Everyone else sees some connection between the patience or care they imagine archaeologists use in excavation, and web design. I don’t buy that at all, because archaeology really doesn’t require that much patience or attention (just good note-taking), and web design doesn’t require it at all.

No, the real (and very prosaic) answer to “how did your archaeological work prepare you conceptually for web design” is “because it got me working with databases.” That’s really the only connection between what I used to do a decade ago and what I do now.

I often miss archaeology, because it’s a very satisfying job in its daily details. I particularly miss working and living outdoors. The career also provided a good mix of brainwork and hard physical labor, a combination lacking in most other (any other?) jobs. For the sake of reminiscence, I scanned a few old photos of my archaeology self, shaggy hair, beard, sunburn and all.

The more I work, the more I can work.

The way to make friends is to have friends.

The more I eat, the hungrier I feel.

When I don't yell at the dog, he's more likely to do what I want.

Lonely people never leave the house.

The more I ride my bike, the more I want to ride my bike.

Money attracts money.

Watching TV makes me want to watch TV.

To be loved, love.

The more I give, the more I have.

I can't sleep when I'm tired.

If you want something done, give it to a busy person

Someone recently asked me for some businessy advice about working in China. Specifically, about team dynamics and the decision-making process. All four regular readers of 大黑狗 can probably guess my opinions on the matter, but this presents a golden opportunity to wrap them all up.

First, the usual disclaimer: this is a huge topic and my experiences are limited. I’ve only been here a year, I work in IT for an apparel company, and Xiamen is kind of in the sticks. All this might be different elsewhere in China and in other industries. Also, China is changing very rapidly. My advice will probably be obsolete in a couple of years.

As for team dynamics and decision-making, I can only offer my experiences:

• My work is much less collaborative than in the U.S.
• My Chinese coworkers are uncomfortable doing tasks they haven’t performed previously.
• A lot of work is “borrowed” from other sources (usually competitors). This is so common that objections to the practice are literally incomprehensible.
• Many people see their jobs as paying bills, not vocations. Westerners tend to read this as a lack of craftsmanship, personal initiative, or pride of work.
• The ladder of responsibility is much more hierarchical than at US web companies. I have a boss and I have subordinates. In the US these people would all be my peers.
• I am called upon to solve many problems that are outside my domains of expertise.
• I can’t delegate tasks as easily as in the U.S. — I need to break large tasks into many small tasks.
• The Chinese work ethic favors long hours over efficiency. Doing tasks quickly/with few resources is seen as subverting the need to fill 60-hour, 7-day work weeks.
• Most decisions require extensive consensus-building.
• Language barriers flatten conversations; there’s not a lot of horsing around or tangent-chasing. The barrier is easier to cross in writing than in conversation. We frequently write while we talk.
• Documentation is looked upon as kind of “cute.” I keep a large pad of newsprint on my desk. When we’re working through a problem we’ll map it out in writing. The sheet of paper becomes the only document necessary to start work. p.s. I love this.
• If I didn’t force them to do so, no one would test anything.

An example is in order:

We’re redesigning a shopping website. Let’s say I want to add a GUI widget that allows users to browse to other products without having to reload the page. I know this can be done but we’re not familiar with the technology.

With a Western team I can propose the solution in a brief or electronic document. A coworker will implement a competent (but probably not perfect) solution from scratch or using open-source libraries. They will see this as an opportunity to grow our collective capabilities. The important part is: I can ask someone else to take on a high-level problem, confident they will return a workable solution. Successive iterations, building on a well-understood codebase, are usually just tinkering and optimizing.

When I propose this to my Chinese team, they roundly denounce it as impossible. I find a competitor’s website that does exactly what I’m proposing. A subordinate copies the code and graphics from the competitor and tries to shoehorn it onto our site; it looks bad and works worse. When I point this out, no one sees the problem. I need to break down the code and research the technology. I divide the solution into many small problem domains (graphics production, different code components) that I then delegate. Throughout this process I must make frequent unscheduled “check-ins” to ensure everyone is actually working on the problem. Successive iterations usually involve trashing large bodies of previous work and starting over.

It’s hard to say one approach is better than the other but, I’m certainly used to working in a certain way. That way involves lots of trust and collaboration, with well-paid coworkers who all regard each other as equals, in a legal/ethical/social universe that punishes sloppiness and intellectual appropriation. In that cultural universe, labor is expensive, so we take great care in what we do and reward ourselves for doing it quickly. But it’s also a cautious universe. Every step is mapped out in some Process somewhere, and requires documentation and foresight. Nothing is impossible but everything is expensive.

In my other cultural universe, the profound cheapness of human labor swamps almost all other considerations. Work gets done off-the-cuff, using templates provided from elsewhere. The consequences for failure have historically been dire, so undertaking a task that may fail could literally mean life or death. Extensive consensus helps dissipate culpability. Everything is cheap and many things are impossible.

There’s an old IT saw that goes: “Fast. Cheap. Good. Choose two.” In the U.S. the two are usually chosen for you; in particular, I have a lot of trouble sacrificing “good” so the only free variable is “do you want it fast or do you want it cheap?” In China, “cheap” is chosen by default, so I have to ask “do you want this good, or do you want it fast?” And since “fast” is usually off the table, that leaves one choice. Which is really hard for my personality (i.e. craftsmanlike).