Build Your Own Damn HIG
October 22nd, 2006My summary of C4 includes what I think are the main points from John Gruber’s “HIG is dead” talk. (For those who aren’t famiiliar, HIG stands for Human Interface Guidelines, and is a long-lived and ever-violated prescriptive document from Apple). In that entry, I forced myself to (mostly) reiterate what I took away as the intended messages from the various speakers. But these guys got me thinking, and I’d like to expand upon my reaction to some of the most interesting ideas. I’ll start with Gruber.
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.
I’m picturing some Rowan Atkinson character standing alone on a sinking boat, foolishly but adamantly refusing to bail water as his knees, and then waist, succumb to the rising tide. “Queens order! Bailing shall not be performed by officers! Somebody bail this water at once! That’s an order!” He’ll die, but he’ll die having been right. Is that your fate?
Cry all you want, but the ship is sinking. Gruber presented two high-level alternatives for dealing with this situation, so that we continue to produce mechanically and visually beautiful applications (paraphrased, again because I have no notes):
- Synthesize an implicit HIG based on prevailing standards.
- Do your own thing with gusto.
But these are optimistic instructions. They only cover the decisions that lead to a beautiful app. By putting the choices into a context where the ugg-tastic choices are also visible I think we can learn something, and obtain some calm in the face of these “changing times.”
I propose that Mac developers have always been neatly divided into two groups: those who give a damn at all about HIG, and those who don’t. You know which group you fall into! I further propose that this high-level differentiator neatly and naturally directs developers towards either Gruber Choice 1 or 2. And never the twain shall meet:
- Developer gives a damn at all about HIG:
- Follow HIG to the letter (knee-tastically ugly result).
- Synthesize an implicit HIG based on prevailing standards (beautiful result).
- Developer could care less about HIG:
- Leveraging X-Windows, Java, and tcl (ass-tastically ugly result).
- Do your own thing with gusto (beautiful or ass-tastic result).
Extemporaneous charts don’t lie. Obviously you can make beautiful applications whether you believe in the HIG or not. But most of us prefer to play it safe, and don’t have the confidence to do our own thing with complete gusto. So for most of us the decision is the same as it’s ever been. We believe in the HIG because it helps us make decisions, but we also recognize that changing tides require changing our own personal rules about these decisions.
If you’re a developer who gives a damn at all about HIG, then you’ve already been either following it to the letter or synthesizing an implicit HIG. The only thing that’s changed now is the sheer amount of adaptation that may be required in formulating this implicit HIG. There’s a lot more work adapting to the current tides. Bail faster, peon!
Those charmed and beautiful people who can do their own thing with gusto and obtain beutiful results … bastards! I mean, more power to them. But they’ve always been doing it and getting away with it. They were doing it on System 7, in their own special way. They’re more resilient to the changing implicit HIG, because they choose not to abide by it. Only those of us (the masses) who rely on some form of HIG advice need to adapt furiously in times like these. And the first step toward a successful adaptation may be, as Gruber suggests, recognizing that the world is comfortable with all kinds of freakin’ buttons. And gradients are good, mmkay?
Feeling glum about the implicit HIG? Don’t worry – unlike the real HIG, this one is a sliding scale arrangement. It’s a sort of “gusto and beauty” plan with a safety net. You only adopt as much from the prevailing standards as you feel comfortable with. And if you mess up and end up erring too much in the direction of “HIG to the letter,” well things could be worse. You could look like an ass-tastic Java app. And when some crotchety old-timer challenges your UI and claims it doesn’t comply with the HIG, you can be Apple for the day and smugly reply: “it complies with my damn HIG!” and get back to work.
Update: Scott Stevenson and Michael Tsai have each written thoughtfully about this in their blogs.
October 23rd, 2006 at 12:07 am
HA! Tis’ but true…
October 23rd, 2006 at 1:45 am
[Do your own thing with gusto]
What we need is Interface Builder palettes that follow the HIG when it comes to interactions but expands in new directions when it comes to looks. That way any program that uses it still feels like a Mac program but also looks good. Take Brent Simmons’ new design for NetNewsWire, at the bottom right of the window he has a pop up menu for changing the style of the web view. Having a similar web view we have this switching options on a contextual menu and in the preferences panel, but Mr. Simmons’ way is so much better and obvious to the user. His design is the way of the future, which means I now have to sit down and create a subclass of NSPopUpButton that draws itself in such a pretty manner. Mr. Simmons, among many thing, is a better programmer than me, I would love to benefit from his expertise and be able to drag and drop that button subclass from a Developers Unite Interface Builder Palette. These resources exist and are wonderful: cocoadev, cocoabuilder, list of reusuable cocoa classes … But when it comes to interface we have to apply the Mac way, make it drag and drop easy for developers. A palette project like that has not only the benefit of making sharing easy but also knowing that the button was approved by fellow developers as not being ass-tastically ugly — at least on it’s own, how you use it is another matter.
October 23rd, 2006 at 2:09 am
Hm, only three paragraphs down and I write a comment, sorry for that.
“I”™m picturing some Rowan Atkinson character standing alone on a sinking boat, foolishly but adamantly refusing to bail water as his knees, and then waist, succumb to the rising tide. “Queens order! Bailing shall not be performed by officers! Somebody bail this water at once! That”™s an order!” He”™ll die, but he”™ll die having been right. Is that your fate?”
Muauhahaha :-))) I am _so_ into Rowan Atkinson and I can _so_ picture this scene. Great, great work!
Made the morning, cheers.
Best,
Jan
—
October 23rd, 2006 at 2:29 am
Points for using “ass-tastic” (and its brother “ass-tastically) so effectively here.
October 23rd, 2006 at 2:41 am
I unfortunately wasn’t able to attend C4 and hear Gruber’s talk, so excuse me if I end up repeating some of his arguments.
The longer that Apple keeps the HIG outdated and getting increasingly obsolete, the worse it is for users. We, as developers, should not only provide consistent user interfaces for usability reasons, but we must also do it to maintain a certain level of professionalism for third-party developers. Keep in mind, I’m not talking about the different types of interfaces, such as Aqua, Unified Aqua, Polished Metal, etc. I’m talking about applications that try to conform to a certain interface style, but aren’t consistent with each other.
Let’s take, for example, three Unified Aqua style applications I have on my screen at the moment: NetNewsWire Pro, K.I.T., and Yojimbo. They all have a similar visual setup: a unified toolbar at the top, a sidebar on the left, and a bar on the bottom of the sidebar with an add button represented by a plus sign, and an options button represented by a gear icon and a downwards pointing arrow. First off, the controls on the bottom bar have wildly different widths. The Yojimbo controls are much wider than the NetNewsWire controls, and width of the K.I.T. controls vary depending on the width of the glyphs.
As for the glyphs, some are glossy and some are not. The size and shade of the gear icon and associated arrow vary significantly between apps. The bar that these glossy icons sit on is represented as a matte gradient in K.I.T. In Yojimbo, the glossy controls match the bar beneath. And in NetNewsWire, the bar is similar to the controls but a little off.
Then there’s the sidebar background color, with some apps using a certain shade of blue, others white. Apple certainly doesn’t set a good example here with most (if not all) of their apps with sidebars having background color that is a slightly different shade of blue. Other Unified Aqua apps like Colloquy have started to use a subtle blue gradient as the background. And as for the sidebar selection bars, their gradients differ too among apps for both when the view is active and inactive. I’m sure by now you get the point that it’s a mess.
These are all excellent applications and I don’t intend to slight their developers in any way. These inconsistencies are not the fault of the developers. They are the fault of Apple for not having complete specifications for this (extremely popular) interface style in their HIG and for failing to provide free icons for use in commercial applications.
So what Gruber said about “synthesizing an implicit HIG based on prevailing standards” was well meaning, but the problem is that we don’t have exact standards for these new interfaces and for this reason, attempts to synthesize them come close, but fall short of meeting an actual standard.
And along with standardization, I fully support “doing your own thing with gusto”. If you have a talented UI designer on your team and have the initiative to make something great, I say go for it. The state of UI design on the Mac is only better because of programs like Quicksilver and Delicious Library, for example. They serve to inspire other developers and show users the creative edge that Mac developers have over those on other platforms. And if we don’t rely on indie developers to push the frontiers of UI design, who do we rely on? Apple? The same folks who gave us iTunes 7 with fuzzy mauve scroll bars, glossy black selection bars with blurry edges, and block caps ad nauseam?
What the Mac developer community needs is a Wiki-style site where talented Mac UI designers and developers can come together and develop a new and updated HIG. This site would detail proper button widths, gradients, exact heights for large and small source list items, etc. There would also be a collection of icons and glyphs under a BSD-style license that developers can use to make their apps consistent with other apps of the same visual style. And what’s most important is that as new UI styles and designs get popular, we can add them to the indieHIG promptly so that as developers implement the new style, they can be consistent with each other, providing a better experience for the user.
– Brandon Walkin (a.k.a br- on #macsb)
October 23rd, 2006 at 3:55 am
A wiki is great, we have one at cocoadev, but we should go further. I don’t want to have to read about the proper size of the arrow on the gear button or the shade of blue of a source list. I just want to drag and drop these objects to an interface. At the moment we all end up implementing the same idea from scratch and hence they are all slightly different. I do hope the new Interface Builder 3.0 comes with all kinds of new goodies.
October 23rd, 2006 at 7:35 am
As I mentioned to a few people at C4, I think part of the strain for HIG followers is that the rules have suddenly changed: Apple has shifted into a “cinematic UI” mode, and there ain’t any rules could be established for this, right now. Perhaps in a few years we’ll be able to codify a few things.
Also, as John Gruber pointed out, the Web has broken all the rules and basically established anarchy as the rule for UIs, so it’s no surprise that there’s (somewhat less, thanks to years of HIG inertia) anarchy in the Mac UI world.
October 23rd, 2006 at 7:50 am
There was some good discussion at C4 about having those “new implicit HIG” widgets like the gear button available in Interface Builder. The conclusion was interesting: it’s not too likely that Apple will give them to us. (That’s not to say that the people involved in the discussion necessarily wanted it to be that way, of course!)
My take on it is that we might see some of those things, but if we do, they’ll probably be a generation behind Apple’s latest look. Apple is constantly rolling their own widgets for their latest apps — see iLife and the software using ProKit, for instance. It’s in their interest to have that software look different (and “better”) when compared to what we’re pushing out the door because it keeps Apple on the cutting edge.
Even if they wanted to give us their new widget sets in real time, I don’t think they can: Apple is following the “do your own thing with gusto” path, so by the time they know where they’re going, they’re on the verge of shipping. (Consider John Gruber’s iTunes 7 screenshot discovery, for instance.) They seem to be using their own private widget kits for these new looks instead of something shared around Apple, and they’re probably not really consulting across product teams to build something shared right before shipping, so there is no central update that they can ship to give us the new widgets in Interface Builder. If Apple does want to give us those widgets, it’ll be a lot of work to roll them together into a single package and normalize the differences to provide something that’s middle of the line and usable across the board. I don’t think they could do it at the same time as they ship an update to iTunes, iPhoto, or GarageBand at the very least. It would take a while.
A community repository of these widgets that we could drop into our software would be a Good Thingâ„¢, but depending on your philosophy on application design, it may only be a start in the right direction. Some classes of applications are now trying to differentiate themselves by looking different from the others on the platform, so developers trying to make software like that will have to go the Apple route and forge off in their own direction. Unfortunately, that’s not as easy to bundle.
October 23rd, 2006 at 11:18 am
I think the HIG need not be followed to the letter anymore. Compare this with the best literature. It can break conventions such as spelling and grammar and become better in the process.
The best designers treat the HIGs similarly, following them in spirit, but occasionally breaking them in such a way that the end result improves.
In the eighties, this was not possible because the ‘readers’ of applications were too inexperienced.
October 23rd, 2006 at 11:21 am
I thought grubers talk was the best of them all, it was very thought provoking.
I do agree with the idea that the HIG is dead. I’ve never actually read more than one page of it, mainly because I didn’t have time. Yet I sorta just know where buttons should go and how things should look because of all the apps I’ve used.
I think the interesting point of grubers talk was that the HIG essentially isn’t being used anymore. People who develop mac apps know how the interface should be setup so it makes sense. The other thing I thought was interesting was he was basically saying how the new HIG is doing whatever makes your app look cool and gives that wow effect (IE DL, AppZapper, QS, Shiira).
Gruber was also saying how developers have to waste time implementing those gradient table views, special no-frame windows, fancy buttons, etc, etc. Well, we shouldn’t. I dont understand why there isn’t a repo or something, or just a page on cocoadev linking to UI subclasses and UI icons so we devs dont have to waste time implementing what has already been done 100 times already. I made a page on Cocoadev for icons, but we need NSButton, NSTableView, & NSWindow subclasses for all those fancy UI tricks.
October 23rd, 2006 at 2:52 pm
The longer that Apple keeps the HIG outdated and getting increasingly obsolete, the worse it is for users.
If that’s the case, the Mac should be a lot harder to use now than it was three years ago. I don’t think it is.
What the Mac developer community needs is a Wiki-style site where talented Mac UI designers and developers can come together and develop a new and updated HIG
So get to it. :)
October 23rd, 2006 at 3:21 pm
So get to it. :)
I’m working on it right now, Scott. When the site is up I’ll make sure to let you know. :)
October 24th, 2006 at 12:16 am
Since it’s fairly related, check out RSControls for Mail-like controls. The page links to this one, so I apologize if that creates a paradox of some sort.
October 24th, 2006 at 1:04 am
I’m in the unfortunate position of having used IB since around NS3.2 (and still do use GORM), which means my “UI design” involves letting the components snap to the grid (or these days the blue lines) and then being somewhat confident that my app looks something like someone else’s app. The only thing which has changed since then is the fractional quantity of other apps my app looks like…but as I’m often the only user and I like that look I’ve got better proportional user satisfaction than non-conforming apps like Finder and Safari so I must be right and they’re not ;-)
October 24th, 2006 at 2:50 am
I used to be a giant proponent of the HIG. I would completely freak out on apps that used their own custom widgetry and scream stuff like “not a Mac app” and “belongs on Windows”.
To say nothing of the fact that apps that use their own widgetry tend to look like ass if you’re using ShapeShifter.
But at this point, I don’t really care about HIG compliance anymore. Apple doesn’t follow them. At all. Ever. Why should I, when shiny apps demonstrably sell better than HIG-compliant ones?
RIPHIG.
October 24th, 2006 at 9:39 am
I worked on several iterations of HIG when I was at Apple in the late 90’s. That was always my favorite assignment, because I thought the notion of HIG was at the heart of Macdom (and I had a lot of company in those days.) But I have to agree that It’s All Different Now. If Apple had made a committed, consistent effort to keep the guidelines current and relevant, we might be having a different conversation. But they didn’t and we aren’t. So it goes.
October 25th, 2006 at 4:12 pm
“Build your own HIG?” iTunes 7… asstastic!
October 27th, 2006 at 2:06 pm
I’ve blogged my comments, they just got too long:
http://www.zathras.de/angelweb/blog-build-your-own-damn-hig.htm
October 29th, 2006 at 3:35 pm
Daniel,
I find this part of your post interesting:
Developer could care less about HIG:
Leveraging X-Windows, Java, and tcl (ass-tastically ugly result).
Do your own thing with gusto (beautiful or ass-tastic result).
Speaking as one who targest both X-Windows and Aqua with my code (which is Tcl), can you cite any examples of the “ass-tastically ugly results” you are speaking of? Gimp.app? Inkscape?
I think that you touch on an interesting issue, since in my own programs, I have to pay attention to multiple sets of HIG’s. X11 apps, despite what you say, do have some consistency in their interface conventions: control instead of command is the standard keyboard accelerator key, for instance, and “about the app” is usually located in the “help” menu instead of the application menu. Getting these details right isn’t a small task, and it’s certainly easy to tell when a Tcl/Tk app, for instance, is ported straight from X11 (or Windows) with no attention paid to some of these details. They do stick out.
An interface convention that no one seems to have mentioned is “an ugly-ass X11 application” that is nonetheless deployed as a standard Mac app bundle, and features hooks to allow some degree of integration with the Aqua environment. GimpShop and Gimp.app are good examples here: so is Inkscape. They are “ugly Gtk X11 apps,” but they can be installed via standard drag-and-drop, and dropping the correct file on the app icon will launch the app and open the file in the X11 environment. (AppleScript is really helpful here.)
I guess my point is that there are a wider range of acceptable interface conventions than the HIG, which Apple itself breaks on occasion. A lot of the applications that people praise here, though, are to my eyes way too busy to be useful.
October 29th, 2006 at 11:01 pm
Kevin: I think there is a lot of variance in how people perceive interface “ugliness,” and to be honest it just sounds like the things about X-Windows (and Windows) ports to the Mac that infuriate me are not that bothersome to you.
You ask whether I can cite an example? I would say every single one of them. I’ve yet to see an X11 interaction or any other non-Mac-native interface presented on the Mac with anything less than hideous results.
Functional? Maybe. But not beautiful and by no means a Mac app. Yes, the Gimp and Inksacape both fall into that category, in spite of having some fair amount of consistency as X11 apps.
October 30th, 2006 at 8:22 am
Daniel,
You say: “to be honest it just sounds like the things about X-Windows (and Windows) ports to the Mac that infuriate me are not that bothersome to you. You ask whether I can cite an example? I would say every single one of them. I”™ve yet to see an X11 interaction or any other non-Mac-native interface presented on the Mac with anything less than hideous results.”
Fair enough. I think there’s a difference in philosophy here about what the “Mac platform” is. I perceive you defining the Mac platform as it’s always been: the most elegant, intuitive GUI environment around. And, by extension, a “Mac application” is one that reflects the best design and usability practices of that environment. From this standpoint, the user-level continuity between the old Classic Mac OS and OS X is more important than the significant “under-the-hood” technical changes.
I guess I’m in the minority here: I see OS X as the most elegant, intuitive Unix platform ever devised. For me, the golden part of OS X is not the Cocoa frameworks, but the BSD subsystem. All those command-line tools that can be called and piped together in various combinations, and called from an Aqua GUI: that makes incredible power available to the programmer.
I’m also glad that X11 is available. To me, Gimp.app is a native Mac application–but then, I consider X11 and the BSD subsystem to be part of the “Mac environment.” Not the only part, by any means, but an integral part. The packagers of Gimp.app and OpenOffice do a considerable amount of work to make sure that these apps behave with as much integration as possible in the Aqua environment.
In the end, this may be more a matter of taste and philosophy than anything else–and I’m sure more folks would agree with you than me. That’s fine.
October 30th, 2006 at 8:48 am
Kevin – if I had to guess, I’d definitely assume that you’re in the minority. But I’m glad to have you and all the others in your minority on the Mac platform, instead of Linux :)
November 1st, 2006 at 11:57 am
There has been a lot of focus here on making beautiful UIs, which is something I think Mac developers are getting increasingly good at. Another important drive for having a guidelines is the need for consistency. I guess you could say I’m not worried about the future of Mac UI aesthetics, but I am concerned that a lack of guidelines could lead to a lack of consistency.
Just the other day my girlfriend’s Dad asked me why I use a Mac. He’s a Windows user and is wondering what all the hype is about, and he’s considering buying a Mac. I told him the number one thing that makes me a proud Mac user is attention to detail in the UI. Isn’t this why the HIG was so important back in the OS 7 days? The Mac has pioneered a UI that is consistently usable. Things behave as you expect them to across all Mac apps. That’s the idea anyhow. Granted a lot of what makes this happen is handled by the OS–but not all of it, especially when you are talking about X11, Java, XUL/Mozilla, etc.
So I love the idea of a place in which to create an “Indy HIG.” It seems to me that for cross-platform apps–especially those built in cross-platform development environments–to look good and feel like “real” Mac apps, there are going to have to be some sort of guidelines going forward. Guidelines–not just Cocoa widgets.
In my mind XUL/Mozilla is the closest to any of the other major cross-platform development platforms of enabling developers to ship native-feeling Mac apps. But it isn’t quite there yet. I think a document or even just a community that continues to have a dialog on these issues can only help.
January 16th, 2007 at 9:24 am
I was reading this and thought the idea of a site to discuss and develop a “de facto HIG” was a good one. However, in order to find Brandon Walkin’s excellent project, I had to use Google; I thought it might be nice to leave a link to it ( http://indiehig.com/wiki/ ) here for people who are looking for it.