Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge the block navigation and content structure (document outline) buttons #20719

Closed
jasmussen opened this issue Mar 9, 2020 · 11 comments
Closed

Comments

@jasmussen
Copy link
Contributor

The block editor has two similar but still somewhat distinct actions related to blocks:

Screenshot 2020-03-09 at 13 08 24

Block Navigation (press ^⌥O) lets you quickly navigate to a specific block in the canvas using quick keyboard shortcuts. It also lets you traverse the hierarchy of nested blocks.

Screenshot 2020-03-09 at 13 08 48

Content Structure is a quick overview of showing a word-count, small block stats, as well as a heading-level checker to help users create the correct heading level hierarchy.

As part of #19348 (related to #18667), I moved the Content Structure button into the footer to reduce the weight of the top toolbar buttons. The top toolbar is prime real-estate and permanently visible buttons there provide cognitive weight even when they're not used. However the presence in the footer buries the feature, which deserves better.

In effort to revisit this balance, we should consider merging the two buttons in a tabbed interface. This would not only keep the interface compact, but it would also explain both how the two features are related, but also how they are separate.

The navigation tab would be default:

merged navigation, nav

The document outline tab would be tab number 2:

merged navigation, outline

A previous effort was made to merge these two (#14956), which could be revisited (CC: @youknowriad).

@jasmussen jasmussen added the Needs Design Feedback Needs general design feedback. label Mar 9, 2020
@mrleemon
Copy link
Contributor

mrleemon commented Mar 9, 2020

Good idea.

@ZebulanStanphill
Copy link
Member

This seems reasonable to me.

One thing I would change from the mockup: use a more natural way of showing the counters, e.g.

63 words
2 headings
5 paragraphs
7 blocks

Separating the labels and values with space in between like the mockup makes it a bit more difficult to tell which number goes with each label.

@ghost
Copy link

ghost commented Mar 9, 2020

Hi.
As an casual Gutenberg user, fan of these design threads and interested in design but not one designer, so excuse me if I say something ignorant, but I want to contribute with my personal experience, given that I spend days off Gutenberg before coming back to edit page, so I there may be something valuable in exposing the way I sense the interface with enough detachment, in contrary to devs that know every single part of it in their minds.

I believe this thread deserves attention because I never memorized the meaning of the Block Navigation icon and its coexistion with Content Structure icon is really confusing! (I don't even sense what they are while writing right now)

Block Navigation icon seems a disaligned hamburguer icon (I don't know why - I never saw that icon on internet), in which I expect its functionality to open a sidebar or dropdown with top WP controls to appear (which now is the position occupied by the black WP button, even if it doesn't show contents that are in WP sidebar (posts, pages, media, comments...). Also, I don't even am able to mentally organize the name Block Navigation.
Because when I think of the sidebar at the right, with its Document and Block top organization, for me instantly becomes clear one thing: okay this is hierarchy settings of the page. Settings by level. "I navigate in document settings", and "I navigate in block settings". Then there is another "block navigation (settings)?"

It is a mess in my mind, and I never, never returned to Gutenberg with a clarity regarding the Navigation Block icon that I may have acquired in the last experience. Every revisit is a discovery one more time.
In my mind I organize settings in the sidebar, actions in topbar, and info as secondary labels. If you tell me there is a place organizing infos and ask me where it is, I don't know. Probably I would say together with publish date, author and other infos of the document, there could it be document and blocks info (page info).
But even that staaaarts to become out of place in my mind given what I explained about my perception of Gutenberg sidebar serving only for settings.

Okay.

Content Structure:
I imagine this info icon to showcase exactly information from both block navigation and content structure, so how I approve this merge proposal!
But I would not understand the hamburguer icon. It doesn't resemble in any way for me the hierarchy (a vision only now I had when exercising its meaning in this text). So please, if you can rethink the icon is going to be appreciated.
I believe you can be bold to explore dropdown cases in which there is no need of 2 tabs at all, to improve easy of access, given that few information in content tab can easily be merged with the other tab to compose a single page info icon/dropdown.
See for example the add block dropdown: it is huge, full of information and organized in columns etc. Not that I am a fan of that, it is almost saturated. But comparing the add block dropdown with 2-tabs-info-dropdown, I imagine a beautiful and efficient middle term.

I read you are removing the footer. Well, I didn't received well its introduction at first because there were already so many sidebars and topbars (Gutenberg + WP).
Later on, when fullscreen by default was approved, I replicated the change here and for my surprise, I became okay with the footer. The page visually remembered a normal text editor, like Word, Google Docs, Libre Office... now the footer was understood immediately. I was waiting Content Structure and Block Navigation to be moved into footer somehow, and the ideas about word count etc were really great.

And now, reverting the footer while merging the icons with the misaligned hamburguer icon being the chosen, this direction is not addressing the understanding of page for users like me, so I decided to make this exposition of my mental perception about this design and I hope this contributes with your knowledge.
Thank you.

@ZebulanStanphill
Copy link
Member

ZebulanStanphill commented Mar 9, 2020

I definitely agree that the Block Navigation icon is not the clearest, and I think merging the Content Structure into the same popover makes the icon even less suitable.

I also tend to forget that the Block Navigation exists, partially because it only really has one use right now: selecting blocks in nested contexts. I really think the Block Navigation could be expanded to be way, way more useful. I very highly recommend looking at what Divi has done with their new Layers View feature. The Block Navigation menu could become a simple alternative for moving blocks in and out of complex nested contexts.

I've heard of several people complaining about the lack of clear borders on parent/child blocks in the block editor. They want to be able to clearly see the hierarchy of blocks. I don't think the solution is to add visible borders/padding to everything; we already tried that and it made the UI overly jumpy and complex.

I think that the best solution to this problem is increasing the functionality of the Block Navigation menu. It could become the prime interface for viewing the block hierarchy and moving stuff across the page, without the content getting in the way.

The Block Navigation interface could even become pinnable as a sidebar, providing desktop users with a clear view of not only the immediate parent blocks, but also all nearby children and sibling blocks.

I also think the Block Navigation name is a bit confusing since we have a block called Navigation. The name does technically make sense at the moment, since block navigation is all you can really use it for, but I think a name like Divi's "Layers View" would be better suited for the interface if it was expanded with more useful functionality.

I bring this up here because I wonder if, after making these changes to the Block Navigation interface, will it still make sense to bundle the Content Structure info into the same part of the UI?

@karmatosed
Copy link
Member

There's a lot to digest here and it's all great! I wanted to first call out how I think merging is useful and the principals behind this we should bring into other areas. I also think there is a lot of power to be unlocked in the block navigator that we haven't yet, this goes a lot of the way towards doing that.

I actually think the way you are showing content works really nicely as a starting point. It could get more visual, or not. Stripping back is a great first step.

Looking forward to getting this in and I would encourage seeing it as an iteration, that's something we can build on. First though, we need to merge and then take from there.

@mapk
Copy link
Contributor

mapk commented Jul 7, 2020

This was discussed in the Gutenberg Design Triage today in Slack. Generally it makes sense to combine the Document Outline with the Block Navigator because the two block trees follow a similar structure. This PR attempts to resolve that: #14956

There is some question around how important the Word Count, Block Count, Heading Count, etc is... Maybe these can be moved to the Document tab in the sidebar?

@rilwis
Copy link

rilwis commented Sep 30, 2020

+1 for this.

I think it's best to keep the documentation outline, and make it clickable (and thus, no need for the navigation anymore).

@munirkamal
Copy link
Contributor

+1 for it 👍

@shaunandrews
Copy link
Contributor

I think Joen's original suggestion to use tabs makes a lot of sense, and could work well with the list view as a sidebar: #27395

@paaljoachim
Copy link
Contributor

I am removing the "Needs Design feedback" on this issue. Let's go for "Needs dev"..:-)

@paaljoachim paaljoachim added Needs Dev Ready for, and needs developer efforts and removed Needs Design Feedback Needs general design feedback. labels Feb 16, 2021
@mtias mtias removed the Needs Dev Ready for, and needs developer efforts label Jul 13, 2021
@talldan
Copy link
Contributor

talldan commented Jul 20, 2021

Is this still needed with the persistent list view?

I personally can't see a way for the two to be merged nicely, so going to close this issue. Feel free to open a new issue with a new proposal that takes the persistent list view into account.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.