Is it wrong to use the hand cursor for clickable items such as buttons? [closed]

Question

I've always thought the hand cursor to be the ideal visual indicator for "you may click here" to the user. We are used to see it in this context daily because of it's usage on hyperlinks and hence all web buttons.

                 

However, most desktop applications seem to keep the defeault pointer arrow for buttons.

                                 

I really feel better when buttons, and other clickable items such as checkboxes and radio buttons use the hand cursor. Somehow, I find it personally pleasing to see this cursor when I hover over clickable items, maybe because it's consistent with how webpages and even many games do it.

But as developers, We have to think of the children user and sometimes do things not as we like them but as the user likes them. Problem is, I feel so fuzzy about the hand cursor on buttons that I'm blind to the possibility of it being inappropriate. Many design mistakes are caused by such personal decisions.

                                      

What do you think about it?

Edit: Recently I've taken notice of usage of the hand cursor on Photoshop (CS3 on XP), but probably only because I was using it more extensively. Screenshot:

                                         

Do note that many of the places where the hand was used are obviously clickable.
EDIT2: Do also note that they've even used a custom cursor, which to be honest I'd never do, especially for something trivial as a hand cursor that's so ubiquitous. And it's not even pretty.

Flavorous

I change mine. I don't see a problem with it. – Castra

Glad to see I'm not the only round peg. – Flavorous

You cross post this on UI.stackexchange for possibly better responses – Sliwa

Answer 1

The reason why the cursor changes shape when over a hyperlink probably has to do with the following:

• hyperlinks started in blocks of text and as such it wasn't obvious that you could click on them to open another page.
• the change in display style for links in and of itself probably wasn't enough to communicate the "clickability" of a link. Possibly also because the changes in display style aren't exactly standardised, while the handshape cursor is.
• buttons on web pages used to be "normally" clickable I think though I can't remember whether they caused the cursor to change shape. Nowadays "buttons" are often "faked" using css and you need some other way to tell the user they can click on it => handshape cursor has become the default for that.

All of the above however is geared towards communicating "clickablity" within the content of a webpage. Buttons, buttons on toolbars, menu items etc have always been clickable without changing the shape of the cursor. And you don't see browsers changing the shape of the cursor either when you are hovering over a menu item or toolbar button.

In a desktop application you probably wouldn't change the cursor over every item in a tree even if that brings up different information in a panel to the side of the tree? Or for every item you can select in a listbox? Or for the radiobuttons or checkboxes on a form? So why do it for form buttons which in a desktop application have always been easy to identify and are clickable by nature.

I wouldn't change the cursor shape for anything in a desktop application that is (has always been understood to be) "clickable by nature". I would only use "web-like" cursor shapes when displaying information in a "web-like" manner. For example clickable parts of text in a grid in which the text is not normally clickable. Otherwise I'd stick with the standard cursor shapes. It also helps to keep down the "noise" in the user interface.

---

update in response to comment(s)

@Camilo: I get your "command" vs "selection" distinction. I would even add "navigation" to that mix. However, I still don't see the need to change cursor shapes on a command ui-element.

The distinction between navigation and command may get somewhat blurred if you think of them both simply as responses to user actions. To me there is a clear distinction between the two. Navigation are all actions to open forms, select items, etc. In general just rummage around... Commands are all actions that cause data to change, cause notifications (mail, messages of any kind) to be sent, or where the initiated action may take a longer than a second or two (establishing a connection, filtering a large dataset).

Loosely: if you would submit a form on the web using a "POST" (or "DELETE"), it would probably be a command, whereas anything else would be navigation.

Anyway, one thing I would never do is have a ui-element that is naturally more geared towards navigation and selection (like a treeview) execute a command. So where clicking on a treeview item will probably change the contents of some other part of the user interface, in my apps it would never for example initiate a payment...

As such, a tree of possible servers to connect to, to me is still a selection element. I would hope the actual connection is not made on a single click, but only when an item is double-clicked or after an item has been selected when a "connect" button is clicked. And therefore, in this particular case, I still wouldn't use a handshaped cursor on the tree.

Spiculate

