As the world of customization begins to open up for Mac OS X Leopard, we here at MacThemes are ready to continue keeping the community informed of the latest news and events in Mac design, themeing, and software. Though our front page has been whispering along as we leave our beloved Tiger systems waiting for the 10.5 GUI to burst open for creativity, we’re certainly not going anywhere, and we want to deliver as much new, exciting content to your eyes as we can. To honor this, we’re launching a new series entitled “MacThemes Editorials”, which will feature the personal opinions of our very writing staff on GUI customization and software. Austin Heller premieres our series with a piece published today on his weblog, entitled “The HUD Conundrum”. We hope you enjoy it!

---

If you’re fairly knowledgeable about Mac software, you might be familiar with heads-up displays (HUDs)- those semi-transparent black windows you see occasionally in applications. Over the past couple of years, they’ve been showing up as pleasant-looking replacements for palettes, and, when implemented properly, can be useful when you have a lot of data to manage- after all, it’s a lot easier to see through a semi-transparent window than a totally opaque one.

But there is a fundamental problem with HUDs: on the software front today, there is no aesthetic consistency. Certainly all of them are equally usable and serve similar functions (more on that later), so the issue is more of a cosmetic one. But isn’t that the whole point of HUDs- to be nice-looking replacements for palette and/or inspector windows?

So let’s take a look at some examples, from a per-application basis. Here’s what a HUD window looks like from Apple, in the Finder’s Quick Look:

Twitterrific’s main window:

Pixelmator’s “Layers” palette:

Coda’s “Clips” window:

There are three others I won’t list for sake of running this post preposterously-long with images: CoverSutra, iPhoto, and Shiira.

A few observations regarding the four pictured above:

1. None of the titlebars have the same shade of color or, when applicable, the same glossy appearance.
2. Each HUD has a different sized drop shadow- or, in the case of Twitterific, have no drop shadows at all. *
3. Every scrollbar is a different color- shiny black, shiny white, and pure gray.
4. The highlight selectors of each HUD are inconsistent- Twitterrific uses an outline, Pixelmator has the bright Aqua highlight, and Coda uses a solid, semi-transparent blue.

Et cetera.

* Yes, I’m aware Twitterrific offers the option to turn on the drop shadow. However, the drop shadow is turned off by default, and I imagine most Twitterrific users just stick with the default settings.

Now, for those curious, Leopard’s Interface Builder 3 ships with support for standard HUD windows, which look exactly like Quick Look and iPhoto. This is good for uniformity, but it doesn’t really solve the problem, since they’re only available for Leopard and the majority of Mac users are still running Tiger. On top of that, this window subclass lacks HUD-style resources many applications would require- namely, scrollbars, buttons, and selection highlights.

Then there are the third-party HUD window subclasses. Soon after iLife ‘05 shipped, several well-made third-party ones emerged for download, my favorite being BlkAppKit, a Shiira subproject that looks identical to the HUD style used in their web browser.

But then we get back to the uniformity problem: Shiira’s solution does not look like Apple’s- it’s beautiful, and in my opinion better-looking than the standard Leopard subclass, but the fact stands that it’s not consistent with Apple’s HUD appearance.

There are two solutions to this, the way I see it:

1. A good, though not guaranteed, solution is to have developers write to Apple. Apple has a good track record of listening to their developers regarding OS X’s aesthetics, so enough support could result in making HUD-style widgets a reality.
2. A more tentative, though effective, solution would be for developers to just copy Apple’s design- precisely down to the last pixel, a task that wouldn’t be hard for GUI communities- until something official comes along.

Defining a HUD

There’s another issue that is at least partly related to aesthetics: what defines the usage of a HUD window? Quick Look, Coda, and Pixelmator use HUD windows to assist standard applications; but Twitterific and CoverSutra are actually full applications that use this window style as the main window.

I say “partly related to aesthetics” because if rules are given for a HUD window’s usage, accompanying design rules (note: graphic design, not usability design) distinguishing palette/inspector HUDs vs. full application HUDs should also be established. Twitterrific’s yellow titlebar, set in 13px Lucida Grande as opposed to 12px white Lucida Grande for palette HUD windows, sounds like the perfect solution to me.

If only Apple had a document that could lay down the guidelines for all of this.