Always use a comma to separate thousand, e.g., 23,000,000.
Dialogs are used to communicate results of user actions and system events. Dialog can include error messages, warning messages, success messages, inline validation, and system status information.
- Deliver messages at the right time. Not every action needs a dialog.
- Don't say too much and just what is necessary. Don’t be too verbose.
- Avoid the word "please", except in situations in which the user is asked to do something inconvenient (such as waiting) or the software is to blame for the situation. Also note that using the word please can be interpreted to mean that the required action is optional.
- Only use the word "sorry" in error messages that end in critical problems for the user (like incapacity to use the system or data loss).
Error messages are used to inform the user that an error happened. They are the most likely to bother your users, because their particularity is that they cannot be dismissed, they must be addressed. There are two types of error messages: errors caused by the user, and errors caused by the system. If you can’t avoid error messages, use them sparingly.
When an error caused by the user occurs in a form, you must:
Put a prominent top-level error message
Display a banner that summarizes what happened, with links to all input in error (really helpful for screen readers) and how to resolve the existing error. The message can’t be rejected by the user with a close button, it can only disappear when the error is resolved. The banner appears at the top of the form and moves the content below.
Highlight the incorrect input field
The problematic input field should be prominently indicated and should include instructions that invite the user to try another answer. To do that, the label should be red and red instructions should be added below the input field.
When an error caused by the system occurs, you must:
Display a modal prompt
The prompt is used to grab users’ attention. It must be explained in the message why the error has happened without blaming the user for the error. Give the user indications: contact the support, try again in 10 minutes, reload the page, etc.
Success messages are used to inform that an action took place or that a form was completed successfully. It appears in a green banner at the very top of the screen, over the content. The success message dismiss itself by an animation because it does not require any actions from the user. Contrary to error messages, success messages should never block people’s progress, they should encourage the user to continue.
When displaying a success message, you must:
Present the success message in context
The success message should be presented in context on the same form that was just completed, so as not to block any further progress.
Avoid success message page dead ends
When the success message is displayed in a process, it can include useful actions related to the task the user just completed. It gives user clear and actionable next steps.
Use a Prompt to show a complex success message
Sometimes, success message contains information that people want to keep, like a code or a link to an invitation. In such case, keep this valuable information visible on the screen by using a prompt. The user should be able to copy and paste the information.
Warning messages are used to help users prevent error situations. They appear in a yellow banner at the top of the screen and move the content below it. It should contain a suggested next step. It should be rejected only by the user.
Inline Validation is direct feedback displayed as the user progresses through the form to confirm that their answers are valid. Inline Validation helps people complete forms quickly and with less effort, fewer errors, and more satisfaction. The opposite approche is to validate all the inputs at the end of the process, when the user submits the form.
It can give many types of feedback: suggestions for valid answers, confirmation that a correct answer was given, and live updates designed to help people stay within necessary limits.
Inline validation is useful for the answers that are not obvious, answers with specific formatting requirements or answers with potentially high error rates (e.g., Name would not be appropriate for inline validation).
44px x 44px + 10px clearance around hit zones (54px total)
Ideally, links and button hit zones should not be smaller than 44px by 44px so that they are easy to activate on touch screens with the average human finger size and, with a mouse or trackpad, do not require a too precise aim.
If the hit zone has to be smaller for technical reasons, it is important to make sure that there is a 44px non-clickable space around the hit zone plus a 10px clearance (minimum non-clickable space between 2 hit zones), which makes a 54px by 54px non-clickable space required for any hit zone.