Handling Form Errors and Validation with Alun Lucas

​

[00:00:15] Sani: Welcome to no hack show, a weekly podcast in which smart people talk to you about better online experiences. We have a very special returning guest today. Joining us to tell you all you need to know about making your web forms better by providing better error messages and handling validation in a better way.

Alan Lucas, welcome back to no hack show. Great to have you back.

Hey, great to be here.

Okay. So, uh, the first question, as I mentioned in the prep for this episode is how did you get into forms? Like, I want to know the story of Zuko and the story of you.

Okay. It's a funny one because obviously everyone asks that because it's forms a kind of a niche interest, although we would always argue they're super important. So I think the story of Zuko or Formissino as the company was originally known, uh, is. Basically form from frustration. The founders came across plenty of forms sort of 10 years ago now, terrible form experience, even worse than the nowadays.

Uh, and there was a desire, okay, we need to do something about that. It's almost like a mission. You know, forms have been imported from the paper world. into the digital world and no one had really done much in the way of improving the user experience. So I think Formissimo and then Zuko came out of that.

It's kind of a missionary zeal to make forms better by identifying and fixing the problems. So that's kind of where it came from. Myself, again, I'm not a forms or a UX guy. Historically, I worked in advertising for Um, I kind of got a little bored, wanted to spread my wings. So I went away and did an MBA.

And from the MBA, I did a little bit of a stint at Google. Then I did some venture capital. Um, from venture capital, I started working in startups and scale ups in, in the Manchester area in UK. After a couple of those, I kind of got the opportunity to come and work for Zuko. And it kind of made sense because in advertising, it's all about customer acquisition.

So it was kind of. A natural fit with that and my tech and investment skills to come on board. And I'll freely admit, you know, when I first came on board, I knew a bit about forms, but I was no expert, but certainly when you work for a company and you're looking at thousands of forms every year, you learn pretty quickly.

Patterns that work patterns that don't work and you kind of build on your knowledge and say you become a kind of forms geek um Which there are a few of us about but a lot of people kind of switch off when they talk about forms because it's just always the boring bit at the end of The process but actually if you mess forms up you've messed your whole uh funnel up.

So Getting them right is super important

And it's not a crowded niche, right? Even though, like you said, almost, almost every website, not every website, but almost every website has at least one form. It's like a house and a lock to get in. Like every house is good to have a lock. And if you build good locks, you're going to make a lot of money and people will need you.

So, so it was sort of a, you kind of landed on forms by accident. This was not something that you. 30 years ago, 40 years ago, you woke up and you were a kid and you said I'm gonna make better forms for everybody like there's nothing romantic like that.

No, there's nothing like that. I guess the company has a more romantic side, but for me, it was kind of falling into it, but it just kind of fit and say, when you get into forms, you kind of get passionate about getting them right, which is kind of what we've been doing at Zuko from the analytics side for many years, but we've also launched a form builder because people kept saying, well, okay, you do better.

So, okay, let's, let's do that. So we launched a form builder that tried to incorporate a lot of the

And to make it easier for people to do it. And this is what I wanted to ask you as well. 10 years ago, 15 years ago, everyone had to build their own form. Like you have HTML elements, you have PHP to process or whatever server side technology. Now there's a lot of solutions that can actually help you build a form.

So which one leads to more problems? Like building it on your own or just trusting a solution off the shelf.

learnings. Uh, classic answer. It depends. Um, so historically our Zico analytics customers, um, they've always built their own forms because they want control and you want exact control. And if you want to build the perfect form for you. You probably need to do it yourself because if you want to optimize and you've got a testing program, obviously you want a hundred percent control over the form. If however, you just want to build relatively simple forms or get it out there quickly, then a form builder is great because you can embed it on your website very quickly. You don't need to have a developer. Um, if you're not too complex, then it's a very quick and easy way to do it. Um, you can get more complex with it, of course, but say if you want, as we'll talk about today with error messages, if you want to start building your own custom error messages, it's a lot easier to do it yourself than if you've, if you've got a form builder, because a form builder has been built for, you know, broad, broad set of use cases, so it can't get too specific.

