An alarm tells the user of a critical system problem that causes the user to be unable to proceed or continue working. An alarm always has an “error” status type, since it always relates to an important system issue where something has gone wrong.
It is likely that the software will not be able to function correctly until fixed, so the user will not be able to access most parts of the UI. Making the alarm dismissible relies on there being a page outside the main UI the user may land on until the system returns to an operable state. For example, in Earthworks, this is the “Dashboard”.
Note: An alarm is the most serious and significant form of system status communicated in our interfaces. Alarms must be very carefully considered. A cross-discipline team is typically consulted to identify situations requiring an alarm.
- There is a system critical action the user must take. The user must stop work and immediately attend to a problem or error.
Don’t use when
- The user should attend to the issue but can carry on working for a time until the issue is resolved and/or the UI can sensibly be rendered while the issue is in play. Use a Prompt instead.
- If there is minor information that is “nice-to-know” but does not require the user to take any action. Use a Notification for such scenarios, where basic information is conveyed to the user, but such information does not require user action.
|Updated full layout.