Writing Flow: Trailing placeholder attempt 3

[jasmussen]

This PR is based on initial work by @youknowriad in #4425, it's simply branched off of it.

What this PR does is:

• From Riads initial work, it removes the trailing inserter in favor of a permanently clickable area at the bottom, which is more like a editor, fixing Consider removing the trailing inserter in favor of a clickable area #3078
• It adds a permanent inserter to the left of a block
• On phone and small viewport sizes, this inserter shows up below the selected block
• Buttons are actually bigger now, including the ellipsis, and all the code around those have been simplified a bit

It is an experiment for now, as the UI gets a little heavier on the side, but I would recommend you check out this branch and get a feel for it. The potential this has is to get rid of the sibling inserter and reduce the number of ways to insert content from 3 to 2 — only through the Editor Bar, or in context of the block selected.

Depending on the feel of this, my hope is to lighten the design further, visually reducing the weight:

GIFs:

The design hasn't yet been optimized for the mockup (which features subtler icons for the movers and inserter), as it is pending your thoughts here.

[jasmussen]

Note that the visual weight of these buttons will be further reduced once #4512 lands.

[youknowriad]

I do think it's a good idea to move the inserter there and drop the "sibling inserter". The "sibling inserter" feel like distraction sometimes. But there's something that bothers me design wise even if I can't think of a better way to show this inserter without touching the movers.

[jasmussen]

But there's something that bothers me design wise even if I can't think of a better way to show this inserter without touching the movers.

Yes, it's hard to put a finger on it, which is why I decided to try and implement it in code so we can get a feel for it. Perhaps by trying this out in a branch we can narrow in on a good design.

I personally feel like this design largely addresses it for me:

• The icons are smaller, so it doesn't look so "crowded"
• The Inserter icon has a slightly different design which lightens it and "groups it" compared to the arrows

[youknowriad]

@jasmussen Agree this last design is better, I was trying the PR and it felt a bit heavy.

[jasmussen]

Used a little CSS hackery to adjust the design of the side inserter:

[litka]

In this iteration, it's kind of ambiguous where the block will actually get inserted. This is, in part, because the inserter is associated with the block you are hovering, rather than the space in-between blocks, which where the new block will actually go.

Say you want insert an image above the paragraph you just wrote. You would need to work out in your head which block to hover in order to insert the image in the right spot. It's much more cognitive load than simply hovering the space between the blocks where you want to insert the image.

[jasmussen]

In this iteration, it's kind of ambiguous where the block will actually get inserted. This is, in part, because the inserter is associated with the block you are hovering, rather than the space in-between blocks, which where the new block will actually go.

Say you want insert an image above the paragraph you just wrote. You would need to work out in your head which block to hover in order to insert the image in the right spot. It's much more cognitive load than simply hovering the space between the blocks where you want to insert the image.

This is right, except for the case where you use the inserter in an empty paragraph, where it would simply replace the paragraph.

The argument for why this is better, that it reduces the amount of ways you can insert content in to two ways, and both work the same way, i.e. they insert after the selected content (or replaces it when empty). The only use case where this is less optimal is if you want to insert something before the first block, and I'd argue that isn't a stresscase, because in case of text you just make a linebreak at the beginning, and in case of an other block you just use the movers to move up.

As such, it simplifies and unifies insertion mechanisms so they all work the same.

[jasmussen]

Rebased this and merged in the new focus styles. I'm liking this a lot:

@youknowriad @mtias can you take a look?

[youknowriad]

@jasmussen I wonder if we should remove the border around the "+" in this inserter. It feels a bit weird to have a border for this button by default and the exact same border for the movers but only once focused.

[jasmussen]

I wonder if we should remove the border around the "+" in this inserter. It feels a bit weird to have a border for this button by default and the exact same border for the movers but only once focused.

This is an aspect of the design that I feel makes it work visually, and less so without it. With the normal "add" icon, the thick border makes the icon much heavier to look at, and next to the up/down arrows it felt too heavy.

I understand your feelings, but having looked at it for a couple of days I feel like it's working. Obviously it would need more eyes on it, and opinions. But I think it may be one of those "getting used to it" things.

[afercia]

Reporting here some of the considerations from #4425

1
when tabbing and focusing the "appender space", the focus indication is very light, almost not noticeable; also, I can't see a caret blinking... not sure why.

