9 Принципов Верстки Проектов

9 Принципов Верстки Проектов

Недавно я проводил тренинг для одного из наших клиентов по передовым методам реализации проектов с использованием HTML и CSS. Часть обсуждения включала в себя разбор таких процессов, как разработка, ориентированная на один стиль (фреймворк), подходы OOCSS, SMACSS и модульный дизайн. Ближе к концу последнего дня обучения кто-то спросил меня: «Но как мы узнаем что правильно спроектировали дизайн?»

Сначала я смутился. Я ведь потратил часы, рассказывая им все, что им нужно, чтобы «сделать это правильно». Но, поразмыслив, я понял, что этот вопрос уходит корнями в насущную потребность в оценке того, что часто представляет собой набор субъективных решений – это такие решения, которые были сделаны множеством людей еще и в разные промежутки времени. И все что мы получим в конечном результате это руководство как надо именовать классы и специальные рекомендации по разработке в стиле SDD (style design development – работа в одном стиле, от своего фреймворка), но эти «лучшие практики» основаны на более глубоком смысле, который не всегда явно виден изначально. Например, конкретные рекомендации, такие как «Минимизировать количество классов, с которыми сотрудничает другой класс», не так полезны без более широкой оценки модульности фреймворка.

Я понял, что для того, чтобы точно понять, хорош ли наш дизайн, нам нужны критерии более высокого уровня, которыми можно измерить реализацию дизайна словно линейкой. Нам нужно что-то, что было бы не похоже на специфичный CSS и не утомляло при его использовании. Подобно универсальным принципам дизайна или эвристике Нильсена, нам нужен чеклист, который поможет внедрять дизайн без объяснения как это делать. Чтобы преодолеть этот пробел, я составил девять принципов реализации проекта.

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

**1. Структура**

Верстка логична и семантически правильно оформлена, неважно, со стилями или без.

**2. Эффективность**

Наименьшее количество разметки и активов используется для достижения дизайна

**3. Стандартизация**

Правила для общих значений хранятся и реализуются свободно.

**4. Принцип Абстрактного мышления**

Базовые элементы отделены от конкретного контекста и образуют общую структуру.

**5. Модульность**

Общие элементы логически разбиты на части для многократного использования.

**6. Опциональность**

Настройки для базовых элементов доступны через опциональные параметры.

**7. Масштабируемость**

Код легко расширяется и спроектирован с заделом под будущий функционал.

**8. Составление документации**

Все элементы описаны для использования и расширения других.

**9. Точность**

Недвусмысленное представление предполагаемого дизайна и 100% понимание конечного результата.

Чтобы было проще понять, как каждый принцип применяется к проекту, мы будем использовать макет дизайна из одного из моих проектов в качестве основы для этой статьи. Это специальная целевая страница, рекламирующая ежедневные сделки на существующем веб-сайте электронной коммерции. Хотя некоторые стили будут унаследованы от существующего веб-сайта, важно отметить, что большинство этих элементов являются совершенно новыми. Наша цель – принять это статическое изображение и превратить его в HTML и CSS, используя эти принципы.

## Структура кода

Принцип здесь заключается в том, что содержание нашего документа (HTML) имеет смысл даже без презентационных стилей (CSS). Конечно, это означает, что мы используем правильно упорядоченные уровни заголовков и неупорядоченные списки, но также используем семантические селекторы, такие как < header > и < article >. Мы не должны отказываться от использования таких вещей, как разметки ARIA *(это набор инструментов и указаний для того, чтобы сделать веб-контент и приложения более доступными)*, атрибутов alt и любые другие вещи, которые могут потребоваться.
Это может показаться не столь значительным, используете ли вы для якорной ссылки обычный тег < a > или < button >, несмотря на то, что они визуально идентичны, они обмениваются разными значениями и обеспечивают разные взаимодействия. Семантическая разметка передает это значение поисковым системам и вспомогательным технологиям и даже упрощает переработку нашей работы на других устройствах. Это делает нашим проекты большой задел на будущее.

Для создания хорошего структурированного документа необходимо наличие знаний семантической верстки, знакомство со стандартами W3C, а также время, чтобы сделать ваш код доступным для машин и людей. Простейшим тестом является просмотр вашего HTML-кода в браузере без стилей, вот три вопроса для проверки:

Это можно использовать без CSS?
Не потеряна ли иерархия тегов?
Доносит ли смысл страницы исходный HTML сам по себе?

