- [Instructor] In this segment,
we're going to look at good practices
for constructing error messages.
It is so important to not expose code
or technical details in error messages,
because they could be used for reconnaissance purposes.
But that being said, error messages have a purpose,
which is very often to help users
understand what went wrong.
So ultimately, we need to find the way
to balance exposure and usability.
So I wanna share with you some best practices
for writing good error messages,
with credit to Saadia Minhas who wrote an excellent article
in uxplanet.org on how to write good error messages.
Now bearing in mind through all this
that we wanna make sure that we're honoring the constructs
of input and output validation,
and that we're not exposing any unnecessary details.
At the same time, we're looking to make the experience
a really good one for the users.
So let's look at some of those best practices.
Our first best practice is that our error messages
should be short and meaningful.
If you look at the message on the left hand side
where you see the green circle in the check box,
you can see an email field and the instructions are,
"Please enter your email address in format
yourname@example.com."
Now we're assuming that the field was filled out,
it was filled out incorrectly,
so this is the message that's being displayed.
It's a precise and meaningful indicator
of the desired behavior.
Let's compare and contrast that
with the message on the right that says,
"The email address you entered
does not match the required format.
Please enter your email address using standard format."
But we never say what the standard format is,
so it's a long message, it has unnecessary details,
but it's missing the required information.
So short and meaningful error messages
are more understandable.
And in this case, we're asking for input
that's going to meet our input validation rules.
Our next best practice is clear and simple.
In this case we have a network error,
where the network connection is lost.
On the left hand side we're just being told,
"The network connection is lost,
do you wanna cancel or reconnect?"
The user's informed about the problem using simple details,
again, clear and simple, either cancel or reconnect.
Again, compare and contrast it
to the message on the right hand side,
"Network error, the operation couldn't be completed.
WDGeneralNetworkError 500."
Well, that may be revealing some details,
you know, to our bad guy
who's looking for reconnaissance clues.
On the other hand, it's not the least bit helpful
for our users, who have no idea what that actually means.
So in that case, you know, the user's not concerned
with the technical details of the error that occurred,
nor will they understand that, it doesn't help them.
But the first message, the message on the left,
the user's informed about the problem using simple language.
You know, technical details
make an error message more complex, certainly less usable,
and has the potential of exposure.
So clear and simple.
Our next best practice is to be visible and noticeable.
If you look at the message on the left hand side,
we're gonna assume that our user
did not fill out the city and zip code fields,
so those boxes are now in red with the relevant option
of what they need to do right there.
"City is required, zip code is required."
Again, we're not violating any of our rules,
we're asking for that information,
and it's always better to display error messages
along with the relevant options.
Look at the right hand side where we have,
"City and zip code is required."
But that's up at the top of the form,
and the user will take a while
to relate the error message with options.
So it's a really good experience to provide error details
right along with the control or the field.
And our last best practice is to be humble and positive,
again, we want our users to have a good experience.
We have a name field, apparently it was skipped,
the user didn't put in their name,
and now we just say, please,
"Please enter your name."
The user's informed
in a humble, polite, positive way about the problem,
opposed to the box on the right hand side, which says,
"You didn't enter a name."
The error message seems to blame the user,
and if that message was in caps,
it would feel like they're yelling at the user,
and no one wants to feel like they're being yelled at
or insulted, all right?
We wanna be humble, we wanna be positive, all right?
We wanna be straightforward and simple, all right?
But we just want to inform the user
so they can do the next correct thing.
So quick recap, clear and simple, short and meaningful,
visible and noticeable, humble and positive.
Again, not revealing, no unnecessary details,
we don't wanna give any ammunition or any clues
to anyone who is doing a reconnaissance operation.
At the same time,
we wanna make sure that we're providing a great experience
for our user community.
And that's a closer look.