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 don’...
Yes. There is a very simple, effective heuristic that adjusts to the preference of each user.
Place a check box in the warning message dialog that says:
Don't show this message again
Which can be improved further by stating where that dialog can be reenabled.
Don't start with choosing colors!
1. First, distinguish notifications from errors
This is a common point of confusion with UX. Consider these two messages:
Sorry, the app has crashed - This is an error, and should be highlighted as an error (i.e. pop up alert, dialog, red button, etc).
You have rejected a date with Kate Upton - Although this sounds like ...
A better modification of such a statment which I see being used is:
'A company_name employee will never ask for your password'
This message alerts the user that if the person is asking for a password, there is something fishy and he should alert the concerned authorities immediately. With all the live chat functionalities that most industries are providing,...
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 ...
These are Confirmation messages - Windows have a fairly detailed page on their guidelines. The whole of that page is pretty useful but here's some excerpts (emphasis mine):
Confirmations are most useful when the action requires the user to make a relevant and distinct choice that can't be made later. That choice often involves some element of risk that ...
"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 worse,...
The fewer words the better, and no words at all are better than negative words.
Don't say why you think there might be a problem, or even that you think there is likely to be a problem. Instead just make it easy for them to contact you in the event that they do happen to come across a problem.
I quite liked an experience I had recently at surfdome where it ...
Some of the invoices are not eligible for payment. They were excluded from payment processing. [details]
Error messages should separate two things:
Information for the end user (What they can do to "fix things")
Diagnostics for support and for the developers
Of course the developer is happy because they see what they want. But it's not helpful ...
Answer "No". "Successfully" can be removed:
Joel Spolsky covered this issue very well here:
The basic rule of thumb is that:
"In fact, users don't read anything.
This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do ...
The convention is that the question mark indicates extensive help is available, provides an interface for someone having a problem to click, and implies that a more sophisticated means of resolving the problem is being offered. The (i) indicates only that some additional explanatory information is available, but not an extensive help system.
Think of an (i)...
I would recommend moving away from colour for confirmation messages in this case.
I say this because it can be confusing for the user especially since you are using red and green for "Reject" and "Accept" so when they have successfully done an action moving from red to green can be disorientating and unworthy extra cognitive overflow.
Take a look at ...
Most security breaches are from social engineering, and so telling someone that they should never under any circumstances give anyone their password is an attempt to increase security. I would suggest a statement more like:
If anyone asks you for your password, you should assume they are a criminal and report it immediately!
Idea provided by @Kaz
As a ...
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 ...
From a security perspective, make sure you're only showing messages if the user has provided their password, even if they're banned.
I would recommend a ban notifcation (including time), when the user attempts login, show them the reason they were banned and the length of time they were banned for.
if there is an appeals process, this would also be the ...
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 ...
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 ...
I'm surprised nobody brought up the Mac OS X shut down dialog. It presents you with an "Are you sure?" window, but has a timer so that if the user walks away, expecting the computer to have shut down, it will while still allowing the user time to cancel.
Jakob Nielsen’s F-Shaped Pattern For Reading Web Content references an important tendency of users when reading websites:
Users first read in a horizontal movement, usually across the upper
part of the content area. This initial element forms the F's top bar.
You want your user to see the notification, so the top area of the page within that top bar of ...
Anything the user will take for granted should fade away.
Message has been sent after clicking "send"
Item has been deleted after clicking "delete"
Contact has been added after clicking "add"
Items that should remain visible are mission only critical things like:
Incoming call (someone is waiting for you on the other end and needs your ...
It currently accounts for about 20% of the activity on the site.
The fact that 20% of the activity on your site is private messaging indicates that your users consider private messaging to be of high value. So, you should be hesitant to remove it. Even if private messaging is not directly of benefit to your community, it still provides increased ...
We might want to distinct between several types of messages that got confused here:
feedback messages in response to user actions, e.g. "form saved"
unprovoked events, e.g. "new e-mail", "license expired", etc.
system status, e.g. "idle", "processing", "process complete", etc.
Each of these have its own conditions and best-practice solutions.
1. Feedback ...
If you are writing prose, a . (full stop) is there to show a the end of a sentence so that you know when the next one starts. If you only have one sentence, then it isn't strictly necessary for clarity. Hence, if it's a short notification message of only one sentence, you can leave it out.
That said you should keep to the style guides given for your ...
I spent some time exploring how other sites deal with downloads, and liked how Google Drive handles them.
Here is a screen shot of two downloads simultaneously happening on Google Drive:
What I like about this method:
While this message box is similar to the Toast idea mentioned in Idea 5, the box is positioned on the bottom of the page, rather than the ...
I vote A. I read the result/s initially as result per second.
Result(s) seems more natural, but I would prefer the option were you'd detect if the number is larger than 1 and change result to results.
Maybe take a look here: english.stackexchange here the (s) seems to be the standard.
Another option is to put it like this:
Matching results: 1
You should always show a message. User needs to have some sort of control, even if it is a simple you are temporarily banned and showing of the timer ( duration of the ban )
I would also suggest adding a button " contact us" where that user can dispute if needed, maybe they feel it was unfair or whatever...basically give them an option to be heard.
I'm going to give you a high level answer since everyone else is already tackling the "show one or two messages" part.
Don't be one of those apps
Instead, here are some counterquestions to possibly affect your design decisions:
What percentage of users is going to encounter problems if they don't reboot? Is it worth nagging 100% of your users if <5% ...
There is another issue with the word "successful" that I experienced in our SaaS. We provide a function in our application, where you can send stuff via email. However, the only thing we do is to send the email. The message used to be "Email successfully sent." User feedback then made us realize that they got the message more or less wrong as they believed ...