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

Embed Block: How to select the block without starting video #483

Closed
jasmussen opened this issue Apr 24, 2017 · 15 comments
Closed

Embed Block: How to select the block without starting video #483

jasmussen opened this issue Apr 24, 2017 · 15 comments
Labels
[Feature] Blocks Overall functionality of blocks Needs Design Feedback Needs general design feedback. [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Regression Related to a regression in the latest release
Milestone

Comments

@jasmussen
Copy link
Contributor

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

@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 😄 )

@jasmussen
Copy link
Contributor Author

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.

@ellatrix
Copy link
Member

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

@jasmussen
Copy link
Contributor Author

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.

@rileybrook
Copy link

rileybrook commented Apr 26, 2017

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.

@jasmussen
Copy link
Contributor Author

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

@notnownikki
Copy link
Member

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.

👍 from me!

@mtias
Copy link
Member

mtias commented Feb 6, 2018

@jasmussen do we still want to do this?

@jasmussen
Copy link
Contributor Author

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.

@jeffpaul jeffpaul modified the milestones: Bonus Features, Future Feb 8, 2018
@jeffpaul jeffpaul added the [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later label Feb 8, 2018
@aduth
Copy link
Member

aduth commented Feb 27, 2018

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).

@notnownikki
Copy link
Member

notnownikki commented Feb 27, 2018

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.

@aduth
Copy link
Member

aduth commented Apr 13, 2018

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

@karmatosed
Copy link
Member

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.

@jasmussen
Copy link
Contributor Author

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.

@youknowriad
Copy link
Contributor

closed by #12981

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks Needs Design Feedback Needs general design feedback. [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Regression Related to a regression in the latest release
Projects
None yet
Development

No branches or pull requests

10 participants