Критерии качества

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

Большинство описанных критериев не имеют двойной трактовки, однако так же будут критерии, в которых есть возможность выбрать тот или иной вариант.

Документ живёт вместе с развитием индустрии, а значит со временем критерии качества могут меняться и модифицироваться.

1. Удобство проверки и дальнейшего использования

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

1.1. В вёрстке присутствует разводящая страница со всеми страницами и компонентами

По адресу index.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 По умолчанию поддерживаются 5 последних версий стабильных браузеров Chrome, Mozilla, Opera, Safari и Edge Chromium. А также стабильные версии мобильных браузеров.

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

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. Разработка калькуляторов, валидация и отправка данных из форм, работа с фильтрациями через сервер.

Весь этот функционал оценивается и реализуется отдельно.