![](https://habrastorage.org/webt/lk/zv/h2/lkzvh2e7lxr6j1jhb6oqjsliiu8.jpeg)
Современная мобильная аудитория с каждым годом предъявляет всё более высокие требования к качеству приложений и сервисов. И в первую очередь это касается проектирования взаимодействий и мобильных анимаций.
Каждый день мы обмениваемся сообщениями, используем социальные сети, мессенджеры, и многие из этих сервисов содержат десятки нестандартных продуманных анимаций.
Кастомные (нестандартные) анимации — это большое поле для экспериментов и развития приложения. Какие знания понадобятся дизайнеру и какие проблемы могут поджидать в процессе разработки? Давайте рассмотрим эти вопросы на примере приложения iFunny.
Основы
Документация
Начнём с теории. Три следующих документа нам помогут лучше понять, что представляют собой анимации в мобильных интерфейсах:
- Material Design от Google. Здесь в основном описываются анимации с математической и инженерной точки зрения. Это базовый документ для любых дизайнеров, которые работают с интерфейсами. В нём найдётся множество рекомендаций по дефолтным «безопасным» значениям скорости и ускорений, базовые принципы хореографии движения объектов, примеры и многое другое.
- Human Interfaces Guidelines от Apple. В этом документе анимации описываются с эмоциональной точки зрения. То есть какие ощущения и впечатления у пользователя должна оставлять анимация в интерфейсах.
- 12 принципов анимации Диснея. Мультипликаторы Фрэнк Томас и Олли Джонстон в 1981 году опубликовали книгу «Иллюзия жизни: анимация Диснея», в которой рассказали о 12 основных принципах реалистичной анимации. Несмотря на то, что эти правила создавались для мультипликаций, многие из них напрямую перешли в современные интерфейсы.
Назначение
Каждая анимация должна чётко выполнять свою функцию. Поэтому важно понимать, к какой группе она относится и какие будут ограничения в плане проектирования.
Условно все анимации можно разбить на 3 большие группы:
- Вспомогательные. Наиболее объёмная группа. Эти анимации упрощают навигацию, отражают положение того или иного объекта в системе, демонстрируют иерархию объектов приложения, акцентируют внимание и делают интерфейс в целом интуитивно понятным для пользователя.
Один из примеров такой анимации — плавный выезд картинки из общей галереи, который демонстрирует иерархию объектов и имитирует действие в реальном мире, когда мы берём картинку и подносим ближе, чтобы её рассмотреть. - Передающие статус системы и индикаторы обратной связи с пользователем. Основная задача этой группы анимаций — показать пользователю в реальном времени, где он находится, что происходит с приложением, и отобразить реакцию системы на совершённое пользователем действие.
Пример — спиннер, появляющийся при обновлении страницы профиля. - Развлекательные. Сюда можно отнести любые анимации, основное назначение которых — развлечь пользователя. В iFunny встречаются такие анимации при оценке мема или репосте в ленте Featured и Collective.
Несмотря на то, что эта группа накладывает минимальные ограничения на дизайнера, внедрять её стоит очень дозированно и только там, где она уместна, поскольку каждая подобная анимация отнимает время у пользователя и может стать преградой в достижении конечной цели.
Длительность
По умолчанию Android предлагает три основных значения длительности анимаций:
- 200 мс — короткая;
- 400 мс — средняя;
- 500 мс — долгая.
Конечно, это не значит, что нельзя использовать другие значения. Экспериментировать можно и нужно, но на начальном этапе данные значения смогут уберечь от ошибок в выборе оптимального варианта.
Если говорить о рекомендуемом диапазоне значений длительности анимаций в мобильных интерфейсах, то это примерно от 100 до 700 мс. Эти цифры основаны на особенностях зрительного восприятия информации человеком, а именно на саккаде и фиксации.
Ускорение
Какими бы оптимальными ни были значения скорости и длительности, линейное движение объектов всегда выглядит неестественно, фальшиво и будет раздражать ваших пользователей.
Рассмотрим основные виды кривых ускорения, используемых в мобильной разработке.
![linear](https://habrastorage.org/webt/qg/0m/ku/qg0mkunviwdk1bmoqyzry7ervii.png)
Linear: движение с равномерной скоростью. Выглядит такая анимация всегда плохо и искусственно, поскольку в физическом мире все объекты движутся с неравномерной скоростью.
![ease-in](https://habrastorage.org/webt/br/ma/e6/brmae6grx6qp_x4qxnm21i56kl0.png)
Ease-in: медленное начало и быстрое завершение. Эта кривая используется достаточно редко в интерфейсах, поскольку из-за длительного разгона анимация выглядит всё ещё заторможенной.
![ease-out](https://habrastorage.org/webt/h_/75/xz/h_75xzjo6usuf8hzl-1zujincic.png)
Ease-out: быстрое начало и торможение. Используется достаточно часто. Быстрое появление объекта в начале движения не заставляет пользователя ждать, а плавное торможение имитирует поведение движущихся объектов в физическом мире. Выглядит естественно и приятно.
![ease-in-out](https://habrastorage.org/webt/lk/8t/ry/lk8trypjh_gfj-2-dlp2fdz5_5k.png)
Ease, ease-in-out: медленное начало, разгон и торможение. Эти кривые ускорения используются чаще всего. Выглядят аккуратно, естественно и соответствуют принципам анимации Диснея: плавное начало и плавное завершение.
Но при использовании кривых ease и ease-in-out в такой программе, как After Effects, изменять форму кривой стоит осторожно, чтобы анимация не стала очень резкой.
Опыт iFunny
От теории перейдём к практике на примере iFunny. Разберём сложности и проблемы, с которыми пришлось столкнуться, и посмотрим финальные варианты некоторых анимаций.
Главное меню
Поскольку в iFunny было решено отказаться от привычного «гамбургера», то для нестандартного меню нужна была и кастомная анимация.
Один из начальных прототипов выглядел так:
![menu](https://habrastorage.org/webt/lz/dw/dz/lzdwdziapb1rqks4sx7i0ag34ec.gif)
Всё в нём было неплохо: и плавное появление, и проработанная общая хореография движения. Использовалась кривая ускорения ease-in-out.
Анимация была максимально плавной и общий тайминг составлял 700 мс.
Но любое решение в анимации, как и в дизайне в целом, должно быть взвешенным и обоснованным. Некоторое время спустя стало заметно, что приходится ждать всё дольше и дольше, пока все элементы не займут своё конечное положение при новом вызове меню. Попытка ускорить всю анимацию сделала её резкой и ещё менее приятной для восприятия.
![menu](https://habrastorage.org/webt/jv/vb/i7/jvvbi7dt74jx-zbcdnf6uywj-x4.gif)
В этом случае вовремя вспомнили о назначении анимации. Поскольку вызов навигационного меню — это действие, совершаемое пользователями сотни раз за день, то его основная задача — предоставлять быструю и комфортную навигацию между разделами.
На помощь пришло очевидное и верное решение — упростить. Итоговая анимация навигационного меню выглядела так:
![menu](https://habrastorage.org/webt/ix/r_/tf/ixr_tfxzqzrpukvoup9lrwjp_9g.gif)
Общее слаженное движение сменилось на последовательное появление элементов из прозрачности.
Т.к. ощущение выпадения меню сохранялось, то задний фон был максимально упрощён. Теперь он, как и все пункты меню, появлялся через альфу.
Итоговый вариант сохранил изначальную задумку и позволил уменьшить тайминг до 250 мс (против 700 мс в первоначальном варианте). Анимация осталась привлекательной и стала выполнять поставленную перед ней задачу.
Галерея мемов
Ещё одна основная анимация приложения iFunny — прокрутка галереи мемов.
Хотелось поддержать общую концепцию многослойности приложения.
Первая версия выглядела так:
![gallery](https://habrastorage.org/webt/8o/go/d-/8ogod-oypvkrh57kappfbtkxs4m.gif)
Но оказалось, что при скролле галереи мемы наезжали друг на друга и отвлекали внимание от новоприбывшего элемента. Также всплыла проблема пользовательского опыта. Классический вид галереи — горизонтальный или вертикальный. В нашем варианте было ощущение, что мемы складываются в большую стопку, и возврат к предыдущим мемам был уже не таким естественным, как свайп вправо, при котором мем перемещается следом за движением пальца.
Недостатки были устранены возвратом к классической галерее с небольшим уменьшением масштаба уезжающего мема.
![gallery](https://habrastorage.org/webt/-1/l_/cz/-1l_czbtkfbfpgfzgydrhofigly.gif)
Здесь ещё стоит обратить внимание на интересный момент в плане разработки. Анимация не стала проще — осталось смещение и уменьшение масштаба уезжающего мема. Но визуально галерея стала легче, опрятнее и сохранила вид, привычный пользователям.
Прочие анимации
Большую часть времени проектирования дизайнер тратит на разработку куда менее заметных и массивных анимаций. Такая работа тоже очень важна: именно из деталей формируется общее ощущение от работы с интерфейсом.
Например, последовательное появление мемов при переходе в вертикальную галерею, которое проводит взгляд пользователя сверху вниз, задавая вектор последующего движения.
![explore](https://habrastorage.org/webt/po/3m/mg/po3mmgu4juhrhlgptv_ilzysjpm.gif)
Удаление ответа на комментарий. Благодаря такому решению, после удаления комментария взгляд пользователя возвращается на то же место, где он был до вызова контекстного меню.
![comments](https://habrastorage.org/webt/vh/ix/do/vhixdo1cmimqutqetgyl7_meens.gif)
На экране личного профиля пользователя его никнейм располагался под аватаркой, а при скролле переезжал в тулбар. Таким образом, пользователь мог в любой момент посмотреть, чей это профиль.
![comments](https://habrastorage.org/webt/pl/yw/us/plywusbqnvwswgwvgaz6lbdpcjm.gif)
Это решение, кстати, было подсмотрено у Twitter. На самом деле нет ничего зазорного в том, чтобы заимствовать некоторые удачные идеи.
Вкладки. Чтобы сохранить воздушность и аккуратность внешнего вида, подписи неактивных вкладок скрываются. Название появляется только в активном состоянии.
![comments](https://habrastorage.org/webt/7g/os/wd/7goswdtpwp1lnynsihmgaksccoi.gif)
Работа дизайнера не заканчивается на передаче метрик анимации и описании общих принципов поведения элемента. Иногда задача требует составления небольших алгоритмов, которые предусматривают корректное отображение элементов в нестандартных ситуациях. Например, раскрытие ответа на комментарий.
Изначально спиннер показывался сразу от момента тапа по иконке раскрытия ответов до момента их появления. Но при быстром интернете это смотрелось неопрятно.
![comments](https://habrastorage.org/webt/8m/ov/bk/8movbkoq9syayjk5ktpxx9csit0.gif)
Для этого случая были придуманы несложные правила, которые позволяли обрабатывать ситуации с медленным и быстрым интернетом по отдельности.
В начале уже говорилось о том, что нижняя граница длительности анимации для комфортного восприятия человеческим глазом — это 100–200 мс. Именно поэтому мы ввели задержку появления спиннера. То есть если ответы успевали загрузиться быстрее, чем за 200 мс, то спиннер не отображался.
![comments](https://habrastorage.org/webt/dr/eg/y5/dregy5zseqajy0_dkn0ruirq9ho.gif)
Если ответы не успевали загрузиться за 200 мс, спиннер отображался с 201-й миллисекунды. Дополнительно, чтобы исключить кратковременное моргание, было задано минимальное время отображения спиннера.
![comments](https://habrastorage.org/webt/yp/44/_o/yp44_ox8jiv6zig8sbylkheobtm.gif)
Очевидно, что анимации в мобильных интерфейсах — это важная и нужная часть дизайна взаимодействия. Тщательно продуманная мобильная анимация облегчает потребление контента, положительно влияет на лояльность к бренду и даже увеличивает количество времени, которое пользователь проведёт в приложении. И развитие в этой области — неотъемлемая часть любой сильной и прогрессивной команды.
А вы экспериментируете с мобильными анимациями? Делитесь с нами своим опытом и решениями в комментариях!