That's a, that's a very good answer. I think with any technology, with any CMS or any website builder, you know, the more broad appeal it has. The more generic it feels like that's just the nature of it. And it's not going to, it's going to work well enough for most people, but not perfect for any single use case, which has its downsides and upsides.

I guess I I'm more on the downsides there, but, but I guess. Um, it makes it easier for people to get into, into the websites and web forms. So, uh, yeah, let's talk about, let's talk about, uh, the main topic here today. And that is really handling errors and validating web forms. Uh, so how does Zuko help? And let's talk about the Zuko forms, the, the, the builder.

How does Zuko help with error messages in particular? Mm

uh, if we're talking about the builder that we built, obviously there's, there's patterns for error messages, which we can kind of come into about where you do it wrong, where it goes wrong. So we've kind of tried to avoid that and had have patterns that. In general, I know, obviously, you know, any experiment, experimentation person will always sell tests, say, test everything. Yes, well, I get that. But in the majority of cases, there are patterns that are smoother. And we've seen it to be smoother because we have the advantage of 10 years of observing forms based on data. So we can see. How certain patterns affect it. So Zuko has been built for, with patterns, uh, with Zuko form build has been created with those patterns in mind.

Again, I don't want to go into too much detail because I kind of, once we start talking about error messages, we can compare there, but things like using inline validation, giving feedback immediately. Um, putting the error message in the right place, making sure it's clear and using things like positive validation as well, as well as negative when there's an error, things like that.

Uh, and I think we've got one example I'll show you later, but then it's kind of, you know, we can tie into, but certainly the form builder, you know, we've created things that we want to, we're confident will deliver, you know, an optimum user experience in 99 percent of cases.

Right. But the, the key with the form builder is that you're using the data that you have collected over years and years and years of running ZooCoin, finding what works and what doesn't work with web forms. It's not just best practices. It's not guesswork. It's really data that that's supposed to lead to a happier solution for, for the user.

So. Let's talk about the error messages. And you know, when you talk about form error messages, I think you have to start with the native browser error messages because they're just there and you can't ignore them. Even if you want to, you have to do something about them to disable them. So what's good and what's bad about them?

Yep,

browser messages. So I'm just going to share my screen because, uh, just, we've got an example of people don't know. I mean, when you see it, you'll, you'll recognize exactly what you, what you see. Um, so if I can just share my screen first.

And I'll be honest. I've never used screen share on Riverside, so hopefully it works. That said, go ahead.

seems. Well, let's see. Right. I'm just going to share now.

Oh, perfect.

There we go. So, uh, I think we all recognize this big exclamation mark. Please fill out this field. And so what the browser will do, let's use Chrome as the classic example. It's got inbuilt validation, depending on the field type that it will, it will trigger on the standard stuff looks like this.

Now, obviously you can hook into that, uh, yourself with your own forms and use the, use the same validation and you can trigger the same messages or amend the messages, et cetera. So in terms of whether you should use native browser messages, typically we would say no, but they're better than nothing, I suppose is what the way I would see it.

Um, so. You'll be getting messages, but there's the issues with, though, the browser messages, you know, the positive size that they'll be translated into the local language will be great. The browser will know when something's typically invalid because they've been created for a broad use case. Uh, so they will be able to understand when something's invalid.

They're not going to have a incorrect validation on the downside, though. They're typically generic. You know, you can see here, please fill out this field, which I guess if you've got a blank field, there's only so many places you can go. But if you, if you go through all of them, they're all, you know, fairly generic.

I mean, there are, there are some, you know, some ones now that chrome is built in, you know, for things like email, which will give you a more detailed prompt. And I think we've got an example of this later, but they're also, Hello. Temporary they disappear very quickly, so they don't stay on the screen. So they'll they'll trigger.

You'll see it will go and what was the what was the error message? They typically only trigger for one field at a time, which is often one of the biggest issues you'll find. So, in this case, you might go, Oh, I've got to fill out the email field. I've got an error on the email. I'll do the email field. I'll go back to submit, you know, and they'll typically only trigger on submit as well, which is again on a long form.

You don't want everything to trigger on submit. And particularly if you're only doing one at a time, because what you'll find happening is people will, uh, you know, as I say, they'll make an error on the email field. They'll, they'll click submit. They'll go, they'll go fix it. They'll click submit. They'll get another error that we've not seen before.

