Tag Info

Hot answers tagged

337

The reason I believe it is important to have an apologetic tone is to ensure you are communicating to the user that, though a mistake has been made and he is interacting with a machine or application in this case, you still respect his action and are humanizing the mistake. To quote this article from UXMatters: “You’re going to display your error ...


163

Don't write error messages blaming the user. There is no actual benefit to you from doing this. In the event that someone accidentally triggers these error messages, you damage your relationship with them. Even if you do manage to tell a single malicious user that you know they're malicious, it isn't going to make them like you any better. All you're ...


137

When we’re dealing with Banking and money transfer, it is an exceptionally bad idea. Finance isn’t supposed to be funny, since it’s a very serious business. Instead, error messages should be clear and to the point what is actually wrong, and not some random fun message. When a user receives an error message, she/he is already under pressure, since users ...


83

While Mervin's answer is excellent, I would go beyond saying it is "acceptable" or "preferred". I would say you "must" use an apologetic tone for one very good reason: if the user is making a mistake, it is because the user does not understand the rules or logic of the system. That is not the fault of the user! It is responsibility of the system to ...


61

Just a guess: If they used black (minimum intensity for all three color channels) or white (maximum intensity for all color channels) you might think they are off, so instead they use only one of their base color channels (out of Red Green Blue). Red light may remind some people of an alarm and others of a district in Amsterdam. Green may seem like ...


59

"I'm sorry Dave, I'm afraid I can't do that." That scene from 2001: A space odyssey is a good example for why this can be a dangerous practice. Beware of anthropomorphising a computer to the point where the user starts ascribing malice to it. Error messages need to be non-personal to avoid the user feeling like the computer is complaining at them, or ...


55

Personalisation Igor. Content personalisation can be appropriate at times, like in an email or after login. Amongst a few, it makes the system appear more 'human', and can facilitate some personal 'bond' with the user. But one can argue that by attaching a name to a notification you won't achieve that (I see proper personalisation as real user-dependent ...


49

Taking a step back: Why was this feature made available (visible) to the user in the first place? If it is a feature not available to a specific user (or user class), hide it. If it is a premium feature that you'd like to upsell - do so. History export is a great way to backup your data, but is available on premium accounts only. Get in touch with ...


41

Just because your brand color is red doesn't make the use of red for errors obsolete, it's just a matter of extent. Take the Viaplay signup form for example: Viaplay has red as their main accent color, which is used throughout the website for actions buttons, icons, header, graphic elements etc.. however, in the form they do tone down the use. They ...


39

The book About Face 3 has some good advice. The paramount of which is to design the software to eliminate the need for error dialogs. In cases where that isn't possible, the authors recommend: Make an error dialog polite, illuminating, and helpful. (Remember that the error message is actually the software reporting it's inability to perform, not the user's ...


39

I would say that you can make the error messages more personal and "human sounding" without resorting to trying to be funny. For example, a message that says "Error processing transaction" can be translated to "We are very sorry, but something went wrong." "We are very sorry, but something went wrong and we did not send this transaction." They key ...


38

There are two big problems, from an internationalization perspective: How sure are you that your Name data contains the name the user is called by? Getting your name data format correct is a classically difficult problem. As soon as you add name wildcards to your error messages, they will become much more difficult to translate to other languages. Without ...


37

Warn them, and show a link to download Firefox, etc... here's why IMHO, the visitors who come to your website or web application with an IE6 browser, fall into two general parties: Members of a locked down major corporation that can't afford the time or money to update their entire organization's security settings after allowing everyone to move to IE7,8, ...


36

Encapsulated flags are the only solution I've found that reach all edge cases. Pointing the flag at the label rather than the input allows for consistency with radio buttons and check mark groups or weird inputs like sliders or sorters. Highlighting the field with red is also helpful, but not always possible. Example usages below. download bmml ...


32

Before you completely hide a part of the UI for a feature which the user doesn't have access to, consider: Will the user know about that feature? Will they spend a lot of time hunting for it? Would you be better off keeping it around in some kind of "disabled" state along with a tooltip or other indicator so that they can learn why it's not available? ...


