Matt Gemmell

My new book CHANGER is out now!

An action-thriller novel — book 1 in the KESTREL series.

★★★★★ — Amazon

Death of a Dogcow

interface 5 min read

Apple loves it when people go on about how the Macintosh got a lot of UI design principles right long before the competition. We all love stories about the Icon Garden, and fondly remember Clarus the Dogcow (mascot of Apple’s Developer Tech Support department) in the Page Setup dialogs; how she symbolised all that was great about the Macintosh UI. Ah, the good old days.

Banished from Mac OS X, we all held out hope that she would return one day, gracing a Print sheet in some bright future where Windows and its mind-bending punishments were only a distant memory. Alas, it seems that instead of simply being put out to pasture in Cupertino, Jobs may have actually imposed a final solution. Clarus may now be dead.

Mac OS X’s Aqua UI has always been designed primarily to look cool. Certainly, there are some sound UI principles, missing from OS 9, which have finally been implemented. Witness the back-and-forth command-tab behaviour of the Dock (since 10.1, at least). Windows as layers independent of their parent application. The Apple menu actually making some kind of sense from a hierarchical command-structure point of view. But coolness reigns. The Genie effect. The magnification feature in the Dock. Hell, the entire Dock, complete with puffs of smoke and speech-balloon contextual menus. Apple has taken coolness to heart, and has successfully thrown the baby out with the bath-water. Your system and Apple applications are now designed explicitly to look cool; you’re running demoware.

Erik and I were chatting today about how Apple has lately been, at best, ignoring its own UI guidelines, and at worst flagrantly violating them. We decided to post a list of particular problems with Apple’s UI “innovations”, in the hope that others will add their own gripes.

Before I really start, let me first state that I’m not going to list “metal windows” as bad UI in themselves. I think that a different style of window can play a useful role - but it must be a tightly-defined role, and the rules for its use should be adhered to as strictly as is practicable. It’s in this area of adherence to guidelines where Apple falls down with respect to metal (“textured”) windows. But more on that later. For now, on with the list.

Graphical buttons

Standard UI elements are there for many reasons: consistency, ease of use, getting useful features for free (such as keyboard-navigation), making use of well-tested and optimised drawing code. Choosing instead to whip up all your buttons, checkboxes and so forth in Photoshop shoots those objectives in the foot. Not only does your app have to implement normal behaviours manually in a lot of cases, but your app bundle’s size balloons very quickly. In most of Apple’s i-apps, the buttons are TIFF images in the bundle, and not just one image per button: usually, there are four (normal, over, active, disabled). Multiply that by the number of buttons and widgets, and you begin to see why they launch slowly, resize slowly, and just generally run slowly. Your video memory is being used by these daft image-buttons, where standard UI elements would do the job just fine.

Update: I noticed the following paragraph, brazenly displayed in the Mac OS X Aqua Human Interface Guidelines section on Textured Windows.

Avoid creating custom controls for use with textured windows; standard controls look and behave appropriately when used with this appearance.

At least they’re preaching sense, if not practicing it.

Non-standard toolbars

Safari’s toolbar, and in many ways Safari’s UI as a whole, is the realisation o f a problem born back when Quicktime Player gained its metallic interface. Here’s a hypothetical situation: you’ve seen a lot of “skinnable” applications around - they’re fashionable, ever since MP3 player software started becoming a big thing - and you’ve designed a great skin for your app. But you’re the OS vendor, and the app in question is the public face of your heavy-duty cross-platform media engine, so you need consistency - no spotty teens making a Shania Twain skin to drool over. What do you do? Lose the skinnability, but keep the skin.

A bit later, you’re launching a new platform (itself a re-skinning of a previous one), and you want to keep your funky metal skin. But, furthermore, you want to use the same skin in some of your other apps, to fit in with your “digital hub” marketing angle. Amidst rising complaints from the developer community, who want to make cool apps too, you’re faced with a dilemma: keep the skins, or please the developers? You do both: integrate the skin into the OS frameworks, and let developers use it themselves. Then the whole platform will be cool!

But wait a minute - you’re supposed to be the king of usability, the very originator of truly easy-to-use software, and your OS’ adherence to UI guidelines is said to be the jewel in your crown. Better cobble up some UI guidelines for the skin, and fast. The problem is, there aren’t really any guidelines which fit. It’s a skin, after all. It’s meant to look cool, and be basically usable, but not much else. It’s certainly not meant to be inherently intuitive, or be a study in good HCI. So your guidelines don’t fit, are incomplete and vague, and are quickly disregarded by the legions of developers who just want to look cool (same as you).

Then, surprise surprise, you find that you really can’t even pretend to stick to your published guidelines since they’ll interfere with the Prime Directive: make it demo, number one! So you disregard the guidelines yourself, leveraging the fact that you’re the OS vendor to make sure that your users are so exposed to your skin-UI that it becomes quasi-intuitive through sheer familiarity. Then, one day, you wake up and realise that the average UI standard on your platform has dipped considerably, that you are personally one of the worst culprits, and that you’re increasingly being compared to another OS vendor that you wished was just a distant memory. Where’s the dogcow now?

Getting back to Safari’s toolbars specifically, the problem was so easy to foresee: web-browsers have toolbars. They have Back, Forward, Home, an address bar, and so forth. Apple wanted to use metal windows for their browser, cause that would be cool, man. There’s a standard toolbar API in OS X (the NSToolbar and NSToolbarItem classes), and whilst I think it’s fair to say that NSToolbars weren’t designed for use with metal windows, they would work just fine. Safari’s toolbar could readily be replicated using an NSToolbar set to small size and “icon only” (and indeed if you wanted to add labels for the toolbar items, you could do so with just a little custom drawing code, to replicate the Bookmarks Bar-style sunken text). You’d also get configuration sheets, reordering, dividers, and so forth - nice functionality, at no cost. Great, so that’s what you do. Erm… no. Actually, apparently the answer is to re-implement toolbars entirely, just for Safari. But look on the bright side: if the ex-REALbasic AppleScript Studio kiddies complain loud enough, perhaps we’ll soon see NSTexturedToolbar in the AppKit before long. Then it’s just a few short steps to Java-like UI hell in a handbasket.

Inappropriate use of metal windows

Of course, this is all begging the question as to whether Safari ought to use metal windows in the first place. Since Safari is a web-browser and is thus (1) definitely a multi-window application, and (2) not representing any physical media-related device of any kind, Apple’s own metal window UI guidelines advise using standard windows rather than metal ones. Then the normal NSToolbar appearance would fit, with no need for hackery, and you’d save engineering time and hassle. OmniWeb has already proven that NSToolbar is more than up to the task of providing web-browser toolbar functions.

Violating UI guidelines

This is a miscellaneous set of sub-points, extending from the previous section/rant/essay. The essential point is that Apple is not only failing to continue the grand tradition of the Macintosh HIGs (Human Interface Guidelines), but is actually going backwards - violating some long-standing UI principles whilst they trample all over the new ones. A few examples:

I have more to say on all this, but I’m tired and should really get some sleep. All thoughts and comments will be received with interest.