Сложный интерфейс: когда анимация помогает, а когда мешает?

Товар летит в корзину. Значок подпрыгивает, счётчик меняется, кнопка возвращается в исходное состояние. Всё заняло меньше секунды и выглядит как завершённое действие. Через мгновение приложение сообщает, что добавить товар не удалось.

Что именно означал этот полёт? Если «нажатие принято», почему он выглядел как подтверждение покупки? Если «товар добавлен», откуда взялась ошибка? Можно убрать анимацию, но противоречие останется: интерфейс успел сообщить результат, которого система ещё не знала.

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

Кому принадлежит слово «готово»

Возьмём корзину, содержимое которой хранится на сервере. Нажатие кнопки означает намерение добавить товар. Запрос отправлен — операция выполняется. Ответ получен — приложение узнало результат. Это три разных момента, даже если при быстрой сети они кажутся одним.

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

Это не запрет на оптимистическое обновление. Некоторые продукты сразу добавляют товар локально и отправляют изменение позже. Тогда экран показывает предварительное состояние, за которое приложение обязано ответить: что случится при отказе, как пользователь узнает об откате, переживёт ли изменение закрытие экрана. Если корзина по правилам продукта полностью локальна, ждать сервера вообще не требуется. Один и тот же визуальный эффект может быть честным в одном контракте и вводить в заблуждение в другом.

Вопрос для ревью конкретнее, чем «нужна ли анимация»: какой факт уже установлен в момент её запуска? Если установлен только факт нажатия, переход не должен изображать подтверждённый результат. Можно подсветить кнопку или показать состояние ожидания. Полёт товара к корзине лучше оставить моменту, когда корзина действительно приняла товар, либо явно показать, что результат предварительный.

Здесь важно не спутать визуальную точность с устройством серверного API. Ответ «успешно» тоже может иметь разные значения: изменение записано окончательно, поставлено в очередь или принято для дальнейшей обработки. Приложение не должно обещать больше, чем означает этот ответ. Анимация лишь делает уже выбранное обещание заметнее.

Доставка меняется быстрее, чем приходит расчёт

Теперь пользователь выбирает курьерскую доставку. Экран сразу раскрывает адресные поля; это локальное следствие выбора, его не нужно ждать от сервера. Но окончательная стоимость зависит от адреса и расчёта доставки. Пока расчёт идёт, старую сумму нельзя молча выдавать за новую.

Через секунду пользователь переключается на самовывоз. Первый запрос ещё не завершился, второй уже отправлен. Ответ на курьерскую доставку приходит последним. Если просто принять последний полученный ответ, экран покажет стоимость курьера рядом с выбранным самовывозом. Плавный переход суммы сделает ошибку не менее опасной, а убедительнее.

Для этого сценария сначала нужен договор о состоянии экрана:

Что произошло	Что уже можно показать	Чего показывать нельзя
Выбрана доставка курьером	Выбор и адресные поля; расчёт выполняется	Новую итоговую сумму как подтверждённую
Выбран самовывоз до ответа	Самовывоз и расчёт для него	Ответ прежнего выбора как актуальный
Пришёл ответ для текущего выбора	Рассчитанную сумму и условия	Видимость успеха до проверки соответствия ответа выбору
Расчёт завершился отказом	Причину или понятный путь повтора	Прежнюю цену под видом действующей

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

// Поле объекта, который управляет одним оформлением заказа.
int _quoteRevision = 0;

Future<void> selectDelivery(final DeliveryMethod method) async {
  final revision = ++_quoteRevision;
  showCalculating(method);

  try {
    final quote = await loadQuote(method);
    if (revision != _quoteRevision) return;
    showConfirmedQuote(method, quote);
  } catch (error) {
    if (revision != _quoteRevision) return;
    showQuoteError(method, error);
  }
}

Это схема границы, а не готовая реализация экрана: showCalculating, loadQuote и другие функции здесь обозначают обязанности приложения. showCalculating обязана пометить прежнюю цену как неактуальную для нового выбора и не дать подтвердить заказ с ней как с окончательной. Пример предполагает, что loadQuote(method) возвращает расчёт именно для переданного способа доставки либо ошибку; код приёма ответа от сервера должен это гарантировать или проверить. При каждой смене способа доставки новый номер делает предыдущий ответ неактуальным в пределах этого экземпляра оформления заказа. В настоящем продукте дополнительно решают, нужно ли отменять запрос, что делать с промежуточными ценами и допускается ли покупка до получения расчёта. Номер запроса не заменяет этих решений. Он лишь не даёт позднему ответу прежнего запроса стать текущей ценой и запустить связанный с ней переход.

