Monday, October 23, 2006

Build Your Own Damn HIG

Daniel Jalkut responding to John Gruber at C4:

Is the HIG dead? I don’t know. But Gruber’s talk was thought-provoking, and I’m feeling pretty convinced right now, high on sleep deprivation and freshly returned from the fray. At the very least I think it’s time for us crotchety old engineers indoctrinated by System 7 or earlier values to mellow out a bit. I got so used to defending the party line for so many years, that I stopped questioning whether it was worth defending. Taking a step back now, I have to wonder why none of us, noticing that Apple was “constantly violating its own HIG,” stopped to consider whether we were the suckers for being so hung up about these problems on their behalf.

Violations in appearance are the easiest to see and get the most play. They bother me because I like looking at a consistent interface and because I think many of the custom controls are ugly. But it’s not that big a deal because, as the Web has shown, people know how to recognize weird-looking buttons. More important, I think, are higher level design and behavior. These were never as codified as the appearance guidelines, they’re more subtle and so are harder to build into an implicit HIG, and yet they determine what it’s like to use Mac software. This is where the real shift has happened in the second Jobs era.

I’m thinking of the card interface in Address Book; the decision that (until recently) iMovie would take over the screen and not allow more than one open document; the increased use of icons for verbs; the increased use of modes; the use of large multi-paned windows and tabbed inspectors over larger numbers of smaller windows, i.e. extreme reduction of window clutter even when this makes the interface constricting; the behavior of selected objects and panes; and the trend towards tabbed windows with a very small number of controls on each tab.

Apple has, deliberately or not, been doing a lot of things differently. There have been both good and bad ideas, with little guidance about which ones should be adopted, and in which circumstances. New ideas are rapidly adopted throughout Apple’s apps, but are slow to make their way into the frameworks. The problem is not that Apple has been breaking its own rules or writing new ones. It’s that—as the brushed metal saga has shown—Apple’s choices seem more driven by fashion than considered design. It’s leaving a leadership vacuum.

Update: Scott Stevenson writes:

Some Mac users are concerned that the lack of guidelines means things could spin completely out of control. Here’s what I’ve learned: Mac users, on the whole, have a sense of taste. If an app’s experience isn’t right, they simply won’t use or buy it. The Mac user base is its own filter. It’s not just theory, we’ve seen it happen.

Which is true to an extent. However, in some ways things already have spun out of control, and there aren’t enough apps for us to have the luxury of choosing a product that has the right functionality and good taste (though, fortunately, these sometimes coincide). Scott says “Can you imagine Front Row with NSTableViews,” but that’s a false dichotomy because Front Row is a full-screen app that will be controlled from across the room; it’s obviously an exception. I can imagine Mail with a normal outline view, and it works just fine. Also, I don’t buy the idea that there can’t be consistency or guidelines or framework support because the new stuff is still in flux. Gear buttons have been around for at least three years. They should be relatively easy to standardize. Yet they still look and behave differently in each app and they have no support in either Carbon or Cocoa. They are mentioned in Apple’s publication style guide, which calls them action pop-up menus—rather unfortunately, because “action button” has a completely different meaning in the interface guidelines and because historically pop-up menus (with up- and down-pointing triangles) have been for showing states. The gear button more closely resembles the pop-down menu, which has a larger down-pointing triangle and typically contains commands rather than states.

Possibly Related Posts

  • SQLite 2.8.13
  • Disco, FlexTime, and the HIG
  • Drive
  • Universal MacPython
  • The Design of Everyday Games

2 Comments »

jacobolus
October 24, 2006 2:02 AM

Hear hear!

I'm sick and tired of these new widgets apple adds in 5 different ways to their own apps. The gear widget, browser-style tabs, source lists, etc. etc.

I think the rule should be if it's in >1 Apple app, it should be in interface builder for all devs to use.

sponge bog
October 24, 2006 5:14 AM

There are 2 main issues:

- Apple is no more a partner to most 3rd party developers. It's a competitor. By creating its Application division, Apple decided to be a new Microsoft and behaves as such.

- Apple does not know where to go. If you look at the iTunes 7 UI, it's a Windows UI. Apple thinks the wow factor is everything whereas it's definitely the Bullshit factor they are moving toward.

RSS feed for comments on this post.

Leave a Comment

Copyright © 2002–2007 Michael J. Tsai.
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.