Red Sweater Blog: Build your own damn HIG

Daniel Jalkut recently blogged about building your own damn HIG, where he takes inspiration from John Gruber's C4 speech on why the Human Interface Guidelines may be dead. If you haven't read it yet, you may want to so so now.

One thing he overlooks is that, just maybe, computers have become more sophisticated: Back when the Macintosh came out, resource limits forced elements on screen to be simple. Now that we have more colors and more pixels, and bigger hard disks, there's room for more variation, without making things too difficult to recognize.

Similarly, back then Apple pretty much had to introduce people to the GUI. "educate" the users. Nobody knew insertion marks, pointers, the mouse, menus... These days most people are familiar with the basics. Just like a caveman would probably not have understood what a button was before the invention, the race as a whole had to learn, so to say. What would be an odd, stuck pebble, maybe, that you can push a button and cause something else to happen, maybe miles away, is a more recent invention.

That you can move a mouse and a pointer will move synchronously on the screen, and that the "world" on the screen basically works the same as the real world, is even more recent. But these days, children see their parents use a computer, and much of a computer's chips and usability has partially made it into simpler devices, be it the iPod or your TV or your cable box.

I also think that he's overlooking a third option, apart from ignoring the HIG or just following your stomach: Doing your own usability research and creating your own UI, inspired by the basic conventions of the platform you're on (not applicable items are shown dimmed, close boxes have an "X" symbol and either a certain shape or color...).

I often recommend the book GUI Bloopers by Jeff Johnson to people who don't know about usability. Why? Because even though it mainly has screen shots from Windows 95 and System 7, it is still perfectly applicable to today's user interfaces. With the vocabulary of these simpler operating system user interfaces, with these prototypical, I might even say archetypical graphics as examples, it shows you the thought behind the guidelines, not the word up front.

It's like the Bible: "An eye for an eye" doesn't mean: If someone hits you, hit back. Rather, it tells you to consider commensurability: If someone pokes out your eye, don't kill his family as it happened in those days. So, what seems to be a very violent command to today's audience, was actually an obvious call for moderation in the context of ages past.

And before I go off on a tangent, I'd better close this posting.

Reader Comments: (RSS Feed)

Denis Defreyne writes: I don't believe that the third option, creating your own GUI, is a good approach. The perfect example for this is Haxial KDX (http://www.haxial.com/products/kdx/). It has its own GUI; it uses no GUI elements provided by the native operating system, and doesn't even try to simulate them. It does have all the elements you'd find in a typical GUI: a cursor, windows, menus, buttons, icons, scroll bars, and much more. Items are dimmed when they're not used. Close boxes are represented by an X. But it still feels very different from, say, Mac OS X GUI; for example, directories are opened with a single click, not a double click. Windows have menus associated with them, and they're opened by clicking on a striped area in the title bar. Maybe these are just details, but they take a little while to get used to. The problem is that it doesn't just LOOK entirely different, it also BEHAVES quite differently. If Apple changes their GUI, people complain about lack of consistency. I think people are overlooking one thing: all user interface elements are still quite recognisable. If SomeApp 2.0 suddenly has gray buttons instead of blue ones, nobody's going to be confused and wonder what "that gray rectangle" is and does. If, on the other hand, you take a Haxial KDX approach and give your application a radically different GUI (but still based on the basic ideas of GUI design), THEN you loose consistency—especially if the behaviour of your custom GUI elements doesn't match the behaviour of their native counterparts. I believe that there is more than enough consistency between Apple's apps. Even the GUI of iTunes or the third-party Disco app (http://www.discoapp.com/) is consistent enough. Heck, if every app would use only the native GUI elements provided by Apple, and no custom ones at all, Mac OS X would look a lot more boring than it does now. Custom GUI elements set applications apart. It makes them pretty. It makes them easier to recognise. It's similar to the world wide web. If no web pages would be styled (no CSS, no font tags, no tables for layout, nothing), the WWW would look awfully dull. Fortunately virtually every page has its own style. Sometimes it's really awful and inconsistent: h2's larger than h1's, bright flashing pink pieces of text, etc. But sometimes it's pretty and consistent: a recognisable header, navbar, sidebar, main content, etc. To cut a long story short, I believe that "being consistent" does not mean you should use the standard set of interface elements all the time. As long as an interface element is recognisable and functions identically, it is "consistent".

Uli Kusterer replies: ★ @Dennis: Well, one could argue that one would still be using the standard set of interface elements all the time. They'd just be themed, so to say. The look is modified slightly, maybe a few of the proportions, but the rest of the GUI element is the same. But yes, I mainly agree. On the other hand, if someone (justifiedly) creates a completely new user interface element, it now becomes much harder not to make it look just like a themed variant of another.

Mark Munz writes: I agree with Dennis' comments. While the "look" of Apple's apps may change, they are still consistent in their behavior. The upper left window buttons remain where they should, the buttons behave in expected ways. Apple has to push the envelope, otherwise everything would still look like System 7. That said, I too, wish that more tools were available to allow us regular folks to easily develop ProKit-like or iTunes-like interfaces. I'm hoping that Leopard + the new IB will help make that easier, whether it comes from Apple or somewhere else. Regardless of the look, the consistency is an even deeper magic. If iTunes, Safari, iLife were inconsistent, you would struggle to even use these -- but that's not the case. Most of the behaviors are right in line with what you expect. They also tend to follow such guidelines as how many pixels from the edge to place content, etc. Does HIG needs to be updated? -- Definitely! It should include guidelines for developing ProKit and iLife style applications, including HUD guidelines. Is Apple blatantly ignoring HIG? Yeah, in some cases. And some of the decisions aren't great (Mail's toolbar comes to mind), but I think they're still following the spirit in a lot of ways. Also, remember that Apple consists of many, many teams -- some of which may just ignore the guidelines. Should we throw out HIG? No. I don't think enough developers study HIG in the first place. Once you better understand HIG, you can push the envelope. But if you're just making it up as you go -- your app will show it. We've all seen the shareware program that you launch and just go "ugh! -- that's total crap". Often times, it points to not following HIG. We're not all GUI wizards, so HIG acts as a nice set of rules to keep us from creating really ugly crap. And finally, a reminder: HIG is not a document cast in stone. It changes over time. What was acceptable in the early 90s for System 7 looks horrible today in Mac OS X 10.4. Even the stuff of 10.1 looks out of place (old-style tabs and that striped line pattern come to mind).

Comment on this article: Name: E-Mail: (not shown, hashed for Gravatar) Web Site URL: (optional) Comment: (plain text only) Please Enter the following word:

Or E-Mail Uli privately.