+1 for mentioning that historically the hand cursor was necessary, but nowdays, most casual users (hence the most in need of visual cues) spend quite some of their computer time on websites. And Possibly also because the changes in display style aren't exactly standardised, while the handshape cursor is. - it is not, it's just another style you can change like color or text-decoration. See here: w3schools.com/css/pr_class_cursor.asp (but webmasters did exploit the color and text-decoration more on <a> tags). – Flavorous

And I would change the cursor in a treeview if it conveys a command (such as a tree of possible servers to connect to) 9, but I wouldn't if it conveys a selection (such as a list of folders). So in my mind the arrow is associated with selection, and the hand with command. But maybe I'm just different than other users. The concern on "noise" is surely valid, but I have strong feelings about the hand cursor on buttons, and I also would like to borrow some of the "light" feeling of web pages. – Flavorous

What if clicking on one of the nodes of such a tree performed the connection to the selected server? I'd notice something would happen if I click it, initially because the cursor changed, and after that because I'd see a tooltip in the lines of Click to connect to http:/server.com/, but if the cursor didn't change I'd think nothing would happen (besides selection) on the first try. Note that it would still be a trivial connection, such as Imgur versus Tweetpic, not Visa versus Paypal. And in my defense all web buttons, even the most obvious ones (like Google's), use the hand cursor. – Flavorous

@Camilo: I suppose people would pick up on that, but it just goes against what I think people have come to expect from ui elements like treeviews. And yeah I know most web buttons use the hand cursor. Just my opinion that it is superfluous... :) – Spiculate

I value your opinion, and I'm considering it - but if I use a hand cursor, I should use it consistently, so it's kind of a big UX decision. I guess it does have a lot to do with mimicry of the web's feel. – Flavorous

@Camilo: I agree, consistency is very important, more important than the single choice of what cursor shape to use. If you do go for a different cursor shape, I'd recommend creating your own version of the button (and other) controls, so you don't end up having to remember to change the cursor shape for every button (...) in your app. – Spiculate

Yes, I'm already creating my own versions of every control I use. For instance, if you resize a normal .NET treeview, it flickers a lot, and the solution to doublebuffering it is complex, as is the listview (this helped me a lot: dev.nomad-net.info/articles/double-buffered-tree-and-list-views ) Also, I've inherited the form class to add certain functionality and I couldn't be happier with the result - I highly recommend inheriting every .NET class that doesn't satisfy you completely. – Flavorous

Answer chosen becuase the question's been open long enough and it's the most upvoted. – Flavorous

Answer 2

Personally, I have found in my research that this is generally perceived as one of those "we have always done it this way, so it is the expected and best way of doing it" situations.

The hand cursor made one of its earliest appearances in Hypercard stacks. Which were targeted at less-experienced users. So, like a lot of things, it got picked up and carried along with us.

However, because of its inconsistent use, I don't think there really is a "best" choice between the arrow and hand... people are used to either and/or both, so any consistent, thoughtful use of both seems to be generally effective.

For me, though I go by the following guideline:

Arrows are for items that are obviously clickable, like things that look like buttons, radio-buttons, drop-down menus and such. The hand is useful when you need to give something that may or may not appear button-like a little extra attention. It really does re-enforce the call to action of "click-me!", "click-me!".

Also, on the internet, I have noticed that the hand tends to indicate items that when clicked, will expose MORE relevant content regarding what you just clicked on, while the arrow seems to be more "command" driven, i.e. "do this now".

But, like I said, as long as it is consistent, users will adjust quickly to you site's use of either cursor because they have been exposed to both for so long already. The only real trouble seems to occur when you are inconsistent in your handling of the two cursor types.

IMHO - There is nothing that is inherently "intuitive". Intuitive is just another way of saying "more familiar" or "less familiar".

Outclass

Well, to be honest I'd go for your guidelines if I could differentiate between "obviously clickable" and "some hints are needed", because I tend to think of most buttons on the web as clickable before moving the cursor to them. But I also have a gut feeling that novice users feel reassured by seeing the hand cursor before they click, and I think it's more friendly too. I've updated the question with a image of Photoshop's usage of the hand cursor that I didn't realize until few days ago. Basically, I think it's easier to percieve consistency on "command" vs "selection" than on "clickability". – Flavorous

