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

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

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

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

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

Термины

В тексте я использую термин "Верстка" в 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;

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

Вывод

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

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

Что дальше?

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

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

Итак, вы проделали огромную работу: писали код, разделяли на блоки, навешивали стили, адаптировали код для мобильных устройств. Работа готова. Давайте убедимся, что это действительно так, и заказчик не вернет ее на доработку.


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

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

Внешний вид и работоспособность сайта

1. Целостность верстки, соответствие техническому заданию. Должны быть сверстаны все страницы, которые есть в макете и все скрытые слои, модальные окна, формы.
2. Внешне сайт выглядит как макет. Присутствуют все картинки. Размеры элементов и блоков соответствуют макету. Если это обсуждалось с заказчиком, то сайт должен соответствовать макету с точностью до нескольких пикселей.
3. Подключены необходимые шрифты. Размеры, толщина и начертания шрифтов соответствуют макету. Также указаны правильные межстрочные расстояния.
4. Все интерактивные элементы работают в соответствии с техническим заданием: ссылки ведут куда надо, модальные окна всплывают, форма отправляется. Конечно, в том случае, если это была ваша работа, а не программиста. В противном случае убедитесь, что у модалок прописаны стили класса, отвечающего за его появление, а у формы есть атрибуты method и action.
5. Интерактивные элементы имеют состояния при наведении, клике и выделении (:hover, :active и :focus). У всех ссылок, кроме пунктов меню, должна быть реакция на :visited. Если состояния прописаны в макете или стайлгайде, они должны соответствовать замыслу дизайнера. Если они не были предусмотрены в дизайне, состояния остаются на усмотрение верстальщика. При взаимодействии с интерактивными элементами ни сам элемент, ни окружающие его блоки не меняют своего положения, если это не было предусмотрено в техническом задании.
6. Кроссбраузерность. Сайт должен одинаково выглядеть и одинаково работать в разных браузерах. В каких именно обычно обговаривается в техзадании. Иногда заказчик требует поддержку старых версий IE, иногда не требует IE и Edge вообще. Но обычный набор: последние версии Google Chrome, Mozilla Firefox, Opera, Safari, Microsoft Edge, Internet Explorer.
7. Адаптивность верстки. Сайт должен нормально смотреться на самой разной ширине экрана: от самого маленького мобильного до широкоформатного десктопа. Внешний вид сайта при настолько отличающихся размерах может сильно различаться. Эти различия дизайнер отображает в макете. Работа верстальщика сверстать так, чтобы сайт точно соответствовал дизайну в определенных промежутках размеров экрана. И не разваливался при любой ширине экрана.

Качество кода

Теперь проверим те детали, которые не видно невооруженным взглядом.

