Copyright 2004 by M. Uli Kusterer Tue, 30 Dec 1969 07:58:58 GMT Comments on article blog-build-your-own-damn-hig at Zathras.de http://www.zathras.de/angelweb/blog-build-your-own-damn-hig.htm witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) en-us http://www.zathras.de/angelweb/blog-build-your-own-damn-hig.htm#comment3 http://www.zathras.de/angelweb/blog-build-your-own-damn-hig.htm#comment3 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).
http://www.zathras.de/angelweb/blog-build-your-own-damn-hig.htm#comment2 http://www.zathras.de/angelweb/blog-build-your-own-damn-hig.htm#comment2 Uli Kusterer writes:
@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.
http://www.zathras.de/angelweb/blog-build-your-own-damn-hig.htm#comment1 http://www.zathras.de/angelweb/blog-build-your-own-damn-hig.htm#comment1 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".