Edit: seems this is because focus goes to the external wrapper, not on the actual editable element, so if you start typing nothing happens.

A stronger focus style and making the caret appear as default in all editable fields maybe could help?

2
Same when hovering with a pointing device: there's no "hover" style and the cursor style is cursor: text; which doesn't help understand that space (actually a button) is clickable. I'd consider some hover style and cursor: pointer;

3
I see there are an input field and a button, both unlabeled. There's no label (or aria-label) for the input. There's no text (or aria-label) for the button.

As you know, all UI controls must be labeled with some meaningful text.

4
I'm not sure users will understand the subtleties behind not having the clickable space when the last block is a paragraph. As a user, once I learn that clicking that area adds a block, I'd expect that to always work even when the last block is a paragraph.

5
New: seems with a mixed use of keyboard and mouse, I'm able to make 3 inserters appear at the same time: the + on the left, the + below the block, and the clickable area:

[jasmussen]

New: seems with a mixed use of keyboard and mouse, I'm able to make 3 inserters appear at the same time: the + on the left, the + below the block, and the clickable area:

The idea of this version of the branch is that we can remove the sibling inserter (the one between blocks) and the trailing inserter, in favor of just the side inserter.

In that vein, here are some mockups that I've been exploring to make the added inserter on the side less visually heavy:

These also include a drag handle, which we may or may not want, given that drag and drop may be coming. I'm leaning towards us not needing this, and relying on the grab cursor being sufficient, but it's always good to keep an explicit icon in mind.

[karmatosed]

@jasmussen out of the 4, 1 or 2 for me and preference to 1. I have a little note of caution with us using : as it is visually similar to the ellipsis and easy to confuse.

[jasmussen]

Rebased, and fixed a bunch of things. I think experience wise, this is in a good place.

I may have broken some things in a rebase, so I'd appreciate a look at this. The accessibility issues (missing aria label, and other things reported) also haven't been fixed yet. But I think this would be good to get in sooner rather than later.

[jasmussen]

@afercia regarding your feedback:

1 and 2 refer to the fact that this is now a button instead of an input field, but it masquerades as a button. Is the problem here that tabbing to this doesn't immediate set the caret there, and that typing doesn't work? Or to put it differently, if we addressed so it truly behaved like an input field would that address it? Alternately we'll have to look at making it an input field again.

3 I'll try and address in a minute.

4 I think is a fair point, but given the context of #3078 that this feels natural in other editors that do something similar, I think it would be worth ticketing this one separately as something to consider once this particular PR is merged in.

5 is also worth ticketing separately. But one of the goals of this PR, and #3078, is to allow us to retire the sibling inserter entirely. The sibling inserter is the one that shows up when hovering between two blocks. Edit: to phrase it differently — once this PR is in, we should open a ticket that is called "remove the sibling inserter".

[jasmussen]

Okay, I think I addressed most of your concerns Andrea:

• The trailing placeholder is now an input field, but with no placeholder text
• Because it's input, tabbing into it and typing, as well as clicking both behave as expected
• Because it's input, it doesn't require an aria-label — is that correct?
• The trailing appender now has exactly the same visual style as the first appender, which is to say it has a hover style when you mouse over it. This also addresses an issue where if you have metaboxes on the page, it's unobvious where to click to type.

GIF:

I really like how this PR simplifies the editor from a visual and cognitive point of view. I think it's ready for final sanity check and review. CC: @youknowriad, when you have time, thank you, and thanks for doing all the hard initial work on this.

[iamthomasbishop]

I'm not aware of all of the background of this, so take my thoughts w/ a grain of salt.

While I like that you're simplifying the entry points, I am also wondering if the positioning of the inserter will cause confusion around where a new block can/will be inserted. Maybe I'm just attached to the inline (sibling?) inserters, because their placement is super obvious :)

Although, as nested blocks becomes a thing, maybe this positioning makes sense for that case?

In terms of mobile, I like that you moved the inserter inline with the manipulation controls - it seems clearer that you're inserting something below - even if I'd also like to be able to insert above :)

One other thought: what if we were to keep the the inserter button on the trailing space, but invisible. until the user hovers that trailing block. This is already the behavior of the tool hints when you hover the trailing space, so we could align these.

Fantastic work, and I love that you're considering making the product as distraction-free as possible. It's super inspiring as we work on mobile GB :)

