On Mar 18, 2:43 am, "D.Kreft" <dkr...@gmail.com> wrote:
> On Mar 17, 4:53 am, RobG <rg...@iinet.net.au> wrote:
>
> > It is much more user friendly to let the user complete the form and
> > submit it. Run validation onsubmit (or onblur of individual fields if
> > you like) and cancel submit if they don't get it right.
>
> > Do not lock users into getting a field valid before letting them
> > proceed to the next field. By all means display adjacent error text
> > onblur, but the form only needs to be valid when it is submitted. Its
> > state in the meantime is irrelevant to anyone but the user.
>
> To be clear, the goal here is not to lock the user down to *one field*
> and forcing him to getting it right before moving on,
Good. :-)
> but rather to
> remove the ability to submit the form if we know that there is no hope
> of succeeding due to malformed or missing inputs.
You need to be more outcome focussed. Disabling the submit button
serves no useful business outcome of itself, it is a means to an end.
The underlying requirement (I’ll guess) is to is take all reasonable
measures to ensure the form is valid before it is submitted -
hopefully it is in addition to, and not a replacement for, validation
on the server.
> Opinions may vary on
> whether or not this is the right thing to do,
I think the vast majority of opinions would be in the “not” camp.
> but in this particular
> case I have no choice as I am constrained by the design spec to make
> this site behave in this manner--I have no say in the matter.
Presumably there is a change control process? Specifications should
never be set in stone, particularly design aspects this low-level.
Clearly you have thought through the usage scenarios and are
struggling to come up with an elegant solution - doesn't that tell you
something? Shouldn't that be conveyed to those have the power to
modify the spec, along with a suggestion on a better implementation
that achieves the required outcome in a much more efficient, user-
friendly and elegant manner?
The following is the traditional usage pattern: when the user first
opens the form, it will be invalid (I presume). As they fill in each
control, validate on blur and place message text adjacent to the
control regarding the error. This allows them to complete the form in
their own time, in whatever order suits them and to get things right
however they wish. They feel empowered as the form isn’t telling them
what to do, just advising when things aren’t yet valid. They may
never focus on some control that must be changed to become valid, how
will you know to check that control? How will you know that the user
hasn’t just left that one control to last?
On submit!
The submit event is important, that is when you know that the user
*thinks* they have completed the form and you can show error messages
for all the controls that haven’t been successfully completed. If you
remove that event from the process by disabling the submit button
until the form is valid, you’ve made a rod for your back that is
difficult to live with (as you’ve discovered). And for what purpose?
None, the outcome is the same - the user can’t submit the form until
it’s valid[1]. The difference is that by using the submit event to
validate the form and cancel submit if it’s invalid is that you have a
specific event on which to validate *all* the form controls. It also
much more natural for the user,
Now I’m not in your shoes, I can only provide you with arguments to
take to those-who-must-be-obeyed, it’s up to you to present them in a
way that delivers a better user experience and a robust, elegant
solution. And if you have to stick with the disable-the-submit button
approach, good luck! :-)
1. Trusting that the script runs unaltered in an unmodified page -
there are simple techniques to circumvent scripts that attempt to
prevent submission (hence the requirement to always perform server-
side validation).
--
Rob