1. Валидность. Верстка должна проходить проверку валидатора (http://personeltest.ru/aways/validator.w3.org/) Валидатор не должен показывать критических ошибок, но предупреждения допустимы.
2. Семантичность верстки. Сайт должен быть сверстан с использованием специальных семантических тегов, с учетом спецификации HTML5. Так структура сайта выглядит более логично. Также использование семантической верстки улучшает индексирование сайта поисковиками.
3. Доступность. Ваш сайт должен быть сверстан в соответствии с современными требованиями доступности. Помимо моральных бонусов, выполнение этого пункта также даст вам плюс к индексированию поисковиками. Для доступности необходимо использовать семантические теги, структурировать разметку при помощи заголовков, прописывать атрибут alt для подписей к картинкам, должна быть предусмотрена возможность фокусировки на интерактивных элементах и элементах форм при передвижении с клавиатуры.
4. Единообразие и аккуратность кода. Код должен быть написан или отформатирован так, чтобы его было легко читать и понимать. Возможно, ваш проект когда-нибудь будет дорабатывать другой разработчик. Надо писать так, чтобы ему было легко разобраться в коде. Структура проекта дело вкуса и привычки. Но хороший тон давать понятные названия папкам и файлам. Также хорошая практика оставлять комментарии в html, css и javascript файлах с указаниями, за что отвечает то или иной кусок кода.Также в вёрстке не должны оставаться закомментированные и неиспользуемые куски кода, лишние файлы, старые версии файлов.
5. Сайт должен корректно работать при добавлении текстового контента. Верстка должна быть надежна. Даже если вы верстали не интернет-магазин или блог, владельцу сайта может понадобиться изменить контент. При этом вёрстка не должна съехать или развалиться. При добавлении текстового контента вид и расположение блоков должно оставаться похожим на то, как это было нарисовано в макете.
6. Базовая работоспособность сайта должна сохраняться при выключенном javascript. Основной функционал сайта должен быть доступен при отключенном javascript. Это не касается украшательств сайта: эффектов и анимации. Но все страницы должны быть доступны, а в формы можно попасть и без всплывающих попапов.

Оптимизация скорости загрузки страницы

Проверьте в инструментах разработчика, сколько секунд грузится сайт. В идеале скорость загрузки должна составлять 3-4 секунды.

Убедитесь, что:

• скрипты css подключены в <head>, а javascript в конце html файла, перед закрывающим тегом </body>
• для картинок выбран верный формат, и они сжаты. Если изображений много, и они должны быть в хорошем качестве, целесообразно использовать для их загрузки библиотеку LazyLoad.
• css и javascript файлы, если их было несколько при разработке, объединены в файл и сжаты. Если javascript используется не на каждой странице, то к этим страницам его подключать не надо.

Еще более мелкие проверки

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

1. В <head> прописан DOCTYPE: HTML5 и кодировка UTF-8.
2. Логотип компании должен быть в формате SVG и в виде ссылки.
3. Изображения должны масштабироваться в зависимости от размера окна (max-width:100%; height:auto;).
4. Телефон размечен с помощью ссылки с атрибутом tel.
5. Все внешние ссылки должны открываться в новом окне.
6. В формах label и input/select/checkbox должны быть связаны между собой. По клику на описание поля формы курсор должен становиться внутрь поля для ввода. Также должны быть указаны правильные типы для инпутов: type=email/url/tel. При работе с формой с телефона, в зависимости от типа инпута, должна показываться разная клавиатура: обычная или цифровая.
7. Должна быть предусмотрена валидация формы: при попытке отправить пустую или неверно заполненную форму должны появляться уведомления о необходимости заполнить поля.

Ещё больше о верстке можно узнать на нашем шестимесячном курсе Профессия: Программист Узнать подробности!

Как "подружить" дизайнера и инженера? Как дать им работать с одними и теме же данным, без ущерба продуктивности? Как хранить дизайн в системе контроля версий. Если вас интересуют эти вопросы, в такой же степени как и меня, то добро пожаловать под кат!

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

В первой части я, вкратце, описал проблематику как самой вёрстки, так и её автоматизации. Так же поделился своими результатами исследования этой темы. Остановился же я на вопросе контролируемости автоматизируемой вёрстки.

В данной статья я раскрою более подробно это понятие и поделюсь результатами своих исследований.
Хочеться с чем-то поиграться? Вот проверка концепции.

Контролируемость

А о какой контролируемости вообще идёт речь?
Я выделил два основных положения:

1. Возможность влиять на процесс генерации HTML кода.
2. Прямое редактированию результата, которое будет учтено при последующей генерации.

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

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

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

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

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

Решение

Главная идея если макеты делаются для создания HTML документа, то весь макет можно описать в HTML и CSS.

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

Но если макет описан в HTML документе, то что мешает разработчику открыть код и дописать логику, оживить макет там, где это невозможно сделать с использование визуального редактора? Ответ ничего, да с оговорками, но это возможно.
Таким образом у нас появляется 2х сторонняя связь между инструментом дизайна и исходным кодом.

Возможно, кто-то скажет, что это звучит как утопия, Unity 3D, скажу я в ответ.

Unity, как и любой другой игровой движок уже давно реализовали подобную концепцию в своих инструментах.

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

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

Хорошо, я хочу иметь что-то типо Unreal Engine, но для WEB. С чего вообще начать?
У меня есть на руках:

1. Простой Drag&Drop визуальный редактор;
2. Концепт модуля генерации разметки;
3. Какой-то HTML код, что я хочу редактировать.

Первым вопросом стало, как это всё объединить вместе.

Движёк

Любой движёк состоит из модулей, значит с этого и стоит начать.

Ух, тут прям в голову начинают лезть мысли о модуле мокирования api, тестирования, управлением хранилищем, создания анимации, оптимизации, работы с зависимостями, документирования

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

Модуль отображения

Возможно вопрос и очевидный, но вообще, что мы и где рисуем?

У нас есть HTML код, который мы должны чем-то прочитать и отобразить. Логичным выбором тут будет самый популярный рендер WebKit Blink, его мы используем как модуль отображения(рендеринга).

Модуль чтения-записи

А вот с модулем чтения всё не так очевидно. Пока речь идёт о единой точки входа (весь код лежит в index.html), никаких проблем нет. Но реальное приложение может иметь сколь угодно сложную архитектуру и храниться в любом формате.
Пока видится 3 варианта как с этим справиться:

1. Работа с финальным кодом, с промежуточным рендерингом;
2. Максимальное покрытие всех стеков популярных технологий;
3. Строгое стандартизирование.

Чистого варианта тут нет, каждый имеет свои минусы.

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

Первый же вариант кажется очень перспективным, но с рядом сложных моментов, решение которых может оказаться дольше, чем 2.

Из очевидных проблем:

1. Сопоставлени промежуточного с оригинальным;
2. Приведение промежуточного кода, к формату оригинального.

Проблемы интересные и требуют исследований.

Модуль создания разметки

По всей видимости, самая простая часть.

Модуль визуального взаимодействия

А с чем мы вообще можем взаимодействовать?

Вот так выглядит дерево на одном из лендингов, описывающее 2 блока, лежащие рядом.

Глядя на него, вспоминается Adobe Illustrator в котором, чтобы добраться до нужного элемента, нужно кликнуть на одно и то же место 2 * N раз. Если там это оправдано, то в редакторе интерфейса это совсем неуместно.

Но если присмотреться, из редактируемых элементов тут только заголовок и параграф. Остальные описывают расположение элементов.

Этот факт хорошо иллюстрирует следующую концепцию не весь HTML код значим одинаково.

Из этого сформулируем правило. HTML код делится на:

1. Значимый и;
2. Незначимый.

Пользователь взаимодействует со значимыми элементами.

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

Сам же редактор должен соответствовать всем ожиданиям дизайнера.

Связь

А что мы вообще имеем и что с чем связываем?
У нас есть:

1. Код, как источник правды;
2. DOM дерево;
3. Визуальное отображение.

При изменении кода, меняется DOM, что приводит к перерисовки отображения.

При изменении визуального отображения мы можем:

1. Изменить DOM, сохранить производный результат в код.
2. Изменить код, что приведёт к изменению DOM.

Каждый из вариантов приведет к перерисовки отображения.

Состояние

Но каков жизненный цикл DOM? Помимо редактора, его может менять и логика.

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

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

Всё вышеописанное звучит так, что в пору дождаться сильного ИИ, а пока оставить данное занятие Или вводить ограничения.
Снова обратимся к сравнению с игровыми движками. Там всегда есть как минимум 2 режима:

1. Редактор;
2. Предпросмотр.

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

Что же касается остальных, то я бы разделил их на 2 типа состояний:

1. Ручные, те что может понять редактор и дать над ними контроль;
2. Автоматические, непонятные редакторому, управляемые программно.

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

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

Резюме

Из вышеописанного складывается следующий концеп:

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

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

Проверка концепции

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

Код же выступает источником правды и хранит данные репрезентации, мета информацию, и структуру (контейнер-потомок).

Последующие же открытие кода восстанавливает состояние визуального редактора.

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

Ограничения

1. Значимыми элементами считаются те, у кого есть класс или идентификатор;
2. К элементам не применяются сторонние эффекты;
3. Идентификатор является уникальным, повторное использование приведёт к неожиданным последствиям;
4. Большинство крайних случаем не рассмотрены;
5. Ошибки ожидаемы;
6. Компоненты и состояни не реализованы;
7. Код в HTML формате.
8. Передвижение контейнера с потомками возможно при "захвате" пустого места

Вывод

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

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

Что дальше?

У меня есть ещё месяц свободного времени, так что достаточно игры в "кубики", пришло время реализовать чистовую модель редактора. Для начала, в качестве целевого стека, буду использовать React, а точнее JSX + styled-components, как наиболее используемый и изученный.

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

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

Разумеется, буду очень рад видеть конструктивную критику и дискуссию.

Всем мир!