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

Confusing + button behavior #7271

Closed
jancavan opened this issue Jun 11, 2018 · 28 comments
Closed

Confusing + button behavior #7271

jancavan opened this issue Jun 11, 2018 · 28 comments
Labels
[Feature] Inserter The main way to insert blocks using the + button in the editing interface [Type] Enhancement A suggestion for improvement.

Comments

@jancavan
Copy link

jancavan commented Jun 11, 2018

Is your feature request related to a problem? Please describe.
There's a + sign that shows up next to a block. I think it's great because if I have multiple long blocks, my mouse cursor doesn't have to travel all the way up to the toolbar:
screenshot 2018-06-11 10 50 09

However, I was confused on how I could get it to show up again. @karmatosed pointed out that I'd have to hit return, but this wasn't intuitive to me.

I think part of the reason why is because the + button is being used in two different ways depending on the context: on the toolbar, it adds new blocks. If it's next to the block itself, it can also change the type of block (e.g. Paragraph to a Quote) then automatically adds a new Paragraph block beneath it.

Maybe this is even just a verbiage issue since it says "Add block", but the action of adding a block is fulfilled by hitting enter, not by clicking the + button.

Describe the solution you'd like

Apart from hitting return to add a block, maybe clicking on the white space beneath the block adds a new block under it.

@jancavan jancavan changed the title Plus sign next to a block is sometimes not displayed Confusing + button behavior Jun 11, 2018
@chrisvanpatten
Copy link
Member

I agree; either clicking white space for a new block or making the in-between inserter available below the last block would be great improvements. Perhaps as part of #7220?

@ZebulanStanphill
Copy link
Member

Related: #5054.

@jasmussen
Copy link
Contributor

CC: @mtias, I think he suggested we simply always show the trailing appender. Right now it's only there if the last block is not a text block.

@spencerfinnell
Copy link

I think he suggested we simply always show the trailing appender. Right now it's only there if the last block is not a text block.

👍 Super confusing having it switch back and forth as you write.

@karmatosed
Copy link
Member

I've also gone back and forth on this. I think I tend to agree to show the trailing adding at all times. We could maybe be super clever and phase it out as people learn but that's dangerous moving sand ground and to be tested.

@spencerfinnell
Copy link

spencerfinnell commented Jun 12, 2018

@karmatosed I think having to click in to an existing Paragraph block then press Return shouldn't be something people need to learn/do.

Another inconsistency which may be noted elsewhere:

  • Click the last paragraph
  • Press return to make a new insertion point
  • Delete that "block" without adding anything
  • You still have access to an insertion point

So the only time you have to do something different to add content is the first time you want to add something after your last paragraph.

@jancavan
Copy link
Author

If the trailing appender were to be shown every single time, isn't this assuming that users want to add a new block following the block they just created even though they don't want one?

I think a user shouldn't be presented a new empty block unless they explicitly create one.

@ZebulanStanphill
Copy link
Member

I would prefer the sibling/in-between inserter to be used for inserting blocks at the bottom of a post rather than always having a placeholder there, especially in nested contexts. This is because the placeholders take up space, causing the editor to be one step further from looking like the front-end and making multiple levels of nesting look particularly awkward. But if the placeholders stay as the method for inserting new blocks at the bottom of a post and/or <InnerBlocks/>, I think the behavior should definitely be made consistent so that the placeholders are not hidden when the last block is a Paragraph.

@ZebulanStanphill
Copy link
Member

Related: #6834, #7006, #7763, and #7950.

@ZebulanStanphill
Copy link
Member

ZebulanStanphill commented Jul 16, 2018

Perhaps the insertion icon in placeholders should look different to indicate it is replacing the placeholder. Perhaps an arrow to the side of the plus to make it clear that the block is being inserted at that spot and to simultaneously differentiate it from the normal plus icon?

On a related note, right now the sibling inserter just works the same as pressing Enter, which I think is a mistake. You have to click twice to actually get to the menu to insert a specific block, and then of course you have to click again to actually insert the desired block so it takes a total of three clicks when it could just be two. It is also confusing to click a button that looks like it should act the same as the one in the toolbar, only for it to insert a placeholder and you have to click another identical icon to actually get to the inserter menu.

Having the sibling inserter open the inserter menu directly just makes so much more sense, in my opinion. Can you think of a single downside to doing this? People just writing posts would not be affected since Enter would and should keep acting like it does now, and keyboard users would likely be using Enter and slash commands. Mouse and touch users would definitely benefit. It would also solve #7763 by allowing the sibling inserter to be used in nested contexts that do not allow Paragraph blocks.

@collinanderson
Copy link

Having the sibling inserter open the inserter menu directly just makes so much more sense, in my opinion. Can you think of a single downside to doing this? People just writing posts would not be affected since Enter would and should keep acting like it does now, and keyboard users would likely be using Enter and slash commands.

This makes sense to me.

@hedgefield
Copy link

hedgefield commented Jul 26, 2018

