Hot answers tagged disable
14
Grey it out when you want the person to know that the control exists, but that it is disabled.
Hide it (make it completely invisible) when it doesn't matter whether they know that it is there or not.
In general I would opt to grey out controls rather than hide them, because someone could remember seeing a control somewhere that then not be able to find it ...
14
As with so many questions regarding UX the answer starts with 'It depends'. This is because UX is inevitably based in context and action.
Some arguments for using a disabled state:
Even if not in use, the user has a chance to learn that the action is possible. You may even have a tooltip explaining the criteria for use.
The user can learn where controls ...
9
To answer your specific question, users should not be able to activate disabled options.
To diverge from UX standards like this is a bad idea - most users would never click the disabled button, and those who did (likely by accident) would be surprised by the result.
They way I would solve this is to display printer status next to the button. Normally, this ...
7
I see three main approaches:
Hide the flow.
Display "service not available" page on selecting the flow.
Disable the flow with some indication (tooltip, information ("i") icon).
There are advantages and disadvantages to all approaches.
The main drawback to the first is that if someone comes to the site expecting to find the flow but can't see it then ...
7
This reminds me of Woocommerce, where they hide the all-important add to card button unless all options have been chosen.
Take a look at this:
vs the subsequent screen which shows the add to cart button and the number of items you want to buy. What if you wanted to buy two shirts but different sizes?
Hiding the most important parts of your navigation ...
5
I don't think the radio buttons are a bad idea per se, but it's an explanation that itself raises new questions: if there are other modes, why can't I switch to them? It would be best to support this (or a simple label) with an explanation of the current mode and what it takes to be able to switch to the other mode.
download bmml source – ...
5
If you selectively hide options from customers, you are going to create a lot of confusion. If a customer sees a feature while using one browser, but then doesn't see it when they are on another, it will not be evident why. The result will be a confused and frustrated customers.
If it is not available, rather explain why not and then let the customer ...
3
It depends an awful lot on how you expect the application to be used.
If all your users are power-users (like Photoshop in @edgarator's answer) then you typically want to grey out rather than hide - you want your users to know that the feature is there, and they're going to be using your app for a while.
However if your users are less technical or (more ...
3
Offer the buttons regardless of whether a user has the privilige to use them.
When a non-priviliged user clicks one, bring up a pop-up, thanking them for wanting to use it and offer them the way to get the privilige to actually do so.
For example all StackExchange sites allow you to click vote buttons. When you are not logged in they bring up a pop-up to ...
3
Disable the button if the report is not available. AND change the button label so say so. The idea of "shaded means it's un-clickable" is a common paradigm. And the wording strongly reinforces the idea.
Don't make your users click on buttons to find out if it's available or not. It won't take many clicks to really get them mad. It will come across as "ha, ...
3
I've always gone with the following rules to make this determination:
If any action on the current screen/page/window will change the availability of the field, it should be disabled/enabled as the values/inputs change.
If no action on the current screen/page/window will cause the field to be available, then the field should be hidden.
If the information ...
2
Do your best to rethink the grouping to slim down from 12 tabs to a smaller number, if possible.
Is this part of a stepped process ? (like setup, creating a profile, etc)
If so, I think 3 is the magic number in terms of the total number of steps. To slim down to 3, ask yourself 'do I really need this data ?' or 'do I really need this data now (can I ask ...
2
I agree with Bevan's answer; you shouldn't depend on the user clicking a disabled button for anything, but to answer your general question, I do think there are circumstances where it's reasonable to provide an on-screen response to tapping on a disabled button:
As a user, I generally assume a disabled button implies either that the system requires some ...
2
+1 to ChrisF's answer, but my comments became to long to write there:
You should make use of either ChrisF's approaches #1 (hide the flow) or #3 (disable the flow with some indication, i.e. tootip), but it depends on what your users expect to see. If you don't they would miss the flow that they don't have access to or if they never knew it existed, then ...
2
Took me quite a while to notice the buttons.
Try moving the Create an Account information you have below the puzzle to the right side of the puzzle. Since the right hand column (subscription, etc.) might be interesting to someone who is signed up, rather than a stranger. Make the reasons for account creation clearer and prominent, also, since you are using ...
1
I would not use radio buttons unless the user can interact with it.
You can use a simple label or hyperlink (explaining what the modes are) instead.
download bmml source – Wireframes created with Balsamiq Mockups
You can have a overlay or a modal window pop-up when you click on the mode to explain what it is.
1
This is what apple says about hiding application features according to its location:
People should be able to find all the available features in your app.
Don’t hide features by failing to make commands available in a menu.
Menus present lists of commands so that people can see their choices
rather than try to remember command names. Avoid ...
1
This question is very general. Without context it's hard to give an answer that would help. So this answer will be very general as well.
There are generally two reasons why an element can be active or not:
The action the control would cause can't be invoked (e.g. a disabled "save" button because not all required data has been specified)
The application is ...
1
It's generally due to the separation of presentation and logic. Particularly in the MVVM world. It's certainly doable though.
Let's take a simple MVVM example (Assume C# and WPF here, but this should be general purpose)
In my application I have a Paste button, which is bound to a PasteCommand in my view model. PasteCommand has a CanExecute handler that ...
1
If your site is iPad-specific, disabling zooming is definitely ok.
iPad users are definitely comfortable with non-zooming UI. Consider iPad native apps - they never require zoom for normal navigation. Zoom is only used for very specific controls in apps - such as enlarging images/photos/maps. If your content in native-app form would not include zooming, ...
1
I would suggest that hiding the button completely can add confusion for the user, as the other (unhidden) options might not make as much sense when you don't know the alternatives.
Allow me to give an example:
If the button which the user can see is "old" and there is an opposite button hidden - the hidden button could be "new" or "young" as they are both ...
1
I haven't heard of a golden rule unfortunately; it would be great if anyone knows of a study. A couple of thoughts and my experiences:
Is the user interested in simply accessing the "child" field without going through a parent field that enables/shows it? If yes, than hiding the field might make it more challenging for the user to know that the option is ...
Only top voted, non community-wiki answers of a minimum length are eligible
