Form-Field Validation: The Errors-Only Approach

Advertisement

Error pages for form-field validation are dreadful. You’ve just filled out 20 form fields, yet you get the same bloated page thrown back in your face because a single field failed to validate.

I clearly recall the often loud sighs of despair during our last usability study each time a test subject encountered a validation error page.

We also noticed that test subjects who had been exposed to validation errors began to take preventive actions to avoid them in subsequent steps, by writing things such as “N/A” in the “Company name” field if in doubt about whether the field was optional.

Form Field Validation Error Page at BlueNile.com1
When getting the exact same page but with an error message, the user will feel they have made little or no progress, despite having typed 90% of the form fields correctly. (Image: Blue Nile2)

Some of the frustration with validation error pages likely stems from the user being returned to the same page they came from. Being returned to the exact same page is problematic for a couple of reasons:

  1. With all form fields still displayed (valid or not), the user might have difficulty identifying the few erroneous fields among the many valid ones.
  2. More critically, seeing the same page twice makes it seem like the user has made no progress, despite having just filled in numerous form fields correctly.

At Baymard Institute, we reflected on this problem and got an idea that we call “error fields only” — which is exactly what this article is about. Before exploring this idea, let’s look at three traditional types of validation techniques: “same page reload,” “optimized same page reload” and “live inline validation.”

1. The Traditional Way: Same Page Reload

Here’s a typical validation error page from Staples’ checkout process:

Staples validation error3
The current error page for Staples’ checkout process. Besides having a subpar indication of errors, Staples4 also breaks a handful of checkout usability guidelines5.

When the user first submits the page, the entire page is reloaded, but with indications of validation errors. A message at the top of the page tells the user they have made an error and describes what the error is; further down the page, the label for the erroneous field is in bold and red.

This is significantly better than the sad practice some websites adopt of only highlighting the erroneous field in red or bold (without any description) and letting the user guess what went wrong. But the implementation could be much more thorough. Let’s look at how Staples’ page could be improved.

2. Same Page Reload: Optimized

To have a fairer baseline for comparison, we’ve made three changes to substantially improve Staples’ error page:

Mock-up of an optimized Staples validation error page. Click for full size.6
A simple mockup of an optimized version of Staples’ error page. Notice the anchor link at the top and the tailored description near the erroneous fields.

