How to Display Input Errors?

[amy.damnit]

What is the preferred way to display data-entry errors on a form?

Here are some ideas I have...

Assuming a vertical form with labels on the left and Text Boxes on the right...

1.) Have red text appear next to the Text Field that has an error.

Telephone No: _______________ **ERROR: You must enter a Tele No.


2.) Shade the background of the Text Box to hightlight the suspect field and then have a generic error message at the bottom reading **Please complete the highlighted fields.


Of course Option #1 allow for more detailed error messages.

How do you guys handle this topic in your forms?

Thanks,


Amy

[sdavis2702]

Yay for number 1.

[DaveMaxwell]

Depending on the style/complexity of the form, I typically do number one, but I'll also throw in the shading for number two quite often. I find it draws the attention a little faster than just throwing the error message next to the field.

(moved this to a more appropriate location where it might get some more in-depth discussion)

[sdavis2702]

I agree. The reason why I chose #1 is because it clearly tells people what to do and it tells you with the text, which is always a good thing. However, when I am the one who has made the error, I quickly scan for a big red block like in #2. So I'm with Dave... both would actually be my preferred method.

[C. Ankerstjerne]

You should bear in mind that some people will not be able to see that the text is read (colour deficiency), and some people will not be able to easily scan the page to see the errors (screen reader users and users with a small viewport size, the latter being a rapidly-growing segment with the increasing number of mobile phones with good web browsing capability).

As I see it, a very good solution would be to output the errors like this:

• Create a text box at the top of the page, notifying that there was an error in the input. Make the text box stand out visually in a way which can be idenfitied by everyone (thick border, different background colour, dark red bold text, etc.)
• Make a list in said text box, identifying which form fields were not filled out correctly, but do not go into too much detail on how it was filled out incorrectly in this list.
• Make each list item a link to the specific form field.
• Write a longer text specifying how the form field should be filled out, and how it was filled out incorrectly. This text should have emphasis or strong emphasis (i.e. using EM or STRONG), should be labelled with 'error' or something similar, and should generally have the same visual style as the text box at the top. The text should be placed after the field label but before the field itself.
• Make a link after the incorrectly filled-out form field to the next incorrectly filled-out form field (is there is one) and the list at the top, with an appropriate link text (e.g. 'Skip to next input error' and 'Go back to list of input errors').

[amy.damnit]

Yay for number 1.

Okay, thanks Sean!


Amy

[amy.damnit]

Depending on the style/complexity of the form, I typically do number one, but I'll also throw in the shading for number two quite often. I find it draws the attention a little faster than just throwing the error message next to the field.

Good points.

That may be a bit over my head right now - I need to get this site done yesterday!

But, I can likely do this with Amy.com v2.0

I assume I'd need to know JavaScript and/or AJAX for that, right?

(moved this to a more appropriate location where it might get some more in-depth discussion)

Okay, thanks.


Amy

[amy.damnit]

You should bear in mind that some people will not be able to see that the text is read (colour deficiency), and some people will not be able to easily scan the page to see the errors (screen reader users and users with a small viewport size, the latter being a rapidly-growing segment with the increasing number of mobile phones with good web browsing capability).

As I see it, a very good solution would be to output the errors like this:

• Create a text box at the top of the page, notifying that there was an error in the input. Make the text box stand out visually in a way which can be idenfitied by everyone (thick border, different background colour, dark red bold text, etc.)
• Make a list in said text box, identifying which form fields were not filled out correctly, but do not go into too much detail on how it was filled out incorrectly in this list.
• Make each list item a link to the specific form field.
• Write a longer text specifying how the form field should be filled out, and how it was filled out incorrectly. This text should have emphasis or strong emphasis (i.e. using EM or STRONG), should be labelled with 'error' or something similar, and should generally have the same visual style as the text box at the top. The text should be placed after the field label but before the field itself.
• Make a link after the incorrectly filled-out form field to the next incorrectly filled-out form field (is there is one) and the list at the top, with an appropriate link text (e.g. 'Skip to next input error' and 'Go back to list of input errors').

Christian,

Thanks for the in-depth response! (Wow, someone brought their "Thinking Cap" today!!)

Do you have any visual - or better "live" - samples of what you described??

