Gutenberg: Add Block: More

[mtias]

We need to implement a more-tag block, the one that gives the ability of splitting a post with a "read more..." link.

This already exists as a comment in WordPress, it'd be good to adapt our parsing to recognize it without extra comments. We also need a good visual design for it.

[ellatrix]

Note that this comment can currently be anywhere in the content, not necessarily at the top level. Not that this needs to be possible with the block editor, just making this note for old content.

[jwold]

Just took a stab at what the UI could look like. Would love any feedback/suggestions!

1. What would we call the section? I've just added a placeholder called "thing".
2. When you click the read more button I'm imagining a new block appearing, which can then be moved up or down as needed.

[jasmussen]

Very slick. Love it, thank you @jwold.

If we are able to add some recency to the inserter ( #888 ), which seems increasingly important as 30+ blocks are incoming with the embed aliases, the category becomes slightly less important. However it feels like a layout block to me, as it affects the front-end layout rendering. What do you think?

[jwold]

Thanks @jasmussen! I wanted to followup on your question above:

1. 30+ blocks - where is the best place for me to see what these will be?
2. What if we only show popular + search, and then have a button to expand and show all?

[jasmussen]

30+ blocks - where is the best place for me to see what these will be?

Very soon, "embed aliases" will be merged into master, which means if you check out and build the plugin (or wait another week and get it from the plugin repo, fingers crossed), you'll see a whole bunch of blocks. Every oembed supported in WordPress gets its own block. Even if it's a thin veneer.

What if we only show popular + search, and then have a button to expand and show all?

Yep, this is the type of enhancement stuff that makes sense to think about. The idea I had initially was to mimic the emoji inserter pattern, with tabs. The idea being that it's important that _search_ can find the block you need.

[jwold]

(or wait another week and get it from the plugin repo, fingers crossed)

I think I'll have to just wait. Looking forward to it! My background is more frontend. By chance is there a screenshot that could be shared?

The idea I had initially was to mimic the emoji inserter pattern, with tabs

I like that idea. Did you end up wireframing it? Would love to play a bit with it.

[aduth]

The embeds alias pull request was merged earlier today, and can be seen on this demo site:

https://testgutenberg.wpkonsulterna.se/wp-admin/admin.php?page=gutenberg

[jasmussen]

You might need to click the login link in the homepage: https://testgutenberg.wpkonsulterna.se/

I like that idea. Did you end up wireframing it? Would love to play a bit with it.

There's a screenshot in this ticket which we closed. But the concept can be revisited: #81

[jwold]

@jasmussen and @aduth thanks! That link was helpful.

Here is a prototype I've been playing with (hotspots should appear when you click around): https://invis.io/DMC2YHNG5#/238003019_Recent

1. While I like the visual simplicity of just having icons, I'm worried that they could just cause confusion. I'd recommend no icons at all, or icons + text. Thoughts?

2. To make up for the extra room the text takes up, we could have a sliding tab menu, as indicated in the prototype.

[jasmussen]

I dig that quite a lot, @jwold. I'm on board with that. Though it'd be nice if we could start with only a few tabs so that we don't require any overflow magic yet. Then one day when it becomes pressing with more tabs, we can look into an overflow mechanism for the tabs.

[jwold]

@jasmussen good point! Let's keep it simpler. I've made some changes to how blocks are labeled, shortening some of the labels and combining two of them. This allows us to fit all of them into the tab interface at the bottom without an overflow section, and without being required to only use icons.

Any suggestions/feedback? (note that all the buttons at the bottom are clickable, including search)

Link: https://xd.adobe.com/view/709eff9d-2c54-495b-8c42-fb01f9585385/

[jasmussen]

Sorry for the belated response, been to Paris for a meetup, it's been intense. Prototype and design is solid! Thanks for doing that @jwold!

It seems as if the tabs at the bottom function as "bookmarks" for scroll anchors now, essentially duplicating the categories.

Would it make sense to approach it as separate things? I.e. we have, say, 3 tabs at the bottom:

• Recent
• Text & Media
• Widgets
• Embeds

Yes, we might want to make the inserter a bit wider to accommodate these.

Each tab is its own screen, showing only blocks in that are in said tab. Under each tab, we can then have sub-headings. For example, _Text & Media_ might have these subheadings:

• Formatting
• Images & Galleries

We might even want to start with just two tabs, "Blocks" and "Embeds", and then expand when we see a need to?

[jwold]

@jasmussen no worries, it’s always a bit crazy around WordCamp time!

1. Switching from long scroll to true tabs - I like this approach better. Just doing a long scroll can be a bit confusing and cause disorientation. Making the buttons at the bottom a true tab based menu seems to make more sense in this context.

2. Number of tabs - I went back and forth a bit between one button or four. I agree, let’s stick with just Blocks and Embeds for now with the appropriate subheadings.

3. New prototype - Here is the updated prototype, happy to make additional tweaks as needed! https://xd.adobe.com/view/aa0b015c-17a3-4874-a534-d4d0755b73fa/ (the 3 tabs, the search text, and the x on the search screen are clickable)

4. Placement of menu - Should the menu be at the top or bottom? I’ll leave it at the bottom for now, but it might make sense to move it. If we did move it to the top, it could allow some more flexibility with the tabbed UI look. Like this: https://dribbble.com/shots/690799-Kareer-me-Mobile-App-Preview or https://dribbble.com/shots/598146-RemixJobs-new-Activity-tab-UI-design.

5. Headings/subheading - If a section only has one subheading, should it just be the same as the heading? (I’ve done that in the current prototype).

6. Subheadings overall - Do you have any suggestions for any of the subheadings?

[jasmussen]

Solid thoughts, solid prototype. I think that's basically what we should use as the target mockup for now.

Placement of menu - Should the menu be at the top or bottom? I’ll leave it at the bottom for now, but it might make sense to move it. If we did move it to the top, it could allow some more flexibility with the tabbed UI look.

It has to be able to do both. When you click the inserter from the Editor Bar at the top, it has to open downwards, and if you clik the inserter from the one at the bottom of the block list it opens upwards (unless you're at the start of the document).

In both cases, the search box needs to be close to the inserter button, so that we can set focus there in an accessible way. Here's what I'd imagine, very quick and dirty:

I phrased the headings/subheadings badly. I meant only one level, so I should've said headings. What I meant to say was that since we're using a gray material for the tabs, we should probably remove the gray material from the headings. Something like this:

[jwold]

Thanks for the feedback!

1. Agreed that the search box should be closer to the button (regardless of orientation). Good point! This prototype will reflect the opening downwards orientation

2. Good job on the quick and dirty wireframes! :) I’ll update the prototype based on your feedback.

3. Headings - Ah yes, that makes sense. I’ll update that.

(Will post the new prototype shortly)

[jwold]

@jasmussen I believe the prototype is up to date. Let me know if you recommend any further changes.

https://xd.adobe.com/view/57a1eb10-949b-48fe-bc4e-48a2bb587d66/

I like the simplicity of the headers dividing the sections without background colors. Might play with it some more in the future, but for now it's good.

[jasmussen]

Love it. I think it's solid. Thanks so much!

[jasmussen]

Should we open a separate ticket, with your prototype as the mockup?

[nic-bertino]

I think there's a massive amount of cognitive load to scan the amount of embeds as they currently exist, particularly when considering that each embed requires the same input once you've selected it (a URL).

I understand the "mystery meat" embed approach, but I think a simplified approach would go a long way to fulfilling the "effortless" portion of editor focus:

• Insert "embed"
• Paste link
• Autodetect source/styling based on link parameters (and fail elegantly if it isn't supported) and show to the user
• Customize if necessary

I think this is a pattern that is reflected in other services (Facebook comes immediately to mind when pasting links into updates). This approach would alleviate dependency on search as well, or perhaps, change search so that when searching "Vine," the embed block would show.

[swissspidy]

This issue here should be used to talk about a "More" block, so yeah I'd definitely open a new issue for this unrelated topic.

[mtias]

@jasmussen can we get some designs for the block itself here?

[jasmussen]

Sure. So the icon to use is this:

Neutral:

Selected:

Since there are no advanced properties, we can hide the cog.

[mtias]

Is the "more" there just text?

[jasmussen]

Yup. Did you have something else in mind?

[mtias]

No, this seems ok, though maybe a bit obscure. What about using "Read More" which is generally the label that is shown on the front-end?

[jasmussen]

I like "Read More", only reason I went with the above is because it's close to what's in the current editor. Which is not a great design, but I don't have anything better, and at least the existing design is "tried":

☝️ that's from current core editor.

[jasmussen]

Maybe make it full-width, since we can, that'd be nice.

[mtias]

Yes, I'm familiar with the current one, but it sounds like a good chance to improve on it (it's also an image in core as far as I remember).

[jasmussen]

So long as it's an abstract concept implying _the stuff above this separator will show on archives and indexes, what's below shows on the single page_, I don't know that there's a ton we can do. Except full width, as it hit me above. But good point, I'll open the discussion to core editor also 🎉

[swissspidy]

Please note that users currently can add custom text to the more tag. This needs to be supported.

[saracannon]

I think full width would be nice like you said. But I don't think that "_the stuff above this separator will show on archives and indexes, what's below shows on the single page_" every really comes across even in its current implementation. Not quite sure what to do about that other to maybe instead of a cog on the block have an info icon that explains what it is.

[jasmussen]

Updated mockup with full width:

[kopepasah]

Assigning to you @dmsnell, because you seem to be currently developing.

[melchoyce]

Please note that users currently can add custom text to the more tag. This needs to be supported.

Maybe when you click into it, _Read More_ could turn into a placeholder, like the citation in the quote block.

[dmsnell]

Well the parser now supports this but I haven't added the block. Can maybe try next Monday if I don't have higher-priority tasks on Gutenberg then!

In the meantime, this is a good first-commit kind of block

[westonruter]

Note that only one of these blocks should be allowed for a given post. As such, it depends on #1661 to prevent multiple more blocks from being added at a time.

[youknowriad]

1661 has been merged, we could use the useOnce setting here.

[youknowriad]

closed by #1440