They'll fix that. And they'll go down the form until they've done all the errors. It's very inefficient way of showing people where the error messages are. And so it's, uh, it's not great. Um, One of the other big things you'll find, uh, and if you want to build any sort of form, you'll, you'll often find that if you're trying to use a non native form element, this won't work.

And Uh, for those of us, well, we see this all the time because you'll often get developers who build dropdowns out of divs rather than using a native select element. So therefore you're not going to get any error messages. So therefore you're going to have problems with the native native browser messages.

Not to say they're completely useless, but we would always say, if you're going to build a form, do it right, create your own validation and your own error messages. You can use the native validation as part of that, but you need to be clear why you're doing it, what the situations are as well, if that makes sense.

so you need to be more specific, but this is something I learned from your slice It when you sent them a few days ago that only the first error message is shown I never really looked into that. I never noticed that but That is the most annoying user experience that you can imagine. Like, okay, I go back, I scroll on a long form, especially I fixed the field I submit.

And then it's the next field and the next field. And of course, that's kind of a, an edge case. It's not going to happen to everyone, but that is just terrible. And I had no idea this is how it worked.

Yeah, exactly. And I guess it's, I guess the validation in browsers is not been designed specifically to create the smooth form user experience. It's been created to deliver a validation. So really what you need to do is take that validation. If you're going to use it and run with it and use it to, to, to hook into your error messages.

Right. And, and like I said, non native elements just are not going to work period. There's nothing you can do with, with the browser validation to make them work. So I guess the, the, the beauty of handling your own error messages is that it's going to give the right error message, right place, right time, you know, and like you said, positive validation as well.

So, so what is the next thing that, uh, that, that we should be aware of?

Well, I think I suppose the, once you've, once you've got past the browser, which is to be obviously client side validation, there's still a broader question of whether you should validate error messages. On the client side or, or the server side.

What's your answer there? Is it either or? Both Depends.

So whenever I'm asked this question, I always get reminded, uh, how to get a little bit philosophical at this time, the Chinese leader Deng Xiaoping, I think he said a quote, it doesn't matter whether cats is black or white, as long as it catches mice. So in a way, it doesn't really matter as long as it does what you're supposed to, supposed to do.

He was obviously talking about capitalism and communism. So a bit deeper than, than forms, but I think you kind of just got to take it, uh, take each one for its advantages. Yeah.

Mm-Hmm?

Client, uh, client side is faster, but browser side obviously enables you to do validations you cannot do on the browser, just on the browser itself.

So typically I can use our example, we use for our own registration forms, we use a mix. So if it's a simple validation, like an email validation, it's typically done client side, if we're just talking about the formatting. So formatting, missed fields, any, anything like that is done client side because it's faster.

If we need to validate a user, whether they've already got an account or whether there's something deeper, that sort of thing, it obviously has to be done server side. So we validate that side. So, and I think most forms will probably be like that. If you can use client side. Then great. But in most cases, you'll probably need a element of, uh, of server side to do some deeper validation.

So it's kind of just like you've just got to take each, each case as it comes.

Right. And of course, in some cases, like you said, a browser is not good to know if that email exists in the database already. So. Hopefully the browser is not going to have that information in it because if it does, oh my God, you are in trouble. Like your website is as horrible as it gets. Uh, so yeah, go

so just one last point that my, my developers have made clear to me as well is actually also, you'd likely, you know, any sort of registration form or, uh, you're likely going to need some kind of server side validation because, uh, Otherwise you could get spammed to heck. If you can't validate people on the server side, they can essentially hit you, not necessarily through a browser, but build some scripts and you're, it's just unvalidated.

So it will just keep coming in and in and in and in. So you need some sort of server side validation, which is, like I say, not necessarily user experience, but just to protect yourself.

That's a really good point. And also, uh, one thing, uh, I'm looking at your slides as well. I don't think that's really important and we can see it in this, uh, this, uh, slide we're seeing now is that showing the error message where it needs to be shown. So that's kind of a, uh, what do you think about the forms that show you all the error messages at the top, like

