Как связать движением состояния и не помешать тем, кому движение неприятно

Когда новое состояние вырастает из старого, человек не теряет нить: видно, что откуда взялось и куда делось.

В корзине три товара, кофе из Кении удаляют.

Слева строка пропадает, и список прыгает вверх. Справа строка уезжает, а список смыкается следом.

Нажмите «Проиграть» под каждым экраном.

Смена экрана

Здесь то же самое. Когда подробности заказа раскрываются из его карточки, понятно, куда вернёт кнопка «Назад». Когда экран просто подменяется, связь между карточкой и подробностями человек восстанавливает сам.

Когда длительность подбирают для каждого перехода заново, приложение двигается вразнобой: шторка вяло, диалог резко, меню как-то ещё.

Так сейчас выглядят переходы магазина.

Каждый по отдельности выбран разумно, а вместе они дают пять длительностей и пять кривых, и ни одну нельзя повторить, не открыв исходник.

Набор — несколько длительностей и несколько кривых с именами по роли. Для приложения магазина хватает такого:

Кривые взяты из Material Design 3, там они называются standard decelerate, standard accelerate и standard.

Готовый набор удобнее самодельного: он описан, и разработчикам он знаком.

В обновлении Material 3 Expressive компоненты Google перешли на пружинную анимацию и эту таблицу больше не развивают. Но как точка отсчёта для своего набора она по-прежнему годится.

До и после набора

Ниже три перехода магазина — шторка, меню и плашка — слева с прежними числами, справа по набору. Нажмите «Проиграть» под каждым экраном.

У части людей движение на экране вызывает головокружение и тошноту. Для них в системе есть настройка, и интерфейс должен её слушать.

В первую очередь она нужна людям с вестибулярными нарушениями.

Крупный сдвиг, приближение и параллакс вызывают у них головокружение, тошноту и головную боль — так эти реакции описывает WCAG.

Таких людей немало. По данным американской ассоциации вестибулярных расстройств VeDA, с нарушениями вестибулярной системы сталкивались до 35 % взрослых старше 40 лет в США.

Бывает и так, что движение отвлекает и мешает читать.

Настройка есть во всех основных системах:

Сайт узнаёт о настройке через медиазапрос prefers-reduced-motion, приложение — через системный флаг.

Решение, что показать вместо движения, принимает дизайнер.

Включите «Уменьшить движение» в коробке ниже и проиграйте те же переходы.

Что обычно делают с разными видами движения, когда настройка включена:

Для разработки это одно условие в стилях. Вот как оно выглядит для шторки:

/* Обычно: шторка выезжает снизу */
.sheet {
  transition: transform 300ms cubic-bezier(0, 0, 0, 1);
}
.sheet.is-closed {
  transform: translateY(100%);
}

/* Уменьшить движение: без сдвига, только проявление */
@media (prefers-reduced-motion: reduce) {
  .sheet {
    transition: opacity 200ms linear;
  }
  .sheet.is-closed {
    transform: none;
    opacity: 0;
  }
}

В WCAG 2.2 этому посвящён критерий 2.3.3 «Анимация от взаимодействия» уровня AAA.

А критерий 2.2.2 уровня A касается того, что начинает двигаться само. Если оно идёт дольше пяти секунд и стоит рядом с другим содержимым, его должно быть можно остановить.

Переход, который прекрасно выглядит на быстрой сети, на медленной прибавляет своё время к ожиданию.

Экран заказа в магазине открывается так: сначала проигрывается переход 400 мс, и только потом приложение просит данные у сервера.

На хорошей сети ответ приходит быстро, и этого никто не замечает. В метро ответ идёт секунду с лишним, и к ней прибавляются те же 400 мс анимации.

• Запрос уходит в момент нажатия, а не после анимации.
• Анимация не блокирует ввод. Пока шторка едет, по ней уже можно нажимать.
• Анимация не прячет загрузку. Растянуть переход, «чтобы не было видно ожидания», значит заставить ждать и тех, у кого сеть быстрая.
• Долгое ожидание — каркасом экрана, а не длинной анимацией: каркас сразу показывает, что будет на экране.

