Grav-plugin-admin: UX: добавление модульного контента

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

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

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

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

+1 за улучшение обработки модульных страниц внутри плагина администратора

С точки зрения нетехнического пользователя, я думаю, было бы более логичным иметь модульные подстраницы в объединении родительской страницы. Так что, возможно, внутренние элементы (= модульные подстраницы) скрыты от пользователя, и он просто может видеть и добавлять отдельные блоки контента внутри родительской страницы.

Я согласен с @Jugibur

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

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

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

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

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

Также то, что поможет, связано с этим https://github.com/getgrav/grav-plugin-admin/issues/735 . Также мы должны иметь возможность определять страницы, недоступные для редактирования клиентами. С помощью этих вещей вы можете сделать так, чтобы клиент мог безопасно редактировать страницы.

Что-то вроде этого было бы потрясающе:
https://craftcms.com/docs/matrix-поля
https://github.com/benjamminf/крафт-нео

Что касается недавнего слияния # 1174, было некоторое обсуждение того, как пользовательский интерфейс администратора обрабатывает эту неоднозначность. Процитирую Пола Массендари из конца этого номера:

Должны ли мы переименовать «Добавить модуль» в «Добавить модуль»? https://github.com/getgrav/grav-plugin-admin/blob/develop/languages/en.yaml#L36

Типичная кнопка для добавления контента выглядит так:

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

Концептуально модульная страница — это не обычная страница с коллекцией, это структура, содержащая компоненты — модули — и не должна иметь подчиненных ей страниц любого другого типа. Таким образом, в то время как модульная страница может иметь обычные дочерние страницы с точки зрения /sample/page, ее содержимое полностью определяется коллекцией, которая отрисовывается только в модулях, и эти модули не видны и не маршрутизируются в другом месте. Конечно, в качестве конструкции это всего лишь подмножество страницы, позволяющее упростить управление компонентами — такого же эффекта можно добиться с помощью Twig и YAML — но на концептуальном уровне он _не должен_ смешиваться с обычными страницами. Вот почему разделение проблем в раскрывающемся списке «Добавить» было бы предпочтительнее с точки зрения того, как Grav определяет страницы.

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

- home
- blog
  -_introtext
  -_latestarticles
  - _subscribe  
  - article1
  - article2

Что само по себе имеет смысл семантически, но двусмысленность между обычным Page и Modular сохраняется. Таким образом, для разделения между ними — хотя Modular является подмножеством Page — пользовательский интерфейс должен ограничивать выбор тем, что соответствует контексту. Раскрывающийся список в /admin/pages должен предлагать добавить страницу, папку или модуль, на модульной странице он должен предлагать добавить модуль, а на странице и в папке он также должен предлагать добавить все три.

Резюме контекстуального разделения (обновлено 28 августа):
Далее обсудили с @paulhibbitts и @paulmassen и пришли к этому различию, хотя, возможно, для ясности «дочерняя страница» должна быть «дочерней страницей».

+Добавить пункты меню в список страниц
Добавить страницу
Добавить страницу со списком
Добавить модульную страницу
(Добавить папку)

+Добавить пункты меню в стандартном просмотре страницы
Добавить ребенка
(Добавить папку)

+Добавить пункты меню в список (родительская) страница
Добавить ребенка
(Добавить папку)

+ Добавить пункты меню в модульном (родительском) представлении страницы
Добавить модуль
Добавить ребенка
(Добавить папку)

Где папка находится в скобках, потому что она всегда должна быть внизу и отделена от вышеуказанных типов страниц с помощью визуального индикатора, такого как тонкая верхняя граница, чтобы указать, что это _не_ тип страницы, в то время как все вышеперечисленное подходит контекстуально типы. Три; Page, Listing, Modular являются стандартными типами по умолчанию, и https://learn.getgrav.org/content/content-pages , вероятно, следует обновить, чтобы отразить это.

Самая ясная логика выглядит так: Страница — это любой Markdown-файл, отображаемый Grav, в то время как Листинговая Страница — это подмножество Страницы, используемое для перечисления ее автономных дочерних страниц, тогда как Модульная Страница — это подмножество Страницы, которая населяет свои дочерние страницы. как части самого себя. Таким образом, Listing связывает отдельные дочерние элементы, а Modular отображает их внутри себя. Page и Listing имеют обычные дочерние страницы, где Listing в основном перечисляет их в некотором упорядоченном виде. Только Modular имеет модули.

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