Move document information and outline to list view panel

[mtias]

Consolidating list view / navigator, document stats, and document outline has surfaced a few times in the past. I'm proposing we revisit this and redesign the document stats a little bit. With the addition of "time to read" the current grid design is becoming harder to quickly parse:

• Display them as a list and smaller font size at the top or bottom of list panel.
• Add a tab interface to switch between all blocks and outline when headings are in place.

Mockup:

• List view and Outline tabs at the top
• Outline tab only available if the document has heading blocks
• Outline stats fixed at the bottom, shown on both tabs

Related #41330

Some questions to resolve in implementation: does the document stats take up valuable list view space? If yes, we can collapse the information into a single row.

---

Issue updated Sep. 30.

[jameskoster]

Aren't we giving too much prominence to the overview by placing it at the top of the panel? I would imagine the other features of list view are used more frequently...

An alternative that places the details at the bottom of list view:

[mtias]

I can see it at the bottom, but the single line won't work in most languages. Can we try the split two column at the bottom?

[jameskoster]

There is also #36696 to think about. I'm not sure if that's something we still want to pursue?

[mtias]

I don't know that the number of blocks makes a ton of sense in the header. Can we bring it to the list below? Also, it seems these stats should be contextual to what you are doing — editing content or designing. When designing none of those three seem that useful, but blocks, template parts, etc, might be relevant.

[jameskoster]

I quite like the idea of only displaying the stats in the Outline tab. It does mean we'd need to design an 'empty' state for that tab though, for cases where a post/page contains no headings.

Another option could be to add a user preference which toggles the display of the stats. I don't know how many people use them but I suspect it's relatively small. This way, if the toggle is off and the post contains no headings then we can just hide the Outline tab altogether.

[jasmussen]

It does mean we'd need to design an 'empty' state for that tab though, for cases where a post/page contains no headings.

Would it be crazy to just not have the tab if empty?

[jameskoster]

Would it be crazy to just not have the tab if empty?

Then how would you see the stats?

[jasmussen]

Right, that would only work if the stats was a fixed anchor at the bottom of either tab.

[ALJ]

All the mockups above look polished and wonderful, but I disagree with shrinking the usable area of the List view (if that's what's happening).

@jasmussen in your latest List view mockups, is it the intention to have the statistics always visible fixed to the bottom, with the List view items scrolling "behind" it? Another way of asking is: where are the statistics if the List view is so tall as to require scrolling?

I ask because multiple clients have told me List view is one of their favorite features of the block editor as it makes complex/nested block structures clearly visible to them. They want room in the List view to see as much as possible, and expand multiple levels. It would be a disservice to them to make the List view smaller.

[jasmussen]

is it the intention to have the statistics always visible fixed to the bottom, with the List view items scrolling "behind" it? Another way of asking is: where are the statistics if the List view is so tall as to require scrolling?

Good points, I love the list view too. I think we have options here. My initial instict would be for list view items to scroll behind it, since the footprint of the stats isn't that big especially at desktop breakpoints. But we can also flex, so that it is fixed at the bottom until list view items push it downwards. That might make those stats less findable on a large document, though. Another option is to query the viewport height and adjust the behavior accordingly. Yet another option is to minimize the footprint even further: personally I don't find the "Time to read" all that useful in the editor context (I'd rather have that as a block to output for my blog readers!). Potentially we could reduce character and word count into a single row.

In any case, I like to think that these issues will become immediately apparent in a PR that implements this, allowing us to choose among the paths forward.

I'll update this ticket with that context, and hopefully we can thread the needle.

[jasmussen]

This ticket has been updated and should be ready for a dev to pick up!

[ALJ]

... we can also flex, so that it is fixed at the bottom until list view items push it downwards. That might make those stats less findable on a large document, though...

RIght, that might annoy authors who rely on easy access to the character/word counts.

List view and Statistics are both useful but probably for different kinds of authors or at different times. Assembling a nested page of layout blocks is a different task than writing narrative text to fit a word-count limit. Combining the tools into one pane, or making either more difficult to find/use, might be a tricky balance. Regardless of the direction taken, I'm sure the design will be an improvement over the current state and can be more easily tailored in a PR 😄

[alexstine]

Something else everyone needs to think about. I have no problem with combining the list view and these statistics, one could argue that putting the information in a more centralized location actually exposes it more and that is not a bad thing. My problem specifically deals with a context issue. We can no longer call this the "List View" sidebar because it contains more than the list view. For the purpose of accessibility and the tool tip that you get when hovering the button in the toolbar, what should it now be called? "List View" is no longer true. Maybe it should be changed to "Document Structure"?

I probably should have brought this up before now but better late than never.

It is likely something no one else really thought about either because the visible "List View" wrapped in a bold/strong tag was removed in the linked PR. Out of sight, out of mind. However, for accessibility, there are still aria-label with "List View" and a button with "Close List View Sidebar".

Thoughts?

Thanks.

[jasmussen]

That's a good point, thank you.

Maybe it should be changed to "Document Structure"?

Sounds good to me. The tabs would still indicate either sub-section.

[alexstine]

@jorgefilipecosta Do you have time to do some label replacing and probably modify some E2E tests for the new name?

[colorful-tones]

I hate to get caught in semantics, and may I suggest: "Document Overview"? It seems a bit more descriptive of the context and easier to grok.

Great catch on the aria-label and for raising this issue @alexstine

[alexstine]

That still seems fair to me. Describes the purpose clearly.

[annezazu]

@jorgefilipecosta can you confirm you'll follow up on the above? Trying to manage an update for Phase 2 and am trying to ensure this can fully be considered marked as done :)

[jorgefilipecosta]

Hi @alexstine, than you for catching the missing label change. @colorful-tones thank you for suggesting a new label.
@annezazu there is a follow-up PR fixing this at #45524.