Tag Info

Hot answers tagged

292

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 ...


74

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 ...


58

"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 ...


54

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 ...


41

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 ...


40

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 ...


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, ...


37

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 ...


36

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 ...


34

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 ...


31

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? ...


31

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 ...


28

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 ...


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 ...


23

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 ...


23

Yes, error messages should apologize whenever it's remotely plausible to do so. People will ascribe human emotions to computers, so the computers should be as polite as possible, regardless of whether they're actually at fault. A chapter "Bringing Affect to Human Computer Interaction" has a section on apologetic feedback: Nielsen (1998) argued that ...


23

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 ...


22

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 ...


22

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 ...


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 ...


18

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 ...


17

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 ...


16

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 ...


15

The only place where you don't use a full stop is in titles (such as in the title bar of a window). In all other cases, you need proper punctuation. Compare it to a book: the title of the book does not end with a period, all sentences inside do end with punctuation. Except the titles of the chapters, which are titles again. I remember in elementary school ...


15

Instead of using colors, draw visual emphasis through other means, such as using danger icons, font weight, and/or jagged outlines. Here's a an example, excessively using all three of these cues: EDIT: The comments below suggest that I didn't make it clear enough in my original post that using all three of these cues together would be excessive. (I'd ...


15

Showing a message box is not a good solution in most cases (1). It's even worse when the message box contains a message such as "Please Select only Image Files!!" (2). And it gets worse in a context where the user is uploading a file which is not interpreted by the application as an image (3). Message box dilemma The message box is extremely easy to ...


14

You will always have a significant percentage of users who ignores many or all error messages. Even when they call support, have the error message in front of them and claim to have read it, they may very well still not have assimilated the content of the message. You should therefore try very hard to avoid having to put up an error dialog. In addition to ...


14

I usually like to show an error message on top that summarizes all errors on the page, plus in each location, highlight what is wrong. For example with a form, on top you would say that email, phone and address are required, and in the form, set all of these three fields in red with a text along the lines of "this field is required" (or something more ...


13

The basic idea with showing an error message is to let the user know that something went wrong and his actions may not have resulted in a desired way. So, if the error is something that doesn't affect the users perception of the program - don't show it, but keep it in an error log (for example, the function took 50% longer to execute due to some errors, ...


13

Red for error messages and alerting to something that is of critical attention is pretty standard in Western society. It is well used in operating systems, like Windows and OSX to use red for error, yellow for warning and green for success messages. This might be as subtle as just having a red “X” or a green tick, but they communicate the status of the ...



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