Cursor shape while hovering buttons

[Sik]

One of those weird interface nitpicks I was wondering.

On nearly every GUI, when the cursor hovers a button, nothing happens (the cursor retains its arrow shape). However, doing the same over a link will change its shape to a pointing hand, to indicate the link is actionable. Now, I get that links are somewhat less obvious (though they still look blatantly different from text), but why don't we also do the same for buttons? Or any other actionable widget, for that matter?

When I've messed with my own GUIs now I make sure that the cursor changes its shape when on an actionable widget and sure enough it actually feels better. Is there any reason to not do this or is this just inertia from the old times?


EDIT: wait, should this go here or in General Ramblings? Though user interface is an important part of an OS :​P

[iansjack]

I would say that buttons were a generic part of the nterface, and are always pressable to initiate actions. Links, on the other hand, relate to specific programs. All buttons initiate actions, so there is no need for additional hints; not all text is clickable to initiate an action.

Modern user interfaces have evolved over many years so I would think very carefully before changing paradigms that everyone is very familiar with.

[rwosdev]

Well IMO in addition to the post above, it also isn't done because you get the feeling that you're using a webpage/web app, which have never been bastions of quality on the desktop. Each to his own though

[Sik]

To me it's the use of a flat interface that makes me expect a horribly bloated program nowadays. Oh the irony since it's supposed to be one of the easiest things to render :​P Never had any feeling even remotely like that when I made the cursor change to a hand when hovering a button though.

Just wondering if there was any reason to not try it other than "because it used to be like this".

[StudlyCaps]

I think it mostly comes down to the different context of hypertext links and buttons. Buttons tell the application or OS to do something, and were pretty standardized before web browsers where really a thing. Hyperlinks are embedded in text, specified by the remote server providing the page, not by the OS and perform an action which potential involves many more remote machines. It would have been important that people understood the difference, therefore they needed something unique.

Additionally at the time people would still have be using monitors with monochrome or limited color displays, so applications couldn't assume that color alone would be sufficient to indicate the clicking on a link would take an action, the hand is a secondary indicator. Also I suspect that making buttons part of hypertext would not have been ideal, for one the content of a page should be the same on Mac or Unix or Windows, having a "button" means the application decides what it looks like, not the page's author.

Finally it is a bit of user protection. The hand appears on all links in a browser, even when the designer of the page attempts to hide them. So the hand means the user is always given some indication that if they click, something is going to happen.

[Schol-R-LEA]

An alternative - which I believe was used on the Apple Lisa, or maybe it was the old versions of X Window System Motif with the massive borders, I forget - is to change the button subtly, instead, usually by a border highlight. The problem with that is that it tends to make the interface seem 'busy' when you are just scrolling across a button, if it activates any time the pointer is over the button.

IIRC, older interfaces didn't check for hovering (that is, being over something for an extended period of say, half a second or more) vs just crossing over something. It might have been a lack of cycles to make the determination, or the event detection systems weren't fine-grained enough, or the mouse interfaces had insufficient pointing device resolution (or there was too much network lag to handle the pointer suitably, which was why Motif had those big ugly borders), or even just that the idea of 'hover' simply hadn't occurred to anyone yet, I am not sure.

[iansjack]

Just wondering if there was any reason to not try it other than "because it used to be like this".

It's not "because it used to be like that", it's "because it serves no purpose". People don't need the hint that buttons are there to be pressed - that is their reason for existence, their only function in life. Don't take that away from the poor things.

Fripperies in a GUI just for the sake of it, without a clear purpose, are not a good idea.

[iansjack]

Hyperlinks are embedded in text, specified by the remote server providing the page, not by the OS and perform an action which potential involves many more remote machines.

It would be different if hyperlinks were surrounded by a border, or something else that made them really stand out as different from ordinary text. In fact, if memory serves me right, at one time they were so decorated. I can't remember whether then the cursor changed shape or whether this was introduced as a subtler way of identifying hyperlinks.

Anyone who needs some hint that a button is different from ordinary text has big problems.

[DavidCooper]

Some kind of change for buttons could be useful in some situations, such as when a photo of a button isn't a button (and the lack of any change would tell you it's just a photo), so I see no harm in making some subtle change to the cursor (or to the button).

[iansjack]

That's not really a button, but a clickable image. Essentially the same idiom as a clickable text link. In that case some indication of the additional function of the image is useful.

[Schol-R-LEA]

That's not really a button, but a clickable image. Essentially the same idiom as a clickable text link. In that case some indication of the additional function of the image is useful.

I think you have what DavidCooper said backwards: David was talking about a case where there is non-clickable image of what would otherwise be a clickable button in, say, a screenshot. This article discusses just such a situation.

Having been in a similar position myself (where a person kept trying to click on a 'button' that was part of a screenshot in some online program documentation), I am not at all convinced that someone who hasn't noticed that they are clicking on a picture of a button rather than an actual active button, would notice whether actual buttons have different pointers or change appearance if hovered over.

I've seen too many people complain after repeatedly clicking on actual, but grayed out, buttons to expect them to notice if the button gets highlighted or the mouse cursor changes when they are on an active button. Hell, I've personally gotten P/Oed when I've tried to repeatedly click a grayed out button before noticing it wasn't active, at times when I was stressed out or distracted, so thinking an ordinary user will when they are using an unfamiliar system (which many people would find stressful or distracting on its own) is probably unrealistic.

[iansjack]

My bad. I think you may be right.

But we can't really design user interfaces to cater for the possibility of a screenshot of a user interface, can we? Think of the potential confusion if there's an image of a mouse pointer in the screenshot!

[Schol-R-LEA]

My bad. I think you may be right.

But we can't really design user interfaces to cater for the possibility of a screenshot of a user interface, can we?

I quite agree. While the 'change on hover' thing might be seen as a solution for it, I would hardly think that this use case requires it, and, as I said, it is unlikely that the hint would be noticed anyway (as it would only be notable by its absence in the case of the non-clickable image).

Think of the potential confusion if there's an image of a mouse pointer in the screenshot!

I've had that happen. It is infuriating.

A similar, and unpleasantly common, problem in games which don't need a visible cursor happens if the developer forgets to hide it. Jim Sterling (I know, I know, but this time it's relevant), among others, keeps coming across bad indie games with that problem, and always pokes fun at the devs for it (as in this video - while you can surely guess that this is NSFW, given who it is from, this particular one is notably so because of the game in question).

[Sik]

Fun that disabled buttons are brought up because the other day I stumbled upon this:
https://axesslab.com/disabled-buttons-suck/

In short, according to the article being able to have disabled widgets at all is considered a bad idea, period. Not only because of the issue of the user not noticing that it's disabled initially (which probably depends on the widget's looks), but because when they do they still may not know why it's disabled and get extremely confused.

#1 problem with that though is that disabled widgets are disabled for a good reason, and that reason isn't going to go away by just forbidding disabled widgets, so a different fallback is going to be needed anyway.