Crossposted from the new Mercy Corps Blog.

In a recent New Yorker article, Malcolm Gladwell wonders why more basketball teams don’t employ a full-court press. Instead of dropping back to your own net and defending, you press the other guys on the inbounds pass and at the mid-court line. You don’t defend 30 percent of the court (inside the 3 point line), you defend the entire court. This surprising strategy gives underdogs a fighting chance: it keeps the stronger team always on the defensive, and makes greater virtues of speed and endurance (as opposed to ball-handling and shooting). Gladwell’s article has sparked a little interest among webheads, like Martin Kelley of O’Reilly Media, who sees the web enabling a sea change in marketing and communications:

“Traditional marketing campaigns are batch: we plan out a commercial, pick its theme, hire directors, do audience testing and months later air it on broadcast television. Even low-budget nonprofits operate this way: they create a schedule of newsletters to distribute by postal or electronic mail, with carefully constructed branded templates and standardized lengths and formatting ... Many of the most adept citizens of the new web culture don’t sit down to write pre-planned blog posts. Twitter has taught us to capture the moment, to express the thought now and just move on. ... Most of the ubiquitous ‘how to make money on Twitter’ posts fail to make the difference between real-time and batch processing. If you’re real time, you’re part of a conversation and building a community that might be virtual and asychronous but is authentic in its own way.”

The rise of social networking gives organizations with underdog marketing resources (like, um, certain non-profits) a stellar chance to press the full court. In Ye Olden Days (ca. 2005), marketing was planned around calendars (monthly, quarterly, etc.) or for “windows” like Holiday, Mother’s Day, Back-to-School. But with flexible and rapid media tools like Facebook, Twitter and blogs at our disposal, Mercy Corps can substitute speed and effort for ad buy dollars. My colleague Floyd has already written about how our newish design makes this much, much easier.

But more importantly, these tools allow us to turn a liability into an asset. Mercy Corps’ world doesn’t always obey the calendar. We can’t predict when or where the next cyclone or earthquake will strike. We can’t hope that military conflicts will helpfully schedule themselves between the Dads-and-Grads and Fourth-of-July windows. But each of these events represents a unique moment to communicate, with little filtering, what Mercy Corps is doing. Not some abstract brand promise, or mission statement, but the daily reality of our recipients and fieldworkers: yesterday we delivered aid packages to displaced people in the Mardan and Swabi Districts of Pakistan. And here are the pictures. They might not be the studio-quality portraits the art director I used to be would have chosen for the Memorial Day E-Blast, but they show what is actually happening right now.

I came to Mercy Corps almost two years ago after a decade working in the for-profit sector. I’m a great believer in commerce, but I can’t recall ever getting as worked up about printers or software or t-shirts the way I am about giving blankets to cold children. I have a (perhaps naive) faith: the best way to “sell” Mercy Corps to our constituents (and trust me, non-profits have to make the same marketing and branding and sales decisions as for-profit companies, but with the hitch that we don’t actually deliver products to the people who give us money), is to talk about what Mercy Corps is doing.

We just launched the redesign of MercyCorps.org. Like half an hour ago. I've been itching for this change since I started ... 18 months. The project has been in the works since last summer. We've had to shelve the redesign for three emergencies, and it was postponed for Christmas last year.

As a personal milestone, this represents the largest project I've ever executed from start to finish. This is my biggest project by any measure: pageviews, content nodes, dollars transacted, good contributed to the world.

So: take a minute or two and check out the the Brand! New! Drupal-powered! http://www.mercycorps.org. Send me feedback, thoughts, comments. And please consider making a little donation.

I’m scoping a little extra freelance right now for some former clients, and one of them asked for a portfolio. A portfolio! I suck at those things. Off the top of my head I figure I’ve produced 650 to 1300 client-approved deliverables in my career. Some of these I have all my production art for. Some of them were produced for dynamic websites with exotic server environments, so there’s nothing left to look at but unexecutable source code. And some have just plain gone missing: not on my dusty old hard drives, not on my stacks of CDs, probably long gone from clients’ systems.