Анимация появляется после решения, а не вместо него

У Flutter есть подходящие средства для смены представления: неявные анимации, AnimatedSwitcher, управляемые переходы. Их выбор — последний шаг. Сначала у экрана должны быть определены состояния «рассчитываем», «цена подтверждена» и «расчёт не удался», а также события, которые переводят одно состояние в другое.

Например, раскрытие адресных полей может сопровождать локальную смену выбора. Изменение итоговой суммы — только получение актуального расчёта. Ошибка не должна запускать тот же эффект, что успех, лишь потому, что оба события заменили один текст другим. Если нужен статус ожидания, он должен оставаться понятным без вращающегося индикатора: сам индикатор не сообщает ни причину задержки, ни оставшееся время.

У AnimatedSwitcher есть деталь, о которой легко забыть: при быстрой замене содержимого несколько прежних дочерних элементов могут ещё завершать свои переходы. Для ценника, который быстро меняется из-за нескольких запросов, это повод проверить не только кадры анимации, но и то, какой текст человек видит, пока старые элементы уходят. Виджет не исправляет ошибочную последовательность состояний. Он аккуратно её показывает.

Можно остановиться на мгновенной смене цены и коротком выделении нового итога. Можно использовать плавный переход, если на выбранных устройствах он помогает проследить изменение. Здесь нет универсальной длительности или кривой движения. Есть проверяемый смысл: после смены доставки человек должен понимать, какая сумма относится к текущему выбору и окончательная ли она.

А если движение отключено?

Пользователь может попросить операционную систему уменьшить или убрать анимации. Приложению не требуется выяснять причину. Требуется сохранить смысл сценария в другом представлении.

На Android Flutter отражает системное Remove animations через disableAnimations; виджет может прочитать значение с помощью MediaQuery.disableAnimationsOf(context). На iOS Reduce Motion доступен отдельно через AccessibilityFeatures.reduceMotion и не устанавливает MediaQueryData.disableAnimations. Поэтому проверка только одного флага не покрывает обе платформы. Если настройка меняется при открытом приложении, собственное поведение тоже должно обновиться; для таких изменений Flutter предоставляет уведомление WidgetsBindingObserver.didChangeAccessibilityFeatures.

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

Apple в критериях Reduced Motion прямо различает декоративное движение и движение, которое передаёт смысл: последнее не обязательно просто удалять, иногда его лучше заменить более спокойным способом показать изменение. Это хороший тест и для обычного режима. Если после отключения полёта товара оказывается, что подтверждения больше нет, исходный интерфейс был понятен только благодаря эффекту.

При этом сокращение движения не означает, что всё нужно менять мгновенно любой ценой. Резкий скачок большого блока тоже способен лишить человека ориентира. Задача — сохранить результат и понятную связь состояний, не навязывая конкретную траекторию. Собственная настройка внутри приложения может уточнять системную, но не должна заставлять человека заново искать уже выраженное предпочтение.

Как понять, окупился ли сложный переход

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

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

Есть и техническая цена. Быстрая серия смен доставки, длинные цены, крупный текст и слабое устройство способны обнаружить проблемы, которых нет в макете. Flutter рекомендует профилировать анимации в profile mode, потому что debug-сборка не отражает типичную производительность выпуска. Пока на целевых устройствах нет измерений, утверждать, что конкретный переход «плавный и экономный», нельзя. И даже хорошие кадры не доказывают, что человек понял итог.

Так появляется практический критерий выбора. Если переход сообщает только «кнопку нажали», он не должен выглядеть как «заказ изменён». Если сообщает подтверждённый результат, он должен запускаться после подтверждения именно актуальной операции. Если движение ограничено, тот же результат остаётся видимым и проверяемым. Если эффект дорого поддерживать, но его пользу нельзя показать на задаче пользователя, сложность ничем не оплачена.

Flutter даёт свободу двигать почти любой элемент. Эта свобода ценна не количеством анимаций, а возможностью точно связать поведение интерфейса с тем, что система действительно знает. Всё остальное — декорация. Иногда уместная. Но декорации не стоит доверять слово «готово».

---

ArkTelos · ArkTelos Lab Каналы лаборатории: Telegram RU | Telegram EN Новости ArkTelos: Telegram RU | Telegram EN