Показатель отказов: от чего он зависит?

Показатель отказов – важный параметр работы сайта. Он показывает, насколько ресурс интересен и полезен для пользователей. Соответственно, чем ниже процент отказов, тем вы...

Копия сайта и необходимость ее создания

Несмотря на то, что сайт – это не вещь, его тоже можно потерять. Серьезные проблемы с интернет-порталом могут быть результатом:Посягательств со стороны злоумышленников. П...

Грамматические ошибки на сайте: накажут ли за них поисковики?

Стоит ли опасаться гнева поисковика, если на страницах сайта присутствуют грамматические ошибки? Этот вопрос волнует всех, кто уже давно распоряжается собственным виртуал...

Дизайн в браузере

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

Начнем с первого — «дизайна». Тут проблема в отношении к дизайну как к статической .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 этап);
разные состояния и анимацию.


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

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

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

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

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

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

Источник