?

Log in

No account? Create an account

Previous Entry | Next Entry

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.


Comments

( 9 comments — Leave a comment )
apestyle
Jul. 9th, 2012 11:51 pm (UTC)
My windows developer friend bristled:

"It's not like the author has done any kind of research, otherwise it would have been pretty obvious that the description of the Windows CE environment was quite wrong and the fact that Windows design guides, published by Microsoft, have been around since at least 1994 (first one I've used, there may have been some before that)

They didn't have a "desktop where you could store files and folders", they didn't have a "virtual mouse". All this stuff is just made up, out of textbook elitist ignorance.

I think that when someone wants to speak from some kind of authoritative standpoint, they should have all their ducks in a row and their facts well checked. Otherwise, if you can spot stupid mistakes in things you know, how can you be sure that what you don't know is factually correct?"
tacit
Jul. 10th, 2012 12:28 am (UTC)
The post has been updated. I have been able to find a PDF of the Windows version, though it doesn't cover anywhere near the same depth of information as the Macintosh HIG, and postdates it by almost exactly a decade.

The Windows CE devices which used a virtual mouse-like pointing device rather than a touchscreen included almost all the first-generation Windows CE smartphones, which typically included arrow keys, a rocker, or a small ball to move the cursor around the screen. (In fact, when Microsoft changed the name of Windows CE to Windows Mobile, they adopted different terminology for touch screen and non-touch-screen devices, the former being called "Windows Mobile Professional" and the latter "Windows Mobile Standard" devices.) I'm not quite sure why your friend would claim no such devices exist, unless he's thinking of something else when he reads "virtual mouse."

He may not like the essay, but no matter how you slice it, the Start menu in the corner of a small-screen display device like a phone, through which the user selected applications, is a major human interface failure, and it did not survive the advent of better human interface designs for phones.
mcfnord
Jul. 10th, 2012 12:00 am (UTC)
nleseul
Jul. 10th, 2012 12:17 am (UTC)
I can't find a link now, but I know that I've seen a fairly lengthy document from Microsoft explaining how to do good UI design in the Metro visual language.
james_the_evil1
Jul. 10th, 2012 10:38 pm (UTC)
Yup. I have friends on that team, they have a HUGE freaking book. They've learned.
mr_z
Jul. 10th, 2012 08:45 pm (UTC)
use modal dialogs that block user activity only where absolutely possible

Somehow, I don't think you meant that...



Edited at 2012-07-10 08:46 pm (UTC)
tacit
Jul. 10th, 2012 10:00 pm (UTC)
Heh. Right you are! Fixed now.
khall
Jul. 10th, 2012 09:01 pm (UTC)
I agree with all of this. Except, it's wrong in a way. The problem is...computer science is still...bleeding edge. The guys who can write really good programs, are often super-specialized in that. It takes an artists or a photographers or something eye to see...good design. The skills very rarely overlap naturally and there is so much focus on good design of programs, that...the UI is always an afterthought. A lot of the coders I know...the idea is 'look at all this cool stuff it does' not...'how easy can you do this'. It's a different philosophy. Not a right one. But...it is sorta like asking brain surgeons to leave artistic scars. At least from the perspective of the people actually doing it.

K.
james_the_evil1
Jul. 10th, 2012 11:37 pm (UTC)
I deal with this a lot at Insider House, given that I am the "user" representative, and the visual guy. I'm constantly fighting with our programmers over stuff they want to do because it just will NOT work, and in fact the last time they did a major revision to one of our sites I screamed bloody murder & told them it would fail, but was overridden. It cost us two YEARS of audience and users and it's costing a ridiculous sum of money to fix it now. Amusingly enough, as they brought in professional designers almost all the things they were told to do mirrored my initial suggestions entirely.

There's something else I think you're missing in this, tho, which's not just contempt for skills they don't have but contempt for those not at their level & a tendency to work in a bubble of others who think like themselves. I've butted up against that a LOT at work. For instance, one of the guys likes to put connections to other pages or tools in as discrete links or sub-menu blocks thaty're almost identically colored to other text or design elements. I keep telling him "NO, things need to be BIG OBVIOUS BUTTONS, or set out in such a way that it's plainly visibly obvious that it's a separate menu area." He just doesn't get it & keeps insisting "the users MUST be savvy enough to get THAT!" even when our panels of "power users" routinely say they "don't get it." When it's drummed in to his head that things cannot be as obscure as he feels they should be, he gets grumpy about how "the users are just too stupid and I don't want to program for idiots."

On the "bubble" side, about a year & a half ago one of the other guys started INSISTING we add those stupid floating persistent bottom of the screen toolbars, with social networking buttons & hotlink items & such. I responded that they were ugly, users hated them, had limited utility, and that on smaller screens (netbooks, small laptops, pads) they too up valuable space. He responded that they were the HOT NEW THING and ALL the cool programmers & sites were using them & it was all over ever coder website and blog that you NEEDED them. I politely asked if any of those stories had USER feedback (he's no good at people in general, much less users) and he sheepishly replied "no." At which point we did a broad poll on Facebook with something like 10K responses in 24 hours that ran 97% against, even from other people he knew in the tech biz. That shut him up, and time's proved me right as most sites which implemented hose things have removed them, a few companies peddling them as apps or add-ons closed, and Facebook even scaled them back. But in the initial thrust he was all about what his "bubble" told him was right.
( 9 comments — Leave a comment )