Thursday
7 Jun 2007
Why Software Stinks: Introduction
In my recent article Good Service—Bad Software, I made a stink about why open-source software is inhumane and unusable. To all those who read this and thought I was flaming, sorry, I really messed up there; my article sounded like a flame. As some commenters suggested, there are some excellent examples of humane interface design in the open source world. I know that there are forces for good in the open source world; among them, contributors who are unpaid and simply want usable software for their own use. I know that there are people, both in the companies I seemed to be accusing and outside of them, that try to make free and open source software usable.
So I asked myself: why on earth did I actually write this article, when I knew it was going to incite flames? What makes me so passionate that I feel the need to write articles like this? Because, well, software stinks.
Software Stinks
I’m talking all software. Not just open source software; not just free software; not just cheap software; and definitely not just Windows software. To be explicit, for those of you sitting behind your pretty white (or black or brushed-titanium-effect) screens, I include Mac software. As a full-time Mac owner and user, I state that Mac software is awful in some ways; it’s just more consistent in the ways that it is awful.
Don’t believe me? Okay, then try this on for size: Try to write one-page instructions for configuring HTTP proxy settings on a client computer. Those of you who don’t know what I’m talking about, don’t worry, you’ll get the idea in a minute. Suffice to say that “configuring HTTP proxy settings” is something that has to be done surprisingly often in order to make the Internet work on people’s computers.
At first, you will laugh, and scribble down instructions for how to do it Firefox in four or five sentences.
But then I will say: “Those only work on Firefox 1.5 on the Mac.” So you go to the trouble of looking up Firefox’s historical methods of setting this information, and take screenshots on Mac, Linux, and Windows versions of the software for Firefox 1.0, 1.5, and 2.0. There are just enough differences to confuse non-programmers (who will be reading this documentation, make no mistake) unless you make separate instructions for each of these cases.
And you might still be inside of one page. At which point, I’ll say: “Okay, now add instructions for IE, versions 5.0, 5.5, 6.0, and 7.0. Oh, and make sure that they work on Windows 95, 98, 2000, XP, 2003, and Vista(s). Oh, and try to make sure you include instructions in case the person is running Mac IE 5.5 or earlier. Oh, and make sure you don’t confuse the user about proxy versus auto-proxy.” And I haven’t even mentioned the rest of the Linux and Mac browsers. Or all the software out there that uses the Internet but isn’t a web browser. Or if there is a system-wide way to do this on Linux or BSD systems, it will vary (possibly wildly) with your favorite distribution flavor.
Get the picture? This is one task. It is a very simple task, in that you have three short strings you need to enter into some text field or config file somewhere. For many users in the world, you must perform this task to get your computer to do what you need it to do. And the software out there fails.
Okay, if it was simply the case that you needed a giant look-up table from system-type to the instructions, and those instructions were simple, this wouldn’t be so bad. But imagine trying to tell a user to figure out what version of Internet Explorer they are using, when they only know it as “that link on my desktop that I click on to get to my Yahoo mail.”
How do we make it better?
I’m not talking about how we make any one piece of software better. Ask one of the Raskins; ask Joel Spolsky; ask Don Norman; ask any of the couple dozen people who have been banging the drums about actually using the concrete facts of cognitive psychology and the principles of designing for low error rates, comfort, and ease-of-use. They can tell you a lot about how to make your software interface better. There are definite tools for making any given interface better, and measuring how bad it is.
But the tools are not being used! My questions is not how we make software better by better design; that’s Aza’s field. My question is: how do we make software better by actually getting better designs implemented?
That’s why I wrote my prior article about software and the service-driven economy. After I published that article and watched people’s reactions to it, I realized I failed. All I did is talk about the problem. Sorry about that.
Watch for more
Over the last couple years, we’ve been doing a lot of reading, a lot of interface design, a lot of coding, and a lot of trying to build a software company. We’ve done a lot of talking, and we’ve started to realize some of the reasons why it is so frustratingly difficult to make software humane. And that’s what we will be writing about over the next couple months: why it’s so hard to make good software, for both closed and open-source software alike. And, more importantly, what can be done to make writing humane software easier.
COMMENTS
14 Voices Add yours below.