32

A good error message should: Let you know what the problem is. Make you feel like there is something that you can do about it. Speak like a human, and be a consistent extension of the personality of the rest of the application. For generic error messages, you can't do much about the first point, but you can do something about the other two. Do something ...


32

I think the blue goes back to the days of consumer-grade video cassette recorders with on-screen message displays. Superimposing an image on a video signal requires that one know which parts of the signal will be displayed where on the screen. If the video signal includes valid horizontal and vertical sync pulses, one can measure the time since the last ...


29

This is something that you have to be careful with, because you don't know what your users' state of mind is when your application is crashing. As always, it really depends on what kind of application you're writing, and how serious your users are likely to be about it. In the case of something like Google Chrome (as @Josh's answer contains), it's hard to ...


27

I don't find apologies very humanizing from a computer, any more than an automated hold system for a phone network makes me feel like my call is important by saying, "Your call is very important to us! Please stay on the line for the next available representative." I don't think the apologies are the main issue here. Far more important is that they are ...


27

The first thing you have to find out is, if it's really a troll. Your Contact Form and Feedback Form examples have nothing to do with trolls. It's just a feedback message. The third example sounds like a hacker or script kiddie who's trying something, also no troll. So for the first two examples, choose a error message that tells what to do, but does not ...


24

The error message should appear before the form field itself (at a minimum in the markup itself, but ideally visually shown this way on the screen too) so that when someone is reading the form they read that the field has errored before they then read the field in question - that way the user is prepared mentally that "the contents of this field I am about ...


24

Many applications display humorous crash messages (see Chrome's "He's dead, Jim!"). The key here is that the application also provide means to the user to recover the application to some degree (reloading the page, learning more about errors, or sending feedback to Chrome). The ability for the user to do something about the crash, in addition to the ...


24

In general, using only color to indicate information is bad for accessibility reasons. Red/green colorblindness is the most common and occurs in 8% of males. Using an icon, like an X or warning sign, is the best way to go. If you must differentiate color for business reasons (i.e. people at the top think it should be a different color), then pick one that ...


24

You shouldn't lie to your users. If the issue is a 404, don't use language that implies it's a 500; the server's not broken, and that page may never exist. There's no reason you can't use user-friendly language to communicate the actual issue, however. Plenty of sites use 404 language that apologize in human-friendly language for the page not existing, and ...


23

It seems you're already marking optional form fields instad of required ones. There seem to be no 'required' indicators, but no 'optional'-indicators, too, so I wanted to mention that. What I like to do on forms is to "micro-gamify" them: For every field in the form provide a "validation-indicator". For simplicity, let's say it's just a small circle. This ...


23

Yes, error messages should apologize when it's plausible to do so. People will ascribe human emotions to computers, so the computers should be polite, particularly to users who expect people to be polite. For example, websites designed for the elderly would benefit from very polite messages both to show that the site and not the user is at fault to ...


22

There is a very simple rule that I use for myself: Error messages must not display error messages, they must display a solution message. The user does not care what is wrong and why, he simply wants the issue solved.


22

Well, let’s work it from end to beginning: ”!!” Lose the exclamation points. Don’t yell at the user. It’s rude and insulting. ”image files” Does the user know what an “image file” is? Do they understand “image” or “file”? Conduct some user testing, but I’m guessing “picture” is more appropriate. And what is not an image file? Maybe the user ...


19

The point of a good error page is to apologize for the error, explain what happened in layman terms, what might be responsible for this, and what next steps to take. Yet, error 500 rarely supplies a good explanation so the error page has to be vague. This results in users starting to refresh the page hoping it would miraculously render, even in cases of ...


17

I think red is pretty much the convention in this context so you should use red for errors that need to be fixed before you can move on/send the form. Yellow is in general for warnings (eg. user perhaps should/could improve something, but it does not stop from proceeding). Yellow can be used with for example with one of those password strength thingies where ...



Only top voted, non community-wiki answers of a minimum length are eligible