[jasmussen]

Thanks Thomas, as you know I'm a big fan of your ideas so far, and I appreciate your thoughts.

I think it's worth trying it on the side like this, and ideally trying it along with removing the sibling inserter in between. Not just because it's a standard in other similar-ish editors, but because having tried the other UI for the past year, this honestly feels better when in the writing/building flow.

The key issue with the trailing inserter is that it sits where normally in a traditional editor, you'd just place your text caret first, and then insert content after the fact. This PR adresses that. Especially in cases where the last block is a non-text block, like an image. In that case it just feels super wrong to not be able to click and get a text-caret after the last block.

An issue with a block editor like this is that you can't set the caret between two blocks. You know in classic editors where you get a really tall caret when setting it after an image? At least there you can press enter to make room for text or new content to be inserted. The sibling inserter solves this, but it does so in a somewhat UI heavy way. Given we've received a lot of critique of this block editor being cognitively UI heavy, I think it's important we try as many different approaches to simplifying this as we can.

As such, I would propopse we merge this in so we can gather feedback, use it in practice, and get a feel for it. Just watching the GIF is not a clear indication of how this actually feels when writing, which I honestly feel is leaps and bounds better than what we had.

And then if we've had this in Gutenberg in a release or two, we'll know whether the inserter on the side is a good idea or not. If it's a good idea, we should consider removing the sibling inserter. If it did not go over well, then we should remove it from the side, and keep the sibling inserter.

I don't see any benefit to keeping the trailing inserter, though.

[iamthomasbishop]

As always, thanks for the clear rationale. I definitely think this is worth giving a try and gathering feedback to adjust. Y'all have the most insight into the history and what's been tried, so I trust you wholeheartedly <3

Given we've received a lot of critique of this block editor being cognitively UI heavy, I think it's important we try as many different approaches to simplifying this as we can.

Two thumbs way up. 👍 👍

Regarding the trailing inserter, I see what you're saying now and this aligns well w/ what we're considering on mobile.

In terms of the sibling inserter, while it seems like it'd be a benefit to have, I agree it adds cognitive load and can get in the way. As long as rearranging blocks is easy maybe this won't be an issue.

My hesitation about the left-side positioning of the inserter still remains, but I think it's worth a shot and I reserve the right (as always) to be wrong ;)

[youknowriad]

Hey @jasmussen

• I rebase the branch
• I removed the sibling inserter
• I added a small tweak to select the block when clicking its side inserter (to fix the insertion position)

This is looking solid to me. You might want to run a last sanity check and merge

[jasmussen]

Woohooooo! Thank you so much for this! Going to give it a spin and then merge.

[aduth]

I'm trying to rebase #3745 with the changes introduced here. Can you confirm a suspicion for me, which is that state's state.blockInsertionPoint.position, showInsertionPoint's index argument, and Inserter's handling of insertIndex are all now redundant?

gutenberg/editor/store/reducer.js

Lines 507 to 517 in 0d974c8

	export function blockInsertionPoint( state = {}, action ) {
	switch ( action.type ) {
	case 'SHOW_INSERTION_POINT':
	return { ...state, visible: true, position: action.index };
	case 'HIDE_INSERTION_POINT':
	return { ...state, visible: false, position: null };
	}
	return state;
	}

gutenberg/editor/store/actions.js

Lines 209 to 214 in 0d974c8

	export function showInsertionPoint( index ) {
	return {
	type: 'SHOW_INSERTION_POINT',
	index,
	};
	}

gutenberg/editor/components/inserter/index.js

Lines 35 to 44 in 0d974c8

	const {
	insertIndex,
	onToggle,
	} = this.props;
	if ( isOpen ) {
	this.props.showInsertionPoint( insertIndex );
	} else {
	this.props.hideInsertionPoint();
	}

From what I can tell, the value of the insertIndex prop in Inserter will always be undefined, so we're never assigning the inserter position/index.

[aduth]

Also the getBlockSiblingInserterPosition selector.

[aduth]

Also the #4551 PR.

[aduth]

I'm going to take care of the above needed changes in #3745 (maybe cherry-pick into a separate pull request).

[aduth]

When will this insertion point ever be shown?

[youknowriad]

It is supposed to be shown when you open the inserter in an empty post but I just tried and it's not showing up. Might be an issue somewhere else.

