A couple of weeks ago, someone on a programming mailing list that I read asked for advice on porting a Windows program he’d written over to the Mac. Most of the folks on the list, which is dedicated to Windows, Linux, and Mac software development, advised him that simple ports of Windows software generally tend to fare poorly on the Mac. Mac users tend not to like obvious ports from the Windows world, and several folks suggested that he might need to do some rejiggering of his program;s interface layout–moving buttons, repositioning alert icons, and so on–so that they fit the Mac guidelines better.
Which is true, but incomplete, and misses what I think is a really important point about software design. Or any kind of design, for that matter.
Right now, as I type this, Apple and Samsung are involved in a nasty patent spat concerning infringement of certain Apple user interface patents for cell phones. A lot of folks commenting from the sidelines on the spat tend to paint Apple as a villain, usually on the grounds that the patents in question (which generally relate to things like how searches work and so on) are “obvious,” and therefore shouldn’t be patentable at all.
Leaving aside entirely the question of whether or not Apple is the bad guy, the fact that so many folks deride the user-interface patents in question as “obvious” demonstrates a couple of important principles.
The first is that many computer geeks don’t understand design, and because they don’t understand design, they have contempt for it. (It is, unfortunately, a very common trait I’ve noticed among geeks, and particularly computer geeks, to assume that if they lack some particular skill, it’s only because that skill is trivial and not really worth bothering about.)
The second is that people tend not to pay attention to design unless it’s bad. Good design always looks obvious in hindsight, when it is noticed at all.
Today, touch-screen smartphones have generally settled on the same overall user interface idea: a series of virtual pages, accessed by swiping, which contain icons that can be touched to launch applications. But it wasn’t so long ago that such a simple and obvious user interface was unknown. Case in point: The first Windows CE devices.
The Windows CE-based smartphones used the same metaphor as Windows desktop systems: a “desktop” onto which you could place icons, and a tiny “start” menu in the corner of the screen which you would touch with a stylus or move a virtual mouse pointer over with a set of arrow keys or a rocker button to bring up a menu of applications.
This user interface succeeds on desktops but is an abject, epic failure on small screen devices because it simply isn’t designed for a different usage environment. Yet this, and things like it, were the norm for handheld devices for years, because nobody had come up with anything better. Nowadays we look at Android or iOS and marvel that anyone could be so dumb as to attempt the Windows desktop interface on a phone. Good design always looks obvious in hindsight.
So back to the mailing list.
Several of the responses the guy who wanted to port his software received concerned learning things like the ‘correct’ button placement and icon size on Mac systems. But that does not, I think, really address the central problem, which is that Mac users (and I know I’m going to get some flak for saying this) are accustomed to a higher level of design than Windows users are.
And there’s more to design than how big the icons are or where the buttons are placed. Way too many people have this notion that design is something you bolt onto an application after it’s finished; you make the program do what it should do, and then you call Joe the graphics guy from the other side of the building, who isn’t a real programmer but knows how to do some graphics stuff to make it all look pretty.
Back in the early days of the Mac, Apple released a rather hefty book called “Macintosh Human Interface Guidelines.” I had a copy of it for a long time. It’s quite thick, and covers almost every aspect of user interface design. Yes, there are a lot of bits about how many pixels wide an icon should be and where a button should be placed on a window, but it goes way beyond that, into program flow, error handling, and a lot more.
It’s a book I think all programmers should read, regardless of what environment they program for.
I don’t think Windows has ever had an equivalent to this book. Window prior to Windows 95 didn’t seem to have any such book, at least not that I can find. The earliest published document I can find for Windows was produced in 1995, and was quite short, covering nowhere near the depth of program design as the Mac version. A PDF is available here. I’m pretty sure Linux hasn’t either, though individual user interface shells may. (Gnome has one, and so does KDE; Unity seems not to.) And I think that helps contribute to the contempt that many programmers have for design, and to the notion that design is “pretty pictures that you put into the dialogs after the program is done.”
I wrote a reply on the list outlining some of the difficulties Windows programmers face when trying to port to the Mac. The considerations do include where to position user interface elements on the screen, of course; Mac programmers expect a certain consistency. But there’s a lot more to it. Here’s what I wrote:
The issue with Mac software isn’t one of following a list of guidelines, in my experience, so much as one of practicing good design.
The principles in the Apple Human Interface Guidelines tend to promote good design, but there are many applications that don’t follow them (even applications from Apple) yet still give the ‘user experience’ that Mac users want. It’s about good, thoughtful, humane design, not about how big the buttons are or what fonts are used or how many pixels away from the edge of the window the buttons are located.
“Design” is a difficult concept, and one that a great many programmers–even good programmers–don’t have a good grasp of. There are a lot of terrible applications out there (on all platforms), though in the years I’ve been using Macs, Windows, and Linux I’ve found that Mac apps generally tend to be better designed than apps for the other two platforms. Indeed, Linux in particular tends to reward inhumane application design, enshrining programs with great power but also with an obtuse, cumbersome, and heavy user interface that is opaque to anyone without a thorough understanding of the software. EMACS is arguably one of the greatest examples of software utterly divorced from humane design. (Before anyone accuses me of engaging in partisan holy wars, I started using MS-DOS at version 2.11, Windows at 3.0, and Macs at System 1, and I’ve been using Linux since about 1998. I first came to EMACS on a DECsystem-20 running TOPS-20; before that, I used TECO on a PDP-11.)
Humane application design extends way beyond pretty pictures in the splash screen and memorizing lists of rules about where to put buttons on a screen. The principles of humane design are probably outside the scope of one email on an email listing, but they include things like:
Clarity. A well-designed user interface strives, as far as is reasonably possible, for simplicity, obviousness, and clarity. Functions presented to the user should be done in a logical and comprehensible manner, with similar functions presented in similar ways and available options described in the clearest possible language.
Consistency. Different areas of the software’s human interface should be designed, as far as is possible, to be both visually and functionally similar. If the user changes from one mode to another, she should not be presented with a jarringly different interface that is arranged entirely differently. Functions that are common to all areas or modes of the software should continue to work in the same way. The Microsoft Office suite is an example of a set of programs with poor consistency; in each of the parts of the suite, the same functions are often located in different places, under different menu items.
Predictability. Humane software does not modify or delete the user’s information without the user’s express permission. Consequences of user action, especially action that might involve loss of data, should be clearly communicated. User choice should be presented in a way that clearly communicates the results of the choice; for example, an inhumane, poorly-designed dialog box might read “A network error occurred” with buttons reading “OK” and “Cancel,” as the user is presented with no clear way to predict what pressing each of those buttons will do.
Ideally, buttons should be labeled verbs, which help to communicate the consequences of making a selection as rapidly as possible. It’s not great design to have a dialog box reading “A network error occurred; try again?” with buttons labeled “Yes” and “No.” Better is a dialog box with buttons labeled “Try Again” and “Disconnect.”
Clear communication. There’s a great example of this in the Apple Human Interface guidelines. A poorly-designed error message for a text entry field might read “Improper data format entered.” A better error message might read “”Numeric entry only.” A well-designed error message might read “The ZIP code must be five numbers or five numbers with a dash and four numbers.” The software communicates what is expected in a way that is easy for the user to understand, even when (in fact, especially when) an error condition is encountered.
Resilience. The design of the software should strive, as far as is possible, to preserve user input and user data even in the event of some sort of error condition. This means, for example, that the software will not discard everything the user has entered up to that point if the user types an incorrect ZIP code; the software will not lose the user’s input without warning if the user leaves one mode and enters another mode (for example, if the user types part of a shipping address, then backs up a screen to change the discount code she has entered), and the software will always make it clear if data will be or have been lost.
Forgiveness. The user interface should, as far as is possible, be designed to forgive mistakes. This includes such obvious things as Undo functionality, which in this day and age even the most inhumane software implements because it’s become part of the cultural set of expectations from any software. Better implementations include the ability to Undo after the user has done a Save or a Revert to Saved (Adobe applications consistently implement this). Humane software will not irrevocably destroy a user’s data at the click of a wrong button, will attempt insofar as is possible to recover data in the event of a crash (applications like Microsoft Word are quite good at this, though it’s not always technically possible in, say, large graphics editing apps).
Familiarity. Good design does not have to be beholden to the past, but if you’re presenting the user with a completely unfamiliar experience, expect resistance. When a person gets into a car, she expects certain things from the user interface; replacing the steering wheel and pedals with a joystick and the windshield with a holographic projector might be appropriate for a concept car or a science-fiction movie, but probably isn’t for the next-generation Chevy Lumina. If you change things about the expected user experience, make sure you have a clear and compelling reason to do so; don’t violate the user’s expectations merely because you can. This, unfortunately, is the only place where many programmers feel design is important, and is where rules such as the fonts used in buttons and the distance the buttons are placed from the edge of the window come into play.
Responsiveness. The application should be designed in such a way as to remain responsive to the user as often as possible in as many conditions as possible, and throw as few roadblocks in the user’s way as possible. This goes beyond simply shifting CPU-intensive operations into their own thread, and encompasses a number of architectural, coding, and human interface choices. For example, humane software is modeless wherever possible; use modal dialogs that block user activity only where absolutely necessary and where no other design decisions can be made. Make it clear what window or data is affected by a modal dialog (this is a place where I believe the design and implementation of Windows falls short, and the Mac’s “sheet” window is a significant human interface win.) If you must use a modal window, seek wherever possible to allow the user to clear the fault within the modal window, rather than forcing the user to dismiss the modal dialog and then go back a step to fix whatever the problem is.
There’s a lot more, of course, but the basic point here is that good design isn’t something that you glue onto a program with pretty icons and controls that follow all the rules. It’s something that has to be baked in to an application from the ground up, and for better or for worse it is my observation that the users’ expectations of good design techniques tend to be higher on Macs than on other systems.
I think there are also signs of this objectification in the expectations for the way people behave after a romantic breakup. When a relationship–especially a sexual relationship–ends, there’s a social expectation that the people involved will revile each other; ex-partners who are on good terms with one another tend to be treated as something of an aberrant curiosity, like something we should be looking at from behind a roped-off area in a circus sideshow somewhere. Part of that is certainly that the ending of a relationship can be painful, and we are not really taught how to process emotional pain well; but part of it does point to the notion that if we break up with someone, it’s because that person failed in his or her duties to meet our needs, and why would we want to keep them around? After all, isn’t that a bit like hanging on to a broken toaster or something?
My sweetie 
I recently saw a brilliant example of the Magic Genital Effect in a poly forum I sometimes read. A person in that forum argued that a big problem with polyamory is that the secondary will eventually want to be recognized as an equal partner, and that’s bad because it might cause disruption in the “primary couple” and in the primary couple’s social circle if they have friends who aren’t poly. He argued that an existing couple has a history together, and anything that might cause disruption to that is bad and must be avoided.
