Planning Your Error Pages PHP Help

When you were creating the page that shows user profiles (page 196), you began with HTML. You created a mock-up of a simple page and then added PHP as you needed it. There’s no reason to abandon that approach here, because you’re basically trying to do the same thing. You want a nice-looking page for displaying errors, so before you start digging into PHP, get the page looking just right.

Create a new HTML page and call it show_error html. You can begin with the same structure you’ve been using for all your other pages:

When you were creating the page that shows user profiles (page 196), you began with HTML. You created a mock-up of a simple page and then added PHP as you needed it. There’s no reason to abandon that approach here, because you’re basically trying to do the same thing. You want a nice-looking page for displaying errors, so before you start digging into PHP, get the page looking just right.

At this point, you have an empty shell (see Figure 8-3), and it’s time to get to work.

Planning Your Error Pages

Planning Your Error Pages

What Should Users See?
Here’s your first question: what goes on this page that helps your users? To answer that, you really need to think about two things:

1. What information does your user need when an error has occurred?
2. In what tone does that information need to be communicated?

TELL YOUR USERS THAT A PROBLEM HAS OCCURRED
The should be pretty obvious. Something has gone wrong; your user needs an explanation. But even in that. there’s nuance. Should you print out an error that looks like the one here (which is the sort of thing MySQL might kick back to one of your scripts)?

#1054 – Unknown column ‘firstname’ in ‘field list’

Certainly not. Unless the user is a MySQL or PHP programmer, this isn’t helpful at all. Ideally, you want to translate that into normal human language, like the following:

We’re sorry, we couldn’t locate the user’s first name.

That’s much more readable, although it still doesn’t give the user much to go on. “Why couldn’t they fine me?” he might ask.”Is my record missing? Is my first name in the system? Uh oh, has my record been deleted? What’s going on?!?”

Maybe that error needs to be just as readable, but a lot less specific:

We’re sorry! There’s been an error processing your request.

Now, that’s something most people can understand. Things can go wrong, and something has. The details aren’t really relevant for your users; your job is simply to communicate a problem.

BRING DOWN THE PANIC LEVEL IN THE PROCESS
By now, you’ve figured out that, in terms of information, your user really just needs to know that a problem has occurred. Details are probably irrelevant and could even potentially create more worry rather than less. But what about that second item:

In what tone does that information need to be communicated? This sounds pretty touchy-feely, and in fact. it is You’re dealing with human users, and that means human emotions. People become annoyed when the web application they’re using throws up errors, and although you can reduce the stress and frustration, you can’t get rid of it altogether.

Regardless of what you say when problems occur, you need to think about how you say it. A stern, bland error message isn’t as comforting as a casual, conversational one. Sometimes you can even add in a little humor. Take a look at Figure 8-4 for one way to turn a problem into a conversation point. You can almost bet that a user who lands on this page-error or not-is going to come back to the site.

BRING DOWN THE PANIC LEVEL IN THE PROCESS

BRING DOWN THE PANIC LEVEL IN THE PROCESS

Going full on with humor might be a little strong for your example site, but at least ensure that you use conversational language. Just getting away from the stern sounding, “Error 1282: An exception has occurred” goes a long way.

For example, make a few conversational improvements to your error page mockup, as in the following example, and notice how quickly this becomes a little more palatable when the inevitable error occurs:

BRING DOWN THE PANIC LEVEL IN THE PROCESS

This text doesn’t say much more than “Yes, we know a problem has occurred, and we’re working on it.” Everything else is about presentation: conversational words, an image to break up the cold page (which at the end of the day still does say, “Hey, sorry, something’s broken”), a contact link for email, and another link to revisit the offending page. (If you do invite users to contact you with problems, be sure to follow . through. See the box on page 228).

The error page in Figure 8-5 is a heck of a lot less annoying than that in Figure 8-3, and it took no more work to produce.

BRING DOWN THE PANIC LEVEL IN THE PROCESS

BRING DOWN THE PANIC LEVEL IN THE PROCESS

Over-Promise at Your Own Risk
Nowhere other than error pages is it easier to over-promise and under-deliver. If you tell a user that you’re looking into his problem, you’d better be looking into it. If you’re going to supply a contact email address, ensure that it’s real (yes, lots of times error pages have Old, outdated addresses) and that the email actually gets to someone who will take care of the problem.

If your user thinks you’re dealing with her issue, and she comes back in a few hours only to get the same error, all the clever images and language in the world won’t keep her invested in your site. On top of that, she’ll be annoyed not just that something went wrong, but that you lied (well, at least in her eyes) about working on her issue.

If you’re just getting started or have limited resources, you might do well to simply state that you get notified when errors occur, and you usually fix problems within, say, 24 or 36 hours, or within some time period to which you can really commit. You might also give him an email address to use if things are urgent-but only if you watch your email! Another option is to preformat the email with something in the subject line to look for, like “URGENT”or “ERROR.”You could even set a rule up on your email client to highlight such messages. Whatever you do, make sure that your responsiveness matches • what your error page promises, or you’re going to have a lot more than a programming problem from which you’ll need to recover.

One more bit of advice as you begin working in large companies: never let the marketing team write the error page text without supervision. The job of marketing people is to sell and promote, and if error pages are the easiest place to over promise, marketing is the easiest place to over-sell capability. Get someone who is good with words to help you in crafting your error page, but ultimately, you’re probably the person fixing problems; be certain that you can back up what ends up on your error pages.

Know When to Say When

You are now a capable PHP programmer, and you might have some other clever ideas as to what could go on this error page. You could grab the user’s information from the database and personalize the page. You could set up a table that contains error codes, and associated with each error code, a helpful error message that’s easy to read. Then when an error occurs, you could look up the error code and print out the corresponding error message from the database.

It’s true that all this (and anything else you might come up with) would make for a pretty slick error page. But these are ideas that require fairly complex programming in and of themselves. There’s a database to connect to and queries to execute. And every time you write a query, or connect to a database, you introduce the possibility of another error. Where do your users go when your error pages have errors?

As a rule of thumb, you want your error pages free from as much programming as possible: they shouldn’t interact with databases, and they shouldn’t be fancy. To put it simply; if your error page can cause an error, you’re in trouble.

Posted on January 11, 2016 in When Things Go Wrong (and They Will)

Share the Story

Back to Top