In-Page Inserter Revisions

[mtias]

There are a few refinements that had been discussed in the last few weeks around the state of in-page inserters (the trailing inserter, the empty block inserter, the sibling inserter, the bottom of the page click area, etc).

These have all evolved through multiple feedback loops and they are in a pretty good state. However, there are a few refinements that keep coming back that we should look at doing or punting within the next week or so.

Goals

To reiterate, the main goals for these insertion mechanisms are:

• Consistent interface for adding blocks.
• Provide shortcuts for common interactions.
• • Adding blocks between other blocks.
• • Adding paragraphs and media.

The combination of these goals is why we have a few inconsistencies like the sibling inserter using a + icon yet not opening the inserter but adding an empty paragraph instead. Or why we have a trailing inserter with shortcuts for commonly accessed blocks.

Tasks

The proposed iterations, as I'm gathering them, would be:

• Sibling Inserter: Either open the full inserter or change the icon to be a paragraph, it doesn't help to have a + button that behaves differently to the others as it causes uncertainty.
• Trailing Inserter: Always show a + at the bottom of the page. This would be similar to the new block appender for non-text contexts: Add an alternative block appender when the container doesn't support the default block #10136
• Bottom of the Page: Is this something we want to keep if there is always a visible + at the end?

Combining quick access to some blocks (paragraph and image) could be done like this too:

[ZebulanStanphill]

Since you can create a new Paragraph by pressing Enter in most cases, I think it would be most useful if the sibling inserter opened the block library, providing a fast way for mouse users to insert blocks while also having a fast way for keyboard users. This would also allow the sibling inserter to be used in contexts where a Paragraph block is not allowed.

Currently, automatic appenders appear below every block in nested contexts unless the block is a Paragraph. This is confusing, and I keep finding it difficult to add blocks after a Paragraph when using a mouse in nested contexts.

The best solution to this that I can think of is making the sibling inserter available below the last block in a nested context. Alternatively, you can just show the appender below Paragraph blocks like everything else.

However, this immediately introduces the issue of the editor looking less like the front-end, due to whitespace being added to almost every <InnerBlocks />. I think to fix this issue, the appenders should only be shown when you have selected the block with the nested area or one of its direct children.

That appender mockup looks pretty nice. One issue with the current one is that it looks different at the root level versus nested contexts, with the inserter icon appearing on the left and outside of the standard content width at the root level, but on the right and within the standard content width in nested contexts. The mockup has a centered icon, which is more consistent with the sibling inserter and (should) look the same at the root level and in nested contexts.

[StaggerLeee]

There is no option to delete inserted block with "Add text or type...", unless you make it real block and than delete.
It is not thoughtful done.

Imagine User clicks on it by mistake. He/She does not want any block, just clicked and activated it by mistake. Then forcing User to choose some real block just to be able to delete it is wrong. At least by my opinion.

You had it nicely done once and changed for some strange reason. When User activate inserter, and clicked outside this block Inserter DIV (or call it pre-block) is automatically and silently deleted.

Make it work at least with Del keyboard key, when this DIV is empty anyway.

Edit: I see now this inserter is on default allways as last part of content.
Other Inserters middle in content you can delete with Backspace, not with Delete key. Confusing, but maybe because all is new. There is place in this line, put some small icon and all is fine and clear: dashicon trash.

[chrisvanpatten]

Hi @StaggerLeee, that very issue is being tracked over in #10334. I'd recommend checking out that ticket.

[StaggerLeee]

Thank you @chrisvanpatten. User @kkoppenhaver said it fine and I agree, as it is shown im my edit.

[aduth]

I've opened #11329 to start exploring considerations for how the always-visible trailing appender should behave.

[afercia]

Noticed this issue just because it was mentioned in #7177 (comment). Please add the "Accessibility" label to any issue or PR that touches UI controls or other parts of the UI that impact accessibility.

Re: the specific proposal illustrated in the GIF above, I'd like to know how this design addresses accessibility of the "appearing" controls for keyboard users, screen reader users, speech input users, users with low vision (contrast ratio), users with cognitive impairments, etc. Thank you.

