Пользователь
0,0
рейтинг
29 сентября 2014 в 11:45

Разработка → Дизайн в браузере из песочницы

HTML*
Для прогрессивной визуальной разработки нельзя просто внедрить пару тройку фишек. Нужно радикально изменить сознание и фундаментально поменять подход. Я не буду разбивать процесс на избитые заезженные этапы. Опишу более свежо. Две основных составляющих агрессивно нового подхода: «Дизайн в Браузере» и «Автоматизация фронт-энда».

Начнем с первого — «дизайна». Тут проблема в отношении к дизайну как к статической .psd. По ощущению это должно было потерять свою актуальность в тот момент, когда появился адаптив, добавилась динамика и доработка на живую макета стала привычным делом. Теоретически смерть статичных .psd-шек наступила вместе с отходом табличной верстки. Зачем пытаться оживить то, что отслужило?! Тогда это было актуально, так как фактически в таблицу запахивалась картинка макета, только в нарезанном виде. Сейчас же макет выполняет роль ориентира. В большинстве случаев мы не вырезаем ни пикселя. А просто держим макет открытым в соседнем окошке. Для того, чтобы написать всю эту «красоту» кодом.

Дизайн меняется

Сегодня получать картинку с огромным описанием поведения, которое «дизайнеры» определили на глаз в инструменте крайне отдаленном от веба, глупо и неразумно. Макет, вышедший с экрана дизайнера может поменяться по пути к верстальщику. И вы получите огромное количество комментариев и пожеланий, которые невозможно отразить на картинке. Альтернативный подход — разрабатывать дизайн непосредственно в родной среде, то есть в браузере. Видно, как стремительно набирает популярность такой подход.

Кто использует прогрессивный подход?

Ребята на питерском WSD достаточно наглядно показали свои живые прототипы финансовых аппликаций.

Буквально в начале месяца был отличный доклад Антона Виноградова (@awinogradov) из Альфа-лаб на BEMup, где он буквально за несколько минут оперативно набросал верстку приложения Яндекс.такси

Ну и конечно, ждем связку внутренних продуктов ребят из «Одноклассников» Lego + SourceJS. Насколько я понял из небольшой демки в скринкасте от Роберта (@operatino), интерфейс будет собираться из подготовленных, сверстанных и задокументированных блоков. А пока можно навести порядок, используя документацию верстки на SourceJS. Полезная привычка, которая окупается сполна.

И, конечно же, доклад Ильи Пухальского(@pukhalski) Rest in PS. Очень здорово и наглядно разъяснил аналогичную тему.

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

Переход в «правильную» среду

Разработка веб-дизайна в инструментах для него не предназначенных — отчаянный и тупиковый подход. Если отбросить дрибббльную эйфорию, я не знаю, насколько конкретно могу назвать дизайнерами тех, кого принято считать таковыми в не совсем заметных агентствах. Это, как правило, «персонажи», на которых сваливают непосильные обязанности. В общем, они рисуют весь внешний вид, не всегда опираясь на логику, и команда слепо верит на слово. Часто они лезут не в свою область, пытаясь опровергнуть привычное поведение. Но при этом верстальщик должен им отправить макет, который они пристально осматривают и говорят правки. Самое абсурдное, что за эталон в сравнении берут свой .psd файл. Который часто противоречит здравой логике. Глупая ситуация, не так ли?

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

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

С анимацией дела обстоят гораздо печальней. Тут о привязке к среде вообще речь не идет. Над анимацией извращаются в редакторах для видео, или фигачат несколько картинок, чтобы склеить в .gif. Но в итоге все переписывается на HTML/CSS. Не сильно ли трудозатратный процесс с размазанными промежуточными этапами?!

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

Как внедрить в работу

Есть вариант сделать все довольно безболезненно. Для этого стоит отбросить клише в виде «дизайнер — проектировщик, …, верстальщик». А использовать сильные навыки участников команды. Базовые этапы выглядят так:

1. Разработка общих гайдов

