Боль
Как не странно но по самому процессу разработке визуальной части мы в компании отстаем как минимум на года 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.
Большинство из этих проблем я описывал в статье «Дизайн в браузере». Но «староверов» и консерваторов такой скачек может морально травмировать, поэтому по желанию можно причесать процесс без радикальных мер и использовать как промежуточно-подготовительный этап для неизбежного «Дизайна в браузере».
Автор: mkoloskov