The three changes are:

  1. The error description at the top indicates the number of errors (if there’s more than one) and lists them.
  2. These listed errors are links that take the user directly to the corresponding field (especially important in long forms).
  3. A tailored message for each erroneous field shows either an example of correctly formatted data (for example, john@example.com) or a tip on what might be wrong with the data (for example, “Looks like the ending in the email address you provided is missing (.com, .org, etc.),” instead of just “Email wrong — please correct.”

Now, in addition to being able to locate the erroneous fields and spot multiple errors more easily, the user actually has guidance on how to correct their data. Some input errors are plain cases of mistyping or obvious details being forgotten, which most users will spot immediately; but if the user lacks clues and can’t instantly see why the data is invalid and has to guess in order to proceed, then they will likely abandon the process.

While better, this second implementation (and the first) still result in a poor experience. The user still gets the whole page with all 31 form fields thrown back at them, despite having inputted 90% of the fields correctly. The signal-to-noise ratio is still high (two errors among all valid fields). The user will likely scroll up and down the form to make sure all errors have been fixed and, finally, scroll down to click that “Continue” button once again. This diminishes the user’s sense of accomplishment and makes their effort to resolve the errors unnecessarily cumbersome.

3. Live Inline Validation

A very effective technique that resolves some of the issues with the last method is “live inline validation.”

Twitter use Live Inline Validation at their sign-up page. Image credit: Twitter.com7

Here, each form field is validated separately as the user types. The error handling is most often instant, with the user being told that their data doesn’t match the expected format (although the user can scroll past and try to submit the form anyway). Luke Wroblewski has done some excellent usability research on the inline validation techniques8 that work best.

Inline validation alleviates the aforementioned issues by indicating progress and by pointing out the erroneous fields (since the page does not reload). This makes the technique useful for forms in which the fields can be validated independently. In other cases, the data isn’t as simple as a user name, password and email address; sometimes the data needing validation is an array or a set of data. In the realm of e-commerce, one might need an address or credit card to be validated.

To live validate a credit card, you could perform a Luhn check9 to verify the format of the number, and you could verify the expiration date and security code (or “card verification value”) for the correct number and type of characters. However, the validation could still fail if the data doesn’t all match up when the payment vendor tries to authorize the card or if the card is declined. With live inline validation, the user would be first presented with a green checkmark as they input data in each field, and then they would see an error message after submitting the form if any of the fields didn’t check out. Alternatively, live inline validation could be disabled for just those fields for which the data has to be checked remotely. However, this has the drawback of an inconsistent UI, whereby some fields are validated live while others aren’t.

For address validators, the format of the inputted data could be correct, but the address itself could still fail validation (for example, if the address doesn’t exist). Again, live inline validation would begin here with checkmarks indicating to the user that the inputted data is correct, but then, when the user submits the address form, the website would (confusingly) change its mind and tell the user that it doesn’t recognize the address after all.

Our suggested approach, the fourth and last validation technique, tackles these problems.

4. Error Fields Only Approach

As we’ve seen, there are different ways to display error messages, each with its own strengths and weaknesses. Based on these observations, we thought of a validation technique better suited to complex data. What if we removed all validated fields on the error page that reloads? What if we displayed only those fields that failed validation? So, instead of reloading the entire page and showing all 20 fields of the form when only the “Phone” and “Email” fields have errors, you would simply show a page with those two fields and the corresponding messages.

With this approach, the picture is quite different. The user now gets a new page, or an overlay, with just a couple of error fields. A summary of the validated data would also be displayed, along with an “Edit” link in case the user spots something they want to correct. Staples’ error page would then look something like this:

Mock-up of Error Fields Only approach10
A simple mockup of what Staples’ error page would look like with this fourth approach. Only erroneous fields would be shown, and all validated data would be summarized below with an “Edit” link.

This approach makes the error page much more digestible than the traditional technique, and it makes abundantly clear which fields are the problem, which is particularly helpful in long forms.

Now, the user simply has to fix the fields shown and hit “Continue” — no scrolling, no having to pick out erroneous fields from valid ones, no repetition of the same page, just a simple page explaining exactly what to fix and how to proceed.

When To Use Each Validation Technique

Compared to the two traditional reloading techniques (i.e. 1 and 2), the “live inline validation” and “error fields only” techniques both offer the user a sense of progression and a clear distinction between erroneous and valid fields.

The “error fields only” approach is usually best when inline validation wouldn’t quite work. In April 2012, we benchmarked the top 100 e-commerce websites in the world and found that only 8% use live inline validation during checkout (likely due to having to validate both postal addresses and credit cards). In general, the longer the form and the more complex the inputted data and its dependencies, the more likely the error-fields-only approach is the best choice.

Inline validation is effective for simpler forms. When the data is an array or set, such as with postal addresses and credit cards, then the method becomes problematic. In this case, the UI would be illogical (the user would see each field validated individually and then suddenly fail collectively) or inconsistent (only some fields would validate as the user types). Of course, this technique would still require the page to be reloaded as a fallback, in case the user submits the form regardless of inline error messages (or if they have disabled JavaScript); therefore, the page reload techniques (the traditional and newer versions) might be best even for simple forms.

On smartphones, the error-fields-only approach has an advantage over the same-page-reload technique, because users typically lack an overview and context of the form due to the small screen. In such cases, displaying only the erroneous fields would help the user focus on the task at hand.

Rethinking Validation Error Pages

The error-field-only approach is merely a concept, and it needs both refinement and testing. An even better solution to these user experience problems most likely exists. Maybe having a traditional (although optimized) error page with green checkmarks next to the validated fields on the error page (to indicate the user’s progress) would be a better solution; or perhaps applying a slight fade to validated fields, making the erroneous ones stand out, while maintaining the context of the page.

The error-fields-only approach is more an attempt to inspire and a call to action to rethink how we handle validation errors and thus provide a better user experience.

While we can agree that validation pages aren’t the sexiest part of Web design, we should give them attention because their quality will determine whether the user comes to a screeching halt or feels a small bump on the road.

Got your own examples, mockups and ideas for validation errors? Share them in the comments!

(al)

↑ Back to topShare on Twitter

Christian Holst is co-founder of Baymard Institute where he writes bi-weekly articles on web usability and e-commerce optimization. He's also the author of the E-Commerce Checkout Usability and M-Commerce Usability research reports.

  1. 1

    Well…if the author writes for Baymard I hope he does better than his bio on this page…

    “Christian Holst is the co-author of the research report E-Commerce Checkout Usability, as well as founder of Baymard Institute, where he write weekly articles about web usability and conversion rate optimization.”

    Specifically where it says, “…where he write…” – Should read, “where he writes…”

    :)

    But I REALLY like this article…

    -4
    • 2

      Christian, Baymard Institute

      June 27, 2012 11:47 pm

      Hi, thanks for pointing it out :) I’ve corrected the typo multiple times by there is some caching or security feature that keeps resetting all changes to the bio.

      1
  2. 3

    Brilliant idea. I’ve actually come across a similar technique when using TaxAct. After filling in all your information (and for taxes, you can imagine it’s dozens of pages of forms), the website shows you “potential problems” one field at a time. Very useful.

    3
  3. 5

    Great Article! Error-field-only, to me, would work perfectly fine and it would be way less confusing on the user’s end. Although the idea with the green check marks displaying properly filled out or correct fields would also present a sense of accomplishment as well. Really good topic to cover!

    2
  4. 6

    Wonderfully written article, Christian.

    I totally agree, UX is so often tossed to the way side when designers and developers create forms. Forms really are a brands first impression on a user. Why not set ones’ best foot forward?

    Here’s my programming spin on the topic of form validation. I built jValidate, a jQuery plugin (though it could be converted to a standalone JS with minimal effort) to tackle this exact issue. jValidate leverages the power of jQuery & PHP to give users live, real-time feedback. It lets them know if the data they’ve entered is valid, and it notifies them if their messages or orders have successfully been sent. jValidate checks everything from names and email addresses to credit card numbers and message lengths, ensuring they contain sensible values. One of its simplest, but most unique features is its ability to bring users back to their last mistake. It even checks and sanitizes fields that aren’t required, in the event erroneous data is entered into them – all without page refreshing.

    Point of fact, I just finished installing the latest version of jValidate on a client’s website. Visit http://RMDLG.com/contact for a live demo. [ The staff at RMDLG really enjoy when people just say: "hello." So feel free to fill out and submit the form, even if you don't have a question relevant to their offerings. ]

    Once again, terrific article.

    2
  5. 7

    You make a good point here, but form validation is an ongoing problem that needs to be refined every time and adapted to a given situation. And I find the solution you proposed here to be good only for very long forms, like in the example you chose. For smaller forms with 2-5 input field this is not exactly a best practice.

    And how about introducing a new kind of feedback for the user? Say you have a required field for and address, like you said. We cannot know for sure if the address is correct until the information is processed on the server (if not using AJAX), but the address is mandatory for the form to be submitted. Why not inform the user with a different kind of message (say… a yellow warning maybe) that the field was succesfully completed, but the data will be fully checked once the form is submitted?

    IMO (and especially for the example you gave), the best practice is to keep the number of inputs to a minimum. So, for larger forms, the process could be split in individual steps. For example, we require only necessary fields, like name, contact and shipping address (information needed to send the products to the buyer), leaving the billing address as an option to edit separately if different (inputs should be hidden and should be shown only if need to be changed). Then, only AFTER the order is sent, payed and processed should we ask the user if they would like to create an account. Most poeple who buy products online (especially on small, “unkown” websites) will only do a single purchase, so a registered account is irrelevant to them. Why include this step in the main process? And registering as a regular user is definetly not the primary action they hope to accomplish on a checkout form.

    I usually find small forms (or split into individual steps) along with friendly inline validation to be the best combination for collecting user data.

    6
    • 8

      Christian, Baymard Institute

      June 27, 2012 11:43 pm

      Hi Andrei,

      Great points. Yes, as stated, this technique works best for longer forms. For a simple sign-up form inline validation is very effective.

      Your suggestion of introducing a new type of inline feedback informing the user that the input is formatted correctly, but still might not validate when submitted (e.g. with a yellow highlight + description), is interesting. But it requires the user to learn what this type of feedback means, and to overcome the cost of learning, it will likely work best on forms that the user have to fill out more regularly. Do let us know if you try it out.

      In regards to registering for an account before being able to complete a purchase (like Staples does in the example); yes this is a very poor practice disliked by most customers, as found in our checkout usability study (we wrote an article about it here at smashing roughly a year ago: http://uxdesign.smashingmagazine.com/2011/04/06/fundamental-guidelines-of-e-commerce-checkout-design/ ) The Staples checkout is merely a real life example used for the mock-up, not meant as a showcase of good checkout design.

      Thanks,
      Christian

      2
  6. 9

    Ricardo Machado

    June 27, 2012 8:04 am

    Hi, great post on UX.
    Well, I was wondering… Why not using the ‘inline validation’ in conjunction with the ‘Error Fields Only Approach’ ?
    When you click on submit, it would check the fields (as inline validation) before submitting.
    If still there were errors, it would only show (instantaneously, through JS obviously) the fields that were giving errors.

    By doing so, it’d prevent the user from ‘loading the page’ again, and from scrolling up and down to fix the errors.

    Oh btw, what i said doesn’t invalidate the server-side checking!

    3
  7. 10

    I’ve been using this approach for years. I always wondered why other designers and developers weren’t.

    2
    • 11

      I agree. I love all of the ideas above. Only problem i have found is developers not wanting to implement aforementioned ideas…

      0
  8. 12

    Very nice post! I especially like the idea of the Error Fields Only approach. I feel that form usability on any form longer than a simple signup form is so often completely overlooked.

    For the past few months, I’ve been contracting with a major healthcare organization, and one of the biggest projects on the table is a revamped patient appointment request form. It’s a huge form, with loads of JavaScript functionality, expanding decision trees, and complicated validation structure. My responsibility on this project has centered on a usability-centric approach to front-end form validation, primarily utilizing jQuery. We wound up using a great plugin by Position Absolute as a starting point, which displays nifty little inline error prompts on field blur.

    On submit, if there are any uncorrected errors, we show a box at the top of the page with a polite message saying, “Oops. It looks like you might have missed something or made a typo. That’s ok. We all do it. Just correct the information listed below:”

    Then we list the errors, providing the field label and error message, using the same language as the inline validation. Because these list items are labels linked directly to the corresponding fields, if the user clicks on the error message in the list, the cursor jumps immediately to the correct field.

    1
  9. 13

    “Point of fact, I just finished installing the latest version of jValidate on a client’s website. Visit http://RMDLG.com/contact ….”

    I LOVE jsvalidate and the RMDLG.com site does look lovely, but with that said, your comment was all SPAM, self promotional and added nothing to the discussion, least of which the “contact us” form referenced which is really too small to have the problems noted in the article.

    The article does attack (and address) some of the navigational issues of finding the errors you may have committed in filling out a large form, but overlooks the concept that FIELDS MAY BE RELATED TO EACH OTHER, and thus showing the “field in error” may not be sufficient.

    Is your zip code invalid? or is it your street/city (which exist, but in another zip code?)
    please see HTML fieldset tag

    5
    • 14

      I agree, the Error-Fields-Only-Approach works best if all the fields are unrelated. When they are related, the problem seems the same risen by the author for inline evaluations: suddenly many fields fail collectively. So when things become complex I’m unsure which approach will work best.

      The main advantage for using EFO Approach is to reduce code validation steps: inline validation requires many server calls, and still the final submission will require a complete sanification and validation of all user input. EFO may reduce code writing and consequently MAY reduce validation bugs, personal data leacks and security issues.

      When sticking to UX, I believe that inline validation will provide the best experience in most cases, but it’s just my personal point of view!

      1
    • 15

      @steve42 > Thanks for your kind words about RMDLG.com’s UI. I don’t often design front-ends since I’m more a back-end Dev, but it was fun doing that project for them.

      Regarding All Spam: steve42, you are welcome to your opinions on what constitutes thread spam. However, I disagree with your assessment, given the fact that my first and last comments were praise to the author for a great article (so… “ALL” spam? Me thinks not). Moreover, I then gave my opinion on ‘the importance of forms in terms of UX’ (again… “ALL” spam? Again, me thinks not). Thus, I feel your “all spam” label is unwarranted. But I’m not interested in flame war or to invoke trolls. Your opinion is your own and I respect your right to have it.

      Regarding jValidate: I created ” j ” Validate (a plugin for use with jQuery)… not ” JS ” validate (which my research indicates uses the Prototype and Scriptaculous JS libraries). However, JSvalidate is very well put together validation script; I tip my hat to the creators.

      Regarding Self Promotion: It’s the Internet. Nuff said.

      Regarding Form Size: Check out jValidate’s code. Notice that the ‘scroll user to error for correction’ would be especially useful in the case of long forms that require a user to fill in 20 or more fields. However, it’s great for any size form; and the one on RMDLG.com simply gives a demo of jValidate’s mechanics (yes, I know… more “self promotion.” Did I mention we’re on the Internet).

      Regarding HTML Feildset Tag: steve42, you bring up an excellent point. I commend you for this bit of insight. Nice addition to the thread.

      0
  10. 16

    It’s kind of a nice approach, however not displaying the other fields, which are correct you can’t change them afterwards. An example here to show what I mean:

    I filled out the form with an address and a name. Now the form doesn’t recognize the zip-code I was entering. What happens? All fields except the zip-code fields are disabled. So as the form does not recognize my zip-code I want to enter another address, for example the one of my parents or something. No I can only provide a new zip-code, however the street field for example are not shown anymore. I’ll have to use the back-button in the browser to begin filling out the form from the start.

    I hope you understand what I mean. Your technique is really useful in some ways, however in critical forms, I would never do that. Because the example that I gave, would frustrate the user even more, than just seeing the whole form again, where 90% are correct.

    5
    • 17

      Christian, Baymard Institute

      June 28, 2012 1:02 am

      Hi Alex, I see that the article is a bit vague on this point. Sorry for that.
      If the erroneous fields belongs to an array of data (like an address or a credit card) all those fields are of course to be shown as the “error fields only”, only the fields completely unrelated to the erroneous field are to be removed. Just like with the mock-up example, here both email fields are displayed (no just the “retype email field”).

      0
      • 18

        Yepp, I can cope with that solution: Showing error-fields and other fields belonging to that group.

        I’ve eventually found another solution to address this: You could hide the correct fields, but offer the possibility to show them on click or something. I mean there’s enough javascript-animation-magic, which can help us with that.

        It would highlight the erroneous fields by showing them from the beginning, but you would also have the possibility to correct other fields, by expanding them/fading them in, etc.

        0
  11. 19

    A few years ago I started using the “error fields only” approach. I usually combine it with a modal dialog.
    I found that the number of abandoned forms after first failed validation has decreased. The modal approach combined with only one or two fileds somehow feels as a more logical next step to users instead of a step backwards (repetition).

    0
  12. 20

    Christoffer Vittrup Nielsen

    June 28, 2012 12:55 am

    Great stuff! Small things that really matter for the end user!

    0
  13. 21

    nice article, i am currently appointed to work with a form system, some points helped me to reconsider the UI design.

    0
  14. 22

    I like the inline method, however would this method be accessible to screen readers? This group of users finds having a warning at the top with a link to the error most helpful.

    3
  15. 23

    What a great thought; I normally validate using HTML5 or jQuery.validate with a server side backup that returns the user to the form with the present errors outlined in the form – all their data is saved.

    This is a really nice way to do it and I’m amazed that you don’t see it everywhere! Good observation.

    0
  16. 24

    Good article. But even the worst example here is WAY BETTER than those sites that have you fill out the ENTIRE form again just because you made one mistake, or you missed the captcha. I still keep running into one of those every once in a while.

    5
  17. 25

    Caroline Jarrett

    June 28, 2012 2:44 pm

    Great article.

    Kathryn Summers of the University of Baltimore has been campaigning for the ‘errors only’ approach for a long time. She researches best practices for designing for people with low literacy, and found that ‘errors only’ was the only successful approach for them.

    Low literacy is a very common problem in the US and many other countries around the world, but if you think that maybe your particular form doesn’t need to cater for people with low literacy, then consider that in the ‘Design to Read’ project we discovered that there are many reasons why people with normal levels of literacy may in fact be reading with reduced ability for temporary reasons e.g. when reading in a hurry or stressful conditions, while trying to deal with external events at the same time as your form, or when using a mobile device.

    6
    • 26

      Christian, Baymard Institute

      July 1, 2012 11:41 pm

      Hi Caroline, I’ll do a read-up on her research. Thank you for sharing

      0
    • 27

      Caroline that’s a really good point… Probably something that a lot of people don’t consider with form design.

      0
  18. 28

    Great article Christian! After reading this, I immediately adapted this approach for mobile. This turned out to be a huge improvement for our validation, and I expect it to lower our bounce rates significantly.

    However, there is another solution for the address field problem. You could add a submit button just for the address field. So you enter the address, and press “look up address” (or something like that), with some immediate feedback. I would prefer a solution without a button in this case, but it’s still a better than the traditional way.

    0
  19. 29

    This is a brilliant idea!

    So simple! Cant believe I’ve never thought of doing it this way before.

    0
  20. 30

    “When getting the exact same page but with an error message, the user will feel they have made little or no progress, despite having typed 90% of the form fields correctly.”

    Is there any research that confirms this? If the form says there’s (e.g.) only one error-field then I would think I did a pretty good job.

    The other problem that you are trying to solve is identifying the fields in the form that didn’t pass validation.

    I like the error-fields-only approach, but I wouldn’t show the error fields on a new page or in an overlay. Showing the error-fields on a new page is the same as saying to the user (after he pressed the submit button): “Hey, here’s another field to fill out because you failed to fill out the previous form correctly”. Also the user loses the context of the first form and must process the information on the new page. This information load is unnecessary.

    Just an idea: can’t you show the fields that are filled out correctly as labels instead of fields? Then the error-fields will visually stand out more.

    In any case, it seems like your trying to solve a usability problem for forms with a lot of fields. I definitely see the value of this article, but if you’re goal is to increase conversion then I think you gain 80% by reducing the number of fields, and 20% by increasing the usability of the form. No research to confirm these numbers ;)

    0
  21. 31
  22. 32

    Errors-only is a provocative idea and definitely one worth getting some hard data on, especially across different contexts.

    Rather than posing the question as: “Should we show all fields or only the ones with errors?” I think the better question is: “What’s the best way to show the form-filler what they need to do to proceed while keeping abandonment to a minimum?”. The answer to the latter question can obviously change depending on the form (short/long, simple/complex, single-page/multi-page etc), the target user population, and other aspects of context. And whatever we believe the answer to be, it also must be confirmed through user testing.

    For example, for a 5-field registration form, I might go into user testing with an error-only approach, tailored for each type of error that can occur. For the Staples form above, I’d go into user testing with the error-only approach but also a version of the “Optimized” mock-up with some further design optimisation*. For a complex form, I may not test an error-only approach at all, because the fields are too dependent on context.

    Jessica Enders
    Principal, Formulate Information Design

    * If anyone’s curious, further design optimisation options I’d look at applying to the Staples form, to make errors easier to find and correct, include:
    - Shading the whole of the error summary box at top of form.
    - Applying the same shading to the error fields (e.g. the text boxes themselves).
    - Using the exclamation icon on both the error summary box at the top of the page and against each error field.
    - Presenting both the email address and retype email address labels in red, to indicate the problem is related to both fields.
    - Moving the error message to underneath the email address field, so it is more closely associated with it and within glancing range.
    - Changing the error message to “Email address and retyped email address do not match”.
    I appreciate that some of these things may have not been incorporated into the design shown here just because it was an example. I present the further optimisation options as an illustration of just how many tools there are in our kits, as designers, to maximise usability.

    2
    • 33

      Christian, Baymard Institute

      July 1, 2012 11:35 pm

      Hi Jessica,
      As always, great additions to keep in mind. I agree on your reflections about the error validation technique might being context specific, if you go ahead and do some testing before we get the chance/time, do let me know.

      Thank you.

      0
  23. 34

    Nice idea, however… If I were filling out a form, especially one that was somewhat important, like with my mailing address, credit card info, etc. and I happened to generate an error, I’d prefer to see the form in its entirety so I could double check everything else. Otherwise I’d be second-guessing the rest of the info I entered. Email addresses, for example, aren’t checked to make sure they work – only that they’re in the proper format. If i accidentally type xxxxxy@myemail.com it would validate, but it wouldn’t be correct and I wouldn’t receive any information.

    I think with the more important forms, it’s reassuring to see all that I’ve already entered again to eliminate any kind of second-guessing.

    I do like this idea though, and I think it’ll work great on smaller, less complicated forms. Good read, thanks.

    @ux_chris

    -1
  24. 35

    Efren (@mimojito)

    July 2, 2012 2:30 am

    I guess I know what project I’ll be working on next at Staples! It’s like moving a mountain one pebble at a time. Thank you, Christian for giving me some ammunition.

    1
  25. 36

    Very well written and informative!

    Inline Validations are the best as they tell user about the incorrect data as soon as the user moves to the next field. This is the most usable technique plus saves the time of the user too.

    Cheers

    0
  26. 37

    Good discussion here! That idea could work for some things. Still, everybody doing this should be careful: with complex forms, some things are linked.

    Let’s say you’re doing taxes. You have one field that wasn’t filled correctly. The label says “costs”. But costs for what? You have a lot of fields with similar type of information and the automatic error field only shows the field error, separated from the context. Many times labels are designed to make sense when they come after certain other fields. If the context was taken out, the single label might not offer enough information for the user.

    To iterate on this promising idea of showing only error fields: What if the user was shown the group of fields where the error field was in. Something like this:

    “This is your account information. Something went wrong here, could you check this again, please?”

    Then maybe you have 5 fields with one field waiting to be fixed. More fields, yes but in some cases easier to fix because of the right context.

    In my opinion, everybody should do live validation. It’s just not up to the level of UX expectations to make a user wait for a page reload. Everything can be done dynamically by ajax requests. If a bunch of fields need to be validated together (like with credit cards), the whole group can be dynamically checked. Just remember to add a spinner because sometimes it may take a while.

    Another idea: What if we utilized inline validation for form sections and cleared a section at a time. Example: you have a travel insurance form that’s divided into sections travel, information and contact. All could be in one page. After you finish a section, the whole section is minified and get’s a check mark. Then you know you can move on to the next section. The form would be instantly saved instead of waiting for the whole page to be completed (which normally happens only after the user clicks “continue”). I know that requires some coding skills to pull off but if you make millions with one form, it’s worth investing.

    Also one problem with long forms is that the user doesn’t always know if there’s a better fitting input field on the next page. This is true especially to surveys. Of course the problem is bad form design in the first place.

    Sorry, got a little carried away. Good post, good ideas – keep it coming!

    2
  27. 38

    I Disagree. Better to show the entire context of the error state rather than isolating the invalid fields, especially if they are interrelated.

    0
  28. 39

    On a side-note: the “errors-only approach” is not just suitable for form validation, but for the whole programming spectrum as well. In my regular source code (eg. PHP 5), I’m always testing whether something is NOT the case (= false), instead if something is true. This also helped me overcome a truckload of race conditions that could have happened to my programs, and some which actually did happen in the past.

    cu, w0lf.

    0
  29. 40

    Like the approach which I think I’ve encountered once before. One major issue I have is that it may neglect a psychological factor. I’m quite sure some (perhaps many) people would end up on the EFO page and start doubting themselves:

    “Ooh my, I made an error. I’ve made 1 , so I might have made another one the website didn’t notice (wrong phone number which perhaps?)”. Let’s go back to check if all is correct.

    When you let the user stay on the same page you give him the chance to quickly scan all fields and submit the page again. The website might notice when I miss one number, but it won’t tell me that it is not mine.

    0
  30. 41

    Tnx for the article Christian.

    Site consistency is also something to investigate. How do surfers respond when different forms on the same website handle errors differently? Can this be an issue?

    Regards
    Gino

    0
  31. 42

    The main problem I see with errors-only validation is what if the user needs to change other parts of the form due to failed validation on another? For example, if their credit card details failed validation (could be incorrect details, or a declined transaction), they may need to change their billing address… Or if their email address failed on a registration form (maybe they’re already registered), they may want to put a different company name or password which is usually associated with that email address.

    To me this method also seems counter-intuitive as you’re telling the user something is wrong, but giving them back an unfamiliar page. We would be changing the whole context in which we’re asking them to correct their mistake(s). If I’d make a mistake I’d prefer the opportunity to rectify it under the exact same situation, one with which I’ve already become somewhat familiar.

    0
  32. 43

    The main problem I see with errors-only validation is what if the user needs to change other parts of the form due to failed validation on another? For example, if their credit card details failed validation (could be incorrect details, or a declined transaction), they may need to change their billing address… Or if their email address failed on a registration form (maybe they’re already registered), they may want to put a different company name or password which is usually associated with that email address.

    To me this method also seems counter-intuitive as you’re telling the user something is wrong, but giving them back an unfamiliar page. We would be changing the whole context in which we’re asking them to correct their mistake(s). If I’d make a mistake I’d prefer the opportunity to rectify it under the exact same situation, one with which I’ve already become somewhat familiar.

    4
  33. 44

    Good job on this. But – in my opinion – you have forgotten about one of the most visually error indicating technique. I am talking about highlighting (I have always chosen red) the form labels in various ‘visible’ colors in case of errors. That won’t ‘create’ error labels so your site will be still neat and tidy.

    Regards and keep it up!

    Raphael

    0
  34. 45

    Cool idea on progressing with specific errors page but its only useful if you want users to submit the whole form first. You are mistaken about several things. First off, inline-validation stops you from submitting if anything is wrong. It also uses AJAX to do these “remote” validations so even credit cards can be checked inline. If Javascript is turned off, however, I agree that specific error page is a good idea.

    0
  35. 46

    This is brilliant.

    0
  36. 47

    The Live Inline Validation does not take into account fields that are left empty. If I skip 12 fields, I’m still going to have to fix them after submit.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top