Hot answers tagged

57

Type of the information captured and number of fields required It really depends on the type and scope of the information you are asking for and the number of fields that need to be filled: I have tested and used this pattern sucessfuly in login and and password creation. I think because the interface is so simple and the number of fields required ...


25

No, it would seem not, as W3C states 1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA) Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1; Incidental: Text or images of text that are part of an ...


20

I would have to say that this behavior hinders user experience. If you've ever read Don't Make Me Think by Steve Krug then you will quickly realize that this pattern is breaking the rule stated in the title. One might ask, Why is this disabled? There is no benefit to make a user jump through this hoop. Basically what I am implying is that the user is ...


11

we often see the 'continue' button inactive I think this may be false. Read on! For what it's worth, I'm updating some old research on sign up forms for popular websites at the moment, and have found that quite a small percentage - around 5% or less - disable the Submit button (whether that's the final sign up or a continue type button) until the data ...


8

One should not disable the button Consider the situation from the user's perspective. Divide users into two groups Those that do not currently believe they can proceed, so are not looking for a way to continue Those who believe they are ready to proceed, and are looking for a way to do so. For the former group, disabling the "continue" button is merely ...


4

Assuming that we want to keep our UI as simple as possible and we do not want to overwhelm users with controls they can't use then the only reason to leave visible inaccessible features is to tempt users and make them engaged (to gain an account). If anonymous access is no more than a showcase (and you want it like that) then you don't have choice: leave ...


4

My short answer is no. Grey does not always represent disabled condition. I think it depends on the usage, context and the colour scheme of your app. Lets take email sign up popups as a first example. You land on some news website and immediately after the page loads you are presented with a popup with couple of inputs and usually two buttons, Cancel and ...


4

This is a meta answer drawing from the diverse opinions expressed. If you want to disable the button, you should still check for clicks and give reason why it is disabled. This has two advantages: fewer errors are displayed, and if you for some reason did not previously communicate why the form can not be submitted, you can explicitly do so.


3

Buttons are meant to be clicked. If user sees a button, he would want to click. Disabled button becoming active only when all the data is filled in that specific form is not a good experience. I would rather tell user ( which i do with the forms i design ) right at the beginning that all the fields are mandatory and you cannot sign up if any of these fields ...


2

From a UX perspective, there are things that could be done to help the user experience by not setting pointer-events to none. Showing disabled fields to a person is sometimes cruel. If the rules for why the field is disabled are complex and not obvious from the screen layout, it is like holding a carrot just out of reach of the person trying to use the ...


2

There isn't much point cluttering the interface (visual noise) with actions that cannot be performed. It violates quite a few UX heuristic. Obviously when an action can be unlocked via user action, orientation comes to mind (although it may still be worth hiding the locked actions so their introduction to the interface will draw attention). Aspects such as ...


2

Grey is a convention, not a rule It helps to understand why grey is used for disabled buttons: Grey is a neutral color so it's good for communicating subtle or de-emphasized elements. Disabled buttons (because they are not clickable) are usually communicated to the user via de-emphasis. The visual message is: "I am a button (look at my shape) but I ...


2

I think 3 is the best option here. 1 & 2 show the form fields and have them disabled, this could indicate to a user that they could become editable - and they may wonder if they need to perform an action to make them editable. Because they will never be editable, no form controls are needed. The data should be printed. Another thing they may help this ...


2

Option 1. Hiding the content - You go to the tab, you see the explanation instead of the content, you got it. Simple as that. Hiding the content is better than disabling as disabling is usually used for business logic (for example, an option is disables unless some check-box is checked). Hiding the tab - The worst option. Users will get frustrated ...


1

Give users a reason to login or create an account. If getting and keeping people on board is important, making interaction easy and accessible will help to encourage them to become or stay active on your website. What should be accessible depends on the privacy and/or security policies of the website. Since you mentioned Facebook as an example take a look ...


1

Consider just getting rid of save button. Whenever user makes a change, just remember that change and update it. And then give user a non-modal receipt like a toast. It's a common modern way of GUI implementation for Settings changes, especially for web based products. If you really want to have the save button, having one button makes more sense in your ...


1

Some thoughts: Speed – small checkboxes are not the best controls for the fast/frequent actions, according to Fitts's Law. It's too slow and exhausting to use chechboxes for the big data set Errors – placing checkboxes with different actions close to each other (Select and Disable) could cause errors (slips) while performing the action (e.g. clicking ...


1

To disable the option is a general way to go, is more appropriate considering that you should always work towards error prevention. My suggestion is to clearly change the appearance of the non-deletable node in comparison with the default ones, and additionally show a tooltip or something indicating why this node is special and cannot be deleted. Over time ...


1

The first option is the best. It's poor UX to invite someone to do something, and then tell them they can't do it. Think about Donald Norman's concept of 'Affordance'. A handle tells people that they can pull a door, while a plate tells them that they can push it. Your are giving people a handle on a push door here. Use a common pattern, like greying out ...


1

Short answer (and to avoid delving into how you are planning to parse content on your website) is yes it does - http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat.html If the Assistive Technology can't interpret your content correctly when Javascript is turned off on your page (or the web browser being used doesn't support Javascript) then it would not ...


1

I had a problem like this recently. The answer I came up with was this: Elements/controls must be contrast compliant when disabled as this provides vital clues to the user telling them that their task is incomplete or that certain options are selected/deselected. - In short: Yes, they need to be contrast compliant. EDIT - The following is incorrect however ...


1

I prefer 3. The reason is that if you have a couple of greyed out settings, displaying explantory text can become confusing or dazzling to inexperienced users. It is logical that they will try to tap the greyed out setting, in order to try turning it on. The nessecairy information will apear as needed, without overwhelming them. If you are concerned that ...


1

You might want to have a look at a related UXSE question. It is okay to use grey for non disabled things, provided there is no conflict on page. Currently your grey color is overloaded by two meanings. On buttons it acts as a disabled state, on icon is not the case. This reduces affordance and users would definitely frown upon it. The top answers in the ...


1

I would not use pointer-events:none; on a disabled button. It's better to manually set the cursor and hover effect to the default/disabled state. In some cases it's useful to add a tooltip to a disabled button; pointer-events none would disable this. I've added a use case for pointer-events:none; below if your interested.. Pointer Event Use Example ...


1

This is OK and acceptable behavior. BUT: common alternatives are: Allow the user to press save. Disabled buttons can be frustrating to users, and after all, there is no harm done by just re-saving the existing option. This also fixes an awkward case where the user selects Option 2 (enabling the save button) and then re-selects option 1 (do you then ...


1

I will keep this short and to the point as most answers are already covering a lot of valid and good areas. Does it add value? I am not able to think of a case where the user will/should look at the continue button to know whether he has finished filling in a form. Whenever a user wishes to click the button he believes he has finished the form and ...


1

I believe there is a middle-ground. A visually disabled button doesn't have to mean that clicking it does "nothing" as suggested. It will logically prevent the user from advancing in the absence of whatever is required to enable that primary action, but there is no reason that clicking it could not present an alert message to the user explaining why it is ...


1

A Form's 'Continue' button should be disabled until all required fields have been filled out and have passed validation. Why? Well it's common sense, really: Imagine you are a Bank. And you have a simple form setup which allows the transfer of monies from one party to another. You have a 'From which account would you like to transfer money?' field, a ...


1

Yes the "Continue" button should be disabled until all required fields are filled out with at least some text (this assumes that the required fields are designated as such to the user in some way). The affordance here is that the system cannot even attempt to continue until it has the required input from the user. Once the required fields have been filled ...



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