Adobe Experience Manager и WordPress: сравнение опыта разработки

Спасибо, WordPress и Gutenberg, за то, что сделали блочное редактирование стандартом для создания веб-страниц. В этой статье я собираюсь сравнить новый опыт разработки в WordPress с возможностями Adobe Experience Manager (AEM), корпоративной системы управления контентом, которая также поддерживает блочное редактирование. Я реализовал как WordPress, так и AEM для нескольких компаний (таких как Informatica и Twitter) и должен был понять, что, несмотря на то, что авторский опыт имеет решающее значение для нетехнических авторов, разработчики часто пренебрегают им.

Примечание . Под термином «авторский опыт» я имею в виду пользовательский опыт для тех людей, чья цель — создавать и публиковать контент на веб-сайте. Я не имею в виду людей, которые собираются потреблять опубликованный контент. Если вы раньше не думали об авторском опыте, вот учебник для начинающих от Эйлин Уэбб, которая также была представлена ​​​​в Smashing Book 5.

Adobe Experience Manager по сравнению с WordPress представляет собой сложную систему с крутой кривой обучения, особенно для разработчиков. В то же время AEM проще в использовании, чем более известные и дорогие решения для управления контентом, что ставит AEM где-то посередине между бесплатными и очень дорогими решениями.

С технической точки зрения, AEM представляет собой конгломерат технологий с открытым исходным кодом с несколькими штрихами от Adobe, что ставит AEM где-то посередине между программным обеспечением с открытым исходным кодом и проприетарным программным обеспечением. Именно штрихи от Adobe делают систему блестящей и удобной в использовании. Например, конструктор страниц с визуальным перетаскиванием был стандартным способом создания страниц в AEM — задолго до появления WordPress Gutenberg.

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

Компоненты (блоки)

Одной из наиболее важных идей для веб-сайтов является концепция компонента (или блока на жаргоне WordPress). Компонент представляет собой часть контента, которая следует определенным правилам, а не является чем-то большим. Например, у вас может быть компонент видео, в котором автор может только вставить ссылку на Youtube и управлять специфичными для Youtube настройками. Или у вас может быть компонент цитаты, в котором автор добавляет цитату в одно текстовое поле и имя цитируемого человека в другое текстовое поле. У вас даже может быть компонент макета, который содержит другие компоненты и отображает их друг под другом на мобильном устройстве, тогда как на большом экране эти компоненты распределяются по трем столбцам.

Автор точно знает, чего ожидать от конкретного компонента, и может легко наполнить его соответствующим содержанием. Не менее важны долгосрочные преимущества и новые возможности, которые были бы невозможны для подхода старой школы «одно текстовое поле для всего контента», преобладавшего в последние десятилетия:

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

Редактирование на основе компонентов уже давно используется пользователями AEM, а благодаря появлению Gutenberg в WordPress 5.0 редакторы на основе компонентов теперь являются стандартом де-факто для создания веб-страниц.

Примечание . Леонардо Лосовиц более подробно рассматривает значение блоков в контексте WordPress.

Фрагменты

Фрагменты контента и фрагменты опыта — это новые термины, которые доминировали на сцене AEM в прошлом году. Я суммирую эти две концепции просто как фрагменты . По сути, фрагменты позволяют авторам создавать нейтральный контент, который можно использовать в Интернете, на мобильных устройствах, в социальных сетях и других каналах.

Фрагменты создаются вне редактора страниц и, по сравнению с компонентом, меньше зависят от того, как будут использоваться их данные. Представим себе фрагмент под названием «Цитата дня», который авторы обновляют раз в день новой цитатой. Теперь цитируемый текст этого фрагмента можно использовать в самых разных местах:

• Виджет нижнего колонтитула отображает котировку дня внизу каждой страницы. Как только автор обновляет фрагмент, обновляется и нижний колонтитул. Фрагмент определяет, что будет отображаться, тогда как виджет нижнего колонтитула определяет , как будет отображаться цитата.
• Компонент цитаты позволяет авторам импортировать цитату из прошлых «Цитат дня» и добавлять ее в запись блога.
• Плагин добавляет кнопку «Поделиться цитатой дня» на главную страницу. Всякий раз, когда кто-то нажимает на эту кнопку, плагин берет цитату дня и форматирует ее в соответствии с рекомендациями по обмену через Facebook, Twitter и электронную почту.

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

Я ожидаю, что фрагменты станут более широко использоваться, даже несмотря на то, что это понятие имеет разные названия в разных системах. Действительно, Мэтт Малленвег уже объявил, что его команда в настоящее время сосредоточена на «расширении блочного интерфейса для других аспектов управления контентом [включая создание] блока навигационного меню [и] переноса всех виджетов на блоки».

Шаблоны страниц

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

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

• Шаблон №1: Шаблон страницы статьи
  Заголовок, заголовок, область содержимого и нижний колонтитул фиксированы. Автор может обновить компонент заголовка, но не может удалить его. Автор может перетаскивать текст, изображения и видео компоненты в область содержимого.
• Шаблон № 2: Шаблон целевой страницы
  Фиксируются только логотип и заголовок вверху страницы. Автор может выбирать из набора компонентов для целевой страницы, оптимизированных для превращения посетителей в клиентов.

Разрешения и рабочие процессы

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

Типичный сайт AEM включает в себя фактический рабочий веб-сайт и как минимум один рабочий сайт, также известный как промежуточный . Авторы могут публиковать контент на частном промежуточном сайте перед его публикацией на общедоступном рабочем сайте. Процесс публикации контента для подготовки с последующей публикацией контента для производства можно назвать рабочим процессом. Другой распространенный тип рабочего процесса заключается в том, что контент должен пройти процесс утверждения, прежде чем его можно будет опубликовать на рабочем сайте, и только определенные люди могут нажать кнопку «Опубликовать в рабочей среде».

Разрешения и рабочие процессы — это функции, которыми можно пренебречь в небольших командах. Однако по мере роста команды эти функции становятся критически важными для продуктивности и успеха команды. Несмотря на то, что AEM поставляется с основами для создания рабочих процессов, и разработчики могут заставить AEM работать для любых конкретных нужд, он требует значительных изменений кода и не реализуется по щелчку пальцев. Это еще более верно для WordPress. Было бы неплохо иметь удобный инструмент для создания пользовательских рабочих процессов.

Режимы редактирования

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

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

Есть еще несколько режимов, которые отображаются в зависимости от того, как настроен сайт. Один из идеальных сценариев заключается в том, что A/B-тестирование и персонализация настраиваются путем интеграции AEM с Adobe Target. Используя режим таргетинга , авторы могут определять, когда показывать определенные компоненты в зависимости от местоположения посетителя, возраста, реферальной страницы, времени суток и т. д.

Интеграции в AEM сравнимы с плагинами в WordPress, но с той разницей, что интеграции AEM более сложны и обычно настраиваются индивидуально. Особенно интеграция AEM Target может быть более болезненной, чем это кажется продавцам.

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

Визуальный одностраничный редактор

Глядя на скриншоты в этой статье, вы, должно быть, поняли, что редактор страниц AEM не только компонентный, но и визуальный: если компонент обновляется, изменение сразу становится видимым, и автору не нужно открывать предварительный просмотр в новое окно. Довольно особенность. Несмотря на то, что компоновщики страниц вездесущи в экосистеме WordPress, команде WordPress еще предстоит определить наилучшие методы визуального редактирования. Позвольте мне сделать еще один шаг и спросить: что произойдет, если вы объедините визуальные редакторы с одностраничными приложениями (SPA)?

SPA — это веб-сайты, на которых переход с одной страницы на другую кажется плавным, поскольку браузеру не нужно перезагружать всю страницу. Некоторые популярные веб-сайты, такие как Gmail и Facebook, являются SPA, но большинство сайтов в Интернете таковыми не являются. Одна из причин довольно низкого внедрения заключается в том, что создавать SPA сложно, а поддерживать SPA с тысячами страниц еще сложнее. В настоящее время существует два основных способа управления контентом в SPA:

• Содержимое сайта обновляется путем обновления кода. Это явно не удобно для авторов.
• Контент управляется в CMS, которая отделена от части веб-сайта, обращенной к посетителю. Контент из CMS потребляется через API, например, приложением React. Авторский интерфейс выглядит иначе, чем собранный сайт, который увидит посетитель.

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

Резюме

Adobe Experience Manager поставляется с несколькими полезными функциями, которые уже вошли или появятся в популярных проектах с открытым исходным кодом. AEM не обязательно изобрел концепции, изложенные в этой статье, но он, безусловно, хорошо коммерциализируется как одна из самых удобных для разработки систем на рынке.

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

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

Дальнейшее чтение

• «Создание лучшего авторского опыта», Эйлин Уэбб
• «Авторство: среда и инструменты», Справочный центр Adobe
• «Проектирование удобной системы управления веб-контентом», Кристофер Халлахан
• «Авторский опыт», Рик Ягодич