Комментарии 15
Здорово, очень интересно было прочитать
Конструктор - это действительно интересно. Это оптимизация работы дизайнера. Вопрос в цене)
Скорей маркетологов, которые с конструктором не блокируются разработкой, что дает очень серьезное приемущество в скорости
Интересно, а маркетологов ли? Никогда не видел чтоб флоу был маркетолог => конструктор => продакшн. Обычно на каком-то этапе всё-равно дёргают разработчика, например - маркетолог => разработчик => конструктор => продакшн. Т.е. пользователь конструтора это и есть разрабы, но никак не дизайнеры\маркетологи, потому что "сложно", проще через человека делегировать.
Я про такой подход читал у Тинькофф'а, оригинальную статью не могу найти, но вот про свою CMS они рассказывают https://habr.com/ru/company/tinkoff/blog/553748/
У себя мы тоже так реализовали, и теперь разработка учавствует в создании лендингов, только если новый блок надо внести в библиотеку.
Действительно, в первую очередь это оптимизация ресурсов разработчиков, так как теперь не нужен фронтендер, чтобы верстать лендинги. Максимум, когда может понадобиться - если происходит редизайн блоков/сайта или не хватает текущего набора блоков для реализации фантазии дизайнера.
При этом оптимизация работы дизайнера тоже присутствует - раньше дизайнеру все равно приходилось каждый ленд рисовать где-то, даже если он брал дизайн блоков из предыдущих макетов. И в каждом макете был зашит текстовый контент. В случае правок текста (например, не согласовали выше формулировки) приходилось и макет править. А в суматохе можно забыть поменять текст, например, в мобильном макете, и уже разночтения появляются и неудобства. Сейчас дизайнеры в разработке лендов могут участвовать на уровне описания "Сначала презентационный блок, вот иконки. Потом блок '4 преимущества' в темной теме, потом ..." - это требует гораздо меньше ресурсов. Они даже могут сами за считанные минуты набросать черновик из блоков, а контентом займутся контент-менеджеры.
Маркетологам теперь удобнее согласовывать тексты - можно в гугл доке хранить все тексты с пометкой, к какому блоку относится. Все понимают, как выглядит, к примеру, блок "Портфолио студентов" и представляют, как что будет в финале выглядеть. Ну и всегда можно дать на предпросмотр собранный не опубликованный черновик, и согласовывать и править внешний вид и тексты, так сказать, в реальном времени
"Для этого на бэкенд создали задачу, где описали, что нужно пройти по всем лендингам, у каждого из них взять json с контентом, найти там блок по ключу и поменять в нём структуру: добавить контент из поля B в контент поля A, после этого удалить поле B. Такая ситуация возникала раз 10 при редизайне."
Есть более хорошее решение этой проблемы, одназначно лучше, чем описанное в статье (хотя описанное в статье - это первое, что приходит в голову). Решение следующее: админка является полностью независимой библиотекой, имеет свое версионирование и публикуется как отдельный пакет на внутренних серверах. Также имеет внутри себя скрипты миграций между версиями. Все производные продукты зависят просто от некоторой версии этой самой админки и используют ее как внешний пакет. Если возникает необходимость, то в конкретном продукте происходит апгрейд версии админки. А в других при этом апгрейд без необходимости не делается. Обычно такое решение приходит в голову на 6-7 продуктах, когда понимаешь, что обновление нужно в 1 продукте, во втором продукте, оно не обязательно, а в 5 других вообще не нужно.
Спасибо за решение! Подумаем, можем ли применить что-то подобное :)
Если под продуктом понимать лендинг, то сейчас у нас есть один компонент "ConstructorContainer", в котором происходит получение JSON с описанием блоков и рендеринг их в нужном порядке с нужным контентом. Каждый из 1400 лендов - по сути, этот компонент. И в текущей реализации ваш вариант сложно прикрутить сходу. Но, в любом случае, спасибо, что поделились!
мы тоже делаем свой, по сути итог такой же, готовая библиотека компонентов и из нее можно составлять блоки, но более гибко сделали тем, что при редактировании лендинга не нужен никакой жсон, выстраивается реальное дерево и открывается редактор стилей, можно менять стиль абсолютно любого елемента и картинку. К этому функционалу есть фича создания блоков (сделано с тильды, елементы абсолютами раскидываются). Как задача интересно, как нужный проект не думаю, проще взять тильду
Конечно, вариаций решения может быть несколько, и может быть, когда-нибудь мы переделаем все это и назовем "Конструктор Лендингов 2.0" :), но пока что он хорошо работает с точки зрения бизнеса - не требует много ресурсов для своей поддержки и достаточно хорошо масштабируется, а это сейчас главное, можно развивать другие направления.
По поводу редактора стилей - для наших внутренних пользователей такой глубокий функционал не нужен. Нужно максимально простое решение основной задачи - наполнение контентом (то есть вбивание текста в нужные места блока и выбор картинок. Максимум, еще требуется иногда кнопку другим цветом раскрасить, но это исключение и тоже сделано в виде выбора фона кнопки из 4 вариантов цветов)
своё решение хорошо пока в нём..
а потом к нему вернуться сложно,
и главное как правило никто не заморачивается с документаций
и собственно с поддержкой через года.
JSON с одной стороны удобен, с другой, как обрабатывать не известные поля, добавлять, поддерживать старые версии лендиинга/блоков
С конструктором работает большое количество людей (контент-менеджеры, дизайнеры), поэтому есть внутренние документы по тому, как что работает с точки зрения внутреннего пользователя. Описание, гайды, схемы.
С точки зрения разработчика код довольно простой получился - есть базовый ConstructorComponent, от которого наследуются отдельные компоненты для каждого блока. В ConstructorComponent сосредоточена основная логика работы с настройками, а в конкретном блоке только верстка, по большому счету. Так что пока что проблем с быстрым въездом новых разработчиков не возникает :)
JSON с одной стороны удобен, с другой, как обрабатывать не известные поля, добавлять, поддерживать старые версии лендинга/блоков
Необходимости в версионировании блоков пока что не возникало - если на разных лендах требуется разный вид блоков, то можно либо добавить настройки (например, "показывать 2 или 3 столбца") или же создать новый блок с измененным дизайном. А неизвестные поля... Так как бэкенд вообще не знает про структуру блоков, это дает большую гибкость, ну а процесс изменений через миграции, как описано в статье, пока что работает хорошо :)
Спасибо за статью. Тоже подумал сразу о вопросе цены)
Забыл в статье написать, что с конструктором оказалось удобно проводить A/B-тесты. Для этого у каждого блока есть поля "ID эксперимента" и "Группа эксперимента". При рендере каждый блок проверяется на то, а попал ли текущий пользователь в группу указанного эксперимента. Если да, то рендерим этот блок. И в режиме редактирования есть предпросмотр, как будет лендинг выглядеть для разных групп
Мы сделали свой конструктор лендингов. Зачем, если их и так много, и что получилось