Вы здесь

Друпал использующий подход «снаружи внуть»

Было много обсуждений будущего фронт-энда в Друпале как на drupal.org — #2645250, #2645666, #2651660, #2655556, так и в записях моего блога — Будущее отвязанного Друпала, Встраивать ли в Друпал клиенсткий фрейм-ворк?, Выбор клиентского фрейм-ворка для Друпала. Всё это относится к моей концепции «прогрессивного отвязывания», в которой некоторые части страницы управляются клиентской логикой после того, как Друпал отрендерит начальную страницу (не путайте с «полным отвязыванием»).

Записи в моём блоге вызвали множество откликов. Участники сообщества Друпала, такие как Льюис Найман, Теодор Биадала и Кэмпбелл Вертеси, написали статьи в своих блогах, также написал статью Эд Фолкнер из сообщества Ember. Кроме того, в ответ на мою последнюю запись в блоге, Google изменил лицензию Angular 2 с Apache на MIT, для лучшей совместимости Angular 2 с Друпалом. Я прочитал все статьи и комментарии с большим интересом и хочу поблагодарить всех, кто оставил свои отзывы; открытое обсуждение этого вопроса поразительно. Это именно то, на что я надеялся — мозговой штурм участников сообщества со всего мира на основе своего опыта, потому что только с объединённой конструктивной критикой мы придём к лучшему из возможных решений.

Основываясь на обсуждении, а не на выборе клиентского фрейм-ворка для прогрессивной отвязки прямо сейчас, я считаю, что основной вопрос на который хочет сначала ответить сообщество — как мы поддерживаем Друпал и расширяем Друпал другими программами, улучшая взаимодействие с ним пользователя?

Улучшение взаимодействия пользователя с Друпалом это родная и близкая моему сердцу тема. Вопросы взаимодействия с Друпалом привели к приглашению Марка Болтона поработать над редизайном Друпала 7, созданию инициативы Spark для улучшения взаимодействия с Друпалом 8 редакторов содержания и продолжению поддержки инициатив связанных с эргономикой. Фактически, причиной прогрессивной отвязки и принятия клиентского фрейм-ворка является потребность в улучшение взаимодействия пользователя с Друпалом.

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

Повторы или подрыв?

В своей статье Льюис пишет, что вопросы взаимодействия с Друпалом «идут гораздо глубже кода», и что многие из самых больших проблем найденных во время изучения эргономики Друпала 8 в прошлом году не могут быть решены с помощью JavaScript-фрейм-ворка. Это правда, результат изучения эргономики Друпала 8 показывает, что Друпал ставит в тупик пользователей своей сложной ментальной моделью и терминологией, но он также показывает как современные возможности, такие как мгновенный просмотр и добавление блока не покидая страницы, всё чаще считаются доступными.

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

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

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

Снаружи внутрь

Давайте на секунду забудем о Друпале и посмотрим на мир вокруг нас. Подумайте о всех веб-приложениях которые регулярно используете и посмотрите на паттерны взаимодействия с ними. В таких популярных приложениях как Slack, пользователь может выполнить любое количество действий для редактирования параметров (таких как цветовая схема) и изменения содержания (таких как редактирование на-месте) без перезагрузки страницы. Многие элементы страницы могут быть изменены без прерывания потока действий. Другим примером может быть Trello, в котором пользователь может создавать списки и добавлять им карточки не дожидаясь ответа сервера.

Сравните это с подходом Друпала, где любое сложное действие требует от пользователя подробных предварительных знаний о системе. В нашей текущей ментальной модели всё начинается на уровне управления, на самом зернистом уровне и требует неразмеченного процесса сборки снизу вверх. Пользователю нужно сделать тип документа, добавить поля, добавить содержание, настроить режим показа, сделать вид и возможно настроить показ первой страницы. Если каждый отдельный шаг уже пройден, посмотрите насколько сложно его пройти в правильном порядке, чтобы наконец увидеть результат. Хотя мы очень мощные, проблема текущей модели Друпала в том, что она является моделью «изнутри наружу». Вот почему разрушительно двигать Друпал вперёд к ментальной модели «снаружи внутрь». В этой модели я должен иметь возможность начать вводить содержание, нажимая ссылки на странице и бесшовно редактировать любой аспект её конфигурации на-месте и видеть изменения немедленно.

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

Сделать это реальным с помощью моделирования содержания

Восемь лет назад, в 2007 году, я написал о программе работающей с базой данных под названием DabbleDB. Я поделился своим мнением о том, что важно переместить модули CCK и Views я ядро Друпала и перенять интегрированный подход DabbleDB. DabbleDB была приобретена Twitter в 2010 году, но на YouTube всё ещё можно найти демонстрационной видео её работы. Хотя фокус DabbleDB отличается, а взаимодействие с ней устарело, мы по-прежнему можем многому научиться у неё и сегодня — 1) она показывает более интегрированное взаимодействие между созданием содержания, моделированием содержания и созданием просмотра содержания: 2) она показывает многое из подхода «снаружи внуть»; 3) она использует менее устрашающую терминологию предлагаю очень мощные возможности; 4) она использует множество редактирования на-месте. Как минимум, DabbleDB может дать нам некоторые идеи о том, как сделать лучше, как может выглядеть интегрированное моделирование содержания, с поправкой на то, что взаимодействие должно быть как можно более простым и соответствующим современным стандартным.

Недавно появились другие новые подходы моделирования данных с привлекательным взаимодействием. Это решения использующие back end-as-a-service (BEaaS), такие как Backand, реализующие визуально чистый интерфейс с перетаскиванием для моделирования данных и полезными возможностями для разработчиков приложений на JavaScript. Наши случаи использования отличаются, но Друпал может получить пользу из опыта применения богатых возможностей Backand и интуитивного взаимодействия в Backand.

В Друпале это было невозможен в 2007 году, когда CCK был дополнительным модулем для Друпала 6. Оставался невозможным для Друпала 7, когда Views оставался дополнительным модулем. Но теперь, когда CCK и Views входят в ядро Друпала 8, мы можем начать думать о том, как мы можем более глубоко их интегрировать. Такая интеграция будет нетрививальной, но она радикально упростить взаимодействие пользователя с Друпалом. Это должно быть очень интересно, потому что очень много людей Друпал привлекает именно возможностями CCK и Views. Взять интегрированный подход как в DabbleDB и соединить его с бесшовным и простым взаимодействием как в Slack, Trello и Backand — это именно то, о чём нам нужно подумать.

Большинство приведённых примеров объединяют такие возможности как редактирование на-месте, мгновенный просмотр, отсутствие перезагрузки страницы и бесшовный рабочий процесс. Влияние на наши системы форм и рендеринга, обеспечение прямого изменения конфигурации на отрендеренной странице — очень значительное. Чтобы реализовать всё это, нам требуется надёжное управление состоянием и рендерингом на стороне клиента и сервера. Я думаю, Twig может реализовать общую структуру страницы и неинтерактивные части, но потребуется много JavaScript, чтобы реализовать взаимодействие, которое ожидается всеми пользователями паутины.

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

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