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

Перевод материала дизайнера и разработчика веб-продуктов Колма Туита.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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