Переходы между экранами и состояниями: как движение объясняет, куда вы попали

Когда один экран мгновенно подменяется другим, человеку приходится заново собирать картину: это новая страница, окно поверх старой или та же страница, только прокрученная? На телефоне меняется весь экран, и связь между «было» и «стало» теряется. Nielsen Norman Group отмечает, что аккордеоны, якорные ссылки и полноэкранные меню, появляющиеся мгновенно, дезориентируют: без анимированной подсказки непонятно, открылась новая страница или что-то другое.

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

Интерфейс удобно представлять как пространство, по которому человек перемещается. Тогда у каждого направления своё движение, и оно одинаково во всём продукте. Nielsen Norman Group описывает такую анимацию как понятную пространственную метафору: она подсказывает, где пользователь находится в информационном пространстве. Самый наглядный пример — путь покупателя в каталоге.

Главное правило — обратимость. Apple Human Interface Guidelines приводит пример: если панель появилась, съехав сверху, человек не ожидает, что закрывать её нужно смахиванием вбок. Движение создаёт ожидание, и жест закрытия должен ему соответствовать. Поэтому в проектах InterLAB мы описываем систему переходов вместе с дизайн-системой: один набор движений и длительностей на весь продукт, а не решение «на глаз» для каждого экрана.

Самый сильный приём непрерывности — переход с общим элементом (shared element transition). Человек нажимает на карточку в каталоге, и она не исчезает, а раскрывается: картинка растёт до шапки новой страницы, заголовок переезжает на своё место, остальное содержимое проявляется вокруг. Глаз следит за одним объектом и не теряет его, поэтому вопрос «туда ли я нажал» просто не возникает.

Тот же принцип работает внутри одного экрана, когда меняется не страница, а состояние:

• Аккордеон: раскрываемый блок плавно растёт, а контент ниже съезжает, а не прыгает — видно, что именно открылось
• Вкладки: индикатор активной вкладки переезжает под новую, содержимое сменяется коротким проявлением
• Удаление из списка: строка схлопывается, соседи подтягиваются — понятно, что пропало и что ничего не сломалось
• Добавление в список: новая строка раздвигает соседей и проявляется на своём месте, а не возникает вместе с рывком всего списка

Чтобы такие перестановки шли плавно даже на слабом телефоне, разработчики используют приём FLIP. Название складывается из первых букв четырёх шагов:

Долгое время плавные переходы между страницами были доступны в основном одностраничным приложениям: на обычном сайте браузер при переходе по ссылке просто показывал новую страницу. View Transitions API меняет это. Браузер делает снимок старого состояния, применяет новое и анимирует разницу. По умолчанию это перекрёстное проявление (cross-fade), а элементам с одинаковым свойством view-transition-name на старом и новом экране можно задать перелёт из одной позиции в другую — так на вебе и делается общий элемент.

В мобильных приложениях многое уже встроено в стандартные компоненты навигации, и лучше опираться на них, чем изобретать своё: к этим движениям пользователь привык в каждом приложении на телефоне. На iOS для отдельной задачи Apple HIG рекомендует модальные листы (sheets) и всплывающие панели. На Android в Jetpack Compose общий элемент собирается из SharedTransitionLayout и модификаторов sharedElement и sharedBounds, а предиктивный жест «Назад» показывает анимированное превью экрана, на который человек вернётся, ещё до завершения жеста.

Самый неприятный переход — когда анимация закончилась, а показывать нечего: белый экран или одинокий спиннер. Человек не понимает, работает ли приложение. Решение — каркас (skeleton): экран приходит сразу, с серыми блоками на месте заголовка, картинки и строк, а данные проявляются по мере загрузки.

Nielsen Norman Group рекомендует каркасы для загрузки страницы с ожиданием до 10 секунд, а для более долгих операций — индикатор прогресса. Каркас должен повторять структуру будущей страницы: «пустая рамка» из шапки и фона без очертаний контента, по оценке NN/g, по сути не лучше спиннера.

Второй приём — оптимистичная навигация: переход начинается сразу по нажатию, не дожидаясь ответа сервера.

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

Переход забирает у человека время при каждом нажатии, поэтому длительность важнее эффектности. Nielsen Norman Group считает 200–300 мс подходящими для крупных изменений экрана вроде появления модального окна, 400 мс — уже очень медленной анимацией для больших перемещений, а около 500 мс движение начинает раздражать. Там же отмечено, что появление обычно делают чуть длиннее исчезновения.

• Анимируем transform и opacity — по рекомендации web.dev браузер обрабатывает их дешевле, чем смену размеров и отступов
• Не запускаем посреди перехода тяжёлые эффекты: размытие на весь экран, большие тени
• Проверяем на недорогом Android-телефоне: дёргающийся переход хуже, чем никакого
• Не блокируем ввод: если человек нажал «Назад» посреди анимации, переход должен прерваться и развернуться, а не доиграть до конца

Отдельная тема — режим уменьшенного движения. Если человек включил его в настройках системы, сайт узнаёт об этом через медиазапрос prefers-reduced-motion. Критерий WCAG 2.3.3 описывает требование: анимацию, которую запускает взаимодействие, должно быть можно отключить, если она не необходима. Для переходов это значит: вместо сдвигов, увеличения и перелёта карточки — короткое проявление на месте. Смысл «экран сменился» сохраняется, укачивающего движения нет.