Должен ли дизайнер кодить?

Mikhail Koloskov
Дизайн-кабак
4 min readApr 26, 2014

--

Воспаленный вопрос, который особенно последние пару лет сводит с ума как самих дизайнеров, так и коллег по цеху. Чтоб не было недопонимания я объясню, кого в этом посте я буду называть дизайнерами. Возьмем классический минимальный костяк: Дизайнер — Верстальщик — Программист. Как правило в этой цепочке Дизайнер именно тот персонаж, с которого начинается непосредственно сама разработка. Все начинается со структуры блоков, расположение их на холсте. 960px по центру на двенадцать колонок или что-то похожее. Все строго по сеточке. И пошло творение. Иногда это превращается в фанатизм и переходит все границы. Конечно это можно выложить на dribbble и behance, но ведь PSD это не конечный продукт. Приведу пример того, что мягко говоря бесит верстаков:

- Кастомный скролл (не забывать про кросбраузерность и кросплатформаенность)
- Кастомный селект (-\\-)
- Клевые шрифты, которыйх нет в Google Web fonts нужно генерить или изощрится с CuFon. Резултат может огорчить.
- Горизонтальный градиент у резиновых блоков
- Нужно помнить, что контент может меняться не так как вы бы этого хотели и блоки могут тянуться.
- Резиновый макет нужно продумывать на минимальной ширине
- Тени с рваным краем
- Функционал на ховер

Список можно продолжить как минимум на несколько десятков. Ну я думаю моя мысля понятна.

Кросбраузерность

Согласитесь CSS3 творит чудеса. Лично я был в восторге, когда первый раз попробовал применить тень, градиенты и еще несколько эффектов, буквально пару строками простого кода. Ну это же просто мелочь по сравнению с трансформацией и анимацией. Вот эти вещи по-настоящему передают всю красоту и ювелирность CSS3. И было бы глупо не насладиться этой радостью. Дизайнер рисует дизайн продумывает шикарную анимацию, которую где-то подсмотрел плюс добавил что-то от себя. Макет согласовали. Менеджер в восторге. Передает макет на верстку. Весртальщик в шоке. Сто слов мата и боль. Кросбраузерность, для дизайнера понятие расплывчатое. И ювелирность CSS3 превращается в велосипед на JavaScript. Довольно жалкое зрелище наблюдать над тем как дизайнер объясняет какую CSS3 анимацию использовать. И та движуха, которую он придумал в своей голове должна быть правильна понята и реализована верстальщиком. Согласитесь это мягко говоря неправильно.

Адаптив

Статичные скриншоты вымирают. Для адаптива их актуальность и вовсе падает.
Макет с 3-4 изображениями разной ширины (эмулирующий разные разрешения) теряют свою ценность.
Так как за частую адаптивная, сверстанная версия выглядит совсем иначе, чем на макетах и за частую
приходится перерабатывать целиком структуру. Каждый разработчик адаптива думаю знает, что
дизайн нужно тестить на разных разрешениях в процессе работы, а не когда он уже завершен. Чего не
могут себе позволить дизайнера рисующие статику в фотошопе. Гораздо удобней начинать разработку
сразу на HTML/CSS. Конечно как вариант можно сделать продуманный адаптивный прототип в Axure7 или Sketch3. Это вполне приемлемо. Но если есть возможность, то лучше лишний раз не брезгать кодом.

Графика

Очень радует прогресс графики в вебе. Она развивается динамично и правильно. Я имею в виду, что мы все меньше элементов в вебе реализовываем с помощью нарезанных изображений. А создаем графику кодом. Если объективно посмотреть, то из всей графики, которую мы вынуждены вставлять как jpg/png это фотографии. А все то, что касается интерфейса, более изящно создается с помощью CSS3 и JavaScript.
Активно входит в работу SVG. Еще не до конца вошедшая в широкое пользование технология, но потенциал то огромен. Недавно наткнулся на проект snapsvg.io и честно говоря был вдохновлен такому подходу реализации графики. Как не крути, а типичное понимание отрисовки графики в редакторе уходит в прошлое. Уже понятен вектор развития. И вполне очевидно, что без кода тут не обойтись.

Схемы, графики, диаграммы

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

Codepen вместо Dribbble

Все мы люби dribbble. И мы видим как дизайнеры желающие показать живость своей работы делают гифки с анимацией. К примеру видим изображение формы авторизации. И старательны дизайнер склеивает в gif разные ее состояния. Фокус текстового поля, ховер на ссылку, клик на кнопку, прелоудер на отправку и так далее. Его старания похвальны. Но форма это же не иллюстрация, там не нужно особого художества. А смотреть ролик как работает форма немного глупо. Другое дело когда дизайнер может накидать несколькими строками кода на codepen.io и есть возможность посмотреть интерактив, так сказать “потрогать форму”, подправить на ходу если нужно. Этот способ на много гибче, понятней и логичней. К тому же есть возможность показать интерактив.

Вначале код

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

--

--