Gutenberg: Embed Block: How to select the block without starting video

Created on 24 Apr 2017  Â·  15Comments  Â·  Source: WordPress/gutenberg

The Embed block (#316) appears to work well up until a video is actually embedded, at which point it looks as though clicking the block will start it playing. Even though that won't be the case (we should port the click interceptor that's in WordPress now), the UI observation still stands.

What's a good approach to make this interface less obtuse, so we don't frighten users from clicking the block? Let's discuss. Some ideas:

  • Abstract live preview for the block — don't show 1:1 what it will look like, perhaps include a generic border with meta information
  • Add a clickable UI fixture permanently docked near the embed
  • Add a clickable UI fixture that shows up on hover
Needs Design Feedback [Feature] Blocks [Priority] Low [Type] Regression

Most helpful comment

That's solid work @rileybrook, and aside from a few stylistic tweaks, pretty much exactly what I meant.

Inspired by Riley I took it a step further:

embed

All 15 comments

@iseulde brought up an excellent point about fixtures that show up on hover - how do we handle that on mobile? This is especially important as it's on mobile that users are least likely to click a video because they expect youtube apps to pop up and to be charged for data used playing the video.

My preference would be for the abstract preview, perhaps with an option to toggle and see the "live" content? (but I'm not a designer, just a pretty good new-user-simulator :smile: )

My preference would be for the abstract preview, perhaps with an option to toggle and see the "live" content? (but I'm not a designer, just a pretty good new-user-simulator 😄 )

I lean towards this as well. It's a stellar argument for why abstract live preview has benefits, over 1:1 100% live preview.

What would an "abstract preview" look like? How to make it?

By "abstract live preview" I mean a block design that clearly indicates that this is a video that's embedded, and it suggests what the end result will look like, without being a 100% 1:1 preview.

Take the [gallery] block in the current editor, that's an abstract preview. It's arguably _too_ abstract, but it's the same vein as what I mean.

If I understand @jasmussen correctly:

a block design that clearly indicates that this is a video that's embedded, and it suggests what the end result will look like, without being a 100% 1:1 preview.

A solution could be something like the following:
embed
Another alternative could be:
embed 1

A UI element that appears with or without hovering - for mobile users it indicates itself as a block that can be moved around without worry of playing the video. Just brainstorming ideas, please let me know if I am off-base here, as I could be misunderstanding the problem.

That's solid work @rileybrook, and aside from a few stylistic tweaks, pretty much exactly what I meant.

Inspired by Riley I took it a step further:

embed

Wow, fading out the video and showing the caption placeholder changes the feel of it completely! There's no doubt that I'm in editing mode there.

:+1: from me!

@jasmussen do we still want to do this?

do we still want to do this?

This is not a feature that has to be part of the shipping version, but it's definitely something that would enhance the experience. I struggle with selecting embedded videos every time.

This is also related to selection of embeds generally, not just videos. Notably, selecting any embed block (say, a Twitter block) recently regressed to not being possible in #4872 (previously fixed in #4011).

The idea of showing an overlay could work just as well for non-video in helping to make the blocks selectable. Open questions are:

  • Would it have the same background color?
  • Would it include the label for embed type? (Twitter is "rich")

Alternatively, we can restore the intended behaviors of #4011, but this would require reintroducing a prop for blocks to programmatically call to select themselves (e.g. setSelected).

Would it include the label for embed type? (Twitter is "rich")

I'd say it should be the ~name~ title of the block instead of the type. There are cases where oembed is overridden and we don't get type information at all, so how we handle type information in the embed blocks is going to change at some point (I'm working on this now). To make this properly useful, we'd need to switch to the right block based on the URL, and I'm working on that too.

Embed blocks can now be easily selected again as of #5730.

The embed block seems to now work without the video playing. I just tested this using a YouTube video. I am closing, if this is not fixed we can always reopen.

Reopening this issue as the problem is present again, and being worked on in #12981. This ticket has a lot of discussion, including mockups, so it's worth resurfacing these to keep things collected.

closed by #12981

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ellatrix picture ellatrix  Â·  3Comments

BE-Webdesign picture BE-Webdesign  Â·  3Comments

wpalchemist picture wpalchemist  Â·  3Comments

nylen picture nylen  Â·  3Comments

maddisondesigns picture maddisondesigns  Â·  3Comments