В Figma и на ноутбуке любая анимация плавная. На недорогом телефоне та же анимация может дёргаться.

Плавным движение выглядит, когда экран обновляется 60 раз в секунду.

На каждый кадр у браузера остаётся около 16 мс, и за это время он должен успеть всё: посчитать, нарисовать, ответить на нажатие. Не успел — кадр пропадает, и глаз видит рывок.

Одни свойства браузер меняет почти бесплатно, другие заставляют его пересчитывать страницу на каждом кадре:

Все образцы в этом уроке двигаются только сдвигом, масштабом и прозрачностью. Строки корзины из раздела 1 смыкаются не потому, что пересчитывается высота списка, а потому, что нижние строки сдвигаются вверх ровно на одну строку.

Как проверить

1. Откройте прототип на самом дешёвом телефоне, до которого можно дотянуться: свой старый, у разработки, в тестовом парке.
2. В браузере Chrome включите замедление процессора: инструменты разработчика → Performance → настройки записи → CPU: 4x slowdown.
3. Смотрите на две вещи: дёргается ли движение и успевает ли интерфейс ответить на нажатие, пока анимация идёт.
4. Если дёргается, спросите разработку, какие свойства меняются. Обычно помогает заменить высоту или положение сдвигом.

Для каждого движения в продукте нужен ответ на вопрос: что будет, если настройка «уменьшить движение» включена.

Заведите набор длительностей и кривых для продукта, пересоберите на нём три анимации и опишите поведение при «уменьшить движение».

Часть 1 · Собрать набор, 20 минут

1. Выпишите все длительности и кривые, которые есть в продукте: из прототипов, из кода, у разработки.
2. Сгруппируйте по размеру изменения: мелкое на месте, небольшой элемент, крупный элемент, смена экрана.
3. Сведите к трём-пяти длительностям и трём кривым: появление, уход, перемещение. Можно взять кривые Material Design 3.
4. Дайте имена по роли: «коротко», «появление», а не «200» и «кривая 2».

Часть 2 · Пересобрать три анимации, 40 минут

1. Выберите три: одно появление, один уход и одно перемещение.
2. Замените числа именами из набора. Если ничего не подходит, сначала решите, не лишний ли это переход.
3. Проверьте направление: новое появляется оттуда, где нажали, и уходит туда, где его можно найти снова.

Часть 3 · Описать «уменьшить движение» и проверить, 30 минут

1. Для каждой анимации решите, что будет вместо движения: оставить, проявление, убрать движение или только по нажатию.
2. Включите настройку на своём телефоне и пройдите сценарий в прототипе или в продукте.
3. Проверьте на медленной сети и на слабом телефоне: запрос не ждёт анимацию, рывков нет.

ПРОДУКТ: ______________________        Дата: __.__.____

НАБОР
длительности: быстро ___ мс · коротко ___ мс · средне ___ мс · долго ___ мс
кривые: появление    cubic-bezier(__, __, __, __)
        уход         cubic-bezier(__, __, __, __)
        перемещение  cubic-bezier(__, __, __, __)

АНИМАЦИЯ 1: ______________________
было: ___ мс, кривая ______________   стало: ________ / ________
откуда → куда: ______________________
при «уменьшить движение»: оставить / проявление / убрать движение / только по нажатию
как выглядит без движения: ______________________

АНИМАЦИЯ 2: ______________________
было: ___ мс, кривая ______________   стало: ________ / ________
откуда → куда: ______________________
при «уменьшить движение»: ______________________
как выглядит без движения: ______________________

АНИМАЦИЯ 3: ______________________
было: ___ мс, кривая ______________   стало: ________ / ________
откуда → куда: ______________________
при «уменьшить движение»: ______________________
как выглядит без движения: ______________________

ПРОВЕРКА
настройка включена на телефоне, сценарий пройден: да / нет
медленная сеть: запрос уходит сразу, ввод не блокируется: да / нет
слабый телефон: рывков нет: да / нет

Что должно получиться