[youknowriad]

Oh! I guess it's the inversed condition and also some styling issues.

On a second thought, might be it's not needed when the post is empty.

[carlhancock]

How will this play out with nested blocks? It seems like this UI isn't ideal and could begin to break down pretty quickly with more advanced features and functionality such as nesting with columns, etc.

The inserter icon next to the up/down arrows doesn't seem balanced. A single circle icon paired next to 2 circle icons just feels and looks strange to me. The padding and spacing between the elements doesn't look good, it looks squished. If you want to incorporate an inserter button in this way why not place it below the down arrow so the 3 icons are in a row. By being below the up/down arrows it would be at least a little more obvious that the block will be inserted below the current block.

But I have to say that I think this UI change is just flat-out visually unappealing. The existing insert block UI that appears at the end of existing blocks and dynamically displays recent or most used blocks next to the inserter is a lot more visually appealing.

I understand the problems that are trying to be tackled with this and i'm not a fan of the current UI for inserting a block in between existing blocks. BUT I think both of the UI changes (the inserter icon placement and the trailing appender in place of the existing UI) is a step backwards from where Gutenberg is now.

[noisysocks]

From Riads initial work, it removes the trailing inserter in favor of a permanently clickable area at the bottom, which is more like a editor, fixing #3078

Was this removed? Currently, in master, if I click in the whitespace at the bottom of a post, a paragraph block is not added.

[youknowriad]

@noisysocks It shows up only when the last block is not a paragraph. It can't be expanded to all the remaining space though.

[jasmussen]

Sorry, missed the comments post merge.

As a reminder, we are still in phase 1 of an experiment to see which UI will surfive: the side inserter, or the sibling inserter.

How will this play out with nested blocks? It seems like this UI isn't ideal and could begin to break down pretty quickly with more advanced features and functionality such as nesting with columns, etc.

The current plan, and plans can always change and be revisited, is for the mobile UI to be used for nested blocks.

The inserter icon next to the up/down arrows doesn't seem balanced. A single circle icon paired next to 2 circle icons just feels and looks strange to me. The padding and spacing between the elements doesn't look good, it looks squished. If you want to incorporate an inserter button in this way why not place it below the down arrow so the 3 icons are in a row. By being below the up/down arrows it would be at least a little more obvious that the block will be inserted below the current block.

The minimum height of a block is a single paragraph. That means we can't really stack the items vertically.

[jasmussen]

@youknowriad

It shows up only when the last block is not a paragraph. It can't be expanded to all the remaining space though.

Perhaps we should revisit this, and just always have the trailing textfield no matter what. There doesn't seem to be a huge benefit to not having this, whereas there's the occasional confusion of it not being there.

[youknowriad]

@jasmussen This would create a tab trap issue and you can easily end up with a long list of empty text blocks at the end.

[jasmussen]

Great point. Scratch that idea then. Thank you.

[carlhancock]

@jasmussen @youknowriad After using the latest build of Gutenberg with this change in place it only reinforced my opinion that removing the trailing insert block UI is a bad idea. By making this change if you want to create a page that doesn't lead with a paragraph block, or doesn't use a paragraph block at all, you are forced to still interact with the default paragraph block regardless. Because if you delete the default paragraph block Gutenberg adds another one automatically.

This becomes even more of an obvious UI issue with the Nested blocks functionality that is also in the latest build. When you add a Columns block to your page it defaults to adding a Paragraph block in each column. Then you have to add whatever blocks you actually intend to place in those columns below those paragraph blocks... and then delete those paragraph blocks.

Had the trailing insert block UI not been removed the Columns block could have simply defaulted to displaying that same type of UI. And rather than having to work around Gutenberg insisting on defaulting to placing a paragraph block when you may not want to use a paragraph block you could simply dive right into inserting the blocks you actually wanted to use. Instead, you have to clean up what Gutenberg is doing by default to accomplish what you want to do.

This change also eliminates the commonly used block UI as a consequence of the UI change which I think is also a step backward. Having used every iteration of Gutenberg so far i'd come to find the commonly used block UI very handy.

Why the insistence on eliminating the trailing insert block UI at the end of the document? What problem does eliminating it solve?

[jasmussen]

Thrilled to have you be so passionate about the project, @carlhancock, and always glad to have your feedback.

