Внимание! Данная запись отмечена как устаревшая и/или потерявшая актуальность! Возможно автор уже передумал и теперь придерживается другой точки зрения, нежели изложенная в тексте ниже.

Прототипирование сайтов

Дневник / Вёрстка сайтов: CSS, HTML, LESSПросмотров: 17357 (351)

Среди вебмастеров понятие прототипирования имеет несколько значений. Как правило под этим подразумевают эскиз сайта без детализации. Другая точка зрения — прототип это рабочий вариант сайта, также без детализации отдельных элементов. Википедия определяет прототипирование как «быстрая "черновая" реализация базовой функциональности».

Прототипирование постепенно набирает популярность среди вебмастеров и не удивительно, что постоянно появляются новые инструменты для решения этой задачи (см. например «Инструменты быстрого прототипирования» на Хабре). Раньше я воспринимал прототипирование только для быстрого создания графического макета сайта, который можно показать клиенту. Для этого использую Pencil, но постепенно мигрировал к Adobe Fireworks, который заслуживает всяческих похвал.

«Традиционная» схема создания сайта выглядит примерно так:

  1. Клиент описывает свои пожелания, приводит примеры.
  2. Делается предварительная версия ТЗ, в которой, опять же, словами, описываем что примерно нужно будет сделать.
  3. Делается графический прототип: эскиз, где определяется расположение блоков и размеры основных элементов.
  4. После обсуждения, составляется окончательная версия ТЗ.
  5. Делается предварительная версия шаблона сайта, где прорабатываются только основные элементы: размеры, расположение и как правило, выставляется типографика.
  6. Клиент указывает на необходимые правки и с каждым шагом мы всё больше углубляемся в детали дизайна и дорабатываем функциональность до готовности.

Я не иллюстратор, поэтому на занимаюсь созданием дизайна с нуля. Клиент предоставляет либо готовый графический вариант дизайна, либо показывает какой шаблон ему понравился и что нужно в нём изменить. При гигантском количестве WordPress-шаблонов, найти подходящий вариант сейчас не очень большая проблема.

Но в таком варианте возникают нестыковки на этапе прототипирования: ведь нужно точно знать функциональность каждого блока существующего шаблона с тем, что предстоит сделать.

Самый частый пример: когда в готовом wp-шаблоне на главной выводится слайдер или какие-то блоки текста. Определить как именно они наполняются довольно проблематично. В MaxSite CMS мы можем использовать массу вариантов: запись, фиксированный текст, ушки, опции или внешний файл.

Другая проблема — как адаптировать элементы чужих wp-шаблонов к своим наработанным? Тоже частый пример — выпадающее меню. В MaxSite CMS мы давно уже перешли на обычную HTML+CSS3 вёрстку и отказались от сложных jQuery-плагинов. В WordPress-шаблонах часто используют не только плагины для создания меню, но и дополнительные js-библиотеки для разных эффектов, не говоря уже о том, что в разных плагинах используется разная html-структура меню и разные css-стили. То есть переносить такой элемент в новый шаблон будет довольно трудозатратно.

Такие моменты следует определять уже на этапе прототипирования, но не графического, как обычно, а на основе рабочего шаблона.

Идея очень простая: за основу берётся тот факт, что любой дизайн (готовый графический или в виде wp-шаблона) обязательно потребует программирования и html-вёрстки. И если вёрстка зависит от дизайна, то программирование возможно уже реализовано.

В шаблоне D2 множество готовых компонентов, которые подключаются прямо из админ-панели. Самое время использовать эту возможность. То есть при создании сайта, в первую очередь определяется требуемая функциональность, а уже после думаем, как её оформить.

Ну и самое главное, это то, что клиент непосредственно участвует в создании своего сайта на этапе проектирования. В самом простом случае он может выбрать подходящие компоненты. Скажем, то же меню может быть просто меню, а может быть совмещено с иконками соц.сетей, формой поиска или авторизацией на сайте. Это готовые компоненты и на их создание ничего не тратится. Если подходящего компонента нет, вебмастер его делает и сохраняет в своей коллекции для будущих клиентов.

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