Yeah, so, well, I'll show you, get an image for that as well, if I

How common is that? How commonly do you see that in, in, in, in the wild?

nowadays, not so much. It's quite old, but you still, we still do see it. So, I think one of the, yeah, one of the, the, the key basics of error messages is make it clear where the error is and make it obvious. You can see this, this isn't exaggerated, but it's a real example where all the errors are triggered at the top and you're like, you have to go.

Bottom to top, where is it and try and work out what it's telling you. So it's not common. Most people have kind of got over this bit. You still kind of get it or people put it in a different place. You know, they may be right, wrong. I mean, just to use another example, you know, make sure they know there's an error or where, you know, this, this one, it's a little more subtle, but it's like, okay, please answer this question.

Okay. Well, how, which question are you referring to? Is it this one? Well, I think I've answered it. You know, that, that sort of thing. You have any sort of confusion. You, you, well, uh, yeah, you have to be 100 percent clone. It's not that difficult to do. It's pretty obvious. Usually you just put it in the immediate space, you know, immediately above to the right, just below ideally.

And, uh, and sort of what we, we did with our patterns was have, you know, make sure there's, there's a red element to the left. Don't try and be too clever. I've seen error messages, which try and look smart, but actually people know that red is an error message. So if you just an error, just use what everyone is expecting.

Don't try and be too clever. Red, red text, um, potentially with, uh, you know, the use of an X is quite good here because obviously you have visually impaired people just to make sure it's like, okay, you know. Use that, be simple, make it read, put it next, make it legible and put it right next to, to where it is.

And writing the correct error message, the text of the error message, I think it's about as important as placing it where it should be. So, what's your number one tip for writing, and I have an idea what you're going to say, but what's your number one tip for writing a good error message for a form field?

so it's, well, this is kind of two, but it's specific and helpful.

Okay.

So in

And not too smart,

yeah, not too smart, but, but just be, I mean, not too generic, just be

Right.

as specific as you can and be helpful. So if someone's got an error message, the thing they need to know is why they've got an error message and how they fix it.

So just some examples here, we've got some on the left. Some on the right, which sort of a different types. So if you look at the bottom left there, there are validation errors. This is the worst type of one. It's just like, it doesn't even tell you anything. It's like, Whoa. I know nothing. You people will leave and go out the one above it, you know, it does give a little bit more information.

Invalid email address must be within validation rules. Okay, what are the validation rules? Email address? You might be able to guess. Obviously, it's not dot com, but actually, if I had said you need the dot com or dot whatever, that would have been much more helpful. So interestingly, on the right hand side, we have got a native browser one, which is a little more helpful for email address, which is a Please include an at in the email address.

So More helpful, even more so below. Uh, and this is an interesting, more advanced validation rule. So someone's putting a hot nail. It's where you, you build in a common misspellings, et cetera. Again, you use it in an email a lot. It's just like, okay, did you mean this? And actually that's very useful for, um, it's technically not an error message.

It's more of a validation message because it might not be an error. But essentially, it gives that little additional layer of helpfulness. So the more specific you can be, the better and just help people to get over the hump. One of the issues you have as a UX person is Sometimes you're at the mercy of your, your devs and your backend.

So what, one of the things we'll come on to is, is sort of accepting, be as flexible as you can with it with formats, but sometimes. You've got a database, like, we'll talk about phone numbers, it's a very common one

Right.

in the future, but actually phone numbers, you might have a database which does not accept any, any spaces. And ideally, that's a bad user experience, it's a specific point I'll come on to, but sometimes there's just nothing you can do about it because it's the way the database has been built. So you just need to guide the user. So that's where you are very specific. Firstly, and again, something we'll talk about is avoiding error messages in the first place.

Ideally, you should tell people, you know, please use no spaces, but assuming someone puts in five numbers, space six numbers, which is quite a common pattern, certainly in the UK, then if you can't validate it because your data database won't validate it, at least tell someone, please delete. The space we've detected the space.

So you've got to try and build in a validation and errors that take, take that into account and tell people what the problem is and say, I,

as specific and as helpful as possible,

exactly. Ideally you'd have designed that out, but if you can't, you've just got to go, go further.

