I don't like seeing the word 'you' in the message twice. Examples:
- Are you sure you want to delete this item?
- Are you sure you want to continue?
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.Sign up to join this community
Part of the reason that people skip over long messages is due to reading speed.
Assume for the sake of discussion someone with an average reading speed - around 200 words per minute.(*)
If you use just 20 words in a dialog, you're asking that user to spend 6 seconds reading and understanding what you wrote.
While that doesn't sound like much, a six second imposed pause when you're trying to get something done can seem to be an awfully long time.
(*) And don't make the mistake of assuming that low reading speed means low intelligence.
So, three suggestions for you, all aimed at maximum clarity with minimum fuss.
Here is a simple deletion dialog:
Let's reduce the number of words to the minimum to make it easier to read:
Now, let's identify the item at risk, and label the buttons for the action:
Much better - easier to read and clearer.
Another example - a continuation dialog.
Again, let's identify what's going on and label the buttons for the actions.
A definite improvement.
Here's a final thought. Avoid negatives, especially double negatives. Some native English speakers find double negatives tricky, and many who learn English as a second language find them confusing (especially if their native tongue uses double-negatives for emphasis instead of inversion).
I always make a point of showing the user which item is being deleted (especially since the dialogue might obscure the item in question, but also because seeing identifiable text in the dialogue will call attention):
Delete "your favourite item"?
You can also inject a little humour here and there, depending on what kind of app you're making:
Surely you don't want to continue without saving? [Yes I do, leave me alone] [Oh right, thanks for reminding me]
If you user test it you'll notice that humorous messages get noticed a bit more frequently simply because they sort of stand out from the crowd of generic messages and (if they're actually cute enough) get a smile on the face of the user. What more could you want?
It's better to not have such dialogs, instead, implement undo functionality.
The dialog is useless 95% of the time, so why force it on people? Are you trying to help people? or are you trying to place the blame on the user "hey, you confirmed that you wanted to delete that important item, don't blame me!".
Guess what, people learn to ignore these dialogs, they always subconsciously confirm whatever action they just did.
So that's the wrong approach to solve the problem.
The problem here is: user action can have undesired effects if done by mistake.
A better solution for that problem would be to allow the user to rollback his change.
If you allowed them to undo deletions, you get two good things:
Implementing undo is a lot harder than showing a confirmation box.
Delete this item?
Straight to the point.
Google suggest two different ways and both remove 'you' entirely.
Google design writing guidelines suggests the following:
Omit unnecessary phrases
You can skip many common introductory phrases and get right to the point.
Further Material Design alert dialogs suggests rephrasing the question to remove the 'are you sure?'
Alerts with title bars
Use title bar alerts only for high-risk situations, such as the potential loss of connectivity. Users should be able to understand the choices based on the title and button text alone.
If a title is required:
- Use a clear question or statement with an explanation in the content area, such as "Erase USB storage?".
- Avoid apologies, ambiguity, or questions, such as “Warning!” or “Are you sure?”
A critical thing to remember is that people ignore "Are you sure" messages. You have to force them to think about the decision. Here is one of my favorities.
What you've got is grammatically correct, but I take your point.
You could try breaking the message into two phrases:
This item will be deleted, are you sure?
This moves the important part of the question to the front where it is (hopefully) more likely to be read.
I'd also tend to avoid messages for actions that can be undone and reduce the number of undoable actions to an absolute minimum.
For critical messages you want to be as clear as possible and make sure the user reads the message.
By clicking here you agree that ...
Are you sure you want to ....
Get lost on the user, The user reads it as yada, yada, yada, whatever... and clicks yes without looking.
To get the user to read the message it has to be in the right order.
You are about to submit you application, This action can not be un-done, Do you want to continue, Click yes to continue or click cancel
This is a bit long but if you need the user to read the message this is the safest way to go.
The Apple Human Interface Guidelines for Mac OS X have a good deal to say about message boxes (alert panels).
Button names should correspond to the action the user performs when pressing the button—for example, Erase, Save, or Delete. The rightmost button in the dialog, the action button, is the button that confirms the alert message text. The action button is usually, but not always, the default button. (Note that in Cocoa methods, the rightmost button is always referred to as the default button even though it might not be.) For more information, see “Dismissing Dialogs.”
The problem with the Windows Message Box API is that it doesn't allow you to actually specify the names of the buttons you want, instead requiring you to either roll your own message box or use the built in Yes/No/OK/Cancel buttons.
For some more reading, here's an interesting article talking about the problems with message boxes in general: Why Message Boxes Are Evil.
It is not always about these explicit actions like delete,erase,save..etc.. There can be certain scenarios where user may unknowingly exits from an ongoing critical process.
For ex: The user is in the middle of payment and hits the back button.
In this scenario the user needs to be alerted.