Базовые элементы, которые нужно стилизовать: заголовки, h1 h2 h3, абзацы, ссылки, списки, таблицы, копки, инпуты, селекты и.т.д. Основные стили мы можем сложить в базовый CSS файл. Он будет всегда лежать в нашем стартовом ките.

2. Логические независимые блоки

Обычно это 20-30 размеченных основных блоков. C которых можно легко стартовать. В дальнейшем, пополняя библиотеку, делая ее более масштабной и удобной. Штурмовать каждый новый проект с таким арсеналом будет все приятней. К примеру, это может быть форма регистрации/авторизации, комментарии и другие часто встречающиеся в ваших проектах блоки. Все они аккуратно докумментируются, что позволяет с легкостью их переиспользовать и модифицировать.

Мы делаем:
  1. набросок версткой структуры блока;
  2. общую стилизация, учитывая гайды (1 этап);
  3. разные состояния и анимацию.


3. Сама структура сетки

Берем во внимание поддерживаемые устройства и медиа-запросы. Упор идет на продумывание базового фундамента. Для любителей адаптива это будет максимально полезно, так как есть возможность сфокусироваться на каркасе, это даст большую осмысленность. Как вариант, продумать качественную сетку (возможно, взять готовое решение и доработать по необходимости).

4. Интеграция

Здесь не нужно много думать над разработкой. Мы просто интегрируем заранее подготовленный модули (2 этап) в наш каркас (3 этап). Достаточно сделать пару небольших допилов и восторгаться результатом. Так сказать, ощутить всю магию модульного подхода.

Фанатики продавят идею

