seanmonstar

Sep 23 2010
Jul 13 2010

Helpful Errors Messages Are Important

If you write software, you write bugs. And after those bugs, there’s still errors that will happen in code you didn’t get to touch. Errors happen. That’s not new. And users know that things can go wrong sometimes. What pains me, is that we know exactly what went wrong, and we don’t translate that for the user.

In Windows

It’s surprising to find how often you’ll find an error message that’s only helpful to the creator of the original system. So often as user, you can reliably create a certain error to happen, and the only message you get back from the program is something like Error 0x2211108: Don't do that. If we as software engineers would just take the time to make sure that every error shown to a user let them know what happened (if its useful, which it actually very often is), and any steps they can take to fix the error.

Some of the most terrible error message design is the infamous blue screen of death. It completely disrupts the computer (which could be acceptable, some fatal errors can’t be recovered from). But worse, it tells the user virtually nothing useful. Just a bunch of computer gibberish.

Disregarding how ugly the error looks, the Windows team could have at least intercepted the error and displayed a useful message. Here’s an example:

Original BSOD

original BSOD

Improved BSOD

improved BSOD

In Blazonco

A while ago, I went through and documented many of the errors that errors that might bubble up in Blazonco. We’ve created a help page for each error, which depends on its unique error code number. I also tried to make sure that all errors are in a language the user understands. Error codes mean nothing to most people, so we don’t display them. They’re only in the link that the user can click to learn more about1. They don’t need to see that I tried to reference a property of a null object, or that file system threw an error about permissions. Instead, I tried to catch all those, and throw a much prettier error.

cryptic SQL erroruser friendly error

We basically have a try/catch at the top most function of our application, which will try to show the error message in a graceful way (inside that little error popover). But it’s not in that top function where we convert gibberish into English. It’s done whereever a proper error could happen.

$post = new BlogPost;
//...
try {
    $post->save();
catch (PDOException $ex) {
    if($ex->getCode() == UNIQUE_CONFLICT_ERROR) {
        throw new BlogPostException('You already have a blog post with that URL. You will need to use a different one so people can view your post.', 40006023);
    }
}

We still throw an exception, because an error did exist, but we can show much more meaning knowing that it’s a BlogPostException, and the message is much more meaningful to the user than what the SQLSTATE would have said.


  1. We also log all errors that occur. That way, each morning, I can open up our Superadmin and see if a user has ran into an unexpected internal error, or if a lot of users are receiving an “excepted” error too often, suggesting a flaw in the UI. 

Jun 8 2010

At Least Pad the Default Button Styles

Some people like to style buttons to their own design, ensuring they look the same cross browser or enhance the site theme. Others are perfectly fine with a <button /> being rendered differently depending on browser and operating system combination. I understand both sides. Sometimes a styled button can look really nice. Other times, it just makes sense to leave it at default, because users are used to seeing buttons the way their OS always displays them.

As long as buttons have a consistent look across the site, I’d say both are just as usable. If you’re in the latter camp, leaving button styles to the browser, please, oh please, at least add some padding to the buttons. The default button styles leave the border right on top of the text, making it very annoying to read the text of the button.

Here’s a screenshot from Remember the Milk on the left, and my addition of padding on the right.

input[type="submit"], input[type="button"], button {
	padding: 3px 5px;
}

Just a few pixels, but the difference is huge. You can now read the text of each button with ease. Please, don’t forget the whitespace.

Jun 10 2009

Form Accessibility - Try Out Your Own

With web standards being all the rage, and accessibility being a major driving factor in people adopting standards, you might be surprised to actually check out the accessibility of web-sites. After watching a video of a blind user using Jaws, I figured to give using a screen reader a try just to see if I could understand it any better. I ran into a couple problematic areas; what caught my attention first was the use of forms .

When Things Were Right

When a form was built properly, I could easily understand what inputs a form had, and what input I had tabbed to. Quite simply, there were 2 tags the specifically improved the accessibility of the form for my screen reader: legend and label .

<fieldset>    
<legend>Personal</legend>    ...</fieldset>

When I tabbed to an input that was within a fieldset , and that fieldset had a legend , it would tell me. The above would read to me: “Personal grouping.” So if this fieldset wrapped up inputs like your name, telephone, and e-mail address, it would remind me each time that this input was part of the “Personal grouping”, so I knew I hadn’t tabbed to a new fieldset . Good.

<label>    <input name="personal:name" type="text" />    <span>Name</span></label>

For specific inputs, having a label did exactly as we would hope. I tabbed to the input , and it read the label and input type: “Name, text.” It specifically worked with the above example, when the input was inside a label . It would read the rest of the text inside the label .

When Things Sucked

I visited a few other sites that seemed to be using standards, and found that their forms performed far worse. It showed that using the correct structure for forms is actually very important . When a form used a simple paragraph before an input, with no label , guess what happened? Yep, it skipped it. When I tabbed to an input , it would just read me: “Text”. Hey, great. Any text? You got it: poop.

Yea, not good.

Even worse

Even if someone managed to make up information for these fields, or perhaps, say they did have labels on them, one more form feature that screwed my experience using a screen reader: captcha . Some implementations simply had an image above the input, with no alt tag, no possible way for me to ever prove I’m a human being. Minus one call to action.

Try Out Your Own

I’d suggest grabbing NVDA, and surfing your site, and pay attention to your forms. See if the way you made them makes sense to a screen reader. And then visit some of your favorite sites, try out their forms, and compare with their markup. It’s quite enlightening.