Как мы написали конструктор для сайта СМИ на Битриксе

В этом кейсе мы расскажем, как мы придумали и написали модуль, превращающий сайт СМИ на Битриксе в легко администрируемый конструктор, позволяющий заказчику забыть о необходимости обращения к разработчикам, даже при условии, что его сайт ежедневно меняет фронт-енд. 

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

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

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

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

В разработанном заказчиком дизайне, лента главной страницы представляла из себя набор карточек в сетке из трех колонок на десктопе и одной колонки на адаптиве.

После ознакомления с дизайном мы решили провести глубинное интервью и уточнить у Заказчика, каким образом он планирует монетизировать этот проект, так как контент в карточках и колонках был достаточно разноплановый: Услуги, Афиши, Достопримечательности, Организации, Новости, Блог, Объявления и другое. То есть, контент агрегатора можно было сразу же поделить на коммерческие и некоммерческие направления. 

Например, рубрику Новости и Достопримечательности будут читать жители региона и его туристы. А рубрику Объявления, Организации будут просматривать как заинтересованные в покупках различных услуг (например, такси или маникюр) жители региона, так и сами рекламодатели. 

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

– Заказчик рекламы может выкупить любое место в любой колонке;

– Рекламное место выкупается на определенный срок, после чего объявление нужно снять с публикации;

– Эталонно администрировать это силами редакторов заказчика, которые будут получать заявки на размещение от отдела продаж, чтобы не держать в штате разработчика;

– В день могло быть неограниченное количество корректировок в связи со снятием рекламных блоков с публикации, либо продлением публикации на новый срок;

– Отдельные блоки и сам адаптив управляются независимо от типа устройства (на адаптиве часть блоков отсутствовала).

Вместе с Заказчиком мы составили описание всех элементов имеющихся колонок. Несмотря на это, блоки в одном типе могли иметь разные требования к расположению (колонка) и к управлению блоком.

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

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

Для реализации этого проекта потребовалось собрать команду из менеджера проектов, Front-end разработчика (знающего VueJS) и Back-end разработчика, умеющего работать с Rest APi. 

В рамках ТЗ определили последовательно шаги процесса разработки:

1) Подготовка среды разработки

Настройка локальных копий и демо-среды для клиента.

2) Back-end (реализация на уровне независимого Модуля Битрикс)

2.1 Архитектура модуля

2.2 Rest APi (с описанием методов и запросов)

2.3 Кеширование под проект, с уклоном на большие нагрузки (html, memcache) 

2.4 Проработка возможностей SEO

2.5 Проработка возможностей Автотестирования 

3) Front-end

3.1 Интеграция верстки в реактивную среду Vue.js

3.2 Проработка связи js контейнера с Rest APi

3.3 Отладка производительности приложения на клиентах

3.4 Проработка возможностей Автотестирования при деплое

4) Совместное тестирование внутри компании 

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

Сценарии работы редактора можно было отразить следующим образом, пошагово:

Шаг 1: Заходит на сайт в административную панель.

Шаг 2: Создаёт физически новость в разделе "Данные" - Новости - Создать элемент. Устанавливает галочку "Показывать на главной", являющуюся признаком отправки элемента в таблицу модуля.

Шаг 3: Переходит во вкладку модуля в админке (Вынесен в меню отдельно).

Шаг 4: Переходит в основную панель - управление порядком блоков с информацией. Выбирает нужный блок, например, Новости.

Шаг 5: Видит список новостей (помеченные для отображения на главной). 

Шаг 6: Находит нужную новость среди опубликованных на главной, либо через поиск по названию новости

Шаг 7: Устанавливает параметры сортировки (порядок вывода блока в колонках), сроки закрепления публикации (поля для ввода интервала даты активности)

Шаг 8: Блок выведен на главную страницу с указанными редактором или администратором параметрами.

1) Автоматическое управление интервалами активности

– Задается начало активности публикации элемента или блока

Публикация появляется на странице в указанную дату и время. Если она не заполнена принудительно — выводится автоматически с момента присвоения статуса «Опубликовать на главной»

– Задается окончание активности публикации элемента или блока

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

2) Ручное управление публикацией элементов:

- Кнопка «Включить»

- Кнопка «Выключить»

3) Для разделов по умолчанию:

- Возможность задавать ограничение на количество элементов для вывода в блоке

- Возможность задавать сортировку относительно других блоков

4) Отображение блока в зависимости от устройства

- Возможность задать индивидуальные настройки отображать/НЕ отображать

- Возможность задать индивидуальные настройки сортировки для ПК и телефона.

В конечном итоге, после окончания реализации модуля, мы сделали ретроспективу и выделили для себя такие выводы к успеху подобных реализаций на основе своих ошибок:

1. В любой гениальной идее может и имеет место быть две стороны “медали”: бизнес-логика заказчика и логика возможностей сценариев работы решения. Они могут совпадать (и в идеале) стремятся к закрытию единой задачи - автоматизации бизнеса, минимизация операций и рутины. Чтобы на старте учесть все подводные камни и синхронизировать ожидания заказчика и разработчика, категорически важно согласование пожеланий и точное снятие потребностей при помощи визуальных инструментов: логических карт, прототипов, описание пользовательских сценариев.

2. Важно вести документацию проекта и его API с самого начала работ. 

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

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