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

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 1 year ago.

开发者_如何学运维 Improve this 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.

---

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.

---

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".

---

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.

---

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.

---

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)

---

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.

---

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