1/17/2020

Ad Hoc Design Surge 1 - CSS Animation

{:.ds-title}

Scott Weber and John French set out to explore the potential value of adding animation and motion directives into the CMS Design System (CMSDS). Currently, there is no framework or guidance for animation within the CMSDS. We spent two days figuring out if that would be valuable and how it could be successful. {:.ds-text--lead}

Why explore adding animation?

When used correctly, motion and animation can broaden the toolkit designers and developers have to help enrich digital services. It can help give a user confirmation that a task has been completed, or let them know that things are happening in the background.

Animation can be used as a part of a larger strategy to improve inclusivity and accessibility of services by adding another layer of context to digital interactions. It can help to highlight connections between elements and information in real-time or provide simulated haptic feedback when a button is pressed or selected.

For our work at the Centers for Medicare and Medicaid, defining a standardized framework for animation in line with the CMSDS will allow dozens of teams and projects to use and contribute to the animation standards together. This will lead to the consistent, reliable implementation of animation across CMS digital services.

Defining motion and animation options

We started by assessing common UI animation methods that would provide the highest flexibility and value in the CMSDS. The idea was essentially to create “animation classes” that can be added to an element in the same way the design system handles CSS utilities now.

We came up with the following list:

Fade In
Fade In + Grow
Fade Out
Fade Out + Shrink
Color
Shake (Directional variations)
Grow
Shrink
Shrink + Fade Out
Slide (Directional variations)
Slide + Fade In
Slide + Fade Out

In addition to defining these set animations, we explored adding variables to allow for control of animation-duration as well as animation-timing-function for each animation type. This would give a wide range of control on the animation itself while also providing the consistency that variables provide with other utilities like margin, padding, etc.

Governance / Implementation Details

We made several governance decisions around the usage of animations in the design system to ensure that animations are adopted properly and consistently across projects.

Animation Class Naming Conventions

Class structuring would work similarly to the CMSDS utilities.

.ds-u-animate-fade--[ in | out ]
.ds-u-animate-speed--[ slow | medium | fast ]

We wanted to follow the pre-existing CMSDS methodologies for naming and using utility classes, while also being able to incorporate required animation properties. In an attempt to keep users' code as clean as possible, we decided to prepopulate the animations with default variables, so that a user can simply add the class: ds-u-animate-fade--in without having to also specify the animation speed. If they do choose to adjust the speed using the ds-u-animate-speed-- class, the default value can be overridden.

Encouraging Contribution

To ensure consistent, well-tested behavior across sites that utilize the CMS Design System, we recommend users not attempt to combine animation classes to create new animations. Instead, we would encourage users to work with the CMSDS team to request or contribute new animations to the design system itself. This will help ensure that no unexpected errors or usability problems occur if animation classes are combined.

To validate our assumptions around the impact of implementing animations into the CMSDS, we met with Ad Hoc’s accessibility group and discussed general usability concerns with the healthcare.gov team.

Animation guidelines

General

Animation should be considered early on in the process
Animation should enhance the UX and serve a purpose
Animation should feel natural in the context of the interaction

Duration

Shorter durations should be used for simple animations (Ex: fades and color changes)
Longer durations should be used for more complex animations (Ex: moving an object on the screen and page transitions)
Duration for mobile devices should be shorter for smaller wearable devices and longer for tablets

Sample Documentation / Implementation

For this exercise, we wanted to display actual CMSDS components working with the animation classes we have defined as a proof of concept. We also wanted to show how it would be possible to test/display animations easily from within the CMSDS documentation. The section below is an example of documentation for one of the animations with several CMSDS components:

Fade In

Jump to guidance View related U.S. Web Design Standard

Use the fade in utility class to fade an element on to the screen. Format:

ds-u-animate-fade--[in|out]

Reset Fade In: Alert (slow) Fade In: Modal (medium) Fade In: Button (fast)

Guidance

Customization

The following animation Sass variables can be overridden to theme animation properties:

```
$animation-speed-very-slow
```
```
$animation-speed-slow
```
```
$animation-speed-normal
```
```
$animation-speed-fast
```
```
$animation-speed-fast
```
```
$animation-speed-very-fast
```
```
$animation-timing-function
```

Do:

Do use fade in help grab the attention of the user
Do consider the speed and size of the item being faded in

Don't:

Do use fade in help grab the attention of the user
Don't use fade in for large blocks of content (Ex: Don't fade in an entire form)

Next Steps for animation and the CMSDS

This lays the groundwork for us to conduct further research and testing with the programs who use the CMSDS to determine whether or not to move forward with implementation. A potential path forward would be to:

Conduct research with CMSDS teams to determine if/which elements of animation would be beneficial
Present findings to CMS leadership for consideration
Build out other animations into a site package for team-wide testing
Potential full release

line47/design-system-animation