Лучшая практика для написания хорошей структуры – это начать работу с документом с HTML. Прежде чем вы начнете думать о визуальных стилях, напишите простой HTML для того,чтобы понять как документ должен быть структурирован и что означает каждая его часть. Избегайте div’ов и не забывайте думать о том, какой семантический тег подойдет лучше для той или иной обертки. Только этот базовый шаг поможет вам создать соответствующую структуру будущего дизайна.

>Пример структуры html документа от автора:

 

<section>
<header>
<h2>Daily Deals</h2>
<strong>Sort</strong> <span class="caret"></span>
<ul>
<li><a href="#">by ending time</a></li>
<li><a href="#">by price</a></li>
<li><a href="#">by popularity</a></li>
</ul>
<hr />
</header>

<ul>
<li aria-labelledby="prod7364536">
<a href="#">
<img src="prod7364536.jpg" alt="12 Night Therapy Euro Box Top Spring" />
<small>Ends in 9:42:57</small>
<h3 id="prod7364536">12" Night Therapy Euro Box Top Spring</h3>
<strong>$199.99</strong>
<small>List $299</small>
<span class="callout">10 Left</span>
</a>
</li>
</ul>
</section>

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

## Эффективность

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

*Вот пример избыточной зависимости от фреймворка, которая раздувает HTML и CSS. Хорошенько подумайте над разметкой, прежде чем использовать классы фреймворка для достижения желаемого дизайна.*

В дополнение к разметке и CSS нам могут потребоваться другие вещи, такие как иконки, веб-шрифты и изображения. Существует множество отличных методов и мнений о лучших способах реализации этих “приблуд”, от пользовательских иконочных шрифтов до кодировки base64, внедренной во внешние SVG. Каждый проект отличается, но если у вас есть 500-пиксельный PNG для одного значка на кнопке, скорее всего, вы не задумывались об эффективности.

*И не всегда речь идет о размере файла. Для написания эффективного кода важно именно ваше понимание последствий использования иконок в base64 в CSS по сравнению с импортируемыми картинками/иконками и т.д.*

При оценке эффективности проекта есть два важных вопроса на которые нужно ответить:
Могу ли я сделать то же самое с меньшим количеством кода?
Каков наилучший способ оптимизации иконок, веб-шрифтов, картинок для достижения наименьшей нагрузки на сервер/сайт/клиента?

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

## Стандартизация

Создание стандартов для веб-сайта или приложения обычно заключается в создании правил, которые регулируют какой должен быть размер у каждого заголовка, какая ширина желоба и какой стиль для каждого типа кнопки надо применять. В простом CSS вам нужно будет поддерживать эти правила во внешней документации по стилю и не забывать применять их правильно, но лучше использовать препроцессор, такой как LESS или Sass, чтобы вы могли хранить закономерности в переменных и mixin’ах. Основным выводом здесь является переориентировать свое внимание на оценку, создание и применение стандартов, а не на достижение perfect pixel дизайна.

Поэтому, когда я получаю дизайн-макет с шириной желоба 22 пикселя, вместо 15 пикселей, которые мы используем в стандарте, я высказываю, что такая точность не нужна и вместо этого будет использоваться стандартный 15-пиксельный желоб. Если подумать чуть наперед, то все интервалы между элементами будут использовать этот стандарт в кратных значениях. Экстра широкое пространство будет $ gutter-width * 2 (равным 30 пикселям), а не жестко закодированным значением. Таким образом, дизайн приложения выглядит выравненным, а код является последовательным.

 

.product-cards {
li {
display: inline-block;
padding: @gutter-width/4;
color: @text-color;
text-decoration: none;
background-color: @color-white;
.border;
margin-bottom: @gutter-width/2;
margin-right: @gutter-width/2;
}
}

.product-status {
font-size: @font-size-small;
color: @grey-darker;
font-weight: @font-weight-bold;
margin-bottom: @gutter-width/4;
}

Поскольку мы используем стандартизированные значения, полученные из LESS-переменных или mixin’ов, наш CSS не имеет собственных численных значений. Все наследуется от централизованного конфига.

Чтобы проверить стандартизацию, просмотрите CSS и найдите в нем любой жестко заданный параметр: пиксели, цвета HEX, ems или почти любое числовое значение и найдя их, ответить на следующие вопросы:

Должны ли эти единицы использовать существующее стандартное значение или переменную?
По смыслу эти цифры дают новое значение или это повтор? Возможно, вы поняли, что это второй раз когда вы применили частично непрозрачный фон, и такая же непрозрачность нужна в обоих случаях.
Может ли единица быть получена из расчета существующей переменной? Это полезно для вариантов цвета – например, с использованием стандартного цвета и выполнения вычисления на нем, чтобы получить что-то на 10% более темным, а не жестко кодировать полученное значение HEX.

Как можно чаще я использую стандартные значения и создаю новые только как исключение. Если вы обнаружите, что настроите элемент на 5 пикселей шире/уже здесь и на 1 пиксель выше/ниже здесь, есть вероятность, что ваши стандарты и проекты подвергаются риску в последующей поддержке.

По моему опыту, большинство предварительно обработанных CSS должны использовать централизованные переменные и mixin’ы, и вы почти не должны видеть числовые, пиксельные или значения HEX в отдельных компонентах. Иногда бывает необходимо добавить несколько пикселей для настройки позиции отдельного компонента, но даже эти случаи должны быть редкими и заставлять вас дважды проверять свои стандарты.

## Абстракция

Первоначально я назвал этот принцип «Фреймворком», потому что, помимо создания одного конкретного проекта, над которым вы сейчас работаете, вы также должны работать над системой проектирования, которая может использоваться вне исходного контекста. Этот принцип заключается в определении более крупных общих элементов, которые необходимо использовать на протяжении всего жизненного цикла текущего проекта или будущих проектов. Это применимо в широком смысле этого слова: в типографике и входных данных для форм и вплоть до различных схем навигации. Подумайте об этом так: если ваши CSS будут открытыми в качестве основы, например Bootstrap или Foundation, как вы отделите элементы дизайна? Как бы вы поменяли их по-другому? Даже если вы уже используете Bootstrap, есть вероятность, что ваш проект имеет базовые элементы, которые Bootstrap не предоставляет, и они также должны быть легко доступны в вашей системе проектирования дизайна.

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

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

При проверке проекта для абстрактность спросите себя:
Как бы я построил этот элемент, если бы знал, что он будет повторно использоваться в другом контексте с разными потребностями?
Как я могу разбить его на части, которые будут полезны во всем приложении?

Ключевая мысль здесь, это понимать как тот или иной элемент может быть повторно использован. Также важно понимать, как должны храниться эти элементы: как полностью отдельные и независимые классы или, еще лучше, как отдельные файлы LESS или Sass, которые могут быть скомпилированы с окончательным CSS?

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

## Модульность

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

**Базовый CSS**

Это базовая структура, включая значения по умолчанию для типографии, расстояний, цветов и т. д.

**Компоненты CSS**

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

**Родительские компоненты**

Это компоненты “на каждый день”, содержащий стили или настройки, специфичные для ежедневного использования. Для многих это будет фактический веб-компонент JavaScript, но он может быть только родительским шаблоном, который включает HTML, необходимый для визуализации всего проекта.

*Правило для составления и внедрения модулей должна выглядеть примерно так: каждый компонент может иметь несколько стилей для интервала или позиции, но большая часть CSS унаследована от фреймворка.*

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

## Опциональность

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

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

*Наша стандартная сноска по умолчанию на самом деле использует цвета бренда, в то время как специальные выноски с классом “на каждый день” имеют стили, которые мы хотим использовать для нашей целевой страницы. Мы также сделали несколько альтернативных вариантов, например, другой цвет или правый указатель*

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

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

Использование такой методологии, как BEM, OOCSS или SMACSS для организации вашего CSS и создания соглашений об именах, может помочь вам следовать принципу опциональности. Работа через эти методики – немалая часть в построении настраиваемой системы проектирования.

## Масштабируемость

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

Для построения масштабируемого CSS обычно требуется, использовать более продвинутые функции по типу LESS и Sass для записи миксинов и функций. Поскольку все наши сноски из предыдущего примера являются одним и тем же элементом, за исключением цвета, мы можем создать единственный LESS миксин, который будет генерировать CSS для конкретной реализации без необходимости дублировать код для каждого варианта. Код разработан с учетом масштабирования и его просто обновить в одном месте.


@angle: 170;

.callout {
&.qty-left {
.callout-generator(@color-deals, @color-white, @angle);
}
&.qty-sold {
.callout-generator(@color-white, @color-deals, @angle, 2px solid @color-deals);
}
&.qty-out {
.callout-generator(@color-grey, darken(@color-grey, 10%), @angle);
}
}


Делая из сноски масштабируемый элемент, мы создали LESS миксин с именем ```.callout-generator``` который включает в себя все свойства: цвет заднего фона, текста, а также угол поворота и свойства рамки.

*Пример реализации миксина в CSS при генерации парочки новых элементов на основе стандартной сноски*


.review-flag {
.callout-generator(@color-brand, @color-white, 75);
}

В будущем, когда потребуется сделать новые небольшие дизайнерские решения, на основе этого миксина сгенерировать новый стиль будет очень просто.

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

Какие части элемента могут быть изменены?
Как я могу написать код, который можно будет легко поменять под будущие требования?

## Документирование

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

Одно из лучших решений при составлении документации в виде живого гайда – это напрямую включать в систему ваши комментарии из кода. Мы используем подход в реализации документации под названием developmentDocumentCSS, который сам себя дополняет. Но если для вашего проекта пока рано создавать огромную интерактивную документацию, то создавайте мануал на HTML или в виде PDF файла для печати, это тоже сойдет. Что нужно хорошенько запомнить из этого принципа, так это то, что всё что мы делаем, должно быть задокументировано.

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

Могу ли я рассказать кому либо еще как нужно правильно использовать мой код?
Если я попадаю в новую команду, что я должен им объяснить, чтобы они сразу поняли как этим фреймворком пользоваться?
Как мне продемонстрировать виджет, чтобы указать всего его варианты использования?

*Простое руководство по дизайну это круто, но руководство в виде живой документации, созданное непосредственно из CSS, изменит вашу жизнь 🙂*

## Точность

Наконец, мы не можем забывать, что то, что мы создаем, должно выглядеть так же хорошо, как оригинальный макет и отвечать его требованиям. Никто не оценит фреймворк и конечный дизайн, если он не привлекательный. Важно отметить, что результат может соответствовать макету и не будет идеально вымерен до пикселя. Я не люблю фразу «pixel-perfect», потому что предположить, что реализация должна похожа пиксель в пиксель на макет – это забыть любые ограничения и обесценить стандартизацию (при этом мы понимаем, что каждый браузер отображает CSS немного по своему). Сложность соблюдения принципа точности заключается в том, что, например, статический дизайн  для приложений, редко является отзывчивым на 100% и учитывает все возможные размеры устройства. Дело в том, что мы должны опираться на определенную степень гибкости.

Вам нужно будет решить, насколько он должен соответствовать исходному макету и быть репрезентативным для вашего проекта, но и убедиться в том, что он соответствует ожиданиям людей, с которыми вы работаете. В наших проектах я рассмотрю основные отклонения от требований pixel-perfect верстки клиента, просто чтобы убедиться, что мы на одной волне. «В дизайне показан стиль синей кнопки по умолчанию с рамкой, но наш стандартный цвет кнопки немного отличается и не имеет границы, поэтому мы выбрали именно стандартный вариант реализации кнопки». Обоснование – здесь это самый важный шаг.

*При верстке и работе с реальными данными и стандартизованным CSS окончательная реализация выглядит несколько иначе, чем исходный макет. Кроме того, некоторые из требований были изменены, но в итоге результат является точным.*

## Система мышления

Цель этих девяти принципов – предоставить руководство по реализации дизайна верстки в HTML и CSS. Это не набор правил или предписывающих советов, это способ задуматься о вашей работе, чтобы вы могли оптимизировать и достичь оптимального баланса между хорошим дизайном и хорошим кодом. Важно проявлять определенную гибкость при применении этих принципов. Вы не сможете каждый раз доводить тот или иной принцип до совершенства и это нормально. Все таки, статья описывает идеальные подходы. Всегда есть факторы и приоритеты, которые будут отвлекать вас следовать этим принципам. Тем не менее, принципы должны быть чем-то, к чему нужно всегда стремиться, постоянно проверять себя и настойчиво выполнять их, когда вы переводите свой дизайн с макета на финальную стадию разработки, в которой он будет испытан. Надеюсь, они помогут вам создавать лучшие продукты и построить системы проектирования, которыми будут пользоваться много лет.

> Автор оригинала: Tom Greever является автором решений по дизайну и UX в Bitovi, консалтинговой компании по разработке дизайна
>  Оригинал статьи на английском от 14.08.17
Отставить отзыв

Ваш e-mail не будет опубликован. Обязательные поля помечены *