Buttons can be tricky things. Buttons do not always look like buttons and not all button-like things are buttons... so. that is where the experience comes in. You just have to determine what your own interpretations are for "obviously clickable" and "some hints are needed". That is the point. If it was easy, we would all have it down to a science by now. What we accept as "button-like" today could be much different tomorrow. That is why I mention my philosophy on "intuitive". Things are fluid and never stay the same. So what is more familiay today can become obsolete tomorrow. – Outclass

Just look at the English language. There are tons of phrases, words, and slang that were once completely common-place and now, if you spoke that way, people would have a hard time understanding you. UI/UX design is the same thing... only with computers, interaction and design. – Outclass

Answer 3

I think also we need to remember that hand generally indicates it's a link to somewhere else.

I don't think there is clear answer, but to me if the platform I'm coding for (Windows) I'll just follow the examples of the underlying OS to keep it consistent which means no Hand icons for buttons in Windows.

As a user I think it feels awkward to see hand icon in a Windows GUI (unless I'm clicking to a link which will take me to a website)

Terpineol

What about, for example, a graph. So if the pointer changes to a hand in the nodes of the graph, it would be an obvious indicator of clickability. – Flavorous

Sounds reasonable but personally prefer a change in the hovered view (just like button controls) point (presumably you clicking a point in the graph) – Terpineol

Answer 4

The "pointer" cursor should be used for hyper-links or any object that functions like a hyper-link. otherwise the "default" cursor should be used for all other clickable elements such as buttons, toggles, switches, drop-down menus, etc. as by nature "should" look like a clickable item.

Look up the definition of hyperlink for more information.

Example: Google Drive

Bedesman

Answer 5

AFAIK hand was dropped for fat client apps, and instead you have buttons and other user elements who emit tool-tips or have 'hover' effect.

Stay with hand cursor ONLY if you want to mimic web-app look&feel.

Secularity

I want to mimic web application look and feel! Most applications look chunky and heavy, I want to breathe some air into the desktop with a more subtle look&feel such as what Google did with Chrome, and the hand is something that I believe an important touch to accomplish this. – Flavorous

@Camilo: but Google Chrome doesn't use hand cursors on its toolbar buttons or on any other buttons of its forms/dialogues... – Spiculate

@MarjanVenema ~ Those elements take away from the web tho, in just a different format. They use a rollover effect to highlight the hover. – Castra

Well, when I hover over Chrome's buttons, I don't feel the need to have the hand cursor as much, but maybe because most of them represent selections and navigation rather than commands proper (as I consider the bookmark button to be). – Flavorous

Answer 6

interesting point .. let me try to make it simple.

Arrows - are suggestible for Desktop App + interfaces which are very intuitive

Hand - must there for HYPER TEXT, for average user its important to know which text is click-able.

Mulligatawny

The hand cursor is currently not only used for text, it is used on any clickable item on webpages, even if those webpages can change the cursor to arrow for buttons. In the web, the user expects every clickable item to be clickable. Why to make it different on the desktop? Especially if I custom-draw buttons or other controls. – Flavorous

Answer 7

I came here thinking this question would have a clear-cut answer, but looking at these answers as well as going to major sites shows very blurry distinctions. As the line between web and desktop client blurs, I'm observing a similar blurring of the behaviors.

Earlier... desktop clients nearly always used a single cursor, and hover caused button to change visible state indicating area of clickability. Web pages had the cursor change on links, and no consistent behavior when an action was handled by javascript.

Going to some of the most heavily-used websites and apps around, I find... As a user, I don't care as much as I thought. Deskstop clients mostly just change the button, and if the cursor changes, I don't notice. Web clients tend to change the cursor AND often apply a visual button hover state, and rarely do I notice when they don't.

Until someone makes a compelling argument otherwise, I'm going with the simplest rule for our design: always changing cursor on actions, and applying button hovers for regularly used buttons.

Younker

Well, I for one think that every button should have a hover state, regularly-used or not. Otherwise you get the "Windows 8" effect - the interface will look like it wasn't thought for a mouse (in the case of Windows 8, it looks like it wasn't...). – Flavorous