Боль. Или дизайн крупных проектов

    Боль


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

    Похожие публикации

    Комментарии 13
      0
      Жизнь — это боль. Тяжко вам. Крепитесь.
      А если по делу — то в первую очередь палки в колёса вставляет заказчик. Надо работу свою ставить так, чтобы заказчик доверился вам, как профессионалам своего дела. Вы же не учите заказчика делать его работу.
      Получается, на этапе переговоров важно стойко отстаивать свою позицию и не стараться делать всё, что он говорит.
      Кто у вас участвует в переговорах? Этому человеку надо поменять своё отношение к делу. Не просто продать продукт (сервис, портал, сайт), а убедить заказчика в том, что продукт будет сделан на высочайшем уровне в установленные сроки.
        0
        Тут ситуация гораздо абсурдней. Команда работает на проекты компании. «Заказчик» формально, это отдел внутри компании, для которых часто выполняется работа. Существует огромная пропасть между менеджерами(марионетками, слепо угождающими высшему руководству, набивая плюсики в карму) и амбициозной разрабоческой командой. Личная неумелость менеджера умножается на количество подчиненных. А в поэтапной работе, растет в геометрической прогрессии на каждом этапе. Думаю проблема не частная, а глобальная для многих крупных компаний с плохо организованными процессами и непродуманно распределенными полномочиями.
          0
          Вы правы в том, что проблема далеко не частная. Дело действительно в том, что непродуманно распределены полномочия. И тут уже не так важно, насколько велика компания. Можно и с 5-ю сотрудниками иметь полный хаос, а можно и 150 организовать идеально. Удачи вам!
        +1
        Все очень правильно написано, по смыслу. Но такое впечатление, что автор выпил бутылку водки и излил душу.
          0
          Спасибо! Обошлось без допинга. После года рутинный и парой абсурдных задач, начал осмысленно вникать в процесс и пришло понимание, что проблемы не в конкретных этапах, а в самой системе на которую хорошенько подзабили. Но периодически проблескивает потенциал на проектах, поэтому не смог остаться равнодушным и в виде доклада «излил душу» команде, практически с аналогичным смыслом.
          +2
          Плашки «Перевод» вроде бы нет, но не покидает стойкое чувство, что Промпт читаю. Местами даже цепями Маркова попахивает о_0. Хотя, автор вроде бы и сказал, что обошелся без допинга. Опять кто-то Ватсона на файрвол не закрыл?
            0
            Полностью личные заметки. Все реальные ситуации с которыми сталкиваюсь на конкретном проекте. Не удивлюсь, что проблемы массовые.
            +3
            Господи, это просто невозможно читать. Неужели так сложно отдать на вычитку перед публикацией. Пишу в каменты, чтобы обратить всеобщее внимание. Не бойтесь вы дать прочесть ваш текст кому-то грамотному. Не важно, понимает он в тематике или не — русский язык един для всех.

            И да, я готов вычитать и исправить. Просто спрячь в черновики и пришли мне текст. Я исправлю, и опубликуешь. Это открытое предложение для всех желающих.

            ЗЫ: За грамотный Хабр.
              0
              Спасибо за внимание. Мысль и эмоциональный порыв убежали вперед грамматики. Пост отредактирую.
                0
                Так и не исправил ничего из того, что я прислал. Нафик я час убил на вычитку?..
                0
                Абсолютно с вами солидарен. Текст выглядит как слобосвязанные отрывки фраз с повторениями.

                Жизнь — боль, это, разумеется, неоспоримый факт, но было бы неплохо свои умозаключения как-то более структурировано изливать…
                0
                Советы дельные. Все это применяется в Twitter Boostrap. Рекомендую еще книгу «Scalable and Modular Architecture for CSS» почитать, если еще не добрались.
                  0
                  Именно с т.з. дизайна вас должен спасти brandguide.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое