Wp-calypso: Pages: display hierarchical view as default

[rralian]

Currently pages are shown in chronological order, which isn't really helpful or meaningful to users. We should default instead to showing pages in a hierarchical view with chronological as a secondary view options.

This project seems pretty complex to me, and I'm pretty skeptical we can finish this during our iteration. The difficulty is in displaying an arbitrarily-large list of pages, which must be fetched with paginated requests, in a tree format. Hierarchical order is not an option by which you can fetch pages from the API. And when the pagination cuts off, it could have done so with several limbs unfinished. The next paginated request won't necessarily finish those tree limbs in order either.

My suggestion then is, at least for this first pass, to limit the hierarchical tree view to sites where we can fetch the entire list of pages in one request. Then we can assemble the tree view on the client. We can improve/expand this in future PRs.

Will need some design work (there may be prior art somewhere?). /cc @adambbecker @drw158 @mtias @retrofox

[apeatling]

I think I agree that this is going to be too much work. It might be a better idea to see if we can have another team dedicate time to iterating seriously on Pages.

[mtias]

We already have components that display pages in static ordering (used for menus and editor page parent selector).

[artpi]

used for menus

@mtias, the one in Menus needs reworking itself, it is very dated piece of code. I would write a new component and then use it in menus

[mtias]

@artpi yes, the one in the editor should be the base for it, and eventually replace the one in menus :) Also, post-selector is nicer but it doesn't support hierarchy. It's possible @aduth may have something in mind for custom post types that are represented hierarchically.

[aduth]

Also, post-selector is nicer but it doesn't support hierarchy.

It does, though you may be referring to a styling bug in the editor which makes all posts appear as top-level. :smile: I can plan to put together a fix today. Here's how it should look (per "Add Link" dialog):

It's possible @aduth may have something in mind for custom post types that are represented hierarchically.

For the listing pages, I do have plans to list hierarchical post types with an indication for parent-child hierarchies, likely with a visual indentation.

[rralian]

We didn't get to this one as part of our support-cleanup iteration. I'm keeping the item open, but dropping it from the milestone so we can close out the milestone.

[hugobaeta]

I was about to open a ticket about this, since I think today was the first time I looked at the pages list in my site (in calypso). Pages are not meant to be chronological, and we shouldn't confuse users by implying any relation between Pages and chronology. Pages are static and timeless (as I say to any new WordPress user at meetups).

Any way we could do a quick iteration on this to switch to hierarchical view on the single site Pages list?

As a support of this, look at the mess that is my site's pages list, where the hierarchy is super confusing speacilly with the — there on the child pages, and a quick proposal mock of how it would make actual sense:

If there's any way I can help in this, please let me know.

[folletto]

Note: the design above has been updated later, so it's not the latest one. This is the latest one done by Hugo (June 27, 2016):

p4TIVU-642-p2 (also p5j4vm-1gM-p2).

The component already exists: PostItem.

Which would use the same component as CPTs (this an early PR for reference). :)

[lancewillett]

When testing this I found a minor UI issue #13644 — could you fix it while you're working in this view?

[lancewillett]

UX request:

At the bottom of the ellipsis menu I see "Child of __parent__ page" link.

When the list is in hierarchical view, this is redundant. Can we please hide that extra link? And only show it when the list is in chronological view (which with coming changes will be over 100 pages or so).

[jonathansadowski]

With the merge of #13871, pages are now displayed hierarchically using the approach of limiting hierarchies to sites with 100 or fewer published pages. "Child of _____" was removed when displayed in the hierarchical view.