29.06.2020 08:36
firstpasha 34 15900 Источник

А Вас не посещала мысль, что вёрстка руками — это долго, дорого, избыточно и устарело?
Меня вот постоянно. В данной статье я поверхностно затрону текущее состояние индустрии, проблематики и поделюсь результатами своих исследований.


Интересно? Добро пожаловать под кат!



Перед началом


Если хочется сразу "пощупать", вот проверка концепции.


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


Термины


В тексте я использую термин "Верстка" в 2?х значениях:


  1. Процесс создания разметки
  2. HTML, CSS, JS и другие документы — артефакты созданные после работы верстальщика.

Введение


Около 8 лет тому назад, я высказал идею, что ручная вёрстка устарела и на смену ей придёт автоматизация. С того момента я пристально слежу за попытками решить этот вопрос. У нас появились такие инструменты как Workflow, Bootstrap Studio, inVision, Framer, Supernova, React Studio и многие другие прямые или косвенные решения.


А так же мы имеем и вовсе космические исследования этой темы при помощи нейронок, а ля pix2code или sketch2code.


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


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


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


Проблематика


Тут нужно сразу обговорить разницу между вёрсткой и интерфейсом:


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


Интерфейс — полноценный артефакт системы, с которым будут взаимодействовать пользователи.


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


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


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


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


Верстка это дорого, в среднем это от 25% стоимости всей системы для SPA и до 75% для посадочных страниц.


Не существует общепринятой теории вёрстки как таковой.


Стандарт W3C очень широкий и каждый верстальщик / команда руководствуется своими собственными правилами и стандартами, которые попадают в рамки валидной разметки.


Решение


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


Шаблон


Шаг 1


Визуально разделим на высокоуровневое дерево блоков.


Найдём строки и колонки макета




Шаг 2


Семантический анализ, определим основные блоки:


  1. Шапка;
  2. Тело;
  3. Боковые панели;
  4. Подвал.


Тут мы сразу сталкиваемся с интересным явлением, простого макета не всегда достаточно для построения полноценной структуры, так проектировщик интерфейса должен уточнить поведение блоков. Что наталкивает на мысль, что семантического анализа тоже не всегда достаточно.


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


  1. Техническую и
  2. Семантическую.

Отложим семантическую группу для будущих исследований и сосредоточимся на технической.


Несмотря на то, что вёрстка по картинке нейронной сетью задача очень интересная, по моему мнению, она избыточна.


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


Чаще всего это форматы, созданные в таких инструментах как Figma, Sketch или Adobe Photoshop, которые в себе уже содержат практически исчерпывающую информации о макете, самое главное:


  1. Положение элементов;
  2. Тип элементов;
  3. Стили элемента.

Получение HTML документа на основе данной информации является уже решенной проблемой, так инженеры из Figma уже поделились своей реализацией конвертации и результатами исследования, а такие сервисы как Anima прямо построены на синхронизации макетов и интерфейса.


Но почему же подобные решения не привели к эффекту разорвавшейся бомбы и спустя 2 года нет ничего лучше старой доброй ручной вёрстки?


Тут я повторюсь, моё мнение, причина этого два фактора:


  1. Высокие требования к качеству;
  2. Необходимость в контроле.

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


Таким образом, первостепенным является первое требование. Но что же делает код качественным? Если убрать за скобки официальные показатели качества как LTR, Accessibility и подобное, мы останемся с важными показателями качества для разработчиков:


  1. Правильное дерево;
  2. Семантика;
  3. Отсутствие избыточности;
  4. Читаемость и редактируемость;
  5. Использование вырванных из потока блоков только там, где это нужно.

Таким образом главной задачей для автоматизации и будет соответствие этим критериям.


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


Строки и столбцы


Строки


Если позиция одного элемента попадает в отрезок высоты другого, то они образуют одну строку.



Столбцы


Аналогично, если позиция одного элемента попадает в отрезок ширины другого, то они образуют одну колонку.



Отношения элементов


Независимое расположение


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



Расположение с перекрытием


Перекрывающие элементы вырываются из потока, позиционируются абсолютно, не влияют на позиционирование других элементов.



Процесс построения дерева блоков


Шаг 1


Определим все строки.



Шаг 2


Находим отступы у каждой строки.



Шаг 3


Выбираем строку для проработки и определяем тип разметки:


  1. Одноколоночная
  2. Многоколоночная


Шаг 4


Для многоколоночной, определяем тип колонок:?


  1. Плавающие
  2. Сетка

В зависимости от типа, формируем отступы между колонками.



Шаг 5


Определяем тип колонки по количеству элементов в ней:


  1. Единичная
  2. Множественная

Если тип единичный, позиционируем элемент относительно колонки, переходим к следующему.



Шаг 6


Для типа колонки "множественная" находим все строки
Типы строк аналогичны типам колонок:


  1. Плавающие
  2. Сетка

Находим отступы.
Повторяем весь алгоритм пока есть хоть один необработанный блок.



И теперь реализуем полученные утверждения в код.
Упрощение:


  1. Быстрая реализация, покрывающая только ~20% случаев;
  2. Ошибки позиционирования ожидаемы;
  3. Одноуровневая структура исходных блоков;
  4. Стили записаны в атрибут style;

Увидеть и "пощупать" доказательство концепции можно по ссылке.


Вывод


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


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


Что дальше?


Считаю следующий важный этап — это подтверждение концепции контролируемости автоматической разметки. Главным фактором тут будет являться обратное преобразования кода в макет, так, чтобы при изменении разметки обновлялся и он — создание двусторонней связи между инструментом дизайна и разметкой.


Буду рад конструктивной критике и такой же дискуссии. Всем мир!