Taking a look at the error reports, a lot of times they are just from the user spamming the refresh button hoping their square peg would go in the round hole. Hopefully we’ll be able to show them the square hole or the round peg, depending on the situation.

For example – if you accidentally put your (non mandatory) telephone number in the zip code box and submit, when you arrive on the secondary page you are presented with the zip code box with your telephone number in it and are asked to change to a valid input. It is then the realisation sinks in that you maight have totally screwed the form up (but still enterede valid data values) – you search for the back button and it isn’t there…

I particularly like Robert van Hoesel’s idea of filtering the errors out on large forms, rather than having the user skip through the form to locate the errors – however I may worry about the missing fields not being presented in context, especially if they are similarly labelled.

Sometimes reading the the form where you have made one mistake – can allow you a second chance to correct something that has been misspelled elsewhere (especially if you have a habit of quickly typing in your address etc..)

qlkfk qslfkj zerpokljs dqfjlep q lqdskfjljopaezrlkjqdfj lqlfl qksjdfoiare lj kl qll qlkj lkqsdfjlk lkq lkqsj qslkjlk qlkqsfj qsdl

qs

I thought about point 9 in particular. Seems to me to be a holdover from the common rule of thumb that *form* errors should be at the top of the form. Even that’s not entirely true, but when you’re dragged back up to the top of a page so that you can’t even see the context of the error, that’s even more annoying.

Strikes me that the effort was to make the error message easily and neatly incorporate with their existing styling (which it does), rather than realising that the point of the error message was to help the user.

I think Joel (from above) made great counterpoints:) I think the most important lesson for me in thinking through error messaging is that it really is an often overlooked area of customer support that can move the needle quickly and significantly on your app’s bottom line.

That said, this is not a definitive guide or list, so I’d love you to add some of your thoughts, so I can keep thinking this through too.

In other news I couldn’t tweet this today, because my account was spammed last week and so now I get Twitter’s error message, “We’ve temporarily locked your account because of too many failed attempts to sign in. Please chilax for a few, then try again.”

Cheers!
CB

I think you’ve made all great counterpoints here:) I’ve worked on sites with small budgets, huge goals, and tech teams spread impressively thin (e.g. huffingtonpost.com in early 2008).

I wouldn’t say we were “lazy” by integrating error messaging into the browser. Rather, we made some tough, but strategic decisions to do so. Is it the ideal? Nope. It was a way to create a site standard and keep track of lots of moving pieces and goals for various stakeholders.

In a perfect world things might have been different . . . But, your points are well-made. Eventbrite has great newsletters and “how tos,” so I’d prefer to see them come out from behind the browser myself.

Thanks Joel:)

> “if you don’t have a customer support team or the bandwidth to craft unique messaging”

Or if you’re too lazy to build a website properly, perhaps ;-)

If you have a script which checks input on the client-side anyway (to make an alert box pop up) it hardly takes any more bandwidth to make your script insert the error message on the page as HTML instead. And if you’re not going to craft unique messages, surely you’re contradicting points #1, #2 and #9 in this article?

> “2.) prevents the user from moving forward or looking around without a clue”

It’s easy enough to prevent the user moving forward without alert boxes. Just use JavaScript to interrupt the form before it gets submitted, and add the error message to the page instead of triggering an alert. And if your error message is designed properly, there should be no chance of the user “looking around without a clue”

The other 9 points in this article are great tips for building professional forms to give your users a helpful, professional experience; I’d argue that pop-up alert boxes do the opposite of this, and make your website feel like it’s 1998 all over again.

Really good point. I am often annoyed by anything that pops out of a page. In this case though, I’m really recommending that if you don’t have a customer support team or the bandwidth to craft unique messaging that you leverage the browser for simple (sometimes soulless) messaging.

Using the browser’s alert boxes 1.) makes it look like it’s coming from the browser v. your app (this is good) 2.) prevents the user from moving forward or looking around without a clue. It’s familiar messaging she’s already used to seeing.

Cheers!
CB

If you’re suggesting using pop-up alert boxes to display errors, I disagree. Apart from the annoyance of having to click ‘OK’ to make the message go away, once you’ve done this it’s easy to forget what the message said, and then you can’t go back and read it. So it could cause accessibility problems for users with short-term memory issues (or anyone whose phone rings at the wrong moment.

Make your error messages obvious and helpful, and you won’t need to annoy your users with alert boxes.

If I said those unread messages were all from my mom would you believe me?

:)CB