8

I know, i know, we should aim to handle all exceptions, but for those moments when it's just impossible... I thought of something like this:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

I showed this to a couple of technical people, and they immediately reacted negatively to it.

NOTE: Assume that the software can't connect to internet (hence we just can't send directly to our servers).

  • So are there any alternatives to this?
  • What are the pros and cons of displaying error messages like this one?
Improve this question
6
  • 1
    Which part did they react negatively to? Which part of the mockup do you want feedback on? The text or the layout or both or more?
    – rk.
    Jun 3, 2013 at 1:56
  • the stack trace... they say that it'd scare the users...
    – edgarator
    Jun 3, 2013 at 2:00
  • 3
    In what scenario are you presenting the error? What does the application do and who are the users?
    – rk.
    Jun 3, 2013 at 2:09
  • Generally, you should not show a stack trace to your users: it represents a potential security risk and, unless your users are highly technical, bad UX. What does Jim User care how some private method failed? See security.stackexchange.com/questions/19130/… and security.stackexchange.com/questions/4471/…
    – msanford
    Jun 3, 2013 at 16:14
  • 2
    I'll pitch in a contrary view, and say that I am glad whenever a program actually gives stack dumps and detailed trace info when it crashes. Many errors could be fixed by a half-way sophisticated user if the info isn't hidden behind 'user-friendly' messages. That said, it might be less intimidating to move it behind a 'details...' button.
    – Ask About Monica
    Jun 3, 2013 at 20:36

3 Answers 3

Reset to default
6

Pros and cons about showing verbose messages

Pros

  • Unexpected error messages help to find and resolve bugs, and are vital on systems in development or, even after deploy, that still on constantly changing.
  • They do not happen so often, and when happen, you want to know why.
  • Sometimes is more easy receive one copy & paste or screenshot of a error message than find on log files withou user help
  • Sometimes, instead of show RAW error you can show a error code or encrypted message to avoid expose too much your system. See example of Youtube error 500 at the end of this post.

Cons

  • Descriptive error messages are generally understood by those who developed the system, so is not useful when the user does not know how to get in touch with who developed
  • Show RAW messages can help bad intentioned people can help to cause damage to your system. Is not serious, but it is an additional means of finding information. Remember that even banks displays this type of error.
  • It is common for an error displayed on the screen has also been saved on file and the administrator does not need the user to know what occurred. But it does not always happen

Ways to show a unexpected error message

  1. Use default system message.
  2. Use same information of default system error message, but with a nice UI. Put at least how to contact support.
  3. Same as 2, but your UI now start collapsed details too much technical (like your stack trace/encrypted message) and user should click to see more information if the user really would like to.
  4. Just explain that an error occurred, and maybe decrease the severity . Some peolple also lie that someone is already solving by default and says that user do not need take one action.
  5. Do not display a error. Just redirect to some page and let the user find who did something wrong and try it again

Which interface to choose?

Any system start with 1 by default. And this help everyone. If you do not know what to do, just do not do change this. Option 2 is good if you care with you application UI but also would like to help find to resolve the problem. 3 Is better. 4 is a good option if your developers do not want to expose errors or programming mistakes. 5 is only for desperate people or situations where there is a system that detects intrusion attempts.

Keep in mind that 1-3 tend to, in situations of chaos, be better and avoid wasting time. And that 4-5 can be frustrating if your development team is not good.

In the end, what really recommend is the following: the decision you will take heed to what the system developers believe to be best. A UX designer should at most improve the interface, but should not go over the decisions of developers when it comes to exposing errors.

YouTube error 500

Improve this answer
1
  • +1 you've been the only one with pros/cons outlined.
    – edgarator
    Jun 4, 2013 at 1:42
6

Disclaimer

IANUXE (I am not a UX expert)

I Agree with your Dev Team

I believe your developers are right, it's too much, too soon.

In the space of 1 column inch (2.54cm to you internationals ;-) you have asked your user to process:

  1. Something unexpected just happend. OH NO!

  2. Server/App/Company acknowledges that this shouldn't happen. OK NOT MY FAULT.

  3. There is an action that I'm expected to take. HOW DO I DO THAT?

  4. Here is the data you should take that action on. WHAT IS ALL THIS STUFF?! IDENTIFY THEFT?! VIRUS?!

I Would Suggest:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

  1. Clear visual hierarchy explains situation and resolution
  2. Immediate assertion of innocence to the user (our fault!)
  3. Immediate presentation of options in appropriate context (users like to do something in response to errors -- it makes them feel more in control)
  4. Hide irrelevant level of technical detail until such time as is necessary (user is oriented to the situation and the nature of that technical detail)
  5. AUTOMATE: Can't send now, send later. Want to send e-mail? Click for pre-filled address, body, and attachment. Etc...
Improve this answer
1
  • I'm not completely sure about the apology. Like the "Help us fix it!" though.
    – edgarator
    Jun 4, 2013 at 1:48
1

I also agree with your Dev Team:

What you're proposing is both insecure (you're revealing your whole call stack to the world) and scary/burdensome for most end users. TMI!

I generally set up an exception hierarchy with a top level handler designed so that if something unexpected blows up, it will catch the class, function name and value that caused the error, and pass that on to the user, to pass on to the technical staff. Code should be written that way from the bottom up.

That information is generally enough for a programmer to track down the source of the problem and then start doing the appropriate research and forensic analysis, etc.

As for the 'Oops we're sorry' and the emoticon, that depends on your users. Where I work it wouldn't fly - need to just stick to business.

Improve this answer
2
  • No this is not "insecure". This is local app. Revealing its stack trace give exactly ZERO new information to local attacker.
    – Oleg V. Volkov
    Oct 10, 2019 at 1:46
  • @OlegV.Volkov - so you'd like to believe.
    – Vector
    Nov 8, 2019 at 16:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.