Just to reiterate, and because there's a lot more context on that ticket, we are exploring one of two UIs for inserting content here. One has the inserter on the side, one has the sibling inserter between blocks (shows up on hover).

You touch upon "why a paragraph block". The answer is because we are first and foremost building an editor, but we are adding desktop publishing style features to that editor. A routine flow in text editing, like in Word, or Google Docs, you place the caret where you want the content, then proceed to insert after the fact.

By making this change if you want to create a page that doesn't lead with a paragraph block, or doesn't use a paragraph block at all, you are forced to still interact with the default paragraph block regardless.

This assumes the default paragraph block is just the default paragraph block. When it is empty and you type /, you search a list-version of the inserter, making it also a commandline. When #3627 is addressed, any content you insert when the caret is in an empty paragraph block, replaces the paragraph block.

Because if you delete the default paragraph block Gutenberg adds another one automatically.

This is not true. The trailing textfield is not a paragraph block — it is an affordance to create an empty paragraph block when you click it or tab into it.

Why the insistence on eliminating the trailing insert block UI at the end of the document?

No-one is insisting. We are building a complex UI, and we are trying things and revising. The trailing inserter was a long-running experiment, one that I haven't personally seen in other editors, and now that we've tried it, it seems like there's a good reason for that:

• It only helps you insert blocks at the end of the post, and it is only beneficial when the block you want to insert is not text.
• For blogging software, it's probably safe to assume that users want to add text more often than more complex blocks. To address this we added a clunky "recent blocks" UI that did not help spatial memory as the "Paragraph" block might not only move around, but was unobvious to casual users as the thing to insert to just write text.
• The side-inserter, or even the sibling inserter, both solve those problems better than the trailing inserter, and aside from both of those there's still the inserter in the editor bar.

What problem does eliminating it solve?

1. It improves the writing flow. By being eliminated, it becomes drastically simpler to keep writing when the last block you inserted was an image. Sure you can select the image and press enter, or you could use the trailing inserter to find a paragraph block to insert. But when ever other editor lets you set the caret at the end of a post and start typing, anything else is a cumbersome flow.

2. The trailing inserter did not scale to nested blocks. One basic design principle of Gutenberg is that an unselected block is a preview, and a selected block can surface additional fields. This is exemplified in the Image block which surfaces a caption, or the Button block which surfaces a URL input. You're likely to see this pattern even more in more complex future blocks.

But the trailing inserter was always visible. You touch upon it yourself:

Had the trailing insert block UI not been removed the Columns block could have simply defaulted to displaying that same type of UI

If the trailing inserter would always sit at the end of a block list, both parent block-lists and child block lists you'd see plusses everywhere: inside lists (where list items are nested blocks), inside blockquotes (where paragraphs or other quoted content are nested blocks).

If we were to start auto-hiding it to follow the select to edit principle, not only would the obviousness disappear, but you'd still only be able to use it to insert blocks at the end of a list, whereas the sibling inserter or the side inserter both let you insert between blocks, hence making it just another reduntant way of inserting.

It's worth mentioning also that this UI is not yet released in the plugin, so it's very early to note that the UI isn't working yet.

[carlhancock]

@jasmussen I appreciate the detailed response.

Definitely never take anything I say as criticism or hating on Gutenberg just to hate on Gutenberg. I want to contribute where I can with feedback to try and make Gutenberg as good as it can be which is why I follow the development very closely, test builds even before they are released, and why we have multiple members of our team directly contributing (and with merges to their name) to the project.

I'll see how these UI changes in particular unfold. So far testing the previous version side by side with this version I just get the feeling that the insert block UI is going to be more obvious to users when a permanent trailing insert block UI appears at the bottom.

I would strongly suggest doing user testing with the two versions (with no trailing block inserter at the bottom and with a trailing block inserter at the bottom) to see what end users think. Ultimately that is what will be the best indicator of which direction to go in. How easy it is to use. Gutenberg is already going to be a big shakeup to the status quo for users so there more obvious things are the better.

[jasmussen]

Absolutely, and the discussion here has already inspired various improvements to the process of in-canvas insertion, so I'd like to make and share some mockups as soon as I can, that take learnings from both experiments and this discussion.

The ultimate goal is to make it easy and obvious to insert blocks in context of where you're working, but without encumbering the writing flow. It's super difficult, but with every iteration we learn something.