Редизайн иконок файлов для всей линейки продуктов Adobe Статьи редакции
В команде Adobe Design Brand мы создаём брендинг для всех наших настольных, мобильных и веб-продуктов. Фирменный элемент может быть любым: от двубуквенного логотипа до заставки и иконок в интерфейсе самого продукта.
Часто незаметный, но весьма наглядный элемент — иконка типа файла. Тип файла — это имя, заданное конкретному виду файла, который может создавать приложение, например, DOC для файла Word. Иконка типа файла — это значок, присвоенный типу и отображающийся на экране при сохранении или открытии.
С выходом новейшей версии Creative Cloud этой осенью пользователи увидят обновлённые иконки типа файла. В этом материале я углублюсь в размышления и процесс, связанный с нашим последним редизайном системы иконок типа файла Adobe, и расскажу о проблемах, с которыми мы сталкиваемся в процессе развития системы брендов в огромном семействе продуктов.
Определение проблемы
Многие клиенты могут не понимать, что Adobe имеет более 100 продуктов и сервисов в трёх облаках: Creative Cloud, Document Cloud и Experience Cloud
Когда дело доходит до иконок типа файла, пользователи часто рассматривают только основные типы файлов приложения, например:
- PSD для Photoshop;
- AI для Illustrator;
- INDD для InDesign.
Однако большинство наших продуктов могут импортировать и экспортировать различные типы дополнительных файлов (например, только в реестре Photoshop отображаются более 120 различных иконок типов файлов).
Чтобы оптимизировать требования различных операционных систем, наши иконки типов файлов должны быть вручную попиксельно подогнаны под десять различных размеров, а затем выпущены как набор растрированных PNG-файлов, которые упаковываются в ICNS (macOS) и ICO (Windows) файлы.
То, с какой скоростью росла продуктовая линейка Creative Cloud в последние четыре года, значит, что объём усилий, необходимых для создания и поддержки этих иконок типов файлов, в существующем рабочем потоке больше не масштабируется.
Шаг первый: аудит и исследование
Прежде чем мы смогли начать редизайн системы, нам пришлось исследовать, что мы сейчас используем в наших продуктах. Мы обратились к команде каждого продукта, чтобы они помогли нам провести аудит всех их иконок типа файла.
Отсутствие системности было повсюду, и оно, вероятно, стало результатом двух факторов:
- Разные команды владеют семейством продуктов и больше не согласовывают дизайн.
- При появлении в онлайне новых продуктов и типов файлов отдельные иконки создаются как одноразовые.
С информацией, собранной в ходе нашего аудита, мы создали приблизительное представление о существующей архитектуре типа файла.
Во-первых, мы организовали иконки типа файла по семейству продуктов и перекрестно привязали их, чтобы посмотреть, какие дополнительные типы файлов были разделены между несколькими приложениями. Так мы могли устранить повторяющиеся иконки. Сделав это, мы смогли сократить количество дополнительных типов файлов до 65%.
Затем мы классифицировали типы файлов по функциям, таким как «изображение», «аудио», «код» и «3D». Обычно иконка типа файла содержит метафору, которая говорит о её основной функциональности (например, иконка файла HTML будет использовать метафору скобок </>, чтобы сообщить, что её функциональность связана с кодом или кодировкой).
Мы заметили, что некоторые типы файлов использовали несколько версий одной и той же метафоры, в то время как другие имели индивидуальные метафоры, которые можно было заменить более общим значком. Мы начали создавать широкие группы типов файлов, чтобы назначить единую метафору для всей семьи. При этом нам удалось сократить число метафор типа файла в нашей библиотеке более чем наполовину.
Шаг второй: эскиз и дизайн
Получив полное представление о старой системе, мы начали устанавливать основные принципы организации для новой:
- Только основные типы файлов получат ассоциацию цветов логотипа продукта. Например, PSD будет синим и AI будет оранжевым.
- Создаём нейтральную палитру для дополнительных типов файлов, которые поддерживаются несколькими приложениями. Например, Photoshop и Illustrator будут использовать одну и ту же иконку типа файла PNG, вместо того, чтобы каждый из них имел свою собственную уникальную версию иконки по ассоциации с цветами бренда.
- Создаем основную библиотеку метафор типов файлов, чтобы иконки были согласованными и не пришлось настраивать ресурсы для отдельных случаев.
Мы начали делать эскизы с учётом новой структуры.
Одним из основных факторов, лежащих в основе редизайна, было упрощение и удаление как можно большего количества элементов на иконке типа файла без потери её смысла. Мы опустили тег и переместили тип файла в нижнюю часть иконки. Мы также убрали загиб страницы, чтобы сгладить дизайн и создать более современный визуальный язык.
Еще одним важным фактором было соответствие по спектру новому языку дизайна интерфейса Adobe, который в настоящее время распространяется во всех наших продуктах. К тому же мы закруглили углы наших иконок типа файла и начали создавать библиотеку, которая либо использовала существующие метафоры из базы данных Spectrum, либо создавала новые, которые соответствовали их стилю иллюстрации.
Наконец, мы добавили яркую цветовую схему в иконку типа файла, чтобы связать существующий брендинг логотипов наших продуктов. Это изменение создало более сплочённую визуальную систему, а новые иконки стали отображаться лучше в тёмных интерфейсах, тогда как наши старые иконки исчезли на темном фоне.
Шаг третий: итерация и утверждение
После того, как мы определились с направлением проектирования, мы протестировали новые иконки типа файла в контексте. Во время первоначальной проверки мы исследовали все области, где иконки типа файла отображаются в разных операционных системах и в наших собственных продуктах. Мы также рассмотрели каждый контекст, в котором иконки отображались в разных размерах и разрешениях.
На экранах рабочего стола macOS и Windows нам приходилось учитывать иконки, отображаемые в разных представлениях (список и сетка) с различными коэффициентами масштаба (от минимального размера 16 пикселей до 512 пикселей).
Также была проблема со светлым и тёмным интерфейсами, например, в разделах «Недавние элементы» или «Поиск в Spotlight» на рабочем столе Mac. Затем мы рассмотрели, в каких из наших собственных продуктов представлены наши же иконки типов файлов. Например, в панели «Активы», «Диалог медиа-браузера» и «Экран приветствия» при первом запуске приложения.
Как можно себе представить, мы быстро углублялись в неясные и забытые уголки нашей системы, где живут иконки типа файла. Тем не менее, это было ценное упражнение. Нам нужно было осознать масштаб задачи.
Последний шаг состоял в том, чтобы посмотреть иконки типа файла, добавленные в пользовательском интерфейсе наших веб- и мобильных сервисов, таких как Adobe Acrobat и Creative Cloud Libraries. Поскольку эти службы тоже были под контролем разных команд дизайнеров, нам приходилось координировать работу множества людей в соответствии с нашими планами по модернизации системы дизайна типов файлов.
Шаг четвёртый: создание нового рабочего процесса
Мы создали новый рабочий процесс для производства, который использовал скриптовые функции в Illustrator для компиляции и экспорта PNG-файлов одним нажатием кнопки. Новый шаблон сэкономил нам десятки часов мучительно медленной ручной работы.
Ещё нам нужен был лучший способ компиляции этих растрированных PNG-файлов в ICNS (macOS) и ICO (Windows). Раньше мы использовали плагин IconBuilder от IconFactory с нашими шаблонами Fireworks.
Однако при новом рабочем процессе нам требовалось более гибкое решение, которое отвечало бы нашим потребностям: в первую очередь способность перетаскивать любой набор PNG-файлов и наличие приложения автоматически сохраняющего файлы в форматах ICO и ICNS в правильных размерах.
После поиска стороннего компилятора мы решили, что лучше работать с нашими инженерами, чтобы создать внутреннее приложение, настроенное под наши нужды.
Они создали удивительный инструмент, который мы с любовью называем Captain Icon — компилятор, который мы использовали для группирования всех наших новых иконок типа файла. Хотя Captain Icon — по-прежнему программа на стадии внутреннего бета-тестирования, наши инженеры надеются в ближайшем будущем поделиться им в GitHub, чтобы он стал доступен для нашего сообщества разработчиков.
Шаг пятый: внедрение изменений
Мы всё ещё находимся на этом этапе и, вероятно, задержимся на нём надолго. Каждый раз, когда мы выпускаем новую версию Creative Cloud, мы привлекаем менеджеров продуктов и инженеров из многих команд, следя за тем, чтобы дизайн был согласован повсюду.
Внедрение изменений — это чаще всего утомительный процесс общения с командами по электронной почте (сотни писем), установка нескольких версий тестовых сборок для проверки ресурсов, ведение журнала и устранение неизбежных багов, управление несколькими дедлайнами релиза.
Наши продукты также построены на базе разных кодов, и это значит, что команды могут реализовывать одни и те же ресурсы по-разному и находить уникальные для каждой платформы проблемы. Обеспечение качества и соблюдение руководящих принципов бренда, вероятно, является одной из наименее интересных задач для нашей команды, но это важная часть поддержания развитой системы дизайна.
Небольшие изменения могут создать большие отличия
В нашей команде мы часто повторяем метафору дерева Бонсай, чтобы описать нашу работу.
Хотя в деталях легко заблудиться, всё, что мы узнаём в процессе, переносит нас на следующую итерацию, а затем на следующую.
Комментарий удален модератором
прочитал статью до корки....теперь я стал больше понимать инженеров автоваза, ибо на мой обывательский взгляд модель ваз-21901-011 ничем не отличается от модели ваз-21901-022 (индексы утрированны, ибо я вспомнил их на вскидку) - а отличатся они тем-то и тем-то
зачем и нафига? Старые довольно уродливые иконки заменили на новые совсем уродливые
Комментарий удален модератором
Комментарий удален модератором