[StaggerLeee]

Please bring back inserter at the end of the content. Why did you remove it ?

[mtias]

@afercia yes, it'd have to be a thorough re-evaluation of "insertion at the end". The gif just shows a more clear area of "end of post / insert more content" that is not tied to the paragraph. I would expect it to be of similar affordances for keyboard users, screen reader users, etc, as a single place for "add more content", with "recent blocks" being potentially an addition to it, if you want to, but with the focus on the + action.

[afercia]

Reading #12510 and #12536 (comment) I'd be in favor of entirely removing the current "inserter shortcuts" as there are a few a11y issues.

First, the visual order doesn't match the DOM order so when tabbing with the keyboard, the tab sequence "jumps" from the right to the left.

Right now, there's also a contrast issue. These shortcuts are styled differently in two different contexts. In the "default appender", some CSS rules override the default styling of the InserterWithShortcuts component and the icons do have a sufficient contrast. The used color is $dark-opacity-500 ($light-opacity-500 for dark themes):

When clicking, the default appender becomes the "default block" and the InserterWithShortcuts component uses its default styling. In this case, the contrast is not sufficient. The used color is now $dark-opacity-light-700 ($light-opacity-light-700 for dark themes):

Also, after #12510 the default appender shortcuts are rendered only on hover, so the CSS opacity transition doesn't work any longer. Just noting it because right now there's some CSS that doesn't do anything and should be cleaned up when removing these shortcuts. /Cc @jasmussen

In the meantime, I'd propose to temporarily fix the contrast issue. Will push a quick PR.

[jasmussen]

Thanks for the ping Andrea. Given the scope limitation to component directories, I would think we can refactor that whole thing and remove any old CSS once we redo this thing. I'd be reluctant to over optimize for what we have today, given they might be going soon.

[afercia]

Any updates / plans on this? 🙂I'd tend to see this as one of the major inconsistencies in the user interface and it would be nice to help #11329 move on. See also the related #12928.

[kjellr]

Swapped out the Needs Design Feedback label for the Needs Design label on this one — since it looks like we're at a stage where design explorations would be helpful.

[aduth]

In an effort to try to revive this conversation, I've opened #19045 which proposes to remove the current block inserter "shortcut" options.

[ZebulanStanphill]

Should this issue still be open? The in-page inserter shortcuts have been removed now, and the in-page inserter now puts the "+" icon on the right regardless of whether it is as the top level or in a nested block.

[aduth]

@ZebulanStanphill As I understand, while #19045 addressed part of the concern here, there are still considerations for additional changes:

• Should the inserter always be shown at the end of the block list?
  • Currently, it is only shown if the last block is not the default (paragraph) block
• Should the clickable area below the block list be removed or revised?

[ZebulanStanphill]

Personally, I think the inserter should never be shown at the end of the block list, or at least it should always be shown. Either way would be better than it continuing to be inconsistent.

Personally, I think the clickable area below the block list is kind of confusing, though it doesn't bother me that much.

[jasmussen]

Personally, I think the inserter should never be shown at the end of the block list, or at least it should always be shown. Either way would be better than it continuing to be inconsistent.

I would very much echo something needs to be done here, because the way it is now breaks with the "deselected content is a preview" a fair bit. Here's some some exploratory reusable block work I've been doing:

The plus is not shown after a text block, only after a non text block. So the three pluses are a) the one after a separator, b) the one after a spacer, and c) the permanent bottom appender.

If this was consistent (both following text and other blocks), and invisible on a deselected block, it might be fine. But as it is, these buttons are incredibly disruptive to any layout that isn't just text.

[mapk]

It appears the display of inserters have undergone significant revisions with the G2 UI. I'd like to close this as these inserters are no longer littered throughout the interface.

I tested using a Group block, a Columns block, a Buttons block, etc. I don't see inserters all over the place anymore which is a HUGE improvement. 🎉

The only time I see a lingering inserter is on the reusable block once a block is converted to one.

For these reasons, and alongside the recent Block Library work being done, I'm going to close this out.