Admin Pages list displayed as tree

[rawtaz]

I just fired up the bakery demo using Docker Compose and that worked just fine, the website is up and running :)

So I went to the admin console to see what Wagtail looks like. The first thing I notice in here when starting to review this as an editor (coming from Sitevision most recently/currently and a bunch of other CMSs back in the days) is that to navigate the Pages I have to click through one "level" or page at a time. I cannot find a way to simply see the pages on the site in a plain old tree view where I can expand pages to list their subpages.

Honestly, and I don't mean to complain here, this is a dealbreaker right off the bat for Wagtail in the context I'm in. I cannot imagine any of our editors going back and forth in the Pages list to find the subpage they want to edit. And when they make changes, they also don't want to jump back and forth between the frontend and admin console to e.g. hit "Edit this page".

Is a regular tree view of the pages in the admin console something that simply doesn't exist? I'm very surprised if that is the case!

I did search a bit in the issues and dicsussions, but didn't find an answer. Perhaps there is one already. Thanks.

[laymonage]

Hi @rawtaz, thank you for the feedback! This exact feature is in our roadmap, it's called "universal listings":

• Universal listings (search and filtering) #10446

We've been working towards this by making incremental changes to the listing view. It's not done yet, but hopefully you'll see the complete feature soon!

[rawtaz]

Hmm, I haven't read through all the comments in the discussion you reference there, but I'm not seeing a page tree in there (only new ways to filter and get to them, but not in a tree structure). Am I missing something?

[laymonage]

Oops, sorry, I didn't pay enough attention!

Hmm, we don't really have plans to add such a feature at the moment. The closest to this (exploring the tree without loading a new page) would be to use the page explorer in the main menu.

If there's enough interest, we could add this to our plans though!

[thibaudcolas]

@rawtaz 👋 do you have examples of what such a tree view would look like in a CMS, ideally as images? I’m familiar with what you describe for e.g. file system hierarchies, but not for sites’ page trees.

We’ve looked into this a bit in the context of the Universal listings project but didn’t find the pattern worth exploring further (didn’t seem to scale well). That project might be interesting to you nonetheless as it explores alternative means of navigation: search, filtering of page listings, and saved views to name the biggest ones.

And when they make changes, they also don't want to jump back and forth between the frontend and admin console to e.g. hit "Edit this page".

I don’t understand how this relates to the tree representation (if it does?). Visual editing / WYSIWYG editing of whole pages isn’t a goal of Wagtail.

[rawtaz]

👋 :)

do you have examples of what such a tree view would look like in a CMS

Yes, here's a screenshot from how it looks in Sitevision, a (proprietary and commercial) CMS, within the admin/editor backend (NOTE: it's only the part above "Innehåll" in the screenshot which is the tree with the pages of the site):

• The nodes (pages) in the tree can be expanded and collapsed, making it easy for editors to navigate to their desired pages.
• The main reason that this is an easy way for them to navigate is that:
  • they know their site structure and this tree matches the main menu and its submenus of the site pretty much 1:1, so they navigate to the right place straight away.
  • there may be multiple pages with the same name, whereby it's easier to just expand the section you know it's under to find it, than to search in a box/filter to find it.
  • visual navigation is easier than searching/filtering when you have a lot of pages, as there's less cognitive effort needed than if you were to search/filter to get a result list and then evaluate the results to establish which of them you are after.
• When they select a node, that page is shown in a main column to the right of this tree navigation column, and it displays the page and its contents just as it is shown on the public website to regular visitors.
• One can then, in that right-hand side main column edit the text and other content, so essentially the editor can see the outcome/result of their edits right away (this is WYSIWYG editing, which isn't what this discussion is about).
• They can also right-click a node (page) in the tree to get a contextual menu with a bunch of things like Rename, Copy, Paste, Unpublish, Change sort order, Properties.

Related/side note for reference (but not really the issue being discussed): The part below "Innehåll" in the screenshot is the content parts of the currently selected page. The three rectangle icons with "innehåll" at the end of their description is basically three content sections on the page (this is defined by the layout template that the page is using). The middle one ("Huvudinnehåll") is the only one with contents here, and it contains a heading, an ingress text, a body text, then a file sharing module, some text and finally another file sharing module. This part of the admin GUI is where one can add more content parts to the content of the page.

And when they make changes, they also don't want to jump back and forth between the frontend and admin console to e.g. hit "Edit this page".

I don’t understand how this relates to the tree representation (if it does?). Visual editing / WYSIWYG editing of whole pages isn’t a goal of Wagtail.

I was trying to proactively address an argument like "just let the editors navigate to the page they want on the real/public website and then hit Edit to go to edit mode", by saying that they don't want to do that, i.e. they don't want to go back and forth between the public facing part and and edit mode.

Visual editing not being a goal of Wagtail is fine in terms of this discussion, since that's not what I'm asking for here :) Even without that, the page could be navigated to using what's in the screenshot above and then edited in a non-WYSIWYG way, e.g. in a right-hand main column like I described above.

[thibaudcolas]

This all sounds a lot like Wagtail navigation-wise, with the exception that we only show one level at a time within the Pages menu.

[rawtaz]

Yes, and this causes a lack of overview of the pages there are, as well as a lot more clicking and/or typing around to find what you want, when you're navigating to find pages you need to edit. A tree might be old school, but it works really well and I argue it's superior to the current page navigation even if we take into account the filtering (which could still be there even if the pages are listed in a tree type view).