Makes sense to me too, all for it. I find that placeholder to be very confusing too.

@karmatosed
Copy link
Member

Perhaps the insertion icon in placeholders should look different to indicate it is replacing the placeholder. Perhaps an arrow to the side of the plus to make it clear that the block is being inserted at that spot and to simultaneously differentiate it from the normal plus icon?

Would having a different design for the same thing not confuse more?

Having the sibling inserter open the inserter menu directly just makes so much more sense, in my opinion. Can you think of a single downside to doing this? People just writing posts would not be affected since Enter would and should keep acting like it does now, and keyboard users would likely be using Enter and slash commands.

I am totally ok having all adding icons behave the same way. But, we need to be sure they do in this change.

@ZebulanStanphill
Copy link
Member

@karmatosed

Would having a different design for the same thing not confuse more?

Technically, the inserter in the placeholder is not exactly the same as the one in the top bar, because it replaces a block (the placeholder/empty Paragraph block) rather than inserting a new block adjacent to the currently selected one. I do not feel very strongly either way, though.

However, I do think it is a bit confusing that the inserter icon is placed outside of the placeholder and on the left, but for nested placeholders, it is placed inside the border and on the right.

I am totally ok having all adding icons behave the same way. But, we need to be sure they do in this change.

I do not really understand what you are trying to say here?

@jasmussen
Copy link
Contributor

I recognize that a consensus seems to be emerging that the plus between two blocks should behave no differently than any other plus. I recognize the logic of that, and will defer to such a consensus of course.

However I'd like to explain how and why we got to where we are, and why I think it might still be worth it to look at solutions that involve a different icon than the plus to solve the confusion aspect.

The gist is that although Gutenberg is a block editor, it is still an editor. In editors, it is an established pattern that if you want to insert something — text, images, video, or anything really — you first set the cursor/caret where you want the thing, and then you use an "Insert" command — whether that command is in a toolbar, or in a menu, or elsewhere.

This also explains why in the initial implementation, we had only a horizontal line that would appear when you hovered between two blocks — it's a way to make space between them first, to insert new stuff there.

An additional sub-goal was to reduce the number of ways to insert blocks — by making the in-between insertion method be exactly the same as the trailing appender (the one that you use at the end of the block list), there were only two ways to insert blocks — one in the top toolbar, one in the canvas.

Only stating this for context and something to consider if we move away from this pattern. I know @folletto has thoughts on this too.

@hedgefield
Copy link

Thanks for the context Joen. When you're describing the 'make space, then insert' pattern, I'd ask: is there any other reason to create an empty space between blocks other than to insert a new block? (leaving out the styling aspect since that should be done with CSS or a spacer block.) If so, wouldn't it make sense to remove an extra click and potential confusion by just opening the block library right away?

Which I think is what @karmatosed meant when she said

I am totally ok having all adding icons behave the same way. But, we need to be sure they do in this change.

just that we need to discuss here if we're okay with removing the placeholder as test and whether the canvas + can behave the same as the top bar + in all usecases.

@jasmussen
Copy link
Contributor

is there any other reason to create an empty space between blocks other than to insert a new block?

Sure, maybe you'd like to insert a paragraph of text between two images. And having to first click "Paragraph" in a clunky inserter interface feels like an obstruction when you just want to blog. This is the balance we're trying to find here, a block editor that's good for writing too. This is why I try to avoid the term "page builder", as that's not what I feel like we're building here.

I say this fully understanding the confusion of the plus button. This issue is real, and I'm not disagreeing with a change per se. But I'm offering the suggestion that perhaps a different icon than the plus, or a different interface, are alternate solutions.

@hedgefield
Copy link

That's a fair point. I guess the question in that becomes - do we optimize for people writing text, or for people building websites. I agree in your example that an instant paragraph is probably better, but looking at the future of Gutenberg, where it moves more to becoming a full page builder (and people are using it like that now already, looking at the XWP/Google AMP demo and Atomic Blocks), I wonder if it wouldn't make more sense to jump ahead to thinking about things in that way.

In that scenario, I feel like we could rely on the Most Used section to tailor the inserting experience towards how you use it. If you write a lot, the paragraph will be right up there. If you do page layouts a lot, other blocks would be at the top of the inserter. And if you're missing something, you can already immediately start typing the name of it when you open the inserter now.

And not to harp on, but I just also remembered the AllowedBlocks usecase: if you make a custom block where the Paragraph is not in the list of allowed InnerBlocks, the placeholder won't work, it simply breaks. That's something that would instantly be solved if the sibling inserter went directly to the block library.

@jasmussen
Copy link
Contributor

I guess the question in that becomes - do we optimize for people writing text, or for people building websites

Yep, this has been the balance we've worked towards for a long time. And it's not necessarily about optimizing in either direction, I think our goal should be to optimize for both. By looking too long and hard at how page builders currently do things, we might be doing ourselves a disservice by not finding a better solution.

