Hi-Tech

Преодолеть барьер между дизайном и кодом с помощью инструментов проектирования

В дизайне есть два подхода со своими инструментами и направлениями развития.

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

Здесь код важнее дизайна. Второй подход подразумевает, что все, кто участвует в разработке продукта, должны работать вместе. Решения принимают, учитывая контекст, а инструменты подбирают, исходя из конечной цели. Дизайнеры уважают и понимают технические характеристики платформы. Назовём такой подход «объединяющим».

Подход первый: восполняющий пробел

Статус-кво сохранялся много лет — большинство работ требовало владения Adobe Creative Suite. В 2005 году, когда началась моя карьера веб-дизайнера, большинство людей использовали Adobe Illustrator и Photoshop для всех задач.

Он оказался проще, дешевле, а его функциональность была ориентирована на веб. Так продолжалось до тех пор, пока в 2010 году не появился Sketch.

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

Что будет следующим шагом? Но пробел между дизайном и процессом разработки никуда не исчез.

InVision и Abstract выпустили Inspect. Как именно передавать макеты разработчикам — спорный вопрос. Figma и Sketch попытались экспортировать CSS. Avocode, Marvel и Zeplin представили Handoff. Также появились сервисы для конвертирования статичных изображений в код: Supernova Studio, Rapid UI, PageDraw, Teleport, Sketch2React и Anima Launchpad.

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

Тогда было проще. Но давайте вернёмся к моменту, когда печать была основным средством коммуникации в маркетинге. Большинство дизайнеров использовали Adobe Illustrator, Photoshop и InDesign­. Бесконечные споры насчёт инструментов или фреймворков были сведены к минимуму.

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

Дизайнеры отвечали за трёхмиллиметровые обрезки бумаги, которые позволяли учесть неточности в выравнивании принтера. К примеру, полиграфические дизайнеры знали, что различия между цветом на плотной карточке и на тонком печатном бланке 120 г/м² незначительны.

Они знали все сроки — было ясно, что, к примеру, на причудливые эффекты вроде дебоссинга (продавливания бумаги для эффекта объёмного изображения) или фольгирования уйдёт больше времени.

Затем веб-дизайн стал основным направлением, и миллионы полиграфических дизайнеров в одночасье стали веб-дизайнерами. С приходом цифровой печати дизайнеры начали изучать новую технологию.

Вместо того чтобы разобраться, как с ними работать, мы хотели их приручить. Но дело не в самом переходе, а в том, что мы мало знали о новых носителях, для которых делали дизайн. Это стало очевидно, когда многие пытались уместить всё в контейнер размером 960px, называли интерфейсы «страницами» и придумали термин «сайт-визитка».

Для этого мы пользовались инструментами, которые хорошо служили нам десятилетиями: софтом для графического дизайна. Большинство дизайнеров не умели писать код, так что они делали то, что умели: рисовали.

Дизайнеры больше не работали с конечным продуктом, только с его имитацией.

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

Даже растровые изображения меньше используют для коммуникации, отдавая предпочтение более качественным или более живым СSS-анимациям, SVG-иллюстрациям и видео. Сегодня всё это делается при помощи CSS.

Сегодня связь между вебом и печатью примерно такая же, как связь между вебом и архитектурой.

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

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

Подход второй: объединяющий

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

Adobe Dreamweaver, печально известный визуальный редактор кода WYSIWYG, появился в 1997 году. Как ни странно, происхождение обоих подходов можно проследить примерно в одно и то же время. Softress Freeway появился 1996 году, а Microsoft Frontpage в 1995 году, всего через пять лет после Photoshop и более чем за десять лет до Sketch.

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

Постепенно волна дизайнеров, включая меня, отказалась от WYSIWYG-редакторов в пользу менее ограниченного инструмента: текстового редактора.

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

Давайте рассмотрим подробнее эволюцию инструментов дизайна, основанных на коде.

Форматирование кода и выделение синтаксиса были одними из первых инструментов для удобства написания и чтения кода.

Инструменты вроде Haml, Sass, LESS, CoffeeScript и другие упростили работу кодом ещё больше, поощряя краткость, облегчая визуальное восприятие и автоматизируя некоторые из наиболее распространённых задач. Препроцессоры и шаблонизаторы появились примерно в 2006 году.

API-интерфейс React также способствует повторному использованию кода и облегчает его визуальное восприятие, помогая сделать его более понятным и доступным. JSX — это синтаксическое расширение JavaScript, разработанное Facebook, которое не очень отличается от шаблонизаторов, придуманных ранее.

Например, такие сервисы, как Compositor ISO и SEEK Style Guide Sandbox. В последнее время мы видим, что инструменты устраняют барьеры входа: исчезла необходимость настраивать среду разработки, возиться с командной строкой и так далее.

