Перевод статьи Communicating Animation с сайта alistapart.com для css-live.ru. Автор — Рэйчел Нейборс.

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

• Из-за трудностей коммуникации в больших разнородных командах нелегко понимать и решать вопросы анимаций сообща.
• Из-за недостаточных вводных разработчикам бывает трудно к чему-то продвигаться.
• Из-за недостатка внимания или уважения к другим членам команды выходят однобокие реализации, где учтены голоса одних ценой других. Когда речь заходит об анимации, важно, чтобы каждый был услышан.

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

Большинство примеров анимации в документации отражают этот раскол четким делением на две категории: либо тематические и обучающие, как в руководстве Google по материальному дизайну, либо подробные и конкретные, как в методологии дизайна Lightning фирмы Salesforce . Дизайнеры хотят предоставить наглядные подсказки и плавные переходы от темы к теме, наряду с обучающими материалами, стараясь привлекать внимание к анимации как в пределах фирмы, так и среди широких масс веб-дизайнеров и разработчиков. Разработчики же стремятся четко определять и жестко прописывать правила для анимации, чтобы она соблюдала единый стиль и ее было проще поддерживать.

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

• Документация подробно описывает, где что и почему так.
• Параметры по умолчанию дают строительные блоки и правила, позволяющие быстро запустить новый проект.
• Единообразие обеспечивает общий язык и стандартное поведение.
• Подсказки помогут будущим дизайнерам принимать разумные решения.

На момент публикации, примера Абсолютного Руководства/Шаблона/Заготовки/Чего угодно по стилю анимации, идеально объединяющего всё перечисленное, нет. Может быть и так, что руководство-шаблон, устраивающее всех, никогда не появится. Одним организациям нужно больше из указанного, чем другим, в зависимости от проекта и от опыта команды в работе с анимацией. Но у всех подходов есть общие черты, которые можно собрать вместе и создать Идеальную Документацию Анимации для наших собственных команд. Давайте взглянем.

Вводные для разработчиков

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

Поэтому во многих компаниях дизайнеры создают анимации в After Effects или Photoshop, а потом так и отдают их разработчикам. И разработчики должны разбирать эти видеоролики и гифки, чтобы выяснить, что и с какой скоростью меняется. Из-за этого разработчикам бывает особенно трудно их реализовать, и к анимации начинают относиться как к чему-то такому, на что хочется тратить время в последнюю очередь.

Я сама однажды потратила шесть часов на преобразование анимированной гифки в SVG, вглядываясь в каждый пиксель. Если бы дизайнер передал мне нужные значения, я сделала бы эту анимацию ровно за полчаса, как максимум. Мы первым делом заглянем в эти значения — функции плавности, задержки и анимируемые свойства. Ради простоты и единообразия нам нужно включать их в документацию и использовать по всей системе столько раз, сколько потребуется.

Функция плавности

Функция плавности описывает скорость, с которой что-либо меняется за какой-то период времени. Ее корни тянутся из классической студийной мультипликации, где ее называли «смягчением» или «замедлением». Функции плавности — это сокращенная запись для темпов ускорения, замедления и отскока. Мы можем вызвать типовые функции замедления с помощью ключевых слов CSS типа «ease-in» и «ease-out», но когда у всех вокруг одни и те же стандартные значения, все дизайны начинают казаться одинаковыми.

Функции плавности дают нам возможность почти незаметно выделить наш интерфейс из прочих. Нам нужны собственные функции плавности, подчеркивающие черты нашего бренда — будь он профессиональным, забавным, элегантным или даже грозным. И именно для этого созданы кубические кривые Безье. Кубические кривые Безье — наборы чисел, которые можно передавать в CSS и JS-библиотеки, чтобы анимации в них менялись в отведенных им промежутках так, как нам надо. Можно отталкиваться от сайтов вроде easings.net или делать своё с помощью браузерных отладчиков.

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

• Взаимодействия по инициативе человека кажутся быстрее и естественнее, если откликаются сразу же. Замедление (переход от быстрого к медленному), или ease-out, дает немедленную обратную связь, плавно сходящую на нет.
• Реакции системы не так пугают, если их кривая ускоряется, переходя от медленного к быстрому, т.е. ease-in.
• Изменения прозрачности и цвета часто лучше всего выглядят с более постоянной скоростью, но вы можете нарочно нарушать это правило ради собственных эстетических задач.

Большинство методологий дизайна извлекают пользу от указания как минимум кривых ease-out, ease-in и изменения цвета.

Длительность

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

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

Есть верхний и нижний пределы. Хотя человеческий глаз воспринимает картинку всего за 13 миллисекунд, на движение глаз требуется от 70 до 700 миллисекунд (согласно модели обработки информации человеком). Значения в 200–300 миллисекунд — типичные «рабочие лошадки» на временной шкале, от нажатия кнопки до второстепенных анимаций (постоянство этих цифр в мире разработки игр и веба особенно интересно в свете недавнего исследования, по которому выходит, что мы воспринимаем мир «отрывками» по 400 миллисекунд). Более короткие периоды подходят для изменения цвета и прозрачности, которые легко схватываются глазом. Более длинные — для изменений на большой площади, вроде переходов между страницами, или перемещений на большие расстояния, вроде перетягивания объектов или выезжающего меню на большом экране.

Лучше задавать длительности не в секундах, а в миллисекундах. Хотя большинство библиотек для анимации принимают и то, и то, таймеры в JavaScript и Web Animations API принимают только миллисекунды. Кроме того, многим проще работать с нулями, чем с дробными числами (хотя это скорее спор о вкусах, как табы и пробелы).

Свойства

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

Знание того, какие свойства мы собираемся анимировать, очень кстати при описании анимаций раскадровками и спецификациями, а также когда мы создаем особый «словарик» анимаций специально для нашего проекта.

Создание языка анимации

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

Словари описывают отдельные детали. Из таких микроанимаций можно составлять макроанимации — например, модальное окно, которое сначала проявляется на экране, а потом выскакивает на передний план, чтобы привлечь внимание пользователя.

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

Обмен наглядной информацией

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

Раскадровки

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

Такие раскадровки могут быть как вольными набросками (если проектированием взаимодействий занимается маленькая команда, в которой каждый тесно связан со всеми стадиями разработки), так и очень подробными и проработанными (для спецификаций и контроля). Мне как консультанту бывает трудно встраивать видеоролики и гифки в PDF для менеджеров, которые должны пояснить им, где возникают проблемы с анимацией. Так что для долгосрочного хранения я прикладываю раскадровку.

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

Раскадровки представляют взаимодействия и анимации с помощью слов и иллюстраций. Каждое анимированное взаимодействие можно разбить на кадры «до» и «после»; ничто не мешает добавить и промежуточный кадр, чтобы показать, как мы переходим от одного к другому. Благодаря языку понятнее, почему происходят именно эти изменения. Слова такого типа служат мощным инструментом мышления. Обоснование анимаций словами помогает отделить необходимые анимации, которые мы можем отстоять, от тех, без которых в принципе можно бы и обойтись.

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

Черновые наброски

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

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

Любимая программа для создания анимаций в сфере дизайна движений — это AfterEffects. Веб-дизайнерам может быть привычнее создавать похожие на наброски анимаций демо-примеры в Keynote, чтобы кликами проматывать их на совещаниях. Их можно записывать программами для скринкастов, вроде Quicktime или Camtasia. А некоторые инструменты визуального прототипирования типа Principle умеют экспортировать в видео, убивая двух зайцев сразу.

Прототипы

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

Есть два подхода к прототипам: делать их в коде или с помощью специальных программ для прототипирования. Разработчики обычно предпочитают первый, часто с опорой на фреймворки типа framer.js и Zurb’s Foundation; дизайнерам ближе второй, в виде программ типа Invision App и UX Pin. В обоих подходах членам команды придется потратить некоторое время на изучение новой системы, тем самым дополнительно вовлекаясь в процесс.

Большинство программ для прототипирования с функцией анимации, типа Pixate и Principle, рассчитано на приложения. Но и веб не отстает с продуктами вроде UXPin, а фирма Invision — неиссякаемый источник энергии для прототипирования веб- и нативных приложений — подтвердила свой курс на развитие инструментария для анимации, купив Easee.

Прототипы в виде кода, в отличие от раскадровок, ужасно трудно документировать; их могут прочесть лишь разбирающиеся в коде члены команды, а файлы перед проверкой часто нужно по-особому организовывать, а то и компилировать. Стороннему агентству придется немало попотеть, чтобы выдать готовый интерфейс под нужды конкретного бренда, отталкиваясь от кучи чернового кода на входе.

Дайте два!

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

Анимация как командная игра

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

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

• Совместное документирование. Если формат документации позволяет каждому вносить свой вклад — и люди его вносят, хотя бы парой слов — проект сразу становится для них не чужим.
• Командные упражнения в создании промежуточных кадров. Я использую такие упражнения, чтобы помочь разнородным командам научиться работать вместе. Возьмите наброски кадров «до» и «после» и раздайте каждому карточки, чтобы перебрать мозговым штурмом все возможные анимации, с помощью которых можно перейти из точки А в точку Б.

• Взращивайте и защищайте. Команды, в которых некому отстаивать движения и анимации, не могут поддерживать их долго. Кто-то должен полюбить анимацию настолько, что думать о ней станет для него второй натурой, как мы думаем о цвете или шрифтах. Иначе анимация рискует остаться чем-то побочным, как это часто случается с доступностью или тестированием со стороны пользователя. Многие организации исходят из предположения, будто начального усилия достаточно, чтобы определить все будущие неотъемлемые части процесса разработки.
• Найдите «соучастника», а лучше двух. Нельзя упускать из виду возможных «соучастников». Одного защитника мало. Рано или поздно мы все переходим на другие проекты, и здоровая система не должна зависеть от одной своей части.
• Делайте это несмотря ни на что. Иногда людям нужно просто увидеть, насколько анимация меняет всё, чтобы поверить в ее важность. Если что, попросите прощения потом.

Библиотеке шаблонов и, скажем, приложению интерактивной книги  понадобится разная документация. Важно лишь ясно описать и донести эту информацию, а также приучить других задумываться об анимации. Люди боятся того, чего не понимают, боятся перемен. Обучение, общение и сотрудничество обращают эти страхи в энтузиазм и жажду действия.

Нет единственного верного способа документировать анимации. Но когда мы работаем вместе с командой, общими усилиями мы найдем правильное направление. Не будьте одиноким волком анимации: найдите или сколотите свою стаю. Соберите других фанатов анимации из разных областей типа пользовательского опыта, фронтенд-разработки, визуализации данных, дизайна, даже маркетинга. Чем больше точек зрения, тем надежнее наш подход к анимации и тем проще получить поддержку с разных сторон. Все вместе мы можем найти свой собственный «путь анимации», идеальный именно для нас.

P.S. Это тоже может быть интересно:

• Не боритесь с каскадом, управляйте им!
• Голограммы, пленочные засветки и шейдеры на чистом CSS
• «Запашки» кода React-компонентов