Ready for implementation


Goals

Magnolia 4 does not know a unified concept for messages in forms. The goals of our new implementation are:

  • Provide a mechanism for showing validation messages closely connected to the value causing an error or a warning.
  • Since multiple fields may cause both field descriptions and validation messages, it must be clear with which field a particular message is associated.
  • Ensure that field descriptions and validation messages can be visible at the same time, since both may be relevant to fix a problem.
  • Make sure that users with alternate input devices may find and navigate validation messages as well.

Concept

If a user fills out a form and this causes a validation error or warning, she receives a clearly visible message indicating the problem.


A form showing an error message sports a bar at the top counting the number of errors found on the page and containing a link to the first message (1). It clearly marks the form as containing errors.

In fact, the field with the first error has already received the input focus when the form is shown. As a result it has been highlighted both as selected field (blue background in the mockup) as well as field with errors (light red background). Consequently, both the field description at the bottom of the form as well as the flyout with the validation message show up.

Finally, the field has also been flagged using a visual error indicator (the small red stop sign in this mockup). All other fields with errors as well as the tab of an invisible sub form containing errors have been marked using this indicator as well(3). Like this, errors in visible and invisible forms can be easily identified.

Warning messages show up and act much like error messages. They are indicated by a bar using the color assigned to warnings and also feature a flyout, which appears as soon as the problem leading to the warning has been detected and which may also be clicked away as well.


When a message appears

Validation messages show up either immediately after typing or after submitting the form - this is entirely left up to the implementation, but immediate feedback is preferred. If a form reacts immediately to input, errors and warnings show up while a value is being entered or selected and disappear again, if they no longer apply.

The message flyout

A message is placed inside a flyout, which resides slightly outside the form to avoid covering any other field or value. It is properly aligned with the rest of the visual elements. A colored arrow makes the connection to the field explicit. Note that only the flyout of the currently selected field is shown. Both the flyout as well as the highlighting background may be removed using a click.


If a form has been enlarged to cover the entire screen using the full-screen button at the top (1), the flyout is placed inside the form as shown in the mockup below. It then may actually cover other form elements, which is ok, given that the flyout can be clicked away if necessary.


Navigating from one validation message to the next

To make the list of validation messages accessible to all users, an always visible anchor message must act as entry point to a chain of validation messages connected using links pointing from one message to the next. The bar at the top acts as anchor (1) holding the initial link ("show first"). Inside a message flyout, another link ("show next") leads to the next message in the chain. This even switches to another tab first, if necessary.


Linking validation messages like this makes them accessible to users using eight the keyboard or other input devices such as screen readers. The bar at the top ensures that the user doesn't have to scan the entire page to find an error or warning and that he has an anchor for jumping back to the first message.

Handling multiple message types

If a form contains both errors and warnings, the corresponding fields are still marked accordingly. The bar at the top mentions both the number of errors and the number of warnings, but the color and icon it features are those assigned to errors, since errors count as more severe as warnings.


Note that warnings are also part of the UX:linked sequence of message the user may navigate through. Messages in this list are not sorted according to type, but instead appear in the chain sequentially.

Long forms

If a form contains that many fields that not all of them may be visible at once, it uses scrollbars to make them available - see the corresponding sections for standard and complex forms.


The elements highlighting a field with errors may actually cover the scrollbar, even up to the point where the scroll button of the bar is hidden underneath the red bar. This is fine, though, since all highlighting can be clicked away.

If a user starts to scroll a long form, all error highlighting immediately disappears; the only elements remaining are the visual error indicators. The error highlighting does not resume, when scrolling stops and the scroll button is released. The user has to explicitly select a field to see an error message.


  • No labels