The User Experience (UX) Of Disabled Form Buttons
By default, form buttons aren't disabled. When you render a form, everything "just works". That is, until, a web developer decides to get "clever" and starts disabling buttons, pending some desired form state. Unfortunately, many developers are not quite as clever as they think they are; and, buttons often remain disabled even when a form has been completed filled-out. This obviously leads to a terrible user experience (UX).
This is not a theoretical problem. I run into this scenario often enough, most frequently on my mobile browser. A form will be auto-filled, or I'll paste-in a password, and some mobile form thinks that I have yet to touch any of the inputs. And so, the "Login" button remains disabled for some unknown reason (until I manually add — and then remove — a character).
Let's assume for a moment that the web developer is actually intending to provide a better user experience by not allowing a user to submit invalid data. To that I would posit that if a user wants to submit an incomplete form, the form already has a bad user experience. Meaning, something about the form itself lacks affordance. Something about the form is leading the user to think that the form is ready to be submitted even when it isn't.
So, by disabling buttons you're actually solving the wrong problem. And, you're (potentially) creating new problems in the meantime.
And to what end? Ultimately, you're already performing server-side validation and showing user-friendly error messages (I hope). As such, your desire to disable buttons and prevent form submission isn't actually creating any new value.
In web development, there is a concept known as the Robustness Principle. It states:
"Be conservative in what you do, be liberal in what you accept from others."
Unfortunately, we often see this principle being ignored on the web. Every time a phone number input requires dashes or a social security number input restricts dashes or a date input only works with dashes and not slashes, this is the Robustness Principle being needlessly tossed to the side.
I would argue that a disabled button is also a violation of the Robustness Principle: You are unnecessarily restricting what a user can do even when your (sever-side) control-flow is already designed to handle incomplete submissions.
On top of this — and maybe I can only speak for myself here — there is something subtly off-putting about the visuals of a disabled button. I know that when I load a form and the submit button is disabled by default, some tiny part of my brain wonders if I'm even allowed to submit this form. I might even wonder if the form is perhaps not loading properly. After all, why would the button be disabled if the application wants me to use this form?
I do believe that web developers are honestly trying to act in the best interest of their users when they disable form submission buttons. But, this effort is, unfortunately, counterproductive. The good news is, leaving buttons disabled is easy to do. So, developers can immediately create a better user experience by reducing complexity and lowering the level of effort that they have to put in their web forms. That's a win-win!
Reader Comments
Preach! 🙌
The one time I support disabling the form button is directly after submission to mitigate the accidental double-submission. But in this scenario, the default should still be enabled...onClick disable for several ms...then enable again. Hopefully by the time it would be re-enabled, the page will already have submitted. If the user back-browsers to the page, the button would be enabled again as well.
@Chris,
Completely agree - I'm all for preventing double-form submission. I try to do this (whenever I can remember to do it).
I have to disagree, while the "not-enabling-after-autofill" is indeed a bug itself and needs to be ironed out, I feel like that making a round trip to server validation only to return a message to indicate missing field is not necessary and can lead to slowdowns if connection is poor like you are on mobile and have to adjust many fields and you need many back and fourth to validate. Client side validation is an immediate feedback.
Like this comment form for example, it allows me to press submit without an email without indicating me that one is required (red field, * after Email, (required) placeholder...), after I press submit an error pops, what if i misstype my email? Nothing until i press submit, so I needed to scroll up and down two times while a disabled button + in place client validation would have stopped me and saved time. I'm not an UX expert but this doesn't feel right in my hands.
Cheers, K.
@K,
Over time, I'm personally tending to do less and less client-side validation. But, I admit that I always have the luxury of being on a fast internet connection. I don't think there is anything wrong with client-side validation; and, if it's easy for you to add that kind of functionality, I say go for it.
With that said, I think you can include client-side validation and still not disable form buttons. You can always have a
submitevent-handler on the form that callspreventDefault()on the submission event, does the client-side validation, and then submits the form if all is well — all without disable the form buttons.So, in the end, I think we can both have it our way 💪
@K
Client side validation is great UX. I'm in total agreement with you there as well. The situation we desperately want to avoid is having a form filled out with valid values...yet no way to submit it because the submit button is still disabled. 😭
Ben described one situation which may cause this scenario. I personally have come across forms where my hand-typed values simply did not register as valad to the client side validation (even though it was indeed valad). Because I'm a developer, I know how to work around this and can enable the button manually in code...but the layman wouldn't know how to do this causing them to be stuck in a dead end. And that's bad UX in my opinion.
@Chris,
It's nice to know how the sausage is made 😉 Gives us super powers!
@Ben,
Bwahahahaha!
Having just found this, I love the perspective you provide here. I hadn't heard of the robustness principle before, at least in the same vernacular. I have typically lumped that in with error tolerance. There are also a couple other UX problems that disabled buttons create that I thought should be included here.
@Dustin,
Great points - and sorry it took me so long to approve comment (it got lost in the mix).
There is something else I think no one talks about. On touch devices, if we do late validation, since there are no onblur events, the state of the submit button can only change when tapping outside of a given input (or control). This means that when completing or modifying the last required input, the submit button will appear as disabled even when all fields have been correctly completed. This will happen until the user touches outside of that last field. Again, this means an important loss of affordance.
My solution for this is doing late validation to show the error messages under each field and live validation to control the state of the submit button. This works really nice.
I also don't disable the submit button completely when there are validation errors present. I change the buttons appearance so the user understands it is in a special condition. This also works quite good.
@Javier,
Good insight about mobile devices. I mostly do work for desktop devices (and try to test on mobile when I can). The set of mobile caveats is far from my fingertips, so this stuff is great to hear about.
Post A Comment — ❤️ I'd Love To Hear From You! ❤️
Post a Comment →