Right. Okay. This is, and, and I spent a portion of my career as a, uh, e commerce, uh, integration developer working on checkout pages. And I did a lot of checkout testing from different countries. Guessing the phone number format from every single country was the most annoying thing I had to do in my daily job.

It was, this country needs eight numbers, but it has to start with a four. In this country, it's nine digits, but it has to start with a two. Oversimplifying right now, but it is just, you, unless you were using checkout form or guessing the phone number format for different countries, you have no idea how different they can be.

It is just the wildest thing in the world.

exactly. I'm going to jump ahead a little bit. Cause we're kind of talking about it, but the best thing you can do is to be flexible on input. So this is not so much the error message to say it's out here. It's a, we've got an example here. This is a UK credit card provider. But basically.

Hmm.

Errors if you put spaces in it and and so that that's exactly what we're talking about is okay. What format should you use? Um, typically, what you would want to do is jump back and I'll I'll use the example here. Now, this is this is Zuko form builders to give you an example. This is what the interface looks like. Um, Is basically accept, just have a very basic, uh, validation that that means it's a phone number.

In our case, we typically say eight characters and let everyone else put it in as they see fit. So if they want to put spaces, they can put spaces. If they want to put dashes, they can do that. It's fine. The only validation in this case is at least eight characters long. So therefore, typically what you'll do is you'll, you'll allow for a much better user experience.

Now, what you'll have to do is at the backend, you'll need to. You know, either have some sort of formatting yourself or sometimes you just don't need to do that because often you ask yourself why are you using this phone number? Oh, someone needs to call them up in a certain circumstance. Okay. Well, this person's picked up the phone, they don't care whether there's spaces or dashes, they can read, they can use it, so therefore you're just, you're putting in a barrier which is not necessary for, you know, often the reason that there isn't a good reason, just because that's the way you've built it, and that's the way people, people have asked for it.

So yeah, so,

point. That's a very good point. Yep. Mm

interestingly, this specific slide wasn't about that point, but actually about something else, uh, and, and this is probably one of the biggest impacts. You know, once you've got your basic error messages, right, one of the biggest impacts is using live validation. So live inline validation. So typically telling people in, you know, immediately when they've made an error. Um, I want to say immediately, I don't mean as they're typing, because we've all had that problem where he's too early and you spit out an error when someone's putting in their phone number or email address. It's like error, error.

So I'm not even finished yet. It's when you focus out, okay. That's what you tell them immediately. Um, so in this case, you can see here, obviously I've talked about the phone number validation, so error immediately. Okay. You, there's ways to fix it here. So in this case, they can fix it. They get a green tick and an often positive validation is as valuable as errors because there was a study, um, Craig Sullivan, who I know you've had on the show, uh, he refers to, they, I can't remember the specifics, but they did a study of, of on positive validation.

So. Exactly the same questions. Someone gets a green ticket at the end of its positive. Someone gets no positive validation. And then they then asked about their form experience post that and they found the people who got the green tick tended to feel the form experience was better and less stressful because of the green. So

like you're cheering, basically like you're cheering on the user as they're doing it. Like, come on, you're doing a great job. Only 75 field left to go.

yeah, and sometimes it seems a little hacky to do that, but actually it works. So, uh, yeah. And I say, if you get Craig on again, I'm sure you can ask him about it. Cause it's a good story.

I will, I will send him a message after this just to ask him about that and maybe try to set up another episode. But yeah, that, that shout out to Craig. Like who, who, who doesn't love everything Craig is doing online? Uh, but, uh, I, I think it depends on what the form is. Like if you're filling a form to get a bank loan or something that, you know, you are, uh, obviously you have to do it, even if you hate the form.

It doesn't really matter as much because you'll do it. But if it's a form where The brand is trying to get the conversion rate for that form higher. And it's not something that you're selling something or you're getting them to sign up for something that they don't really need. I think this kind of validation and that kind of cheering on from the sidelines, I think it has a significant, it can have a significant effect on, on, on the overall conversion rate.

Yeah, exactly. No, it is also, you know, customers often have a lot of uncertainty about what they're putting in. So again, we go back to phone numbers, but phone numbers also, they'll be thinking, do I do have a space to have a dash? You know, those sort of things. Um, is it, is it right? Is it not? Um, you've got to be sometimes a little bit careful with some feels like credit card number because you get a tick because the validation is right.

