Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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

share|improve this question
    
Why are you singling out Apple in this question? Windows does the same thing (arrow not becoming something else when it's over a button or control). –  wootcat Sep 6 '13 at 18:07
    
I have no experience with Windows. I'm sorry if it sounded as if I was singling out. –  Phil Sep 6 '13 at 19:49
add comment

2 Answers

up vote 4 down vote accepted

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.

share|improve this answer
    
Your insistence that a text-input cursor is supposed to be called a "pointer" is incorrect. It's a cursor either way. Only when in text entry can it also be called a "Caret". But other than that, the name for it is a "Cursor". "Pointer" is more of a colloquial term. –  Arman Sep 6 '13 at 16:51
    
Hmm, I re-read my message and your edit and I think there is a misunderstanding. I am not calling pointers to text-input cursors. I meant to say that I believe mouse pointers should be called pointers and not cursors. –  Ricardo Sánchez-Sáez Sep 6 '13 at 16:57
    
Also, being rude was not my intention at all. Sorry if my tone reflected that. –  Ricardo Sánchez-Sáez Sep 6 '13 at 17:03
1  
Discussion about semantics of cursors and arrows, I find this an excellent, enlightening and a thoroughly prepared answer. Thank you very much for sparing your valuable time to compose this, @RicardoSánchez-Sáez. It has helped me, and it will help many others greatly. If you had a blog, I'd follow. ;-) –  Phil Sep 6 '13 at 19:54
    
@Phil You make me blush! Very glad to be helpful. ;-) –  Ricardo Sánchez-Sáez Sep 7 '13 at 10:26
add comment

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.

share|improve this answer
    
Thank you very much @Izhaki for the quotation and the clear reply. –  Phil Sep 6 '13 at 19:55
    
This is insightful. I missed this bit on my answer but I endorse this advice as well. ;-) –  Ricardo Sánchez-Sáez Sep 7 '13 at 10:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.