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 message ...
My suggestion: never use the word "Cancel" in the default action.
To cancel a subscription, you can, for example, say "Remove Subscription" or "Unsubscribe."
To cancel a download, you can, for example, say "Stop Downloading".
To cancel a setting, you can, for example, say "Revert Settings".
Here's what Facebook does when cancelling a payment subscription (Facebook subscription API).
There's no reliance on Yes/No. There's no misleading use of the word cancel. Clear explanation and buttons that clearly define the impending action.
Then they clearly confirm what just happened.
Skype on the other hand shows what not to do. Much confusion!
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 ...
I would say that "New" is best in most situations, as it is short and distinct.
A good rule of thumb is to look at the other options you will have in your menu. You want to make scanning fast, so you want to make each option as distinct as possible. Here is a crude example of what I mean:
download bmml source – Wireframes created with Balsamiq ...
You can't force them to read something, but you can:
Mitigate the cases where they're instinctively skipping it.
Remove the benefit for those intentionally skipping it.
As Alan Cooper puts it in About Face, you need to "hide the ejector seat lever" and break their flow.
Users who intentionally skip instructions should be held accountable....
Trying to give applications personality is one of those things that's just not well thought out. It definitely seems like it's one of those solutions that developers came up with and never user tested.
In a classic UI UX failure, developers came up with the talking paper clip solution in response to this same issue: https://archive.org/details/g4tv.com-...
"Like" is Facebook's creation and is strongly associated with Facebook. +1 is Google+'s creation and is totally associated with its brand.
Thinking out of the box... It seems your functionality is not exactly the same as "liking". It's more "like & follow". There is no single word for that, so alternatively you could invent your own vocabulary. ...
Ok I might be on to something:
"New" is good for buttons that take the user to a clean "canvas", where the user can add his content.
"Create" is good for buttons that "submit" the user's content or input (either into a database or to some public platform).
In other words, "New" doesn't suggest that you're actually creating anything. It just sets the stage ...
If you feel like jumping the action (click/tap) you can directly say "Select" the ...
Rather than a generic word, I would suggest you try to check what device the person is using and then say "click/tap" appropriate for the platform. But, then come the devices with both, a peripheral device and touch capability, which make this situation awkward-ish. You ...
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 your ...
Let them know what has happened. Here are some situations with longer, clear example notifications that use proper English grammar:
Only the name changed
The task "foobar" has been successfully renamed to "dummy".
Only the data changed
The task "foobar" has been successfully updated.
The name and the data changed
The task "foobar" has been ...
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 ...
The idea of 'click here' being a bad idea originated from data about how people visually scan web pages which show that people don't read online: they skim the page to get the key information. If someone is scanning, 'click here' (particularly if there are lots of them!) links are totally meaningless in isolation: the user has to spend time reading around ...
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 ...
AP style says "spell out whole numbers below 10, and use figures for 10 and above".
Chicago Manual style says spells out numbers below 100, or as an alternative rule to use AP style instead.
Nielsen Norman Group says, basically, to heck with the old rules; everybody just skims online anyway so use figures for all specific numbers, because people notice ...
Personally I like love which is often represented by an icon of a heart and popular in social media. Then you dont have to write the word love but simply use the heart.
But if you don't like the heart icon, you can always find a synonym from Thesaurus.com:
Priority shouldn't be numbered or substituted with characters. Traditionally they've always been a label to instruct the end user what they represent.
This is what we use. A combination for Color and Label or Icon and Label. For a user with accessibility or someone using a screen reader, the priority is read out as text.
Ideally, there has to be a visual ...
Name the buttons for what they do. If the default is "cancel", then cancel the cancel should be something simple like "Don't cancel".
I know that it's not ideal to use the word 'cancel' in both of them, but it's the clearest option in this unique situation, and clarity is far more important.
Edit: Some good suggestions from the comments below are to ...
If it's clear, say it in the least number of words possible. If there is no confusion, then there is no problem.
"Import image" - clear.
"Create app" - clear.
"Add description" - clear.
For further reading, I suggest the Android Writing Style.
I would try my very, very best to avoid using the term 'cancel' for terminating the subscription. Cancel is generally considered to be a safe action. Here, you are using it in a more destructive sense, thus causing the confusion you noticed.
If you manage to avoid the term 'cancel' for the actual activity, you can resume to use it for the cancel ...
A few of my guesses:
Numbers are harder to anthropomorphize - we've reached a point with our understanding of computers where we regularly refer to the computer as another being we regularly interact with. It's much easier to give this creature some kind of name vs. a number, especially given that numbers are often used to "dehumanize" things and make them ...
In the team I am on, our idea on the matter is as follows:
Continue is used when you're talking about a directed flow forward only. Continue implies that anything you've done hitherto will be saved, so that you can move forward in the workflow. Ideally in a Continue-based setup, there will be alternate ways to return to previous app states, if your design ...
It is easy for designers to overthink things (and equally under-think things). I highly recommend reading this research paper:
Petrie, H. & Power, C. (2012). What Do Users Really Care About? A Comparison of Usability Problems Found by Users and Experts on Highly Interactive Websites. Proceedings of Human Factors in Computing ...
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 ...
I prefer 'Sentence case' over 'Title Case' because sentence case respects the difference between proper nouns and the other words.
I always thought that it was customary in English.
In Spanish it is not, we use sentence case, like this traditional Argentine newspaper does.
This traditional USA newspaper uses Title Case instead.
These are language differences....
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 align ...
What about Star? Google Reader did this and it was pretty clear it went into the Starred Items folder and your friends would also see you starred an item; it also served to bookmark.
The other thing I was just thinking is that unless you told people, no matter what term you used it would still be unclear you "liked" that user. That seems totally different ...