Should I show the "Save" button before the required state is achieved

Question

In our web application, to save a transaction (such as an invoice) the user must select the contact's name and add at least one item to the grid.

Presently, the save button shows before these actions are complete. If they click the save button before they enter the required details they will get a message to add those details.

My concern is that having the save button shows before the required state, suggests to the user that they can actually save something.

The other solution we are considering is to only show the save button if the user has entered the required details.

What is the better solution?

Note, the application auto saves the transaction as a draft. Save though commits the transaction and can have impact on other areas.

Answer 1

What is the better solution?

The always-active button.

Why?

With an always-active button, you can select it, and then be told what isn't complete.

With an inactive button, you are stuck. You may not know why it's inactive and as such, hit a dead end.

Answer 2

On the apps I work on (which are similar in nature) the Save Button is always there but it's grayed out if required items are not filled out. The Save Button becomes active when the required information has been entered.

EDIT: See DAO1's comment: "Inactive buttons are incredibly annoying. There's no indication as to why they are inactive providing no way for the user to figure out how to activate it."

We handled it by having the the label of the submit buttons clearly marked.

• "Submit Completed Form to <Name> or <Department>"
• "Submit Questions to <Name> or <Department>"
• "Submit List of xxx to <Department>"

and so on.

If someone is on the "Need Buyer's to Review Page" and the user hasn't entered a question then Submit to Buyer button is gray. There is nothing for the user to submit on this screen. (And yes he has options to go else where.)

I should add that this is for a B2B application and not a customer facing app. This app is as integral to the user's workday as is Excel and Outlook.

Answer 3

First of all, @DA01's answer is 100% correct IMO. I just want to expand on this a bit in the particular case of form elements with asynchronous validations in case it's helpful for you, dear reader. I included some screenshots (apologies in advance for my ugly wireframes).

--

Our team ran into this problem recently while building some complex forms with entangled states (unavoidable; it's a developer tool). We have related form elements using both synchronous (i.e. immediate) and asynchronous (i.e. takes a few hundred milliseconds) validation rules, where changes to one form element can affect the other, and changes to any form element, can cause the client-side validation of the entire form to fail or succeed.

In our case, the validations are usually asynchronous because we're doing static analysis on manually-entered JSON expressions and don't want to block the event loop in the browser-- but the timing (100ms-500ms delay) is more or less equivalent to situations where your form is talking to a fast endpoint on a server (e.g. username or email address availability checks in signup forms).

It's tricky-- on one hand, you don't want to give the user a false positive, but on the other, you don't want to let the user think they can't submit the form.

Here's the best-practices we ended up adopting:

Whenever validation begins to run (typically keypress or blur), go dirty:

• switch the "Submit" button into an interstitial state (this is the always-active state accurately suggested by @DA01).
• if the design calls for it, render the form element as "validating" (we call this "dirty"). Many sites (e.g. GitHub's enrollment form) show a loading spinner next to the form element label for this.
• lock any form elements that depend on this one and update any relevant help text (in implementation-land, we accomplished this by triggering a custom dirty event)

^ dirty (save button interstitial)

Note that the button still looks clickable, and only a tiny bit different from the normal enabled "Save" button-- just enough so that power users know what's going on. You could easily just have it look exactly the same if the delay for validation is short enough, or if this is not a form your users are going to be filling out multiple times on a daily basis. Also notice that dependent form elements are locked/disabled. Finally, note that if the delay for your validation is longer (maybe >= 500ms) you might opt to display an inline loading spinner next to the form element being validated. GitHub's signup flow does a great job of this if you're looking for inspiration.

When validation completes, go clean:

• Unlock dependent form elements that were locked strictly because this element was dirty (allowing them to be interacted with again)
• switch the "Submit" button into the disabled or enabled state, depending on the validity of this element (which you now know) and render any errors and disable/enable other form elements as appropriate

^ clean (but invalid, save button disabled, dependent form elements errored)

^ clean (valid, save button enabled, dependent form elements enabled)

When the user attempts to submit the form and the "Submit" button is in a normal (enabled) or interstitial state:

• Immediately switch on your syncing state (loading spinner) and lock the "Submit" button to prevent double-submissions
• rerun client-side validations again manually (you could try to be clever here, but I'd suggest always re-running to be safe)
• if everything is ok, finish up. If you're not navigating away from the page, be sure that the not-yet-triggered "clean" event from the unfinished inline validation won't cause problems (i.e. in the callback for your inline validations, before doing anything else, immediately check to see whether the form still even exists, and if not, return early)

Note that, for the strategy above to work, you need to debounce (e.g. _.debounce() from lodash) your validations so that you're sure they run in order. If the validation is asynchronous, you'll also need to use a spinlock, e.g. if (metadata.isValidating) { return; } metadata.isValidating = true; validate(function whenDone(isValid){ metadata.isValidating = false; /* now trigger "clean" event */ });

Answer 4

Don't hide it: Because users might think there's no button at all (therefore action) and get really confused + stuck.

Don't disabled it: If you want to tell users that they did something wrong, wait until they do it! Even if you apply inline validation, the user could avoid the fields and disabling the button will give them no clue about the need of filling those fields in order to continue. One workaround could be to tell why it's disabled near the button but I wouldn't recommend it.

Do error prevention: By inline validation / tooltips / good naming in labels and placeholders.

Do validate after click: Because you can't inline-validate what hasn't been filled and you can't blame the user with anticipation (as I explained in my no disabling paragraph)

Answer 5

Your concern is valid. I suggest effectively disabling the Save button (using a visual cue, like a "grayed-out" color, and functionally in the HTML using the disabled attribute) until the front-end validation rules are satisfied, then enabling the Save button.

Useful edit: Validating a user's input and providing helpful feedback as they fill out a form provides a more user-friendly experience, and increases the chance of successfully completing a form. I've found the Save button to be more effective when it saves properly upon click, than act as a try or validate button that checks a user's input and provides feedbeack when they believe they've filled out the form properly.