Why doesn't Mac OS X use Pointing Hand Cursor instead of Arrow Cursor on Toolbars and Tabs?

Question

I want to understand the rationale behind Apple's design decision of not using Pointing Hand Cursor on clickable areas such as Toolbars or Tabbars of applications' user interfaces, and even buttons.

• Why isn't the cursor choice on clickable areas a Pointing Hand Finger which suggests an area to click on?

• Should I opt for that or stick with Arrow cursor on my own applications user interfaces?

• If the applications' UIs are heavily customised (ie. skinned-themed), should cursor choice differ or stick with OS defaults?

Thank you

Answer 1

First, I think a better name for what you are asking about is mouse pointer, not mouse cursor. For me cursor evokes the mouse-unrelated text input positioner (as in the Terminal or text editor cursor that you move around with the cursor keys).

---

Why isn't the pointer choice on clickable areas a Pointing Hand Finger which suggests an area to click on?

Apple wants to reserve custom pointers (other than the text input pointer and the resize window or element pointers) to significate modes within your app, not clickable areas. I guess that the hand pointer is still ubiquitously used in web because at the beginning it was hard to tell hyperlinks from regular text.

From OS X Human Interface Guidelines (I suggest you read them on their entirety before starting to code apps for OS X):

Clearly indicate the current mode. If users can enter different modes in your app, make it easy for them to tell at a glance which mode they’re in. For example, a graphics app might use different pointer styles to indicate whether the user is currently in drawing, erasing, or selection mode. A segmented control can also show which mode the user is in; for example the View segmented control in the Finder toolbar indicates whether users are in icon, list, column, or Cover Flow view. And a popover offers a very strong visual indication of a self-contained task. (To learn more about using a popover in your app, see “Popovers.”)

My best guess is that Apple believes (correctly in my opinion) that the user does not perceive things like toolbars or tab bars. The user perceives tasks he wants to accomplish within your app. The app provides means to accomplish these tasks. Apple doesn't want your user to think that he is using buttons. Apple wants them to use the buttons instinctively.

Now you could say: "But this change in pointer helps the user knowing where he can click on and where he cannot". To that I respond: launch iTunes 11, Xcode 4, Final Cut Pro X, or even Finder. Look at all of these apps and try to decide where the pointer should show a hand and where it should show an arrow. My guess is that you won't reach a satisfactory answer.

There is a myriad of conceptually different clickable elements:

1. regular toolbars with buttons
2. sidebars in which you change the main view by changing the sidebar selection
3. informative displays (labels mostly, but sometimes they become compounded controls) which the app updates when it is performing an operation. They become clickable only when there is an operation going on; clicking gives you more information about this operation.
4. navigation-bar/drop-down-menu hybrids (e.g., Xcode scheme selection and file selection nav bars)
5. tabs
6. ...and more.

After looking at all this some possible "solutions" could be:

Show a hand for all clickable elements! 

Then you show a hand most of the time, why show an arrow at all? In addition, a little arrow is better for pointing than a little hand. See below for more comment on this.

Show a hand only for toolbars (or only for type Y of clickable elements)!

In Apple's mind there are no toolbars, there is your application that does things in different modes. Maybe toolbars make sense for one kind of application but not for others. The fact that toolbars are not mandatory at all precludes for a feature like this to be an OS-wide UX guideline.

Add a new different custom cursor for each different type of clickable area!

This is more confusing than helpful and breaks the "custom cursors significate distinct app modes" model.

Should I opt for that or stick with Arrow cursor on my own applications user interfaces?

I would not opt for what you suggest. Users accustomed to the OS X way will wince at your app if you do this.

If the applications' UIs are heavily customised (ie. skinned-themed), should cursor choice differ or stick with OS defaults?

I would not for the same reason as above.

---

But I still want to show the clickable areas of my app with a different cursor.

If you want to go for this, what I would do is keep the arrow pointer for everything. Just dim it slightly (maybe 10% opacity loss or a similar effect) on non-clickable areas. I have never implemented nor used an app that does this. I would need to use this to see how it feels before fully endorsing this solution. If implemented properly I can see it being a subtle and elegant way of hinting at clickable elements.

Answer 2

Apple design guidelines state:

Discoverability. Encourage your users to discover functionality by providing cues about how to use user interface elements. If an element is clickable, for example, it must appear that way, or a user may never try clicking it.

The idea is that clickable elements should be recognised as such without hover. This is even more important with the growing popularity of touch devices.

See this question for more.

And you should try to adhere to the platform guidelines, unless it makes no sense in your particular case.

Answer 3

If I look at my screen, pretty much everything is clickable. Pushbuttons, scroll bars, sliders, icons, menu titles, window edges, browser tabs, list items, column headers. Text can be dragged in to select and copy parts, in some cases even to edit it. Window titles and bottom bars can be dragged to move the windows.

So my explanation would be that the information density on the typical computer UI is so high that you'd have the hand cursor everywhere, which is effectively just like it is now, just that an arrow is used instead of a hand. It would make more sense to show a special "un-clickable" cursor over areas that can't be clicked.

But I wouldn't even do that, as the UI itself (according to Apple's Human Interface Guidelines, even) should be designed so it is obvious which parts are clickable and which aren't. That makes sense, as otherwise the user would have to wave the mouse over the screen like a metal detector to find clickable hotspots, like the dreaded "mystery meat mouse-over navigation" on some web sites.

That only web links use the hand cursor approach makes sense because there is ambiguity. Underlined text could be just underlined text, so this way you can verify that something is clickable in this degenerate case.