After reacquainting myself with Mac OS X 10.6 Snow Leopard over the past two weeks and collecting a series of notes and observations about its user interface, I assembled everything in the article I published a few days ago. It was well-received and I want to thank everyone offering praise and feedback.
I’m glad it was clear from the start that it wasn’t my intention to write an exhaustive overview of Snow Leopard and the user interface degradation I’ve witnessed in subsequent Mac OS releases. I wanted to provide enough examples of user interface details to prove my point. And while I haven’t received many particular requests in the form of, You didn’t talk about [feature], you should add that example, when I returned to Snow Leopard on my 2009 MacBook Pro, I realised there were still a couple of things I had left out that were worth mentioning. Rather than adding them to that already long overview, I’ve decided to publish this addendum.
User interface
Menu transparency
In my previous piece, I talked about how Snow Leopard treated menu bar transparency (or rather translucency), and how I consider it a better, more user-friendly implementation than the one we now see in Mac OS Big Sur.
What I forgot to mention, however, is the way menu transparency is handled in both Mac OS versions. In both systems, when we pull down a menu from the menu bar, the menu background isn’t matte, but has a degree of transparency that lets you vaguely see what’s behind the menus (a portion of the desktop wallpaper, another window, etc.). On paper, you’d think that this effect may appear similar in Snow Leopard and Big Sur, but when you look at the implementation, things couldn’t be more different.
Here’s Snow Leopard:
The effect doesn’t really change from an image to another, but I wanted to show it both with a black & white and a colour desktop wallpaper as background.
Here’s Big Sur:
While the effect in Big Sur isn’t completely terrible, judging by the feedback I’ve received since I started publishing my Big Sur logbook, many people find the contrast between the menu text and the menu background to be rather poor, especially for inactive menu commands, so they usually enable either Increase contrast or Reduce transparency in System Preferences → Accessibility → Display as a workaround.
Snow Leopard doesn’t have a Reduce transparency option in the Seeing tab of System Preferences → Universal Access. There’s just an Enhance contrast slider you can move to increase the contrast of the whole interface and reduce the menu transparency in the process. But as you can see above, menus in Snow Leopard are already more contrasty than in Big Sur, even with their default transparency. If I had to use more descriptive terms to differentiate these two types of menu transparency, I’d say that in Snow Leopard the effect resembles flat, thin paper, while in Big Sur is more like frosted glass.
Personally, I find the effect in Big Sur unnecessarily tridimensional and I’m slightly bothered by the fact that the menu is not attached to the menu bar (there’s a 2‑pixel gap). But I’m really nitpicking here.
Exposé and Spaces
Snow Leopard is the last Mac OS version to feature the old approach to window management and virtual workspaces before it was rethought and its name changed in Mission Control. Exposé was originally introduced in 2003 with Mac OS X 10.3 Panther, while Spaces was introduced in 2007 with Mac OS X 10.5 Leopard. I think Snow Leopard was perhaps the best version to integrate these functionalities.
From a UI standpoint, judging which is the better approach between Exposé & Spaces versus Mission Control is difficult. It’s mostly a matter of spatial arrangement, and things become quickly subjective here.
Let’s start by examining things in Snow Leopard; here’s the Exposé & Spaces preference pane:
And here’s the Mission Control preference pane in Big Sur:
There is a general overlapping of features. The main difference between the two models, conceptually, is that in Mission Control there is one shortcut to both show All [open] Windows and all the virtual workspaces (desktops); while in Exposé & Spaces, as the name itself suggests, the two things are accessed separately — one shortcut to show all Spaces (F8), one to show all open windows (F9). [In this section I’m going to refer to the default Fn-key shortcuts for practical reasons.]
Here’s what happens when you invoke Spaces in Snow Leopard:
And here’s what happens when you invoke Mission Control in Big Sur:
Details worth mentioning:
- As you know, that is not exactly what happens when you enter Mission Control: at first you only see all the open windows of the applications in the desktop you’re currently in. To also show an overview of all the other desktops and all applications running in fullscreen mode — as in the above image — you’ll have to move the mouse towards the top of the screen.
- Once you’re in this view in Mission Control, there’s not much you can do: you can access a specific window in the current desktop, switch to another desktop, move an app window to another desktop, or add/delete other desktops.
- Note also that if an application has multiple windows, these will appear as a group. So, in a way, your bird’s eye view on the whole situation is a bit limited: you can’t see at a glance the contents of all windows because they’re grouped per app, and you also can’t see much of what’s happening in other desktops, because the thumbnails aren’t big enough.
Over on Snow Leopard, things are more fine-grained. Since Exposé and Spaces have separate controls, you can:
- See all open windows in the current space.
- Have a clearer view of apps and windows opened in other spaces (see above).
- See all open windows in all spaces at a glance if you first invoke Spaces (F8) and then Exposé (F9). See the image below:
With the Spaces + Exposé view combined, you have the possibility of jumping directly to a specific window in any of the spaces. To achieve the same result in Mission Control you have to:
- Invoke Mission Control (F9)
- Move the mouse to show all desktops
- Click on the desktop where the target window is located (or you think is located, since you can’t really see all open windows)
- Once you’re in the other desktop, if you don’t see the window immediately, you have to invoke Mission Control again.
It’s clunkier, isn’t it? In Snow Leopard you hit two keys and you click once on the window you’re after, because you clearly see everything ‘from above’ in greater detail.
[Update — Eric on Twitter writes: “Quick tip about Mission Control — hold down Option when clicking on a space, you don’t zoom in to the space but still switch to it, so you can still pick a window without having to go back to MC (or pick a different space).” I admit I had forgotten about this shortcut. It certainly makes things easier in Mission Control, but the execution is still clunkier than Spaces on Snow Leopard.]
Oh, and another thing. In Snow Leopard’s Spaces preference pane, if you enable the option to Show Spaces in menu bar, you’ll always know which space you’re in thanks to this icon:
And by clicking on it, its menu will allow you to select any other space (though using Ctrl‑1, Ctrl‑2, Ctrl‑3, etc. is faster).
Personally, I have no problems navigating Mission Control: after years of muscle memory, and the fact that on my iMac 4K running Mac OS High Sierra Mission Control still shows all app windows without grouping them per app, I can move between app windows and workspaces rather quickly. Yet I have to point out that the Exposé & Spaces implementation in Snow Leopard is better designed and more versatile.
Labels vs Tags
Tags in the Finder were introduced with Mac OS X 10.9 Mavericks and replaced the previous Labels functionality. Or rather, they expanded the Labels functionality. Before Mavericks, Labels in Mac OS X used to work in a simple way, virtually unchanged since the classic Mac OS: you were given seven colour-coded labels (Red, Orange, Yellow, Green, Blue, Purple, Grey), and you could use them as-is, i.e., by leaving Red, Orange, Yellow, etc. as label names; or change their names and call, for example, the Red label “Important”, the Blue label “Work”, and so on. This designation was simply to give each colour a name that was meaningful to you.
But you could only assign one label to an item, because the label’s colour was the predominant part, not the name. You could have a folder full of important documents, and if you used Red to indicate something “Important”, you could assign the Red label to that folder. But if you wanted to use labels to indicate that the contents of such folder were “Important” (Red) and from “Work” (Blue), you couldn’t assign both labels to it.
It’s safe to deduce that the reasoning that went into the execution of the Tags functionality in Mavericks was to overcome this hurdle and make things easier. With tags, you’re still limited to the same seven colours, but since these are tags and not just labels, the tag name is predominant, not the colour. In fact, with this approach, you can create all the tags you want and then assign a colour to them, if you want. But they can be colourless, or you can have different tags with the same colour. This, among other things, allows you to have an item with multiple colour-coded tags. Using the same example as above, you can indeed have a folder with the “Important” (Red) and “Work” (Blue) tags, along with many other tags of your choosing.
This implementation also allows for more fine-grained Spotlight searches. While with labels you could search all items marked with a specific label colour, with tags you can search for any tag by name.
In practical terms, if the Labels approach was perhaps too simple, the Tags approach is certainly more complicated. From a merely visual standpoint, labels are more effective. Yes, you can only assign one colour to an item, but when you do, the whole item’s name is highlighted, and it definitely stands out:
With Tags, since an item can have more than one colour-coded tag, its name won’t be highlighted — a coloured dot will appear by its side:
And it doesn’t stand out in the same way. You can find a few more examples in my brief piece Labels vs Tags, written in October 2013.
In a nutshell: Tags are more versatile than Labels; Labels are more effective than Tags in how they behave visually.
Pedantic interpolation on Tags’ behaviour in a multilingual setup
There’s an irritating side-effect of how tags and colours work, as opposed to the old Labels model, but you’ll only see it if you, like me, need to occasionally switch from one system language to another. Since with Tags, names are more important than colours, when you change system language the seven default coloured tags (Red, Orange, Yellow, Green, Blue, Purple, Grey) will be localised in the other language. But when you revert to your preferred language, you’ll see that those localised tags have remained along with the original seven. That’s because the system thinks that they’re two distinct sets of tags, not the same set with names changing according to the language.
So, if you switch from English to Italian as system language, the green tag with the name “Green” will become a green tag with the name “Verde” (Italian for ‘green’); but when you revert back to English you’ll find yourself with two green tags, one named “Green”, the other “Verde”. Same for all the other six colours:
This creates unnecessary confusion, and not just because you now have seven additional tags you didn’t want. Suppose you typically use tags as you once used labels, and you don’t assign a specific name to a tag but you just leave its colour’s name as-is (e.g. “Green” for the green tag). If you have English as the default system language, and assign the green “Green” tag to a bunch of folders, when you switch to Italian, all those folders will still have a green tag with the “Green” name, but if you find another item you want to tag as “Green”, after selecting the green dot from the Finder’s File menu as a quick way to assign the green tag, you’ll find yourself with an item that has a green dot but the name “Verde”, because now the system language is Italian and the default green tag is called “Verde”. So you’ll end up with items which indeed have the same tag colour, but different tag names.
Yes, it is as confusing as it sounds.
Conversely in Snow Leopard, with the simpler Labels model, if you don’t alter the default label names (Red, Orange, Yellow, Green, Blue, Purple, Grey) and use them as-is, when you switch to another language their names will be translated into that language, but when you revert to English, they’ll revert to English as well:
Left: System language is Italian. Right: System language is English. The “Screenshots” folder retains its green label and the colour name is automatically localised.
My apologies for this pedantic excursion. I’m aware that the confusion generated by using Tags in a multi-language setup is something that may be annoying for only a subset of users, but it is nonetheless yet another example of something that is implemented without taking into account other scenarios that may differ from the default. And of course this has nothing to do with Big Sur, as the change from Labels to Tags happened way before.
Applications
iTunes
Some people wrote me asking why there was no mention of iTunes in my previous article. On the one hand, speaking about the user interface of iTunes is probably enough material to write a small book, especially considering how, over its long history, it has often eschewed system-wide UI conventions in a few places of its interface. On the other hand, the last iTunes version supported by Snow Leopard is 11.4, and by that version its user interface was already deteriorating. So while I still think that iTunes, in general, is a better application than the current Music + Podcasts + TV apps, I didn’t feel that version 11.4 under Snow Leopard was a particularly good example of iTunes user interface.
iTunes 11.4 under Snow Leopard. Nothing to write home about, UI-wise. In a previous version of this article, I wrote that the Column Browser (shown here) was a feature “sorely missing from the current Music app”, but Mike kindly corrected me over Twitter — the feature is actually present and accounted for in the Music app. Terrible oversight on my part.
While many long-time Mac users tend to prefer iTunes when it was just a music player, I consider both iTunes 9.2.1 and 10.6.3 to be two solid versions of the more jack-of-all-trades iTunes that came later.
iTunes 10.6.3 on my iMac G4 running Mac OS X 10.5.8 Leopard. Buttons that look like buttons; quick access to view options right in the upper area; clean, thoughtful organisation of controls, especially in the status bar at the bottom.
Other odds and ends
Reader Simon H. contacted me via email and, among other things, he writes:
I know it’s not a UI question, but I seem to remember that Snow Leopard had great network stability. What’s been your experience in this regard? Can you confirm?
Quite satisfactory. In more recent versions of Mac OS, all my Macs will sometimes (not frequently, mind you) disconnect from the wireless network or fail to reconnect automatically after exiting sleep. The old 2009 MacBook Pro has been running Mac OS X 10.6.8 for the past two weeks and its connection to the home wireless network has been very stable and reliable.
Another place where I’ve noticed more reliability compared to more recent Mac OS versions is when connected to other Macs for file sharing. Sending or retrieving sizeable files from my two Macs running High Sierra can sometimes fail with what can only be described as a network timeout: the copy process hangs for no apparent reason and never resumes, and I have to abort by relaunching the Finder. With the MacBook Pro running Snow Leopard this has never happened so far, and I’ve shared several large files in the past two weeks between it and my iMac running High Sierra.
In my previous article, I mentioned two very usable browsers you can try to surf the Web under Snow Leopard, as Safari 5.1.10 is too old and unsupported. Jeremy reminded me of TenFourFox, which is more up-to-date. Since TenFourFox is a PowerPC-based browser, at first I thought Jeremy was suggesting running it under Snow Leopard via Rosetta, but it doesn’t work anyway. When I reread his tweet, I realised he said TenFourFox for Snow Leopard. I hadn’t realised there was a separate project for Intel Macs. Anyway, after some Web searching, I found TenFourFox Intel (a.k.a. “TenSixFox”), and also another project, called Arctic-Fox, which seems fairly recent as well. I haven’t had the time to properly test either, unfortunately.
Another thing I wrote in my previous article was about the little-to-no iCloud functionality under Snow Leopard:
Predictably, iCloud (still called MobileMe in Snow Leopard) doesn’t work either. Login fails in the System Preference MobileMe pane and when setting up an iCloud account in Mail. The only way to access iCloud is therefore via the Web.
In the same tweet, Jeremy mentioned that he has been able to set up iCloud email accounts by using the direct incoming/outcoming mail server addresses and configuration. So I went back to Mail and tried again, but even creating a new account and manually entering all the settings found at this Apple Support page, I still was unable to set up an iCloud account. Mail kept telling me that “the icloud.com IMAP server rejected the password” for my account.
And with this, I think it’s all for now. I still welcome feedback via Twitter or email, and may write further updates on this subject in the future.