• Набор длительностей и кривых с именами.
• Три анимации на этом наборе: было и стало.
• Описание поведения при «уменьшить движение» для каждой.
• Результат проверки на телефоне с включённой настройкой, медленной сети и слабом устройстве.

План работы: 20 минут на набор, 40 на пересборку, 30 на «уменьшить движение» и проверку. Всего — около полутора часов.

Частые сложности

• «У нас сложный продукт, четырёх длительностей мало». Проверьте, что делают лишние. Чаще всего это два почти одинаковых числа, между которыми разницу никто не видит.
• «Разработка говорит, что учесть настройку сложно». На сайте это одно условие в стилях, в приложениях — системный флаг. Сложно становится, когда решение «что вместо движения» не принято, и его приходится придумывать в коде.
• «Без движения непонятно, откуда взялась шторка». Проявление на месте и затемнение фона сохраняют связь. Если и так непонятно, дело не в движении, а в том, где шторка стоит.
• «Нет слабого телефона». Замедление процессора в Chrome — не замена, но первые рывки покажет. Попросите у разработки или у тестировщиков самый старый телефон из тех, что поддерживает продукт.

Движение в продукте связно, если

• Новое появляется оттуда, где нажали, и уходит туда, где его можно найти снова
• Длительности и кривые взяты из набора с именами по роли
• Для каждой анимации решено, что будет при «уменьшить движение»
• С включённой настройкой сценарий проходится и понятен
• То, что двигается само дольше пяти секунд, можно остановить
• Запрос не ждёт окончания анимации, ввод не блокируется
• Движение сделано сдвигом, масштабом и прозрачностью
• Анимация проверена на слабом телефоне

Что мешает

• Число на каждый случай. Пять переходов — пять длительностей, и приложение двигается вразнобой.
• Появление из ниоткуда. Экран подменяется, и связь с тем, что нажали, теряется.
• «Уменьшить» значит «убрать всё». Шторка открывается без следа, и человек не понимает, что произошло.
• Анимация перед запросом. На медленной сети к ожиданию прибавляется переход.
• Проверка только в редакторе. На слабом телефоне анимация дёргается, а увидят это пользователи.

В этом уроке учимся связывать движением состояния, работать с общим набором и с настройкой «уменьшить движение». На следующей ступени — описывать правила движения для всей команды.

• Understanding Success Criterion 2.3.3: Animation from InteractionsW3C WAI · на английском · бесплатноКому мешает движение и чем оно опасно, почему смена цвета и прозрачности движением не считается и какую анимацию считать необходимой. Критерий уровня AAA.
• Motion и AccessibilityApple Human Interface Guidelines · на английском · бесплатноЧто Apple советует при «уменьшить движение»: меньше автоматического движения, масштаба и приближения, пружины без отскока, растворение вместо сдвига — это абзац в разделе Cognitive страницы Accessibility. Страница Motion — про движение вообще: не анимировать частые действия и не заставлять ждать конца анимации.
• prefers-reduced-motion: Sometimes less movement is moreweb.dev, Томас Штайнер, 2019 · на английском · бесплатноКак сайт узнаёт о настройке: медиазапрос prefers-reduced-motion в CSS и JavaScript, анимированная картинка с неподвижной заменой, демо с появлением при прокрутке. Статья для разработки 2019 года; «вибрирующая» кнопка регистрации в примере — как раз то движение, которое урок убирает.
• How to create high-performance CSS animations и Why are some animations slow?web.dev · на английском · бесплатноКакими свойствами двигать — transform и opacity, — почему top и left тормозят и как проверить это в DevTools. Вторая статья объясняет, откуда 16 мс на кадр и что браузер успевает за это время. Справка для разработки 2020 года.
• Easing and duration: tokens and specsMaterial Design 3 · на английском · бесплатноШестнадцать длительностей от 50 до 1000 мс и кривые появления, ухода и перемещения с именами токенов и значениями для CSS. Длительности здесь длиннее, чем в уроке: переключатель 200 мс, раскрытие на весь экран 500 мс; саму систему Google больше не развивает.