Tag Info

Hot answers tagged

52

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


22

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


17

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


14

Generalising between platforms I would go with the following basic guidelines, they further emphasise a disabled field with a grey background. Normal (with a value) Black text, white background, black border. Normal (with a placeholder) Grey text, white background, black border. Disabled Grey text, slightly lighter grey bg, grey border. E.g.


10

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


7

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


7

In most cases, forms are made of native elements and the look and feel is therefor (ideally) determined by the operating system. Mac OS has a different way of showing something is disabled if you compare it to windows. Here are two text fields of Windows XP and Mac OS X with native behavior: vs. I would advice you not to change this behavior for several ...


6

Some things I have seen done before in this scenario: Make placeholder text green instead of grey (user input is in black) Placeholder text is in italics (user input is in normal text) Put angle brackets around text, eg. < your name here >. (This one is somewhat "technical", i.e. something a programmer is more likely to understand) I would suggest ...


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

From WCAG 2.0, which is generally accepted as a way to be 508-compliant in your product: 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; ...


2

I can't find any specific user research data on this topic but there is plenty of tests showing LESS is MORE. Option 3 shows roles and although disabled has a chance of raising questions "Will the Viewer role accidentally get assigned?" (friction) Option 2 removes the role but also raises questions, "I can assign roles to the first 2 but why not the last ...


2

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

Of your three options, I prefer the second because it adds an upgrade option, empowering the user to solve the search availability issue. Alternatively... Create a button for each concurrent search that your user's current account can perform and replace each one with a confidence animation when its search is running. Something like...


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

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


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

I'm going to give you the simple and correct answer : You NEVER disable a button unless it is performing a server-side, behind-the-scenes call, often referred to as AJAX, where you don't want that server-side action performed multiple times due to multiple clicks. It would also re-enable itself upon return providing you with the information needed to ...


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


1

Option 1. Design principles There are two design principle behind this recommendation: Progressive disclosure A strategy for managing information complexity in which only necessary or requested information is displayed at any given time. Signal to noise ratio The ratio of relevant to irrelevant information in a display. The highest possible ...


1

It depends on what your user needs to be able to do. For example, the following cases would support responsive disclosure (hiding the options that are not needed based on the earlier selection)... the administrator wants to see what options are available to the normal user a new user isn't sure whether to pick administrator or not and wants to know what ...



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