Tag Info

New answers tagged

2

This is a well known design pattern. You have a form which contains sub-workflows, which can be fired off at different times in different orders. Problems: Legends (asterisks in your case) should be avoided if possible, because it forces the user to dart around the screen to figure out which controls are asterisked. Having the action buttons in a ...


1

Color-coding the data entry boxes will give additional affordance. Are there other visual representations of the two actions (A and B) that might be represented with an icon or symbol? Can you logically group the required fields for each action?


1

There are simply too many rules to validate a phone number input by a user. 1. Phone numbers are ultimately just a string of numeric digits Here is one example showing how to convert anything a user inputs as a list of numeric digits. You would want to use the raw input from the user everywhere in the UI and then also store the converted string of ...


0

Beside adding dashes, you will need to deal with the position of the cursor, especially in case of deletion. This AMD module does exactly that: https://github.com/whenyoubelieve2014/us-telephone-input


0

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


-2

ONLY disable the button if required data is missing or is not entered in a valid way - but still, even if you choose to do that, make sure you easily notify the user that some fields are correct.


0

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


6

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


3

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.


1

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


0

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


0

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


0

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


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


50

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


16

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


3

When you validate an email address, you are checking two things: Is this a valid email? Does this user have access to this email? The only way to do 1. is to send an email, and check that it doesn't bounce. And the only way to do 2. is to send an email with some information and check that the user received that information. That can either be done by ...


1

Without looking at any security aspects I would say it's always best to validate formatting as much as you can in the page before going to the server (i.e. before your authentication request) and, as Alph.Dev says: Give the user clear feedback on what the problem is - if you're validating the email in page you should be able to tell them if it's not an email ...


3

Purely out of usability reasons you should always tell user what's wrong with the input. If the user doesn't know what's going wrong, he has to guess. Guessing on it's own is a a bad user experience because it requires effort. Additionally, the more incorrect guesses he does, the more frustrated he gets. So it's always a good practice to let user know what's ...


1

Here are a few possible strategies: Do nothing. Since the cropping corners are automatically placed in initial positions, you don't have to worry about concave polygons being created accidentally. The only way you will get invalid shapes is if the user deliberately drags a corner to create one. Since there is no objective reason to create such a shape in ...


0

Scroll up to it (have an animation take it to the top of the page). Display the errors and also make sure you have contextual errors, because the user might not remember what was needed to be filled. download bmml source – Wireframes created with Balsamiq Mockups



Top 50 recent answers are included