Правда отмечу здесь еще один важный момент — на этапе прототипирования у нас уже должна быть готовая модульная сетка. С учётом того, что сейчас сайты следует делать адаптивными, вопрос создания универсальной модульной сетки, достаточно сложный. В предыдущих публикациях уже обсуждал этот вопрос и просто отмечу, что пока самый оптимальный вариант — это использование полурезиновой верстки. Базируется она на простых стилях:

блок {
    margin: 0 auto; // выравнивание по центру родителя
    width: 100%; // ширина по всему родителю
    max-width: 1000px; // ограничение максимальной ширины
}

Таким образом, при ширине браузера более max-width, размер сайта будет ограничен указанным значением (1000px). Если же ширина браузера будет меньше, то блок автоматом будет 100%, даже без использования @media-инструкций.

Подобная верстка используется в шаблоне D2 в файлах css-less/layouts/.

Исходя из всего вышесказанного, получается немного другая схема создания сайта.

  1. Клиент описывает, какой сайт хочет получить, приводит примеры.
  2. Если есть готовый дизайн (графика или шаблон — не важно), я определяю смогу ли его сверстать. Обязательно уточняю у клиента насколько точно нужно следовать дизайну. Некоторым требуется пиксельная точность, другим это не важно.
  3. Если клиент сам точно не знает, то предлагаю установить MaxSite CMS на хостинг клиента, чтобы он сам посмотрел базовые возможности системы. Здесь же как правило ставлю свои бесплатные шаблоны, чтобы клиент «пощупал» их настройки и понял, что его будущий сайт будет работать примерно таким же способом.
  4. После этого уже окончательно решаю, буду ли браться за сайт. Клиент может выдвинуть неприемлемые для меня условия. Это может быть как точность верстки, наличие каких-то сложных аля-wp-плагинов или даже бесконфликтность клиента.
  5. Делаю модульную сетку будущего сайта и выставляю все нужные размеры. Выкладываю новый шаблон и переключаю сайт на него.
  6. Клиент может сам выставить нужные ему компоненты. Если какого-то компонента нет, то я быстро делаю его прототип и выкладываю на сайт.
  7. После того, как все размеры согласованы мы отрабатываем типографику сайта. Для этого используется bb-код [ text-demo ] в любой записи. Клиент указывает «базовый» цвет, согласно которому выставляются цвета ссылок, заголовки H1-H6 и заголовки виджетов.
  8. На этом этап прототипирования завершен и можно уже приступать к верстке сайта уже с учетом дизайна.
Небольшая ремарка по пятому пункту. Я стараюсь прийти к какой-то одной универсальной модульной сетке, которая будет поддерживать адаптивность даже на уровне компонентов. То есть стили компонентов написаны так, чтобы при любом раскладе модульной сетки они «не разваливались». Кроме того, я использую разные шаблоны вывода (main-шаблоны). Например в моей коллекции есть правый сайдбар, левый, два сайдбара справа рядом, три в подвале, слева и справа от контента и вообще без сайдбаров. Всё это добро должно определяться в компонентах. Например при двух сайдбарах, ширина сайта обычно выше, а это значит меняется ширина компонентов шапки. Всё это требует довольно сложных css-стилей и активного использования LESS. Но при этом клиент может прямо в админ-панели выбрать понравившийся ему шаблон вывода. Причем возможности MaxSite CMS таковы, что можно сделать это для произвольного типа данных или для любой записи.

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

Комментариев: 1 RSS

1Андрей09-03-2013 22:13

Максим, подскажи, для чего в "Редактирование страницы", поле "Порядок", что именно он делает? Не могу заметить изменений...

Оставьте комментарий!

Комментарий будет опубликован после проверки. Вы соглашаетесь с правилами сайта.

(обязательно)

О сайте

Здесь вы получите самую полную информацию о создании сайтов на MaxSite CMS.

Рейтинг@Mail.ru