But actually there will be some further devalidation when you try to pay. Doesn't mean that it's a valid credit card or it's going to be accepted. So you can be a little bit careful around there. But when it's just basic stuff. Okay. Okay, you've entered a number. Okay, you've entered a number and it's not, you know, you've not entered a load of letters.

Tick. That's, that's a great way of doing it.

That's a great point that, that, and also there's a, I think there's an input type telephone where you can set up the format of the field just to give that hint, almost like a placeholder text or what, you know, it should be three digits space and you know, it's total of eight digits, nine digits. But of course, uh, live inline validation on, on, on blur, I think is way better than anything else.

So

And there's, there's studies about this. I mean, we've seen it with, with our own sort of zico analytics customers, but there was a famous one. It's a few years old now by Luke Robleski, uh, who did it. And I think they saw like a 22 percent uplift in, in conversions by using it. Inline validation. Um, but so I can share the link to that study, but certainly in terms of user experience, it worked, worked really well.

that's very cool. Yeah. Uh, so, so what do we have next here?

So other things to do. So again, going back to kind of what you, what you talk about, the actual language, because I think one of the issues you often have, and this is going to be harsh to devs, but if devs write emails or they write error messages. They're very matter of fact, and it can't, you know, it's not really a, you know, great user experience on occasions, you know, I'm probably being a little unfair there, but we've all seen it.

So we've got examples of it here. So you don't want to be using languages, which is accusatory, you know, saying, Oh, you made a mistake. Um, so we've got examples here where you, there's you, you didn't, you, your, your zip code is incorrect. You've got to be a little blander there. You've got to be specific. Um, so for example, your login and password do not match or whatever, however you want to do, uh, do it.

But just keep it more neutral and passive. Don't, don't, don't say you made a mistake. Oh, you messed up there. It's your fault. You know, just, just try and try and specific and helpful as we talked about before. So that's an important one. Yeah,

as a former web developer, I don't feel offended at all. It's just a fact. It just how it works because when you're, when you have a task to write a, an error message, unless they write the error message for you, you're just going to state the obvious. You're this and this is not correct, period.

Uh, so yeah, uh, I think, I think developers have a point when they do it that way, but also from user experience standpoint, this is excellent. And this is where you don't want to make the user feel bad about what you're doing. Basically, that, that's a kind of the whole thing. So Zuko form builder handles all or most of this, right?

Is it out of the box or do you have to set it up for the fields? How does that

form builder is out of the box. Obviously, I say the messages are reasonably generic. They're specific to each type of field, but it doesn't go as deep as you might do if you created your own form and you knew the type of errors that were getting put in. But certainly in terms of the language, um, and the validation, it kind of covers that.

So, so, you know, it works well for, for most cases.

That's, that's really good. So how can people sign up and try Zuko form builder? Let's talk about that.

Oh, just go to the website. So if you go to Zuko, uh, Zuko. io, you've got obviously Zuko analytics. So if you've already got a form and you want to know where the problems are on your form, you use analytics. If you want to build and publish a form, there's a link Zuko form builder. Uh, you go through that, you sign up, it's a freemium model.

So you can, you can use all, pretty much all features for free, um, at a low level. And then obviously if you want to build up and use that more widely. Then, uh, yeah, there's, there's a paid version as well.

Right. And just to get back to the analytics, it works with pretty much any form. You just add the JavaScript code and then it analyzes it.

If,

the setup like?

set up for analytics, it's just typically two tags. So, uh, you put them on, uh, form load and a successful form completion. And then Zooko will go through and pick out all the standard form elements and the interactions. And then that will move into the analytics piece there. Um, so

fairly simple, right? You just add the text and Zuko takes care of everything else. That's very, very nice. It sounds really good. One more thing you have in your slides that I would like to touch upon. We're reaching the 30 minute mark here. Uh, so the micro copy informs now, do you consider this copywriting?

It's like a, a small area of copywriting that you need a special dedicated person to write the micro copy in your forms. What do you think?

