Namely 2.5

Sorry to be late by a week or so, but there are several reasons why I didn't get a Leopard-compatible update to Namely out sooner.

First of all, I didn't have Leopard any earlier than most of you; I bought it on Friday the 26th of October at the Apple Store on Regent Street. That's because unlike many Mac developers who dedicate a lot more time to this stuff and who have an income from it, I don't have a Select membership with the Apple Developer Connection.

Secondly, I decided to try out Leopard's improved support for application launching through Spotlight before putting any effort into updating Namely. Ever since Scott Forstall had hinted at this feature at the World-Wide Developers' Conference in 2006, I had been feeling a bit anxious about Leopard rendering Namely redundant. (I generally think it's a good thing when Apple fills a gap that was identified and addressed by third-party developers, but nevertheless, we do tend to fall in love with our applications.) My verdict: Spotlight is not bad, but it didn't win me over. I didn't spend enough time with it to figure out how clever it is about choosing between candidate matches (it seems to at least take into account which app you chose last time), but long enough to find a few things that I didn't like about it:

1. A lot of stuff happens visually in the Spotlight menu, which distracts from your main task: quickly identifying the application you want to launch.
   
2. The icons of listed apps don't always appear straightaway.


3. It only shows three matches, so it's effectively a bit less tolerant.

I guess these things shouldn't be an issue if you only occasionally need an application that's not in your Dock. Finding it through Spotlight will still be much faster than navigating to it in the Finder. But I think that if you use Namely (or, for that matter, any other keyboard-based launcher) for most of your application launching, anything that isn't super-fast isn't fast enough. When I launch an application, I don't want to think much, and I don't want to see much. I just want to launch it. Although Namely's sorting isn't perfectly predictable because it adapts over time, it stabilises quickly enough so you can be pretty confident about what it will suggest when you type something.

The third reason for the delay is that I just wasn't sure what to release. I have been (slowly) working on Namely 3.0, which is controlled through a preference pane and doesn't show up in the Dock. So I was considering finishing that off rather than releasing another update to Namely 2.x. However, I wasn't confident that I could get Namely 3 finished and stable within a few days, so I decided to push out a minor update in the meantime.

Here it is. Annoyingly, I couldn't find a way to make it work on both 10.3.9/10.4 and 10.5 (I link against the 10.5 libraries in order to support Spaces, but this seems to stop Apple's secret application-listing function from working on 10.4), so I had to leave version 2.1 available as a separate download.

Design languages

I have recently taken a great liking to the idea of design languages, which think of design as a form of communication between the designer and the user, and which provide a framework or style to work within when you’re creating a design.

Design languages are sort of like design guidelines, but specifically thinking of them as a language is helpful at several levels:

1. It provides the designer with a repertoire of visual “expressions” and constructs that have a specific meaning, helping them to express their ideas without reinventing the wheel.
2. It encourages the designer to stick to the rules and conventions of the platform. In the same way that you usually wouldn’t just throw a Russian sentence into a conversation you’re having in English, you shouldn’t use interface elements or interactions that your user won’t be familiar with.
3. A language is something users can learn. They can then transfer their knowledge between systems that use the same design language.
4. It gets the designer to think of their design as a form of communication, a way to convey the conceptual model and the functioning of the system to the user. It effectively promotes empathy.

On the Mac, the Macintosh Human Interface Guidelines (HIG) define the design language third-party developers (and Apple themselves) are supposed to use in their software. The HIG were once an exemplar of design languages. However, since the introduction of Mac OS X, rather than prescribing the design of interfaces, the HIG have developed a tendency to describe it, being frequently updated to reflect whatever new “conventions” the designers of the Finder, Mail or iPhoto have come up with, sometimes with rather unconvincing logic. The Mac’s design language has subsequently become rather bloated and flaky.

Take as an example one of the simplest interface elements of all: the pushbutton. I’m sure most long-time Mac users can easily recall what a pushbutton looked like on System 6 and 7:

In Mac OS X 10.4, it’s not so easy to say:

Taking the language metaphor a bit more literally, one could say that these are synonyms for the same concept. Worse than synonyms are homonyms, because they introduce ambiguity:

The segmented control can be cofigured to behave in three very different ways, and the only way to figure out which is the case is through trial and error or by guessing from the context. A more traditional way to express the same functionality unambiguously would be:

When Aqua first appeared, it was like a fresh start. It actually seemed simpler than Mac OS 9 in terms of its interface elements. However, Apple hasn’t been very disciplined with keeping it that way, and it’s quite astonishing how quickly the Mac design language has grown through influences from the different application teams' designers.

You could argue that these inconsistencies are just cosmetic matters of graphic design rather than of interaction, since the way Mac OS X’s interface functions is still relatively simple and coherent. But you have to remember that the graphical representation of the interface is the only communication channel from the designer to the user; we rely on it to understand what we can do, in the same way that you’re relying on my use of English to understand this article. It’s a language.

There’s a chapter on design languages by John Rheinfrank and Shelley Evenson in Terry Winograd’s book Bringing Design to Software (parts of this book are available online). Donald Norman has also written an essay about this entitled Design as Communication.

The Grand Unified Download Manager

Since the introduction of Mac OS X, Apple has been doing a great job of offering more and more functionality at the operating system level that application developers used to have to implement themselves. Spell checking, Address Book, Keychain, Dictionary, disk burning and PDF support are some good examples. Almost everyone wins when this happens: users get a consistent experience and are less dependent on particular applications, and developers have less work to do and can simplify their application code. The only ones who potentially lose out are developers who had seen the gap and were actually trying to offer such a service to other applications, like, for example, Nisus Thesaurus or Adobe Acrobat Distiller.

