6

I think that error pages should be more interesting and more independent. Github has some great guidelines for error pages and some great examples - See Here

The problem with the current error pages is that they are not independent. They rely on many resources. Take this 404 page for example:

Screenshot of Resources

As GitHub puts it:

Error pages should be built such that they require zero scripting, zero javascript, and zero dependency on anything whatsoever. That means static HTML with inline CSS and base64-encoded images.

The current error pages violate almost every one of those guidelines.

Now, I'm not suggesting that we turn the whole site into GitHub, but simply that their guidelines for error pages make perfect sense.

However, it will be a challenge to follow their guidelines with the current content of error pages. For example, for questions that have been removed, the error page contains links to similar questions.

Please comment with your thoughts and Thank You for your time!

0

2 Answers 2

4

I think there are different kinds of error pages and one size, as it were, doesn't fit all here.

We probably could go a bit more lightweight on the actual "something went horribly wrong" error pages, but I'm perfectly fine with making "this question has been removed" pages as "heavy" and as helpful as possible since they're not errors per se.

2
  • Cool. I was slightly more focused on the independence of those webpages. As you can see from the screenshot, there are many resources that are linked from the error page. This is okay for 404 errors where you know that the question was deleted, and there are no serious problems. But for more serious errors (500), you might want to consider a lighter weight, more independent error page. Might I recommend a unicorn for the 500 error?
    – Andrew
    Nov 9, 2013 at 6:11
  • 4
    @SantaClaus Unicorns are always a safe suggestion to make around here. :)
    – Adam Lear StaffMod
    Nov 9, 2013 at 6:12
3

I disagree with those guidelines.

Yes, error pages (for real, unexpected errors, like 500 Internal Server Error) should not rely on JavaScript, CSS and images. No discussion there. But as long as the error page gets the message through, even if in an ugly way if that page fails to load some static dependencies or the browser doesn't do JavaScript, then that's fine with me.

As for Stack Exchange, I am even very much in favor of adding JavaScript history.pushState trickery as a simple fix for the reloading problem. Not required to get the message through, but just a bit more user friendly if it works.

2
  • This goes with "One size doesn't fit all". I agree that many error pages (Like 404) need javascript, images, css, etc to get their point across and make the error as easy to cope with as possible. Are the something went horribly wrong error pages for 500 errors?
    – Andrew
    Nov 9, 2013 at 14:56
  • 1
    Yes, that stackoverflow.com/error is shown for 500 Internal Server Error problems and the like, @Santa. So even for those situations I don't agree with GitHub's guidelines. Of course, it's nice to show a good looking 500 error page, and I wouldn't object to such implementation. But getting it right would not be my main concern. Even more: if adding a bit of JavaScript makes them better for most users, then I'd happily add that.
    – Arjan
    Nov 9, 2013 at 15:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .