Grav-plugin-admin: UX: Adding modular content

We definitely have some plans on how to improve modular page management. The way it is now, is merely a matter of simplicity and consistency from the code side of things. It's not the ideal setup yet, but it works and some documentation will help improve the situation too.

Thanks for the reply Andy. I am still quite concerned about the user experience with the current presentation though just in terms of page creation, is there any scope of changes you would consider at this point?

Just a quick follow-up thought - if nothing else I think changing the text of the Add Modular dialog from "Add Modular Content" to "Add Modular Content to Page" could be of help here. In the longer run, and I know you have plans in mind already, I still think having one "Add Page" dialog with the ability to create Parent, Child, or Modular content pages could be a viable approach to explore.

I also wonder if putting the "Parent Page" dropdown as the first item in both "Add Page" and "Add Modular" would also be more helpful for users as that decision really comes before naming the page, etc. What do you think?

+1 for improve the handling with modular pages inside the Admin plugin

From a non-tech user perspective, I think it would be more logical to have the modular subpages in a union of the parent page. So perhaps the internals (= modular subpages) are hidden form the user and he just can see and add separte blocks of content inside the parent page.

I concur with @Jugibur

A normal client is just going to think "i want to edit this page." They will probably click the page's name and then see this:

Whether they want to add some content or edit what's there, they're not going to know what to do from here. It would be a challenge to design it well, but I'm imagining one page where I can scroll through editable boxes for each of the page's modules in the order they appear, and a button to add a new one.

Like I said before, this is something we want to revisit. We know it's not ideal, but it is functional. I.e. it works.

We are now working on an entire JS rewrite of the admin. This will allow us to develop the modular page UI that we intended from the start, but just didn't have the time to properly implement in the initial version.

I think the biggest problem right now is not the UI but not being able to order modular pages manualy. I think this should be default, since most common usecase for modular pages are rows of content. And for those having the date or name order makes no sense.

Also what would help is connected to this https://github.com/getgrav/grav-plugin-admin/issues/735. Also we should be able to define pages that are not editable for clients. With these things you can make it pretty safe for client to edit the pages.

Something like this would be amazing:
https://craftcms.com/docs/matrix-fields
https://github.com/benjamminf/craft-neo

Regarding the recent merge of #1174, there's been some discussion on how Admin's UI handles this disambiguation. To quote Paul Massendari from the end of that issue:

Should we rename "Add modular" to "Add Module" ? https://github.com/getgrav/grav-plugin-admin/blob/develop/languages/en.yaml#L36

The typical button for adding content presents as this:

Which is as expected given the three major types of structures Grav has: Regular Page, Folder, and Modular page. However, the same Dropdown will be there in other contexts - which persists the ambiguity of what a Page and what a Modular Page is. To quote myself from Slack:

Conceptually a Modular page is not a regular page with a collection, it is a structure holding components - Modules - and should not have any other type of Page subordinate to it. Thus, whilst a Modular page can have regular child-pages in terms of /sample/page, its content is entirely defined by the collection which only draws in Modules, and these modules are not visible or routable elsewhere. Of course, as a construct it is really just a subset of a Page allowing easier management of components - the same effect can be achieved with Twig and YAML - but on the conceptual level it _should_ not mix in regular pages. That's why a separation of concerns in the "Add"-dropdown would be preferable, from the standpoint of how Grav defines Pages.

From that perspective, a Modular _should_ not have regular child-pages or other child-items other than Modules, but with the current UI these can be mixed quite freely. An example from Paul Massendari:

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

Which in and of itself makes perfect sense semantically, but the ambiguity between a regular Page and a Modular is preserved. Thus, for separation between the two - though a Modular is a subset of Page - the UI should limit choices to what is contextually appropriate. The dropdown in /admin/pages should offer to Add Page, Folder, or Modular, on a Modular page it should offer to Add Module, and in both Page and Folder it should also offer to add all three.

A summary of the contextual separation (updated August 28th):
Discussed further with @paulhibbitts and @paulmassen, and sort of arrived at this distinction - though perhaps "Child" should be "Child Page" for clarity.

+Add Menu Items on Pages List View
Add Page
Add Listing Page
Add Modular Page
(Add Folder)

+Add Menu Items on Standard Page View
Add Child
(Add Folder)

+Add Menu Items on List (Parent) Page View
Add Child
(Add Folder)

+Add Menu Items on Modular (Parent) Page View
Add Module
Add Child
(Add Folder)

Where folder is in in brackets because it should always be at the bottom, and separated from the above Page types through a visual indicator such as a thin top border to indicate that it is _not_ a Page type, whilst all of the above are contextually suited types. The three; Page, Listing, Modular are then default standard types, and https://learn.getgrav.org/content/content-pages should probably be updated to reflect this.

The clearest logic seems to be: A Page is any Markdown-file Grav renders, whilst a Listing Page is a subset of Page used to enumerate its standalone child-pages, whereas a Modular Page is a subset of Page that inhabits its child-pages as parts of itself. Thus Listing links to separate child-items, and Modular displays them within itself. Page and Listing have regular child-pages, where Listing mainly lists them in some ordered fashion. Only Modular has Modules.

However, there's also a need for themes to communicate via blueprints that they support specific Page types. Not all themes have a default template, or one for listing or modular. Thus the dialogues, modals, buttons or other method of adding pages should reflect what the theme inherently supports through its templates.