When I recently saw this post on the Omni Group forums by Jon Hicks, I saw another perfect candidate for Apple to assimilate: the download manager. As it stands, at least six applications on my machine implement their own download managers: OmniWeb, Safari, Firefox, Camino, NetNewsWire and Transmit. And, as Jon pointed out, they all have different UIs.

So what would such an Apple download manager have to offer? It would of course need to support the most common protocols, including HTTP and FTP. (Perhaps even BitTorrent and Gnutella? Maybe not, since Apple wouldn’t want to make life any easier for those not using the iTunes Music Store.) Pausing and resuming downloads would be a must, too. The interface would need to offer enough functionality to compete with most browsers, but be simple enough for the non-geek.

Out of the applications mentioned above, I personally like OmniWeb’s download manager best, because it has a toolbar that offers some useful commands with a single click, like “abandoning” (clearing and trashing) a download. Also, all its commands have text labels. It doesn’t present any puzzles and coordination exercises in the form of little grey circles and pop-up buttons. However, I do like how other apps have managed to be more horizontally compact by putting the progress bar on its own line below the file name.

Again, someone might lose out if Apple were to offer an OS-wide downloading framework. If it offered enough functionality, it could be developers of apps like Download Wizard, iGetter and Speed Download. But, speaking with my user-hat on, I’m afraid I wouldn’t care.

If Microsoft had designed Finder Labels...

... they would look exactly how they do now.

When colour labels made a return in Mac OS X 10.3 Panther after years of waiting, it was a bit of a letdown. For most, this was because they were functionally the same as what the Classic Finder used to offer. Personally, however, I don't really need more than 7 colours, and the colours are distinct enough, so I don't really feel the need to customise them either.

But this doesn't mean that I was happy when I saw the new implementation. It wasn't a matter of functionality, but one of visual design. Consider this:

Somehow this look immediately made me think of Windows XP, with its overpoweringly saturated, bevelled window frames and buttons. It just didn't look like Apple. But even leaving taste aside, it simply doesn't work very well. The colours are so strong and dark that it becomes harder to read the actual names of the folders. And why those gradients? They just add more clutter.

In his book Visual Explanations, Edward Tufte explains the principle of the smallest effective difference, which implies using the most subtle visual distinctions that still achieve the desired effect. The word effective is important here. There's no point using the smallest perceivable difference if it doesn't tell the story you want it to tell. In case of Finder labels, I see two possible desired effects:

1. To allow you to quickly spot all the files of a particular colour, whose meaning you have memorised, e.g., "All archived stuff is grey."
2. To bring certain files to your attention that you have previously marked with that intention, e.g., "I must review this document, so I'll make it red to remind myself later."

So applying the principle of the smallest effective difference for Finder labels would mean finding a set of colours that fulfil these two purposes when set against the white background of a window.

You can now easily read all the folder names and ignore the labels if you wish, but you can still choose to focus on all the files of a particular colour. Toning down the labels also makes the selection much more prominent. (Also notice I tried to improve how the labels of selected items are shown.) Although the colours look paler, they are still bright enough to have an attention-grabbing quality, especially in isolation:

It's a real shame how simple, proven design principles like this are ignored for the sake of eye candy (and not very good eye candy in this case). I think what we need is an option in the system preferences to switch from "Shop Demonstration Mode" to "Work Mode".

Interesting Typeface Facts

I've just discovered that many of the typefaces in Mac OS X include in their metadata very interesting narratives about their background and history. Just open Font Book and choose Show Font Info from the Preview menu. Arial, Futura, Times New Roman and Trebuchet MS are a few examples.

However, you would have hoped that Monotype know better than to put two spaces after their full stops.

Renaming frustration

I've been downloading a lot of research articles recently. In order to be able to identify them easily, I like to put the author and full article title in the file name. Many of these articles have titles that sound like "Bla bla bla: A new model for bla bla bla", i.e. something containing a colon. Of course, the Mac doesn't allow using colons inside file names. Although annoying, I think this is forgivable. What is not forgivable, however, is that if you mistakenly include a colon, everything you've typed is lost and the file name is reverted back to what it was before you started:

The same thing happens if you try to use a name that's already used by another file.

Notice also that the message doesn't tell you what is wrong with the name, so novice users have to rely on trial and error to find acceptable file names.

What's going on, Apple? This is basic stuff!

Have they never heard of scrollbars?

When Apple introduced the iTunes Music Store, one thing I hated about it straightaway were those views that have left and right buttons to page through a list of albums. At first I thought it was forgivable, given that the iTMS is more like a web site than a rich client interface. But after a short while I noticed that my eyes had become conditioned to move after clicking those arrows, trying to follow the animation. The problem is that they would never be in sync with the actual animation, especially since there's always a delay, which conjured up my old friend, motion sickness. I've now actually developed a habit of looking away right after clicking the arrows, and look back only after the animation is over.

When Tiger arrived, I was shocked to see the same awful paging view used in the Dashboard when you're adding widgets. The delay there is not nearly as bad as in the Music Store, but why on earth would you not use scrollbars for something like this?

It baffles me how Apple, out of all companies, keeps throwing decades worth of interface design wisdom out the window. They've done it with window title bar controls, with the Dock and with the Mail toolbar, to name just a few obvious examples. Jef Raskin once said that instead of interface architects, Apple has been infested with decorators. I think he had a point.

Smart Library drops

Ever since Mac OS X came out, I have been missing how the classic Finder used to try to recognise what kind of file you dropped on the system folder and would offer you to move it to the right place automatically, for example Extensions or Conrol Panels.

With new kinds of extensions being introduced in every version of Mac OS X (Preference Panes, Contextual Menu Items, Screen Savers, Widgets, Dictionaries, Image Units), it would be very convenient if we could just drop these on one of the Library folders and let the world’s most advanced operating system handle the details.