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

Add Tabbed Interface to Insertion Block #81

Closed
timmyc opened this issue Feb 16, 2017 · 11 comments
Closed

Add Tabbed Interface to Insertion Block #81

timmyc opened this issue Feb 16, 2017 · 11 comments
Labels
[Type] Enhancement A suggestion for improvement. [Type] Task Issues or PRs that have been broken down into an individual action to take

Comments

@timmyc
Copy link
Contributor

timmyc commented Feb 16, 2017

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

insert_-_cloudup

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.

@timmyc timmyc added the [Type] Enhancement A suggestion for improvement. label Feb 16, 2017
@timmyc timmyc added [Type] Task Issues or PRs that have been broken down into an individual action to take UI Prototype and removed [Type] Enhancement A suggestion for improvement. labels Feb 17, 2017
@jasmussen
Copy link
Contributor

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

mtias commented Feb 17, 2017

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

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

mtias commented Feb 17, 2017

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

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

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

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

aduth commented Feb 20, 2017

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

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

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

Closing this in favor of #34

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Enhancement A suggestion for improvement. [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

No branches or pull requests

5 participants