If the error affects the entire page on load, and there is information to communicate to the user about the specific error that occurred, use the universal message paradigm at the top of the page. If there is an action that the user can take to resolve the error, include that information in the message.
|Symbol||Last Price $||Change $||Change %||Quantity #|
|Table data is unavailable|
Sorry, something went wrong!
An empty required field should not display an error unless the submit button already has been clicked, allowing the user to tab through the fields, filling them out in any order, without encountering an error. The exception to this rule is if the user has entered incorrect text in a field that requires a specific format, like Date of Birth.
The error state should immediately correct once the error is fixed by the user.
If the field requires a specific format, include the it in the field label. For example, if the phone field must be in format XXX-XXX-XXXX, only allow numbers in the field and add the hyphen for the user at the appropriate place as they are typing. The same fool-proof auto-editing should apply to date–of–birth, Social Security Number, and any other fields with strict formatting where the user can easily be helped in avoiding errors.
If the form's submit button is clicked while there are errors, a generic error should appear above the submit button, the button should shake, the form should display all errors and focus on the first one. The form is now in a state where a blank required field will display an error. Try out the form below to see this in action.
tabto browse results, and