I once worked on a modal dialog for a client, where I needed to show three menu dropdowns. These dropdowns were supposed to have data selected by the end-user before enabling a submit button and closing the modal. However, nothing in the specs defined the state of the data in the dropdowns. We also didn’t explicitly inform the user they needed to make a selection before dismissing the modal. “It will be obvious to the end-user that they need to select something,” was a comment I received from a developer in the project. I, on the other hand, saw an opportunity for small UI tweaks to inform the end-user of what needed to occur as soon as the modal opened up. First, I added asterisks (*) to all of the fields to indicate that they were required. Second, I presented an error message to the end-user if they clicked on the Submit button without selecting a value. Lastly, I updated the dropdown components to have a loading state when the dropdown values were retrieved from a server.
Just to level-set, the difference between a web page and a form is subtle. A web page, from a coding perspective, is any page wrapped in the <html> tag. A form is any set of interactive input elements (like checkboxes, selects, buttons, text fields, etc.) wrapped inside a <form> tag. A form can only exist inside a web page. Clear? Alright, let’s jump in.
Similar to the five states that every UI screen should have, web forms, and their constituent input elements, should have seven primary states. They are in no particular order; valid, invalid, pending, pristine, dirty, untouched, touched. Let’s review them.
- The Valid state of a form or element is when the contents pass all validation tests.
- Invalid state is when the contents of the form or element do not pass validation tests.
- The Pending state indicates the validation is taking some time to process.
- Pristine indicates that the contents (ex: placeholder text) have not changed on the form or element.
- The Dirty state is when the form or element has been interacted with, and the default value contents modified.
- The Untouched state is when the user has not even visited the form or element.
- The Touched state is when the user has visited the form or element and blurred away to another interactive section.
So there you have it, the seven primary states of a web form. Now I say “primary” because, as you may have guessed, it is possible to have a form with multiple states. For example, we could have a Pristine / Untouched / Invalid form at the beginning of an interactive session, only to finish with a Dirty / Touched / Valid form. Each of those states can be styled, and interactivity handled differently. My suggestion would be to keep things simple. Less maintenance and support headaches that way.
You may be wondering if we should always disable a form submit button if the client-side validation fails. My answer is, “it depends.” I typically steer away clients from disabling the submit button on a web form until after the end-user has initiated their first commit. I don’t think the end-user should be presented with a disabled button if they haven’t even done any reading on the form. By the same token, we should not scream at them with error messages that all input fields are required if none of the areas have been touched. Reporting error messages should only be done after the end-user has clicked on the submit and, ideally, some server-validation has executed against the transmitted data. It’s the prudent thing to do. But I digress.
Are you considering a web modernization project for your desktop site but don’t know how to bring consistency to your front-end? Feel like your development teams’ web application’s feature work is disjointed? I can help. Reach out and let’s get your web project on a success trajectory.