don't think you need a specially dedicated person. You just need someone with common sense. I mean, if you've got experimentation people, they'll be used to doing that. Um, it's, it's generally, as I say, just common sense. So use microcopy to tell people what they need to do. So classic example is passwords.

If you tell people in your password, okay, you need to use a special character, capital letters. Tell them that first, they won't make the error. If you just wait until afterwards, then they'll tell an error. So it's just adding that hint text. So again, that's something we built into Zygo form builder, the ability to put that help text in.

Because it just helps. I don't say you don't need anything specialist. You just need to be clear as to why there's an issue. So, you know, it's just simple things here. You know, like use the billing address associated with your credit card That will just, you know, sometimes you think that's simple and obvious.

It's not always. We've all been in experiments, you know, just adding a small bit of instructional copy will will help you do that. So, uh, I think my, you know, I guess it falls into the theme, which I've got here, which is prevention is better than cure. If you can prevent error messages happening in the first place, that that's better than than, you know, Having good error messages.

So we talked about here form labels, make sure that the form label is clear, uh, be flexible in what data formats you accept. So that's the phone number. Don't insist on, you know, no spaces, um, use the microcopy. We've not talked about optional and compulsory, but be absolutely clear, which are optional, which are compulsory.

So people don't leave things blank that they shouldn't do. Um. Inline validation, absolutely fantastic. Always recommend using that. And then the final point there is, is kind of about defaults and preventing errors. So for instance, if you're, if you're looking, so a booking website, as an example, if you're looking for someone to book a holiday, don't let them try and book something in the past, which I've seen a few times creates an error, you know.

There's no need to do that. If they've got a return date, don't book your return date before your flight day out there. Don't let them select things. If you know they're

Wait, that still happens? You're still seeing examples of that happening in live

yeah, yeah, we do. Yeah. I mean, no, not quite. It's not common because there's, you know,

No, of course

they'll be using a plugin, but we still see you, you do it. I mean, it's, it's more than it triggers an error message and, you know, you don't need the errors. It's rare, but we do see it.

That is just crazy. Uh, so we covered a lot of, uh, a lot of things today. So, uh, uh, make sure the user know where the error is, uh, native browser error messages, visual cues, uh, specific helpful inline validation prevention. If you had to pick one, what is the one advice you would give to people to. Prevent or avoid most.

Or handle in the best way possible, most error messages in the form, but just one

I said live in line validation.

inline validation.

yeah, live in line. Like, I mean, obviously I'm assuming that you have got terrible. I've used obviously if your error message is absolutely terrible, then fix them. But if, assuming they're average and you're just like, Oh, how do I make things better? Inline validation.

So telling people immediately when they made an error so they can correct it. And obviously be specific as well. We're all lots of stuff, but the validation triggering at the right time in the right place is, is from our experience that has the biggest impact. Um, and it not just for error messages on a form as a whole, you know, compared to virtually anything you can do.

That's also positive validation. I think falls under that same category. Just let people know that they're doing well and they need to continue with the form. That is not what I would guess. I'll be honest, that is not a, I would have guessed just, uh, writing, uh, good error messages, just explaining exactly what the error is, how to fix it.

Uh,

But again, you mentioned that if the error message is bad, then the inline validation doesn't

Yeah. I think also, I mean, error messages, there's an element of people who will work out how to fix it.

yeah,

I think,

that's a good point.

it's tough. But I think if you're looking for something typically transformative, which people want to, if they come to us in the forms, okay,

Hmm.

what are you going to do? Okay. Do inline validation is probably have a bigger effect than tweaking your error messages, assuming they're not absolutely terrible.

That's from experience, but

Very interesting to hear. And, uh, nothing, nothing gets you upset like seven lines of red text at the top of a form. And that says just do it all over again. Okay. Uh, Alan, thank you very much for being a guest on this podcast. Uh, I will meet you in a few months, hopefully. And, uh, this was fun. Who's who thought forums could be fun, but you know.

To me, they are handling things like this and doing them properly is a lot of fun. So to everyone listening to this episode, I'm sure you've learned a lot about web form error validation and handling error messages. And if you found this useful, please consider rating, liking and sharing the episode and I will talk to you next week.