Behaviour of contextual toolbars during scrolling and editing of documents

[anna-harrison]

When a person moves through a document, for e.g. while doing a final proofread of a long post, either scrolling and using a mouse, or using keyboard navigation (up and down arrow keys, page and page down), how should the toolbars behave? Under what conditions should they become visible to reduce visual distraction?

Contextual toolbars identified so far ( #190 and #16 ):

1. Block move controls (up and down arrows)
2. Block type selector/transformer
3. Block action toolbar (align, delete, clone?, ...)
4. Selection (text, image, etc) toolbar

Possible block states:

1. Normal block
2. Selected block
3. Cursor in block (?)
4. Hovering on block
5. Content within block selected
6. Empty (placeholder) block

Relevant discussion from #core-editor today

[anna-harrison]

Breaking this down, what is contributing to the visual clutter, and what can we do?

(1) The timing with which elements appear in the primary "what I see" zone. The red zone shows the main area that your eye will rest on as you move through a document. Right now, all the toolbars pop up in this zone, increasing visual fatigue

(2) A flat visual hierarchy is currently applied to all contextual toolbars. All three types of toolbars appear "equally" in the same zone, even though the frequency of interaction with these elements will differ e.g. the section toolbar will be clicked on more often than the block transform toolbar

(3) The zone on the right of the page is less visually distracting than on the left. Question: does anyone know if this would hold for RTL languages as well?, or would the zones be inverted?

[jasmussen]

Thanks for opening this ticket.

(1) The timing with which elements appear in the primary "what I see" zone. The red zone shows the main area that your eye will rest on as you move through a document. Right now, all the toolbars pop up in this zone, increasing visual fatigue

Let's keep in mind that the prototypes are neither technically or UI-wise complete. Also, you'll never actually see screens like in the comment above — you'll only ever see toolbars when you click a block.

I invite everyone to try the new Google Sites for an example of toolbars that appear when clicking a block. While it's not the most common pattern to use for editors — it's more commonly used for layout — it is a concept that we are exploring for the prototypes to decide if it can work for us. if in the end we need to decide to go with a popup toolbar, or even a permanently docked toolbar at the top of the screen, like most classic editors do, that is not an expensive course correction. And by having tried this path first, we'll know that the alternative is what we want.

So I encourage everyone to lean into the "block-first" UI, so that we give it a proper shake.

In that vein, here's how I imagine this working:

• You start a new page and see a "Start writing..." prompt. You click there, and see the block outlines and controls.
• You start typing, and very soon block outlines and controls fade out. As long as you are typing, you won't see any controls.
• You select some text to make it bold — whether with the keyboard, or with the mouse — block boundaries and controls fade in.
• You start using the arrow keys again, once done with formatting, and the block outlines fade out.
• Arrow keys and page down let you scroll the document. No outlines fade in while using these keys. You have to select something.
• You mouse over blocks and the minimal outlines show up. You can click to make the full outlines and controls show up, but as long as you're only hovering, you only see the minimal ones.

My remaining question is: what happens if you rest your cursor over a block, then use the scroll-wheel to navigate the page. Do minimal outlines show up for every subsequent block you scroll/hover over?

[anna-harrison]

@jasmussen thanks for articulating the work flow, that's awesome

Regarding the "block controls" - my intuition is still to explore separating the block controls from the selected text controls. In the google sites example, the contextual toolbar is actually a selected text toolbar (with the exception of the delete function). I think that the comments made by @shaunandrews and @mapk in #198 may partly relate to the conflation of block level and selected text level controls

[intronic]

@annaephox @jasmussen

This is interesting - the 'Text box' block component in the new google sites allows multiple html 'flow' content (block elements) like paragraph, heading, UL+OL lists, code) within a single block.
It excludes a lot of others though - images, embeds, etc dont seem to be able to be placed within a 'Text box'.

To embed an image next to text (instead of above or below) you drag it to the left or right of the text and it places the image and text within a 'section' container.

It lies somewhere between prototype 2 (every individual flow element is a block editor) and prototype 3 (every block is in one editor).

[anna-harrison]

The finer grained interactions will need refinement, but at this stage, what are your thoughts on this approach to address above issues.

Feedback... are these the way to go:

• The creation a visual hierarchy for block vs selection toolbars
• The shifting of the lower priority block toolbar to the right

( Thanks @mimo84 @intronic for above demo )

[anna-harrison]

A summary of what we learned in putting together TinyMCE-single+React

[jasmussen]

Sticky scrollbars are in master!

I think that largely addresses concerns in this PR, so I'm closing. If this was a mistake, let me know and I'll reopen!