Not counting the hundreds of unique webpages and emails; and not counting the boxes-and-arrows information designs; and not counting intranets or extranets; and not counting the dozens of comps or concepts or templates or moodboards or spec designs; and not counting the art-directed work someone else designed; and not counting sites I developed but did not design; in the last ten years I have designed sixteen web sites. Web sites where, if you typed a URL that ended with a TLD, you’d land on a page that I designed. Of those sixteen websites, only three still use anything remotely like my original design. Five of them are entirely deceased: the domain registrations have lapsed. One is still in development but very very close to hatching.

1. ecoartspace.org (b. 1999 – d. 2002)
2. medianet.quakeroats.com (b. 2000 – d. 2001) †
3. nwnatural.com (b. 2000 – d. 2004)
4. capncrunch.com (b. 2001 – d. 2002)
5. techtracker.com (b. 2001 – d. 2002)
6. flashbackgames.com ? (b. 2001 — d. ?) †
7. thesmallerthings.com ? (b. 2002 – d. 2003) †
8. chalkboardproject.org (b. 2003 – d. 2003)
9. chalkboardproject.org (b. 2004 – d. 2005)
10. stylemetrics.com (b. 2005 – )
11. adrianandemily.ca (b. 2006 – d. 2007) †
12. actioncenter.org (b. 2007 – d. 2007)
13. globalenvision.org (b. 2007 – )
14. thefilmconnection.org (b. 2007 – d. 2008) †
15. sitkatech.com (b. 2008 – )
16. mercycorps.org (?b. 2009) ‡

†Domain no longer active
‡Design still in development

I am absurdly proud of about ten of these designs. With two exceptions, none of these websites aren’t even close to my best work.

My longest lived design (nwnatural.com) lived four years. I can’t guess which was my shortest-lived design. Perhaps the design I did for an unscrupulous agency for a client called “Flashback Games,” which I recall seeing exactly once, and which had been so depressingly bastardized by the agency’s Flash developers that I literally destroyed all files related to that design. Or so I had thought, for the last seven years, until I stumbled across this:

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.

You can use a Swiss Army knife to cut your fingernails in two different ways. Everyone knows the first way and has probably done it at some point in their lives (usually while camping) you open the little tiny scissors and make scissory motions across the ends of your fingernails. In other words: you exploit the technology of a scissors, which is good for cutting through a thin surface, but not much else. By the same token, the only way you can “scissor” something is using a scissors.

The other way requires a little more finesse. You can open one of the blades — the big one works better — and caaaarefully pare the ends of your fingernails. In other words: you apply the technique of “paring,” using whatever sharp edge is available, in this case the blade of a knife. Importantly, if you know how to pare your fingernails with a knife, you can use anything with a sharp edge to do so, including one half of an open scissors.

In studying material culture, the difference between technique and technology struck me pretty forcefully. In a seminar in ethnoarchaeology I watched several short films on Aboriginal life produced by the Australian government in the 1920s and ’30s. They had catchy titles like “Butchering a Kangaroo,” “Collecting Dew,” and “Building a Fire,” but were deeply fascinating nonetheless. Aboriginal people traditionally carried very little on their persons. In “Butchering a Kangaroo” the protagonists accomplished this feat using a small stone flake perhaps two inches across (which one of the men carried with him), and two straight sticks conveniently lying nearby. The men exploited their own voluminous knowledge of the local environment and kangaroo anatomy. In other words, they exploited technique almost exclusively. If you know the party trick of opening a beer bottle with another beer bottle (or a belt buckle, or the edge of a table), you have a sense what this must feel like.

