I have an application where parts of the screen contain elements that are "dead", i.e. the user cannot, in any way, interact with them.
What would be an appropriate mouse cursor for such frozen elements?
2
-
7What is the reason you feel the need to make this clear to the user beyond the normal lack of response? Is there any indication that users are confused, or does accidentally clicking cause problems?– IncaCommented Oct 13, 2011 at 15:54
-
Accidentally clicking does not cause problems. It's just that I'm imagining frustrated users trying to click on various parts of the windows.– RandomblueCommented Oct 14, 2011 at 17:12
Add a comment
|
6 Answers
The common solution to this issue is to leave the default mouse cursor and instead "gray out" or somehow make a visual change to the part of the screen that cannot be interacted with, rather than your mouse cursor.
Look at some disabled web form controls for an excellent example.
-
Actually in my application almost all of the window is frozen. Only the top "File", "Menu", "Help", etc. button can be interacted with. For my application it doesn't make sense to "gray out" the whole window. Commented Oct 13, 2011 at 15:42
-
2In that case, it might be worth it for you to give us some more information about your app so we can give a better response. I still think that even if you're graying out the whole window, it is a better visual cue than using the mouse cursor.– nfwCommented Oct 13, 2011 at 15:45
-
It may be your widget selection in this case. Consider using label widgets instead of things like text boxes, buttons, etc.? Users generally try to interact with text boxes and buttons but they can intuitively tell that a label is meant to display information, not be interacted with.– nfwCommented Oct 13, 2011 at 15:48
-
3Yes, the default cursor (usually an arrow) indicates the element beneath cannot be interacted with. Otherwise, the cursor changes to show what action is possible. Commented Oct 13, 2011 at 16:48
-
1See comment attached to my answer - the difference between web and desktop apps... Commented Oct 13, 2011 at 17:05
This is the not-allowed cursor (as opposed to the same cursor used for no-drop) and which is part of the CSS3 cursor spec - for example see it used on jsFiddle - move the mouse over the preview/result area to see it in action (as set by the CSS code at top right)
Note: the demo is the CSS code running - not jsFiddle itself changing the cursor!
I would say, however, that I would be more inclined to use this cursor for desktop applications than for web. And if it is used for web, then only for an exceptional case rather than a general case, as the general case of no interaction is indeed covered by the standard arrow cursor (as other answers suggest) - unlike a desktop application where the standard arrow almost always means you are 'good to click'.
answered Oct 13, 2011 at 15:51
-
3What are some examples of applications or platforms that use this to mean this? I've mostly only seen this to mean "invalid drag-and-drop target". Commented Oct 13, 2011 at 16:39
-
I've used it a 3D interactive design application. 1) When positioning a new object in the scene, some parts of the scene are invalid and the new object cannot be positioned there. 2) When trying to select elements in the scene, some elements are locked and cannot be selected (Note this is not the same as 'nothing under cursor to select') 3) When moving an existing object around, the position under the cursor is invalid. Essentially the summary that expresses all three situations is: interaction not allowed Commented Oct 13, 2011 at 16:45
-
I realise this is not the exact same scenario - but the result is the same - interaction not allowed or not possible. I've not seen it used elsewhere... Commented Oct 13, 2011 at 16:46
-
@Random832 I found an example online - added it to my answer above Commented Oct 13, 2011 at 16:52
-
3@Roger Attrill: I would say that the example in your first comment is not so much "interaction not allowed" as "target not allowed". And this gels much more with the drag/drop ancestry of the "forbidden" cursor. Something else to consider: I'd be careful with this "no interaction allowed/possible" analogy. in both web and desktop applications. If you take it too far, then all "white space" should have the forbidden cursor and only clickable controls should get the default cursor... Yikes... Commented Oct 13, 2011 at 17:44
Technically a cursor with some kind of padlock symbol would make sense, but I agree with nfw. Give the user a visual cue that certain elements are locked, rather than have them waste time hovering over them, only to find out they can't interact with them.
answered Oct 13, 2011 at 15:40
(In response to your comment, it's too long so an answer.)
If there is no problem with them accidentally clicking and no real indication of problems, I'd say you don't need to do anything for that, no special cursor. There are plenty of situations you can't click on something: backgrounds, labels, empty space... The lack of response in itself isn't a source of confusion, and it in itself provides feedback: you click on it, nothing happens, ok, crystal clear.
The confusion arises when the user expect something to happen and it doesn't. That expectation may come from other applications where the click does mean something, or from other situations in your application where you can click, (or from other expectations that might be less traceable.) They don't just expect 'something, anything' to happen, they usually have specific expectations. And then it is better to address those specifically, rather than just providing a 'no can't do' image. (For example, users may expect to bring up the settings when right-clicking, and rather than telling them 'you can't right-click' you could point them to the settings.Don't just tell the user there's a problem, but point them to a solution.)
Even more, a special cursor / mouse pointer may well confuse the user even more, because users can take it as something is wrong. Or that in other situations the interaction should make sense: like a greyed out control implies that there actually is a situation where you can use that control, otherwise, why is it there?
So I would advise to just use the standard pointer (the arrow) without anything until either user tests or requests indicate that there is something to fix, and then fix it using the information on the actual confusion.
Based on your comment to nfw, it sounds for me like a "blank canvas" issue, not a problem of disabled content: The user is starting your program and nothing is on stage and enabled besides Project Open/Load, etc.
What about having a start screen instead? Like Viso-Startscreen or a Dashboard like Mocha. So users see where to start and you can present their options more in sight.
It's not a mouse issue. The main goal is to tell the user that he can't deal with the content. I agree with @nfw in the gray approach, but am adding a darker gray message box that tells the user why he wont be able to interact with the content, or any kind of messages that suits the situation.
For example if the only problem is that no existing projects you can show him a big rounded-corners gray button with "Create New Project".. Or "Start here"..etc