Modulz — это основанный на коде инструмент для визуального создания пользовательского интерфейса.

Очередной пример рабочего процесса, который полностью учитывает контекст носителей. Polypane разрабатывают «умную» дизайн-среду, где можно увидеть, как проект будет смотреться в разных браузерах, устройствах и областях просмотра.

Polypane — это «умный» веб-браузер для отзывчивого дизайна и разработки.

Всё это новаторство важно и нужно, потому что огромная часть фронтенд-разработки визуальна. Эти визуальные редакторы кода стали просто следующим шагом на пути к облегчению написания кода.

Предсказание: конечным состоянием моделей виртуальных компонентов, таких как React или Preact, станет частично визуальное программирование. Всё, кроме поставщиков данных, может быть представлено в виде редактируемого визуала.

Браузерные инструменты разработки уже начали двигаться в этом направлении, предлагая графические интерфейсы для визуального управления стилями CSS, такими как переходы, тени и цвет. Я согласен с предсказанием Джейсона.

Набор графических интерфейсов для визуального управления кодом внутри инструментов Google Chrome

Compositor Lab и Modulz Editor упрощают визуальное редактирование компонентов React. Конечно, браузерные инструменты разработки работают на скомпилированном коде, но эти же визуальные инструменты могут применяться и к предкомпилированному коду.

Modulz Editor — это инструмент для визуального создания компонентов React

Xcode — инструмент, позволяющий командам оформлять, разрабатывать, тестировать и отлаживать свои продукты с помощью комбинации редактирования кода и прямого управления.

Также в сервисе можно просматривать проекты с введенными данными и экспериментировать с разными размерами экрана. Lona от Airbnb предоставляет графический интерфейс для создания компонентных систем, мокапов на основе компонентов.

Редакторы Maya, Unity, Cubase, Logic Pro и Final Cut предоставляют инструменты для непосредственного управления, целые команды могут работать над одним и тем же продуктом.

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

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

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

Дилемма

Команды дизайнеров, компании и инвесторы тратят множество времени и денег на то, чтобы поддержать рваный процесс разработки дизайна: традиционный рабочий процесс, основанный на простой работе с изображениями.

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

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

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

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

Какие аспекты разработки следует усовершенствовать, автоматизировать или упростить с помощью наших инструментов? Что означает сегодня заниматься дизайном цифровых продуктов?

Я до сих пор помню слова Ребекки Кокс, одного из моих самых любимых дизайнеров, о том, что в Quora вкладывали в слова «дизайн продукта».

Дизайн — это набор решений для конкретного продукта. Пользовательский интерфейс — это продукт дизайна.

Ребекка Кокс

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

Вот некоторые вопросы для размышления. Итак, раз дизайн — набор решений, какие решения подойдут дизайну цифровых продуктов в наши дни?

  • Как должна вести себя кнопка при зависании над ней курсора, при нажатии, фокусе с клавиатуры и в период неактивности?
  • Как должен выглядеть пользовательский интерфейс, когда нет данных для его заполнения?
  • Как пользовательский интерфейс справится с его заполнением необычно длинными последовательностями данных?
  • В каком порядке элементы будут получать фокус, когда пользователь будет переходить по элементам управления с помощью клавиши Tab?
  • Нужно ли, чтобы какие-нибудь сочетания клавиш могли взаимодействовать с пользовательским интерфейсом?
  • Нужны ли пользовательскому интерфейсу голосовые команды?
  • Должны ли быть какие-то звуки, сопровождающие взаимодействие с пользовательским интерфейсом?
  • Как выбранные цвет и шрифт будут отображаться во всех пермутациях, версиях браузера и операционных системах?
  • Как небольшие изменения, которые я вношу в компонент кнопки, влияют на другие области продукта?
  • Как должен себя вести себя X-компонент, когда данные еще не загружены?
  • Как должен себя вести себя X-компонент во время загрузки данных?
  • Как каркас сайта должен адаптироваться к бесконечному множеству областей просмотра, соотношений сторон экрана и плотностей пикселей?

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

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

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

Исследование иллюстрации для извлечения стилей, измерений и кода предполагает, что иллюстрация — точное представление конечного продукта. Ещё один день, ещё одна характерная черта передачи (handoff). Иллюстрации не могут точно представлять цифровые продукты.

И не в исполнении. Проблема Developer Handoff совсем не в названии. Даже идея дизайнеров передавать работу кому-то другому в процессе производства звучит вполне концептуально.

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

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

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

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

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

Ребекка Кокс

Ребекка утверждает, что люди, в чьих руках право принимать решения, — это те, кто ближе всего к коду.

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

#дизайн

Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть