Критерии качества — основной документ, на который мы опираемся при разработке интерфейсов. В совокупности эти критерии дают необходимое удобство проверки и дальнейшего использования, обеспечивают качество и скорость загрузки страниц. За основу документа взяты наши принципы, которые мы собирали в течение многих лет опыта разработки, а также на основании требований качества, предъявляемых нашими клиентами.
Большинство описанных критериев не имеют двойной трактовки, однако также будут критерии, в которых есть возможность выбрать тот или иной вариант.
Документ живёт вместе с развитием индустрии, а значит со временем критерии качества могут меняться и модифицироваться.
1. Удобство проверки и дальнейшего использования
Вёрстку необходимо легко проверять и использовать в дальнейшем, поэтому у нас есть ряд критериев, направленных на это.
1.1. В вёрстке присутствует разводящая страница со всеми страницами и компонентами
По адресу sitemap.html располагается страница, на которой находятся ссылки на все другие страницы и компоненты, а также отдельные страницы с состояниями. Если проект состоит из одной страницы, то разводящей страницы не предусмотрено.
1.2. Все страницы проекта перелинкованы между собой
При наличии нескольких страницы, если они ссылаются друг на друга через меню или другие смысловые блоки. Пролинковываются только очевидные сценарии и ссылки, в объёме достаточном для демонстрации. Если мы реализуем статический сайт целиком и вносим в него финальный актуальный контент, то страницы линкуются в полном объёме согласно предоставленному ТЗ или спецификации.
1.3. Сборка проекта предоставляется вместе с гайдом по её использованию
В случае, если клиент не предоставляет собственную сборку проекта, мы используем собственные заготовки, которые используются на большинстве проектов. У Лиги есть две базовые сборки проекта, с нативным шаблонизатором (https://github.com/htmlonelove/liga-basic-template) и с использованием Pug (https://github.com/htmlonelove/liga-pug-template). Оба шаблона идут с гайдами для дальнейшего использования, при необходимости.
2. Разметка сайта
2.1. Разметка сайта должна быть валидна относительно https://validator.w3.org/
Валидным считается конечный код из папки build, так как в исходниках могут быть конструкции, которые не валидны и становятся валидными после сборки. При этом в валидаторе допускаются невалидные конструкции, которые генерируются сторонними ресурсами, например, интерактивными картами или внешними формами сервисов.
2.2. В разметке строго соблюдается иерархия заголовков
Если нет прямого указания на использования в том или ином месте заголовков необходимого уровня, мы расставляем их на своё усмотрение, при этом соблюдая иерархию. Заголовок 1 уровня может не участвовать в иерархии, но должен быть как можно выше. Остальные заголовки вкладываются друг в друга, у них нет пропущенных уровней. Для проверки мы используем простой генератор дерева https://yoksel.github.io/html-tree/.
2.3. В разметке используется методология БЭМ
Этот пункт можно связать с компонентами. Мы используем для именования блоков методологию БЭМ. Для разделения блока и элемента, используется ‘__‘ (двойное нижнее подчёркивание), а для модификаторов ‘╌‘ (двойной дефис). При этом нет стандартных ошибок методологии, таких как использование модификатора, без блока, который он модифицирует, или использование элементов внутри других блоков.
2.4. Весь текстовый контент на сайте прогнан через типограф
При переносе контента из макетов, мы прогоняем их через типограф, чтобы избавиться от висячих предлогов, неправильных дефисов и так далее. Для типографии используются общедоступные типографы и плагины для текстовых редакторов.
2.5. На всех телефонных номерах и email стоят атрибуты tel: и mailto:
Это позволяет взаимодействовать с ними на десктопных и мобильных браузерах.
3. Стилизация сайта
3.1. При стилизации сайта нами исправляются огрехи дизайна с разными отступами между одинаковыми элементами
Если в процессе разработки мы сталкиваемся с тем, что одинаковые элементы на разных страницах выполнены по-разному или имеют разные отступы, мы их универсализируем и проводим к одному виду. Если по макету непонятно, что именно верный вариант, он уточняется у клиента.
3.2. Для организации стилей используется методология БЭМ.
В исходниках каждый БЭМ-блок это отдельный стилевой файл. Блоки независимы друг от друга и могут перемещаться между страницами.
3.3. Стилизация контентных областей выполнена через каскад
Если на сайте есть контентные области, которые наполняются через визуальный текстовый редактор, их стилизация делается без классов, а реализуется каскадом, от родительского блока. В случае, если блоки внутри текстовой области одним каскадом не стилизовать, используются классы, которые модифицируют контентные блоки.
3.4. Для адаптива используется резина с перестроением на контрольных точках
Резина — это принцип, при котором на сайте есть резиновая сетка и максимальная ширина. При достижении максимальной ширины, блоки центруются и не увеличиваются. При уменьшении экрана блоки сужаются по ширине, а при достижении контрольной точки перестраиваются иным образом.
3.5. Опционально для адаптива может использоваться масштабирование с перестроением на контрольных точках
При масштабировании блоки не сужаются по ширине, а масштабируются внутри своих пропорций. Таким образом сайт увеличивается и уменьшается, с сохранением пропорций. Этот способ требует иной организации CSS и его реализация обойдется дороже. Если клиенту необходимо масштабирование, это стоит проговорить заранее, так как на финише проекта переделка может привести к большому объёму работы.
3.6 По умолчанию поддерживаются 3 последних версий стабильных браузеров Chrome, Mozilla, Opera, Safari и Edge Chromium. А также стабильные версии мобильных браузеров.
3.7. Никакой текстовый контент сайта не зашивается в CSS
Все тексты хранятся в разметке или атрибутах, чтобы их можно было легко редактировать через админку.
3.8. Для всех элементов, с которыми есть взаимодействие мы добавляем микро анимации по наведению
Интерфейс должен откликаться, поэтому даже если не предоставлен UI-кит, мы делаем их на своё усмотрение. Если кит есть, то мы добавляем только плавность смены состояний. Мы также добавляем курсор лапку на элементы, на которые можно нажать.
3.9. По умолчанию мы не отключаем обводку ховеров, или меняем её на предоставленную в дизайне
Мы не любим просто выключать её, так что, если вы не можете предоставить дизайн обводки, мы сделаем её сами по своему усмотрению.
3.10. Вёрстка соответствует дизайн макетам, по принципам Pixel Perfect
При этом есть допуски 2-3px, а также учитывается тот факт, что макеты универсализируются. Принцип не используется на длине текстовой строки, так как шрифты по-разному рендерятся в разных браузерах. При применении пункта 3.1, допускается расхождение с макетами.
3.11. Вёрстка делается по принципу desktop-first
Сначала делаются десктопные макеты, а потом реализуется адаптив под экраны меньше.
3.12. Футер «прибит» к низу HTML-страницы.
Какой бы большой не была высота экрана — футер остается всегда снизу. Это нужно для того, чтобы на коротких страницах, или большом по высоте экране, футер оставался внизу страницы
3.13. Шрифты подключены в CSS локально из папки fonts с помощью правила @font-face. Подключаемые шрифты должны быть в форматах woff2 и woff. Порядок подключения файлов: сначала woff2, потом woff
Опционально, по требованию, они могут быть подключены со сторонних сервисов.
3.14. Вёрстка проходит тестирование переполнением контента
Речь идёт про изменение объёма контента в контентных блоках. Исключением для этого пункта является ситуация, при которой дизайн не готов под увеличение объёма контента.
4. Скрипты и функционал
4.1. Для реализации скриптов используется нативный JavaScript, если иного не указано в требованиях
По умолчанию мы используем только нативный JavaScript, а также сторонние плагины на нативном JavaScript.
4.2. По умолчанию нами реализуются все визуальные компоненты, на которых не завязана работа с данными
Мы реализуем модальные окна, табы, слайдеры, смену контента и так далее. Всё что относится к визуальной части и не предполагает работу с данными. Мы можем реализовать логику обмена данных, расчёта на странице и так далее, для этого её надо описать и учесть в оценке.
4.3. Все формы по умолчанию имеют базовую валидацию и маски для телефонов и ввода email
При этом валидацию остальных полей мы не делаем на заполненность или маску. Мы вставляем на них обязательность полей формы и выставляем верные типы полей по умолчанию. При этом все необходимые состояния полей реализуются. Если необходимо сделать валидацию форм целиком необходимо описать правила валидации и учесть это на оценке.
4.4. Модальные окна закрываются по клику оверлей и на клавишу ESC
Это необходимо для удобного взаимодействия с модальными окнами, так как это распространенный паттерн взаимодействия.
4.5. Перемещение блоков со скриптами и скриптов между страницами не ломает работу остальных скриптов
Для этого скрипты подключаются ко всем страницам в одинаковом виде.
4.6. Если мобильное меню полностью перекрывает HTML-страницу, то HTML-страница под ним не должна как-либо взаимодействовать с пользователем (скроллинг, весь интерактив и т.д.)
Модальное окно или оверлей, это блокировка. При блокировке фокус пользователя должен быть на содержимое попапа, для этого всё что под ним, не должно никак отвлекать.
5. Работа с графикой
5.1. Вся контентная графика на сайте ретинизируется
Мы подготавливаем всё необходимое, для того, чтобы вы могли использовать графику двойного размера на ретина дисплеи. Вся графика из макета вырезается в двух размерах.
5.2. Вся декоративная графика на сайте ретинизируется
Точно так же, как и контентная графика. Но в отличие от неё, декоративная делается через CSS. Мы также сохраняем все иконки в векторный формат SVG для того, чтобы они чётко выглядели на всех типах устройств и не увеличивали вес загружаемых ресурсов.
5.3. SVG графика собирается в векторный спрайт
Это необходимо для удобства использования. Векторный спрайт первым загружается на страницу. Иконки из спрайта используются в любом необходимом месте.
5.4. Опционально, при возможносности сервера, мы готовим графику в современных форматах.
Таких как .avif или .webp. Они намного лучше оптимизируются и меньше весят, что позволяет сократить время загрузки страницы.
5.5. Для графики указан размер
Для всех контентных изображений явно указан размер. Это нужно для того, чтобы картинка большего размера не ломала сетку.
5.6. Для фоновых изображений указан фоновый цвет
Это улучшает ощущения пользователя от загрузки изображений на сайте.
5.7. Видео добавляется на сайт через айфрейм YouTube или других сервисов
При это никаких дополнительных работ с ними не производится. В случае, если клиенту необходимо видео не через сервис, оно просто вставляется через тег video.
6. Скорость загрузки и работы сайта
6.1. Все стили сайта собраны в один файл, который подключается в секции head
Опционально они могут быть разделены на два, один из которых содержит стили библиотек. Файл минимизирован для максимальной скорости загрузки.
6.2. Все скрипты и библиотеки собраны в один файл и подключены в самом конце страницы
Тут, опционально, скрипты разделяются на файлы библиотек и файлы скриптов. Они также сжимаются для минимального веса.
6.3. Вся графика сжимается максимально возможным образом, чтобы не терялось качество
Для того, чтобы она меньше весила на загрузке страницы. Мы оптимизируем все форматы графики до максимально низкого размера файла, без потери качества. SVG графика также оптимизируется перед тем, как собраться в векторный спрайт.
6.4. На всех страницах для контентных изображений используется ленивая загрузка изображений
По умолчанию мы используем скрипт, который загружает картинки по мере прокрутки, для того, чтобы не грузить лишние картинки сразу.
6.5. Мы делаем предзагрузку основных шрифтов сайта, чтобы максимально избежать дёргания при загрузке
Мы делаем preload только основных шрифтов с первого экрана, чтобы они не дёргались, но и не увеличивали время загрузки.
6.6. Выполнены базовые оптимизации Lighthouse
Все требования по скорости мы тестируем в Lighthouse, он же PageSpeed. Мы не целимся в конкретную оценку, так как она зависит от множества факторов. Наша задача — выполнить всё необходимое, чтобы она была как можно выше. Тестирование скорости проходит без подключённых внешних скриптов и счётчиков аналитики.
7. Работы, которые не входят в базовую оценку
Эти работы не входят в базовую оценку, так как часто они не имеют смысла. Например, на этапе интеграции контент сильно меняется. Также есть технические ограничения, которые могут не позволить сделать на вёрстке хорошо.
7.1. Стилизация разводящей страницы по дизайну заказчика
Мы делаем такую страницу максимально простой и понятной, но не превращаем её в дизайнерский проект. При необходимости мы можем стилизовать её по дизайн макету, просчитав это в изначальной стоимости проекта.
7.2. Наполнение проекта финальным контентом, подготовка финальной контентной графики и полная перелинковка всех страниц
Так как в большинстве случаев в макетах предоставляется не финальный контент и графика, а также в дальнейшем шаблоны интегрируются в систему управления контентом, мы не включаем этот объём работы по умолчанию. При необходимости наполнить сайт реальным контентом и перелинковать эти страницы, мы можем посчитать эту работу отдельно по цене работы с контентом. В случае работы с контентом, мы берём на себя все необходимые работы по типографии контента, оптимизации графики.
7.3. Кадрирования изображений
Для того, чтобы на разных разрешениях экрана использовались картинки разных форматов, в коде используется тег picture, для того, чтобы указать какая картинка используется в том или ином разрешении. Так как на интеграции проекта, в большинстве случаев, кадрирование не используется, мы не делаем его по умолчанию. При необходимости кадрирования важно, чтобы графика на кадрирование была подготовлена.
7.4. Разработка калькуляторов, валидация и отправка данных из форм, работа с фильтрациями через сервер.
Весь этот функционал оценивается и реализуется отдельно.