Not necessarily suggestion the current implementation is the better solution — but you get my point :D — good points though, and all something to look at holistically.

One element that is working well is selecting a block and pressing Enter creates a new empty paragraph. However this cannot always work, because the freedom we are giving block authors means on some selected blocks, pressing Enter will simply expand the block. For example an implementation of CodeMirror might simply expand the editing canvas indefinitely when pressing Enter. In this case, the plus button is an "escape hatch", because we cannot enforce good practices on all plugin blocks.

@collinanderson
Copy link

I was thinking about this case this weekend, and another case where the current behavior is useful is when the last element is a List block. Pressing enter in a list block creates a new bullet point instead of a new block, so if you want to continue with a new paragraph, it's nice to just click below and start writing. You don't need to select "paragraph" and it doesn't interrupt your flow.

@ZebulanStanphill
Copy link
Member

ZebulanStanphill commented Jul 31, 2018

@collinanderson

I was thinking about this case this weekend, and another case where the current behavior is useful is when the last element is a List block. Pressing enter in a list block creates a new bullet point instead of a new block, so if you want to continue with a new paragraph, it's nice to just click below and start writing. You don't need to select "paragraph" and it doesn't interrupt your flow.

You can simply press Enter twice to insert a new Paragraph block. (This is pretty standard behavior in text editors.)

@jasmussen I think the ability to use Enter to create a new Paragraph block instantly from another Paragraph block or a Heading block (and in the expected text editor fashion from a List block as mentioned above) is enough to justify not needing the sibling inserter to also insert a Paragraph. If you are trying to do things quickly, then using keyboard shortcuts like Enter will apply, and most people using Gutenberg as a text editor rather than a page builder will be using Paragraph, Heading, or List blocks most of the time. I would think that the situations where you cannot use Enter to create a Paragraph block would usually be situations where you do not want to create a Paragraph block. And even in those cases, the Paragraph block would most likely be in the Most Used category, and it would not take long to insert one by searching for it in the inserter.

Additionally, perhaps it should be recommended practice that pressing Shift+Enter should create a new Paragraph in blocks where Enter simply adds a new line to the current block, and in blocks where Enter creates a new block, Shift+Enter adds a new line.

Or maybe some other keyboard shortcut could be added that always inserts a Paragraph block.

@jasmussen
Copy link
Contributor

I think the ability to use Enter to create a new Paragraph block instantly from another Paragraph block or a Heading block (and in the expected text editor fashion from a List block as mentioned above) is enough to justify not needing the sibling inserter to also insert a Paragraph

Possibly.

Additionally, perhaps it should be recommended practice that pressing Shift+Enter should create a new Paragraph in blocks where Enter simply adds a new line to the current block, and in blocks where Enter creates a new block, Shift+Enter adds a new line.

Given that you can write any block you like, I'm not sure we can enforce this in the block API. I'm sure smarter folks than me can chime in if I'm wrong.

@ZebulanStanphill
Copy link
Member

Given that you can write any block you like, I'm not sure we can enforce this in the block API. I'm sure smarter folks than me can chime in if I'm wrong.

I know, I just said maybe it should be a recommended practice or something.

Also, yesterday I noticed that in the Custom HTML block, you exit the block by pressing Esc and then pressing Enter. Could that be enforced in the block API?

@ZebulanStanphill
Copy link
Member

However, I do think it is a bit confusing that the inserter icon is placed outside of the placeholder and on the left, but for nested placeholders, it is placed inside the border and on the right

To elaborate a bit on this, putting the inserter icon outside of the block borders does not work in contexts where the content width (set by the theme) is full-width. This is the same issue that #6224 is trying to fix for the side controls by putting them below/above the block. Therefore, I would consider keeping the inserter icon outside of the borders of the placeholder block is both inconsistent and also confusing.

I think the inserter button should go inside the block borders and on the far right, after the most-used block shortcuts. This fixes the full-width problem and also makes the placeholder more consistent with how it looks in nested contexts, where the inserter icon is on the right.

I know that a while back the inserter icon was on the right and that it was changed to be easier to see since people were not always finding it to insert blocks. However, if the sibling inserter was made available at the bottom of blocks and opened the inserter menu directly, this would be a lot less of an issue.

@ZebulanStanphill
Copy link
Member

@jasmussen I just remembered another benefit of having the sibling inserter open the insertion menu directly. It would allow #7763 to be easily fixed by re-enabling the sibling inserter in contexts where the Paragraph block is not allowed.

@chrisvanpatten
Copy link
Member

chrisvanpatten commented Sep 26, 2018

There have been a fair number of requests for this in the past two months (wow, time flew). It might be good to look at revisiting this, perhaps in parallel with #10136 now that we have viable appenders for different circumstances?

@karmatosed
Copy link
Member

There has been some great discussion here, let's move into action forward and we have #7177 linked. I am for now removing the design feedback label.

@mtias
Copy link
Member

mtias commented Nov 17, 2019

Let's consolidate any further improvements in #10519.

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 [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

10 participants