Add Tabbed Interface to Insertion Block

[timmyc]

The latest mockup of the Insertion Block shows a series of tabs along the top of the dialog ( Photos, Videos, Audio ):

This task involves building out support for the tabbed interface and possibly adding in some mock images to see how that experience might feel within the constraints of the Insert Block dialog.

[jasmussen]

Here's the latest mockup:

https://github.com/WordPress/gutenberg/blob/5e50c86e0c5c53cd2245e92537e8931cdc0cb317/mockups/Insert.png

This mockup sheds the tabbar at the top for the near future, as we aren't likely to have 50+ blocks from the start. It is likely to return in some form later on, as we start to get more blocks, but the UI itself will likely need iteration per concerns voiced by @melchoyce and @folletto.

Therefore, let's keep this ticket, but let's not make it a priority yet.

[mtias]

@jasmussen would it be good to mock up a few embeds (twitter, youtube, WP post, etc) as individual blocks instead of "embed"? I guess we can have an "embeds" category for all of those and the ones plugins may provide.

[jasmussen]

Yes, that would absolutely be good.

One idea is that we do have a generic embed block, but if you paste a "known block embed" URL into it, like a Twitter URL, the block converts to a Twitter embed block, with the properties such a block might have (like disable media). I'll work on this next.

[mtias]

My main concern is that it perpetuates some of the mystery meat: I don't know before inserting the block and trying the URL I copied whether we support a service. Also, I have no idea if I would try to insert a tweet by using an embed block.

[jasmussen]

My main concern is that it perpetuates some of the mystery meat: I don't know before inserting the block and trying the URL I copied whether we support a service. Also, I have no idea if I would try to insert a tweet by using an embed block.

I should've been more clear. I meant having a generic embed block in addition to individual blocks for Twitter, YouTube, Vimeo etc., even if internally some of them are mostly the same. The key here is that when you invoke the inserter, search for "YouTube", you should get a block that you can insert.

[folletto]

My take on that is:

1. We need to design "external" blocks slightly differently from "internal" blocks. By external I mean blocks that "retrieve data from an external source"
2. Embeds are a prime example of that. So it's good to reach a some point a blueprint for embeds.
3. I expect the only difference being handling the "loading" moment properly (reducing or cancelling entirely the "jumps" that happen on load, and a proper loading state) but there might be more.

And yes to start backward from the actual specific embeds to then the generic concept.

[jasmussen]

To summarize, just to check if we're o the same page or not:

• Oembeds still work. Paste on a newline, press enter, the link converts into a matching/recognized block
• Inserter allows you to search for "Vimeo" to insert a placeholder Vimeo video block. In this block you can paste the Oembed video URL, and it is then expanded
• Inserter, possibly, allows you to insert a generic "Video" block, where you can paste any URL to a video, and a player will be inserted which has some of the same attributes (aspect ratio, autoplay, etc.) that some of the other video blocks have

Does the above sound right?

[aduth]

Inserter, possibly, allows you to insert a generic "Video" block

Would this behave the same as a generic embed block? Thinking at the point that it converts to an embed, we'd want to use the most applicable block type (e.g. Vimeo block if inserted Vimeo URL). This is relevant also because we can't always assume that any oEmbed provider supports the options you'd referred to. maxwidth and maxheight are part of the spec, but even those aren't always properly supported.

Inserter allows you to search for "Vimeo" to insert a placeholder Vimeo video block

Noting from a technical perspective for generic embeds we might have an issue with displaying human-readable labels. For example, only things we know of built-in providers are regular expression patterns and embed endpoint. wp_embed_register_handler accepts an $id argument, but even this is "internal", usually lowercased, and primarily to ensure uniqueness.

We might consider thinking ahead to enhancing these APIs to provide good labels to be shown in the UI.

[jasmussen]

Would this behave the same as a generic embed block? Thinking at the point that it converts to an embed, we'd want to use the most applicable block type (e.g. Vimeo block if inserted Vimeo URL). This is relevant also because we can't always assume that any oEmbed provider supports the options you'd referred to. maxwidth and maxheight are part of the spec, but even those aren't always properly supported.

Not fully thought through, but this is what I was thinking:

• You want to post a video from MyFavoriteTube.com, but can't see a block for it, so you insert a video block, paste the URL, and we wrap a video player around it since it's just a MP4 file.
• You want to post a YouTube video, but insert the Video block instead (maybe you didn't notice the YouTube block). When you paste the YouTube URL into the block, we detect what it is, and automatically convert the block to be a YouTube block.

Sounds like there might be issues converting a block to show the correct label. That's fine — so long as it works. But figured it was worth spelling out what I currently percieve to be the ideal behavior.

Implicit in all that should be that most of the Oembed blocks are basically the same, just with different names/icons, to help discoverability. Aside from that, simply pasting the URL on a new line and pressing enter, should still work as is. In that vein, the newline is becoming our commandline.

[folletto]

Trying to frame this in terms of flows:

1. If a user pastes a URL, the code should be smart enough to detect if there's a specific embed component, or if to use a general oembed one
2. If a user inserts the block first, then that one is used regardless (i.e. they can add a Video one, so it's going to be generic, or they can add a specific one). We simply honor user's choice.

Then, the video block might be iterated to be more clever, thus suggesting a switch if available.

This makes me think that block plugins should declare also an URL schema if they are meant to respond to that, so it's fully automated, in a similar way than iOS does with Universal Links. Is this a correct assumption?

[jasmussen]

Closing this in favor of #34