Tag Info

Hot answers tagged

79

If a user doesn't have permission to access a particular item of content, I would suggest not displaying it at all. If the user needs to know that content they don't have access to exists - show them the content in a different form and provide them with a way of enquiring about how to gain access if necessary. Eg. as a content list (rather than semi ...


61

I'd like to take @lazer's suggestion a step further. Why not add a small padlock icon after each of the links the user does not have permission to? Then, if the user would hover the link, I would show them a tooltip explaining that they don't have permission to view the page contents.


38

He's making multiple points of varying validity in that post: Explain why an item is disabled: Great advice that almost no one follows! Google search "greyed out menu" and you'll find heaps of people wondering why their menu items are disabled, because the app doesn't tell them. Giving them info when they hover over a disabled item or try to click on it is ...


31

Before you completely hide a part of the UI for a feature which the user doesn't have access to, consider: Will the user know about that feature? Will they spend a lot of time hunting for it? Would you be better off keeping it around in some kind of "disabled" state along with a tooltip or other indicator so that they can learn why it's not available? ...


26

Not quite - but I have taken a step further in the right direction having previously implemented a mechanism in several desktop applications, whereby in addition to any button or menu item being disabled, a tooltip shows the reason why it is disabled. Thus we get something like the following (Disabled should be new-lined) The additional follow ...


23

I worked on a very similar project to yours where users could only view the content based upon their access permissions. Though the initial reaction from the stakeholders was to just show content, to which the users had access, there was also feedback that users might have wanted access to specific content. Thus, hiding unauthorized content would have lead ...


17

I can see a problem with inconsistency if you remove the buttons entirely and start moving active buttons around the toolbar. The usual practice is to provide inactive buttons with an inactive state eg grey or faded. The additional benefits of this approach is that you are keeping the user informed via visual feedback of the state of the system; invisible ...


16

If the button is merely disabled, users will Think the application is broken, Not immediately realize which fields are unfilled and Not realize the fields are unfilled until the very end, which is annoying So, I'd suggest telling your colleagues exactly what you told us, which is that allowing them to submit then find errors might be more efficient ...


15

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


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


13

The save button has become the Skinner Box button for a great deal of people thanks to terrible, terrible software that never autosaved people's work for a good 20 years of popular software. I don't like to keep training people to hit that button, but there's nothing more aggravating than finding your app didn't just save what you did. I found Google Doc's ...


10

Research has shown that consistent placement of the buttons is more important than labels, icons, or colour of the button. Orbitz Can’t Get A Date From these results, we inferred the location of the icon is more important than the visual imagery. People remember where things are, not what they look like. This was also the reasoning behind Windows 7's ...


9

Depending on the application, I often just don't display the parts of the page a user doesn't have access to. It sounds like you have users changing other user's rights, so this method may not work. I would recommend displaying an error message whenever you display a disabled input element. Users can become frustrated when they are unable to perform an ...


9

In an app I created some 10 years ago, disabling is the approach I took. Each form has a Save, Cancel and Close button. Save and Cancel are both disabled until changes have been made. Close is always available and will prompt to save or cancel when changes were made. At the time I thought it was the right way to do things. Now, every time I open an edit ...


9

Generally, I would: show / hide content based on user rights enable / disable content based on availability dependent on everything else. If a user has no rights to see something, security dictates that they should not even be made aware of its existence. Is a user does have rights to see something, (s)he should always see it, but it may be disabled if ...


9

Updated I've updated my answer (a) because I realized that the OP's suggestion ("disabling" rather than "hiding" links) was quite different from the rule we faced; and (b) to say that the big problem we faced was not because we were told links should be hidden in certain situations, but because of a blind across-the-board rule. We went through a related ...


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


8

I see two different approaches. If the actions are disabled because of security I would actually try to remove them if at all possible. Easy with menu items or most toolbar buttons. If the actions are disabled because you have a cheaper version of the software, I'd keep them present but disabled. This lets the user know "you could have this if you paid ...


8

If the submit button is disabled, you definitely have to tell the user why this is so. So why not display a short message telling the cause for the disabled button when this is the case? This short message could be shown under the form - maybe in red or highlighted in another way. And then this approach provides the better user experience in my opinion. ...


8

I agree with this if the case is the user hasn't met certain requirements to enable the option. Like selecting text. But I work with a lot of applications where options are disabled by role. In that case, this particular user will never be able to use those options, therefore, they shouldn't be visible to this user.


7

Another approach is to not show the action at all. Stack Exchange is a good example of this. If I don't have "edit" rights to other people's posts I don't see an "edit" link at all. This means I don't try to click it and wonder why it doesn't work. This might not work in all circumstances, but in your example the "admin" and "financial" options/links just ...


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


6

Usually favor hidden over disabled fields Disabled fields give extra thought for the user about why it is not available. As per Steve Krug's "Don't make me think" you should remove elements that make the user think and which they don't need anyway. (It would be better to give this attention to the field/setting that would make the disabled one available.) ...


6

50 or so elements in the format the user is expecting based on standard Based on these criteria I'd suggest a stable screen. Unless you have a lot of freedom in changing the format into some thing more web-friendly, I wouldn't apply web-specific techniques (expand/collapse) to the form. I'd say this based on converting a lot of paper-based forms to ...


6

You're assuming users never save changes to data they haven't changed. They do - all the time. Partly as an unconscious reflex, partly because they can't always remember what they've edited, and partly because they fear the risk of losing their work so much, they save religiously. I exit forms via the save function all the time. It's a hard-learned habit, ...


6

I agree with TamDenholm in that you should not display the connect option for IE8 users. However I feel there are some users that do care. For example: I may have created an account using FB connect in a different browser I may be using a different computer (most corporate environments use/force IE) These are probably still edge cases, but I would ...


6

You should show the submit button in an enabled state, unless you can easily explain next to it what would enable it, like an Alert saying "You can submit the form after filling in field1, field2, etc". This explanation would have to be directly next to the button and obvious. You shouldn't rely on the state of the submit button alone to tell the user ...


6

The basic rule I recommend is use disabling when a command is currently not available but the user can do something pretty obvious to make it available. I think that fits your situation here. Presumably you have some indication whether each survey is submitted or not (users will need this to know which have been de-submitted and need re-submitting. If all ...


6

You should not show controls to the user if they can not interact with them. It will cause problems like frustration, doubts and may be even leaving the process altogether. If the user finds a control that he can't interact with, first is going to look for an explanation of why. Once he doesn't find that answer, he may feel that missed a step before, and ...



Only top voted, non community-wiki answers of a minimum length are eligible