I think I follow you, but it would be much easier to see in a working website that you or someone else created!

Thanks,


Amy

[C. Ankerstjerne]

Glad to help - was nice to get a little thinking challenge as to what I'd consider a 'perfect' error page

I made an example of what I mean. It isn't live, though (to implement everything I suggest would require some fairly heavy server-side coding, but less can do it too). Just remember that the error messages should be obvious to everyone, both with and without visual clues, and you're way ahead of most of your competitors.

An alternative to the example I gave would be to only present the erroneous fields, but I wouldn't consider that a good idea. Despite assurances to the contrary, the user might still be concerned that the data is lost. Also, the user might realise that he or she mixed up two fields, of which only one had syntax checking, and will then be unable to correct the other field.

[amy.damnit]

Wow! Now that is a *hard-core* error-handling page if I ever saw one?!

Very interesting, Christian.

Thanks for the suggestions!


Amy

[AlexDawson]

Amy, I have a few ideas of my own...

Rather than go with the items above what I would suggest is that you firstly validate as soon as the focus is taken off of the text-box (rather than validating on submit) therefore at each stage of the process errors can be dealt with more easily and the user will be aware of the mistake immediately rather than having to revisit parts of the form. Secondly I would place the error message much alike you would find in an alert box (as it is how most people recognise a warning), I would directly under the element pop-up a yellow box (the color instantly has a feeling of warning) with an exclamation mark icon to the left hand side and the error to the right. Also a nifty thing to add would be to place focus back on the input box which contained the error (good for the visually impaired) and give the input box a different color background (NOT grey) to highlight the element needing editing (perhaps a pinkish red)... this not only eliminates the problem with multiple error messages but it highlights the issue as the person completes the task, draws their focus back to the element and offers an explanation directly below it which is noticeable

PS: You seem to get more (and faster) responses to your topics than anyone I have ever met on here

[amy.damnit]

Amy, I have a few ideas of my own...

Rather than go with the items above what I would suggest is that you firstly validate as soon as the focus is taken off of the text-box (rather than validating on submit) therefore at each stage of the process errors can be dealt with more easily and the user will be aware of the mistake immediately rather than having to revisit parts of the form. Secondly I would place the error message much alike you would find in an alert box (as it is how most people recognise a warning), I would directly under the element pop-up a yellow box (the color instantly has a feeling of warning) with an exclamation mark icon to the left hand side and the error to the right. Also a nifty thing to add would be to place focus back on the input box which contained the error (good for the visually impaired) and give the input box a different color background (NOT grey) to highlight the element needing editing (perhaps a pinkish red)... this not only eliminates the problem with multiple error messages but it highlights the issue as the person completes the task, draws their focus back to the element and offers an explanation directly below it which is noticeable

Alex,

All very good suggestions. (When I used to be a database developer, I used a similar approach on my forms.)

The problem, however, is at least two-fold... One, I am painfully behind getting this website done and if I don't wrap it up in the next week, I'll be out on the street and it will not matter. (Notice the increased number in my tagline... *sigh*) Two, I don't know Javascript and/or AJX yet, so all of your great ideas are down the road.

For now, my approach is to focus only on server-side data validation, which technically, is all you really need. However, being a "pretty coder/designer", I want to make things somewhat interactive and robust so my site looks top-notch, even if it doesn't use client-side technologies at this time.

Maybe I can "chat you up" - as I think you guys say over the pond - in later on, and we can revisit your ideas?!

PS: You seem to get more (and faster) responses to your topics than anyone I have ever met on here

Ha ha. *giggle* Must be my "sparkling personality"?! Not!

