I find myself needing a reference like this more often than not lately. So, here’s a blog acting as augmented memory—I’ll update it as I encounter more user-facing states in the wild.
What user-facing state is
User-facing state is what someone experiences when they interact with (or try to interact with) an element in some capacity. It is reactive, helping to communicate the ways in which something can be manipulated.
The system that displays content can also manipulate state from sources other than the person using it. Think service outages, slow API response times, etc.
Multiple states can be applied to something, from both cumulative user interactions, system interactions, or the combination of both. For example, a collapsed element could also be conditionally disabled.
Some states are discrete, while others can be part of an implicit pair. For example, an expanded element can be collapsed, but does not necessarily need to be.
State also helps to identify purpose via behavior. Because of this, not every component can have every state applied to it. For example, not every component needs to be draggable.
It is also worth noting that on the web, the majority of user-facing state can be communicated programatically. This means that there is an HTML attribute or ARIA declaration that can ensure people who can’t see the content can understand the state something has been set to.
What user-facing state is not
Here are a few examples of what user-facing state is not:
User-facing state is not to be confused with application state—a term commonly used with single page applications to communicate configuration of data.
It should also not be confused with size, context, mode, and other design tokenable qualities that can be applied to a component.
Validation is often lumped in with state—I feel this is a mistake. For completeness’ sake, here’s validation conditions that can augment state:
Content or choices made by someone are within the parameters set by the input. Data can be successfully sent back to the system that stores it.
Content or choices made by someone are not within the parameters set by the input. Data cannot be sent back to the system that stores it.
Content or choices made by someone may have been unintentional, or have unintended consequences. Data can be sent back to the system that stores it, but there may be side effects.
With all that covered, here’s the list:
The status of something before someone has interacted with it, or other content affects it. Oftentimes referred to as “Base” or “Default.”
When someone places a pointing device over an element, but has not yet taken action on it.
An intermediate state that communicates someone has taken action on an element, and that it is in the process of navigating to a destination, triggering logic, or transmitting data. Also known as “pressed.”
When someone selects an element via keyboard or voice command, but has not yet taken action on it.
Someone has previously visited the resource the element is set to navigate to.
An element is fetching data from another internal or external resource.
An element has fetched data from another internal or external resource and indicates that retrieval is completed. Loaded state isn't always communicated after loading state is applied.
An element has had its interactivity conditionally removed.
An element has been completely removed. It cannot be visually seen or accessed via assistive technology.
Indicates element content that can only be read, and not interacted with.
An element has been Activated, which unlocks the ability of additional state to be applied to the element, the page or view the element is contained on, or the overall site or app.
The larger system an element is used in has service issues. This service disruption removes the element’s ability to take action or navigate.
An element has its presence completely removed for assistive technology.
An element is marked for sending as data to another internal or external resource. A Checked element can be Focused, but it's selected state persists after focus is moved.
A Checked element that is no longer marked as wanting to be sent as data to another internal or external resource.
An Indeterminate element is triggered on a parent element when some, but not all children elements are placed in a Checked state (thanks to Kilian Valkhof for the suggestion).
An element has been chosen as one or more criteria for a task. A Selected element can be Focused, but it's selected state persists after focus is moved.
A Selected element that has had its selection removed. Elements that can be Selected, but have not yet been are considered to be Resting.
An element has been Selected and is being moved to another location.
A Dragged element is placed in a new location (thanks to Austin Gil).
An element is hiding the bulk of its content.
An element is showing all of its collapsed content.
An element has its height or width increased or decreased.
An editable element has been manipulated by someone on one or more occurrences.
An editable element has yet to be manipulated by someone.
An indeterminate state. It is triggered when an editable element in a Dirty state, where someone signals that their changes should be captured. Once the changes are successfully captured it reverts back to a Pristine state.
A child element's visual content is partially obscured by a parent element that restricts its height or width (thanks to Dave Rupert).
A child element is panning horizontally or vertically (thanks to Dave Rupert).
An element is actively presenting prerecorded media or animation (thanks to Austin Gil).
Prerecorded media or animation an element is Playing is temporarily halted (thanks to Austin Gil).
Prerecorded media or animation an element is playing reverted back to its start position.
An element attaches itself to the side of the viewport opposite the direction someone scrolls and does not move out of view along with its surrounding content (thanks to LukaJ).
A Sticky element is removed from the side of the viewport and moved back to its original position.