Понятно, что стартовать меняя привычную систему в целом либо страшно, либо влом. Но есть масса ребят, пропагандирующих и наслаждающиеся методологией. Масса — это сила, которая толкает вперед. Так что процитирую одного дизайнера: «велкам в секту». И поменьше вам статики.
Mikhail Koloskov @mkoloskov
карма
3,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (17)

  • +7
    HTML+CSS как среда разработки накладывает слишком много ограничений для неопытного дизайнера. Я понимаю, конечно, что хочется убрать лишние звенья в цепочке, но подобное желание вырождается в желание иметь суперразработчика, который будет и иконки рисовать, и тексты писать, и сервера администрировать.

    Мне кажется все-таки более разумным разделение обязанностей и этапов разработки, и использование для каждого этапа наиболее подходящих инструментов руками наиболее специализированных работников.
    • +1
      Сервера это уже другая тематика, тут разговор про разработку визуальной части.
      HTML/CSS как раз снимает ограничения, которые есть в Фотошопе и дает полный спектр возможностей: адаптив, динамика, взаимодействие и.т.д. Убрать лишние звенья (количество человек в цепочке) не сама цель, больше приятный бонус. А вот умышленное сокращение «неполноценных» инструментарий, шикарный способ приблизиться к итоговой среде реализации для максимально эффективной и логичной работы.
      • 0
        Откройте Axure и сделайте макет/прототип там — знаний CSS и HTML вам не надо там с ходу писать. Интерактивчик, переходы — у нас программисты и дизайнеры меньше материться стали уже год как после внедрения Axure)
  • 0
    По-моему, лучше один раз дизайнер научится чему-то, чем будет тягомотина и трата времени на каждом новом проекте
  • +2
    Вы предлагаете делать дизайн непосредственно кодом? Тогда сразу уж предложите еще и иллюстрации с версткой в postscript писать, в блокноте.
    Просто посадить дизайнера за нормальный редактор, выдающий сразу верстку в коде, вроде webflow, и все. Это куда лучше и проще чем то что вы предлагаете.
  • +1
    Мы именно так и работаем в последнее время.
    • 0
      Удивительно, но и у нас примерно в таком ключе все происходит в последнее время
      • +1
        Ребят, я думаю это вполне логично развитие на качественно высоком уровне.
  • 0
    еще до кучи инструментов для дизайна в браузере — Patternlab от Brad Frost. Пересели на него с самописной системы стайлгайдов.
  • –1
    Сам невольно пропагандировал такой подход, ибо здравый смысл подсказывал о ненужности траты времени на макет, который полностью отправляется в корзину. На что в ответ мне крутили у виска — так же принято, так все работают!
    • 0
      теперь буду тыкать носом в эту статью, спасибо!
  • +2
    Я думаю идеал это когда дизайнер работают точно по такой же схеме, что он работал и в фотошопе, а программа трансформирует это все в валидный код. Если дизайнить сразу кодом, неизбежно накладываются определенные ограничения на простор фантазии, может быть для каких-то серых типовых проектов это хорошо, но если нужно что-то менее стандартное, то такой подход не оправдывает себя.

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

    Если дизайнер будет держать в голове не цветовую гамму или композицию, а строку в которой нужно поменять значение Hex, то такой дизайн не будет радовать глаз. То о чем написано выше впринципе уже существует в том или ином виде. Это тот же Bootstrap, Foundation, Polymer.
    • 0
      Программы трансформирующие в код отлично прогрессируют. Но код на выходе действительно ужасен. Плюс совсем небольшой контроль над архитектурой и вложенностью, что совершенно противоречит методологии Абсолютно Независимых Блоков. И накладывает ограничение на переиспользование и модификацию, без серьезных допилов.

      Что касается Bootstrap и похожих вещей, то они сильно универсальны, но я не брезгаю внедрять в базовый файл стилей отдельные компоненты, к примеру сетку.

      Не могу представить такой пример, где бы я чувствовал себя ущербно без граф редактора, а используя стеройды в виде HAML/Sass и.т.п не чуть не уступающих по скорости и возможностям.

      Опираясь на большинство задач, могу сказать что графический редактор актуален для Иллюстраций, но как правила эта работа довольно изолирована от интерфейса. К тому же учитывая вектор развития графики в вебе и смотря на инструменты подобные http://snapsvg.io и тут закрадываются сомнения.
      • +1
        Создание дизайна это процесс, не всегда понятно заранее каким должен быть конечный результат. Поэтому во время работы над дизайном интерфейса, я перебираю 10ки вариантов, а что если меню будет не сверху, а слева, а если текст заменить иконками, а если… и т.д. и т.п.

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

        По моему так работать намного эффективнее, возможно если цветовая палитра уже подорана, все элементы стандартные, нету никаких фишек, то быстрее сразу кодом. Но при таком раскладе и дизайнер впринципе не нужен.
        • 0
          Касательно общего расположения «меню сверху, слева» — я решаю такие задачи, когда продумываю общий каркас, абстрагируясь от модулей.

          Что касается «Написать код > Cохранить > Открыть браузер» — для быстрых набросков модулей(без развертки сложной системы), вполне подойдет codepen.io c небольшими настройками под себя.

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

            Но все равно отношусь к этому несколько скептически. Во время работы дизайнер должен быть сконцентрирован именно на создании дизайна.
  • 0
    Конечно, такой подход идеально подходит для разработки в рамках каких типовых решений и обычных (привычных) патернов поведения. Или тогда, когда абсолютно уверен и очень четко видишь конечный результат. Порой, что-то попробовать и посмотреть как оно получится, подвигать блоки, дорисовать мелочи и прочие-прочие мне намного удобнее в графическом редакторе. Идеальный вариант сделать графическую концепцию, пару-тройку страниц и уже дальше все это дело верстать.

    Мы занимаемся разработкой сайтов и от макетов нам некуда не деться, так как на них с клиентом согласовывается дизайн-концепция. Чтобы как-то сократить сроки разработки мы делаем подробный прототип, по которому ведется разработка (программирование) и параллельно занимаемся разработкой дизайна и согласовываем его с клиентом. После технолог верстает страницы и «сводит» все с результатами работы программиста. Сейчас мы хотим попробовать рисовать только дизайн концепцию и элементы интерфейса, остальное все будет делать технолог по подробному прототипу, а дизайнер и иллюстратор будут дорисовывать необходимые элементы.

    Правда как всегда посередине :)

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