Probably because there are just some really nice and caring people on SitePoint that want to help. (Making sure I s-t-r-e-s-s-e-d my SOB STORY in the beginning probably didn't hurt either! Then again, financial ruin and being evicted is not a pleasant thought...)

Thanks for the help!



Amy

[C. Ankerstjerne]

Alex
I agree that client-side validation is an advantage, but there will always have to be server-side validation as well for those without Javascript. Also, not all browsers allow modification to input elements styling (but it can be a nice extra, assuming it's only an extra).

[AlexDawson]

Alex
I agree that client-side validation is an advantage, but there will always have to be server-side validation as well for those without Javascript. Also, not all browsers allow modification to input elements styling (but it can be a nice extra, assuming it's only an extra).

Of course, it's just that client-side scripting has the ability to offer "live" validation which in many ways is much easier and usability friendly than the generic refresh and highlight errors, if the user does not have to refresh the page it can be a real advantage in terms of going back over information.

[SpacePhoenix]

You should never rely on client-side validation as any data submitted by the user should never be trusted. User submitted data should be validated server-side for things like is it the correct type, etc.

You could perhaps use AJAX to submit the data to the server-side validation as you go.

[AlexDawson]

No-one mentioned relying on it, I was simply advising it's use for when it IS available, the server-side validation can still take place but the client-side could at least help reduce errors upon their creation. As for stating that any data from the user should never be trusted you are probably on your own there, after all if the user can't be trusted then the whole point of gathering information is lost as it's probably fake

[amy.damnit]

No-one mentioned relying on it, I was simply advising it's use for when it IS available, the server-side validation can still take place but the client-side could at least help reduce errors upon their creation.

As for stating that any data from the user should never be trusted you are probably on your own there, after all if the user can't be trusted then the whole point of gathering information is lost as it's probably fake

Sorry to say, Alex, but I have to take you to task on that last comment...

SpacePhoenix happens to be right on this point.

It is an axiom of computer security - especially on the web - that you NEVER trust any data provided by an end-user. NEVER!!

Any expert in the 21st century will agree with this security stance. There is just way too much that can go wrong if you trust input (e.g. SQL Injections attacks, SPAM attacks, Cross-Site Scripting (XSS) attacks, Database Hacking attacks, etc.)

Alex, you are correct in saying that having Client-side Data Validation makes a better user experience, and it also helps to ensure more accurate data - for those who are legitimate users.

Since I don't have the time to learn or worry about Client-side Data Validation, I won't worry just using Server-side Validation as I know it is safe.

However, the point of my original post was "What is thest way to make (server-side validation) look 'pretty'?!"

Good conversation!

Thanks,


Amy

[C. Ankerstjerne]

I don't think Alex is advocating a lax security, but rather is commenting that the validity of the information the user provides (e.g. correct name, age, etc.) should usually be relied on.

[AlexDawson]

Yes sorry, it did sound rather "off", I was assuming that it was a given that all data should be filtered for potentially damaging code or injected content which could compromise the sites security. My comment was in reference to trusting the information itself given by the users (and the reiability of such information)

[amy.damnit]

Yes sorry, it did sound rather "off", I was assuming that it was a given that all data should be filtered for potentially damaging code or injected content which could compromise the sites security. My comment was in reference to trusting the information itself given by the users (and the reiability of such information)

It's a dichotomy, so we are both right!


Amy

[Stomme poes]

Javascript validation is another reason I keep JS off. I hate popup boxes even if they're properly telling me I'm wrong, and once I hit a page where someone did it wrong... every onblur triggered the error message because it had onblur rather than first checking I did it right... one of the first times I turned Javascript off, this was back in my early days...
but I'm not saying don't use it, most users seem to like shiny flashy junk and on a long form it will catch the error sooner rather than later.

I totally agree with Christian's setup which is pretty much how I tried to get my colleagues to do it : ) They couldn't do everything I wanted so online is a half-butted version but here's our not-online version which does the same things, except someone insisted you couldn't see the tabby links so they're invisible unless you interact with them.

One thing I always have is some contact information appear if the form sends back a fault. Ever try to fill in a form and no matter what you do it's wrong? You're filling everything in correctly! Either you're having a brain fart or someone on the other end screwed up terribly, so ease the frustration of users by giving them some other route to go if they repeatedly fail.
Be careful validating emails. Usually validators are more strict than the email specs. You can have woah!man#--@foomanchoo.org even though many of the free-email companies don't allow those, those characters can indeed be legal. I know someone who's email address is just __@hisdomain.com : )

[amy.damnit]

Stomme poes,

Thanks for the comments.

I am torn about "fat-clients" and Javascript.

On one hand I am a zealot of front-end, real-time, data validation and prompting.

On another, I HATE pop-ups, spam, and most of the things peeople incorrectly use JS for.

I also hate investing time in code that people block.

(Now that I know Alex Dawson is a UI god and author, I'm even more torn!)

One thing I plan on doing is to HEAVILY advertise a conatct e-mail (e.g. "help@mydomain.com") or even a tele # so users don't get stuck if there is a flaw in my validation logic.


Amy

[AlexDawson]

(Now that I know Alex Dawson is a UI god and author, I'm even more torn!)

I wouldn't say I am a UI god, I just understand sensible design (that and I am good at critiquing stuff) , while stomme may not like validation the majority of people find it comforting to know everything is filled in appropriately, especially if they are making a purchase! Information is a valuable item and people don't usually like misappropriating themselves online or anywhere else. Of course some people want to ignore validation but those are the kinds of people who would rather avoid any kind of form filling. Generally my advice in your case Amy would be to use JavaScript validation alongside the server-side validation (as a form of visual assistance to backup the server-side feedback if errors occur), not to say everyone will have it available (or will turn it on) but it does serve a purpose and can be useful (though on stommes note I would add that you should be VERY flexible with the information - for example if taking credit card details don't just ask for numbers and report errors with anything else, as many people like dashes or spaces between groups), if you are flexible and conform to standards of how people input data, there shouldn't be a problem (and if there are a limited number of choices, make things easy and use a dropdown so they don't have to type unless they need to)... keeping things simple is the key, and whatever you do, only ask for the least amount of information possible, if you don't need a persons date of birth (For example) don't ask for it.

[Stomme poes]

Alex++

keeping things simple is the key, and whatever you do, only ask for the least amount of information possible, if you don't need a persons date of birth (For example) don't ask for it.

My boss has said for years now that whether our rates were lower for everyone or not, people were more likely to go with us simply because we asked for the least amount of information necessary. For car insurance, he knew he wasn't going to offer some different rate based on car colour or mileage, so unlike many other insurers, we don't ask that. Keeping the number of questions down is very nice for users.

(and if there are a limited number of choices, make things easy and use a dropdown so they don't have to type unless they need to)...

An interesting side: we have a lot of yes/no questions which to me normally would be radios, but my colleague stated that dropdown selects were easier for him (I don't know in what way, really) so I changed them all.

During a usability/accessiblity meeting of Fronteers, the speaker (forgot her name) stated that dropdown selects were an unnecessary barrier for some people. Either they'd get the focus on it and scroll down to the right choice, but then would get the wrong one chosen while trying to get to the next field, or people would be tabbing and typing through a form but tended to go grab the mouse for the dropdowns... according to her these tended to be seniors etc and it made form-filling more slow and difficult for them.

While it seems obvious to me that it's worth it to make stuff easier for most visitors at some expense to the back-ender, we never managed to move away from the dropdowns (again, yes-no questions mostly).

Re validation, I like validation just fine but I don't like it live. I want to be told my errors after I hit sumbit.

[amy.damnit]

I wouldn't say I am a UI god, I just understand sensible design (that and I am good at critiquing stuff)

But you're one of my heros!

while stomme may not like validation the majority of people find it comforting to know everything is filled in appropriately, especially if they are making a purchase! Information is a valuable item and people don't usually like misappropriating themselves online or anywhere else. Of course some people want to ignore validation but those are the kinds of people who would rather avoid any kind of form filling.

True.

Generally my advice in your case Amy would be to use JavaScript validation alongside the server-side validation (as a form of visual assistance to backup the server-side feedback if errors occur), not to say everyone will have it available (or will turn it on) but it does serve a purpose and can be useful

When Amy 2.0 comes out, hopefully I will know some Javascript.

(though on stommes note I would add that you should be VERY flexible with the information - for example if taking credit card details don't just ask for numbers and report errors with anything else, as many people like dashes or spaces between groups), if you are flexible and conform to standards of how people input data, there shouldn't be a problem (and if there are a limited number of choices, make things easy and use a dropdown so they don't have to type unless they need to)... keeping things simple is the key, and whatever you do, only ask for the least amount of information possible, if you don't need a persons date of birth (For example) don't ask for it.

I agree. I am all for simplicity and ease of use.



Amy