On the other hand, I completed my thesis work with Eskimo people, who are famous for having had a highly advanced Stone Age material culture. Whereas an Australian hunter might carry on his person only a small handful of very generalized tools with which he could hunt a wide variety of animals in many circumstances, an Eskimo hunter would have very complex and specialized weapons optimized for hunting a particular animal in a particular circumstance. The harpoon you’d use to hunt seals surfacing for air during the winter is rather different from those you’d use to hunt seals from the open water, or on shore during the mating season; all of these are probably different from the harpoons you use to hunt walrus. Eskimo material culture places great emphasis on technology.

Of course, Australian Aborigines and Alaskan Eskimos live in very different environments, which explains almost entirely why they place different emphases on technique and technology. If you tried to carry a diverse toolkit of specialized tools across the outback, you’d never make it from one water source to another fast enough to avoid dying of thirst. And if you tried to pare your toolkit down to something that would fit into one hand, you’d never kill and process enough animals in the Arctic summer to make it through the winter without starving. Surviving in the Outback places a premium on flexibility, which favors technical solutions. (If you have the right technique, you can cut your fingernails with any sharp edge). Survival in the Arctic places a premium on efficiency, which favors technological solutions (given the right tool — a fingernail clipper — you can cut your fingernails much more quickly than paring them with a knife.)

I think the history of technology is about the inexorable replacement of technique with technology, improving efficiency at the expense of flexibility.

For example, many years ago, finding your way around required pretty detailed knowledge about celestial motion and the local landscape. You had to use sticks and shadows, or stars, to figure out where North is, and you had to know a lot about the immediate geography (and geographic processes) just to answer “where am I?”.

Maps and compasses turned orientation into a technological task. Reading a map requires a great deal of technique, of course (as does using a compass), but much less than having to orient yourself without either of those things. You have to learn how to read a map, and you have to learn how to calibrate a compass and compensate for the declination of magnetic north. But maps and compasses allow much more efficient orientation than astronomy and local knowledge. If you have a compass and the right maps, you can find your way anywhere in any conditions ... no need to wait for the right celestial conditions (a clear sky), or spend time learning the local terrain.

GPS renders maps and compasses slow and fussy. If you have a good GPS receiver you don’t need to know how to use maps or compasses, and (more importantly) you don’t have to acquire a map before you start out on your journey. The GPS is much more efficient for the unskilled orienteer than maps and compasses, which are in turn more efficient than astronomy and local knowledge.

My discussion of GPS kind of paints technology as the clear winner over technique, but I can think of at least two downsides to a reliance on technology at the expense of technique. From a practical perspective, technological solutions presuppose a certain number of systemic, social, or other technological prerequisites. For example, if the Hubble telescope exploded and took out half the GPS satellites with it, your GPS wayfinder might become a useless paperweight. It would take a a pretty big systemic failure to render a compass and map useless.

But more than that, inattentiveness to technique means putting a lot of knowledge into a conceptual black box. You don’t even have to know what “north” is to use a GPS.

When the topic is GPS and maps, technique vs. technology seems kind of abstract and quaint. But using low-technology techniques allows a craftperson — especially a novice — to peek into that black box. I would rather, for example, hire a designer who started out coding their HTML by hand, even if they use a WYSIWYG tool to do so now. Someone whose only knowlege of orienteering is “I turn where the little box tells me to turn” is not likely to be a creative thinker about how to get un-lost. Just before Orion was born, I got into a little discussion with David Carson(!) about just this subject on the 37signals blog.

The older I get, the less faith I have in technology. (This is surprisingly common among people who work with computers). My French press broke last week, the fourth such press that’s broken for me. I’ve therefore taken to making cowboy coffee, definitely a triumph of technique over technology. With less prompting, I’ve been using a reel mower instead of a power mower, vim in deference to a word processor, and a bicycle instead of a car. (And I’ve started paring my fingernails, which even I admit is pretty pointless.)

I don’t so much fear a technology’s failures (although, with energy prices rising I think it should be a concern), as I appreciate the unusual attention to detail the low-tech method affords me. With the reel mower I can physically feel the way grass grows. Cowboy coffee has literal texture. My commute by bike connects me to all the places between my home and office. Vim makes me slow down and consider my words.