Боль
Как не странно, но по самому процессу разработки визуальной части мы в компании отстаем как минимум на года 2-3. Во-первых, классическая, изолированная, универсальная модель: Проектирование — Дизайн — Верстка. Во-вторых, один и тот же подход остается как для страниц мелких акций (заглушек), так и для масштабных сервисов вроде, где трудно предугадать сценарий развития. Но мы метем все под одну гребенку. Я лично не знаю в нашей компании персонажа, который глобально бьется над улучшением процесса и самой системы разработки визуальной части. В основном звучат умелые фразы, по поводу сроков и складывается впечатление, что все мастера по тайм менеджменту. Многие из резких фраз, как «Процент времени», напрочь убивают всю логику, и наивно полагаться на сохранение продуктивности на том же уровне. Когда разрабатываешь крупный проект, 5-7 глобальных переключений в день на другие задачи, полностью парализуется и сбивает весь процесс разработки основного проекта. Ну, впрочем, это менеджерская магия с выгодой в одну сторону.
Процесс разработки визуальной части — это два отдельных этапа дизайна и верстки. Один и тот же подход остается как для мелких страниц акции (заглушек), так и для масштабных сервисов, где трудно предугадать сценарий развития.
Теперь о вытекающее из этого «боли»…. Ситуация, которая сейчас выглядит так:
Дизайн
Явные ошибки конструкции
Железобетонная структура, совсем не гибкая, хорошо сделанная композиционно, но не предусматривающая изменение. Дизайн меняется. Но если нет закономерностей и правил (а их у нас нет), то базовые ошибки на этапе конструкции усугубляются с каждым новым элементом в разы.
Внешняя стилизация, по вкусу
Согласен, что чисто эстетически, некоторые вещи могут смотреться очень даже здорово. И массу лайков на Дрибббле соберут без затруднений. Но если это их конечная цель. У нас же вразрез другая задача.
Понятно, что в рамках огромной компании у дизайнеров есть заказчик, который примет решение. Но это не должно идти в разрез с общими принципами работы веба, предвзятым отношением, личной «вкусовщиной».
Верстка
Думаю, уже сложилось понимание, что на этом этапе работа далеко не «сахар». Мы получаем сомнительный каркас, не гибкую структуру, макет с эстетическими эффектами, не предусматривающий ресайз … Такой макет затруднительно реализовать даже на полном стеке веб инструментов, а у нас еще и отнимают половину из них, заставляя поддерживать IE8.
Gracefull degradation
Дизайнеры ориентируются на фишки 2014 года, а верстальщики должны впаять это в браузер 2009. Думаю, вы понимайте временную пропасть. Если приблизиться к дизайну, то вы можете поэкспериментировать, открыв даже самые крутые сайты 2009 года. Технологически опираясь на IE8, глупо говорить о тандеме с современным дизайном.
Разработка багами
Я прикалываюсь: «мы 20% пишем код и 80% пишем костыли и баги». Изобретая оригинальный, новый подход «разработка багами» для любителей острых ощущение. Но начинать 10-й проект с таким подходом, близко к шизофрении.
Заденем опять наших экспертов по тайм менеджменту. Когда они говорят, что есть зазор по времени на доработку. Но этот зазор далеко не в пять раз больше, учитывая 20% эффективной работы c нашей стороны.
Тестирование. Судный день
У нас тестировщики это не те ребята, которые пишут тесты на интерфейс, а откликиватели сайта, своего рода MonkeyTesting, только в живом исполнении. После чего выставляется кучу тикетов, что все работает не так, дополненные личным пожеланием. И начинаются локальные допилы. И мы понимаем, что с самого первого этапа проект сделан не под те задачи и не были учтены принципы, по которым это тестируют. Перепил начинается на лету рукам разработчиков. Про дизайнерскую эстетику мы забываем, она просто выпадает из игры. Вcе это кочует из проекта в проект и с каждым новым безысходность умножается.
Лечение
Определив диагноз, всплывают очевидные решения. Нам ну��но наладить максимальное взаимодействие между всеми участниками команды отвечающей за визуальную часть (проектирование, дизайн, верстка), но всем нужны общие ориентиры и инструменты.
Опираясь на лучшие практики, мы начинаем налаживать свою экосистему, учитывая наши особенности:
Гайды
Сборка базовых стилей, с которых будет начинаться любой новый проект. По необходимости, он может дорабатываться и всегда находиться в актуальном и боевом состоянии, как внешне, так и под капотом (я имею ввиду- код). Состав примерно такой:
Типографика (шрифты, размеры)
— Заголовки
— Абзацы
— Ссылки
Цвета
— Базовые цветы
— Цвета для продуктов (у нас несколько разных продуктов внутри одной компании). Хотим избежать 10 практически идентичных цветов, одинаковых визуально, но отличающихся кодом в макетах, поэтому включаем возможные цвета в гайд…
Кнопки
Все состояния кнопок (default, hover, pressed)
Вариации (к примеру с иконкой или без) или размеры (small, large) и.т.д
Инпуты (Samsung не в лучшей форме)
Обозначить эталонный вид форм -одна из моих самых маниакальных фантазий. Знаете, как у любого разработчика есть «бзык», который не дает спать по ночам. У меня это без сомнений — формы. Они буквально меня сводили с ума, к сожалению, не в лучшем смысле. Есть детали, по которым сразу видно — на сколько проработан макет. И формы это явный индикатор. Хоть у нас с ними был полный бардак, но даже у передовых сайтов, таких как Samsung дела бывают намного хуже. Даже в top Awwwards часто появляются проекты, у которых ситуации с формами- плачевна.
Сейчас в гайдах есть стилизация каждого из элеменов формы, которую мы берем за эталон. Что просто существенно облегчит жизнь верстальщикам и даст и понимание возможностей для дизайнеров.
Прелоудеры
В них у нас критическая необходимость. Так как многие действия выполняются динамически, без перезагрузки, что не всегда предусматривается дизайнерами.
Source
Вторая вещь, которая перевернула мой мозг в этом году — Source. В котором наконец-то удалось структурировать модульный подход и донести его в удобном для восприятия виде, не только разработчикам, но и дизайнерам. Тут мы делаем упор на саму конструкцию, используя базовые стили. Мы намеренно отделили основные стили от базовых конструкции для удо��ства.
Пример использования:
Допустим есть задача сделать блок формы регистрации.
Из каких элементов она состоит:
— Заголовок
— Текст инпут
— Чекбокс
— Кнопка
— Ссылка
— Иконка
Все эти элементы есть в базовом ките, вы просто собирайте из них блок, который мы поместим в Source. Source это наша общая база блоков( в которых видна разметка). В дальнейшем которые можно переиспользовать и модифицировать.
Работа в таком процессе даст нам больше логики и понимания, существенно повысит процент полезной работы (которую не нужно переделывать), накопление продуктов нашей работы в общую базу и аккумулирование мощности для новых проектов.
Каркас
У нашей команды сложилось общее понимание по сетке и адаптиву. Выглядит примерно так:
Полный адаптив
Точки перелома (Медиа-запосы):
Cмартфоны
Ширина окна (девайса) < 768px
Ширина контейнера < 768px
Планшеты
Ширина окна (девайса) > 768px
Ширина контейнера = 750px
Десктопы
Ширина окна (девайса) > 992px
Ширина контейнера = 970px
Широкоформатники
Ширина окна (девайса) > 1200px
Ширина контейнера = 1170px
Разбивка на версии
В тех случаях, когда контент специфичный, много функционала и нет возможности использовать одну разметку, мы делаем две версии:
— Десктопы/Широкоформатники + перестройка под Планшет (12 колонок)
— Мобильная версия (отдельная версия) + (своя сетка в 6 колонок)
Анимация
Неизбежная составляющая дизайна, которую мы не можем игнорировать и которой придается большая значимость. Нам нужно внедрять это аккуратно, не навешивая на нее функциональную часть. Учитывая, что все должно работать в приемлемом виде в старых браузерах. В перспективе она будет так же документироваться в Source. Возможно сделать перераспределение ролей в виде Interaction Designer-а. Так как тут нужна гибридная связка в виде Технических знаний + Динамичного дизайна (microinteractions).
На мой взгляд -просто шикарная система, которая в разы увеличить мощность и скорость. Вполне логичная эволюция процессов для крупных проектов. Это не загоняет в жесткие рамки, а дает ориентиры и гарантии того, что работа будет успешно реализована технически.
P.S.
Большинство из этих проблем я описывал в статье «Дизайн в браузере». Но «староверов» и консерваторов такой скачек может морально травмировать, поэтому по желанию можно причесать процесс без радикальных мер и использовать как промежуточно-подготовительный этап для неизбежного «Дизайна в браузере».
