Вы когда-нибудь думали, что ручной HTML-код — это дорого, долго, избыточно и устарело?
Я думаю об этом каждый день, когда создаю очередной GUI-компонент или системный элемент. Эта статья — моя попытка сделать обзор текущего состояния отрасли, ее проблем и поделиться результатами своего исследования.
Интересный? Добро пожаловать под кат!
Прежде чем мы начнем
Хотите попробовать это прямо сейчас? Вот доказательство концепции.
Он показывает общие аспекты концепции. Многие случаи не реализованы, и это влияет на качество, но я думаю, что концепция доказана. Подробности ниже.
Это моя первая публикация на английском языке, будьте снисходительны. Любые предложения по исправлению приветствуются.
Глоссарий
Я использую «HTML-код» в следующих значениях:
1. Как рабочий процесс HTML-разработчика.
2. Как артефакты, полученные после работы HTML-разработчика — HTML, CSS, JS и т. д.
вступление
Около 8 лет назад я высказал мысль, что ручное HTML-кодирование устарело и его заменит автоматизация. С этого момента я внимательно наблюдаю за попытками решить этот вопрос. У нас есть такие инструменты, как Workflow, Bootstrap Studio, inVision, Framer, Supernova, React Studio и множество других прямых и косвенных решений.
А еще у нас есть потрясающие исследования на эту тему с использованием нейронов, а-ля pix2code или sketch2code.
К сожалению, я не могу найти инструмент, который можно было бы полностью интегрировать в мой процесс разработки.
Но чего я хочу? Я хочу получить макетиз Верстальщика, разбить его на компоненты, подправить HTML-код, где нужно, добавить логику, получить библиотеку компонентов и вернуть все это дизайнеру для будущих взаимодействий. Я понимаю, что он превосходит даже самые передовые возможности индустрии, но это моя мечта…
Как говорил Конфуций, долгий путь начинается с первого шага, поэтому я решил выяснить, с чего начать. Об этом и будет эта статья.
Проблема
Прежде всего, мы должны определить разницу между HTML-кодом и интерфейсом:
HTML-код — это полуфабрикат, грубо говоря, результат преобразования графического формата в HTML, CSS и другие файлы, предназначенные для дальнейшего преобразования в графический интерфейс.
Интерфейс — готовый артефакт системы, с которым будут взаимодействовать пользователи.
В 2020 году ручное HTML-кодирование по-прежнему остается основным способом создания веб-интерфейсов, что само по себе довольно интересно. Это идет вразрез с тенденциями параллельных стеков, таких как нативные и настольные приложения, где инструменты визуального проектирования интерфейса являются стандартом для его создания.
Можно долго спорить, почему так, но как мне кажется, основные выводы такие:
1. высокие требования к итоговому коду и
2. необходимость низкоуровневого контроля
предлагаю оставить за скобками «лобби HTML кодеров» :).
Макет сложный, требует использования специальных методов и инструментов для управления, сведения к минимуму ошибок и поддержки в актуальном состоянии.
Анимации — это другой большой вопрос. Создание сложной анимации может оказаться невыполнимой задачей для многих компаний, потому что это очень трудоемко.
HTML кодирование стоит дорого, в среднем это от 25% стоимости всей системы для SPA и до 75% для лендингов.
Общепринятой теории HTML-кодирования как таковой не существует.
Стандарт W3C очень широк, и каждый разработчик/команда руководствуется своими правилами и стандартами.
Мое решение
Сначала мы должны формализовать процесс HTML-кодирования, определить сущности, алгоритм и правила. Конечно, сама тема достаточно обширна, и ее полное раскрытие не является целью данной статьи. Исходя из этого, мы рассматриваем только ту часть, которая в данный момент представляет интерес.
Шаблон
Попробуем определить процесс создания шаблона.
Шаг 1
Визуально разделите на дерево блоков высокого уровня.
Найдите строки и столбцы макета.
Шаг 2
Семантический анализ, определяем основные блоки:
1. Заголовок
2. Тело
3. Боковая панель
4. Подвал
5 . И т.д…
Тут мы сразу сталкиваемся с интересным явлением, макета не всегда достаточно для построения полноценной структуры, поэтому дизайнер интерфейса должен уточнить поведение блоков. Что наводит на мысль, что семантического анализа тоже не всегда достаточно.
И пока нам этого достаточно. Здесь мы можем разделить нашу задачу на две большие группы:
1. Технические и
2. Семантические.
Давайте отложим семантическую группу для будущих исследований и сосредоточимся на технической.
Несмотря на то, что HTML-код картинки нейросетью — очень интересная задача, на мой взгляд, избыточная.
Трудно представить ситуацию, когда в обычном рабочего процесса дизайнер интерфейсов присылает макет в формате растрового изображения.
Чаще всего у нас есть форматы, созданные в таких инструментах, как Figma, Sketch или Adobe Photoshop, которые уже содержат практически исчерпывающую информацию о макете, наиболее главное:
1. Положение элементов;
2. Тип элементов;
3. Стили элементов;
Получение HTML-документа на основе этой информации — уже решаемая задача, так как инженеры из Figma уже поделились своей конверсионной реализацией и результатами исследований, а такие сервисы, как Anima, напрямую построены на синхронизации макетов и интерфейса.
Но почему такие решения не привели к эффекту разорвавшейся бомбы и спустя 2 года нет ничего лучше старого доброго рукотворного HTML-кода?
Здесь я повторяю свое мнение Причиной этого являются два фактора:
1. Высокие требования к качеству
2. Необходимость контроля
Контроль вещь несомненно нужная, но без удовлетворения первого требования он не имеет особого смысла. Будет проще сразу внедрить и управлять качественным HTML-кодом, чем пытаться исправить некачественный.
Таким образом, первое требование является первостепенным. Но что делает код качественным?
Если мы удалим официальные показатели качества, такие как LTR, Доступность и тому подобное, мы останемся с важными для разработчиков показателями качества:
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;
Вы можете увидеть и поиграть с доказательством концепции здесь.
Вывод
Автоматизация высококачественного HTML-кода возможна без использования слабо контролируемых алгоритмов машинного обучения. Это значительно удешевит создание продукции и повысит ее качество. Немаловажно и то, что это упростит работу разработчиков и сделает ее более интуитивно понятной и приятной.
Но необходимы дальнейшие исследования, а сама проблема требует более пристального внимания сообщества для реализации полнофункциональной модели и инструментов на ее основе.
Что дальше?
Думаю, следующим важным шагом будет подтверждение концепции управляемости. Основным фактором здесь будет преобразование кода в макет. При изменении кода обновляется и макет — создается двусторонняя привязка между инструментом дизайна и HTML-кодом.
Будет здорово увидеть любую конструктивную критику и обсуждение. Мир!
