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

In-Page Inserter Revisions #10519

Closed
mtias opened this issue Oct 11, 2018 · 18 comments
Closed

In-Page Inserter Revisions #10519

mtias opened this issue Oct 11, 2018 · 18 comments
Assignees
Labels
[Feature] Inserter The main way to insert blocks using the + button in the editing interface [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Needs design efforts. [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues
Milestone

Comments

@mtias
Copy link
Member

mtias commented Oct 11, 2018

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:

always-there-plus-centered

@mtias mtias added [Feature] Inserter The main way to insert blocks using the + button in the editing interface [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... labels Oct 11, 2018
@mtias mtias added this to the Completed: UI / UX milestone Oct 11, 2018
@ZebulanStanphill
Copy link
Member

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
Copy link

StaggerLeee commented Oct 26, 2018

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
Copy link
Contributor

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

@StaggerLeee
Copy link

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

@aduth
Copy link
Member

aduth commented Oct 31, 2018

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

@mtias mtias added the [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues label Nov 6, 2018
@mtias mtias changed the title Final In-Page Inserter Revisions In-Page Inserter Revisions Nov 12, 2018
@mtias mtias modified the milestones: WordPress 5.0 RC, Future: 5.1 Nov 12, 2018
@mtias mtias added the Needs Design Feedback Needs general design feedback. label Nov 12, 2018
@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Nov 18, 2018
@afercia
Copy link
Contributor

afercia commented Nov 18, 2018

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
Copy link

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

@mtias
Copy link
Member Author

mtias commented Dec 3, 2018

@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
Copy link
Contributor

afercia commented Dec 16, 2018

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):

default appender

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):

default block

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
Copy link
Contributor

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
Copy link
Contributor

afercia commented Jan 13, 2019

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
Copy link
Contributor

kjellr commented Apr 16, 2019

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
Copy link
Member

aduth commented Dec 10, 2019

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

@ZebulanStanphill
Copy link
Member

ZebulanStanphill commented Feb 3, 2020

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
Copy link
Member

aduth commented Feb 3, 2020

@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
Copy link
Member

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
Copy link
Contributor

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:

Screenshot 2020-02-03 at 18 39 48

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
Copy link
Contributor

mapk commented Mar 16, 2020

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. 🎉

Screen Shot 2020-03-16 at 3 11 49 PM

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

Screen Shot 2020-03-16 at 3 14 03 PM

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

@mapk mapk closed this as completed Mar 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Inserter The main way to insert blocks using the + button in the editing interface [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Needs design efforts. [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues
Projects
None yet
Development

No branches or pull requests

9 participants