Split Embed inserter into categories #2120
Comments
|
Having multiple categories to me feels like we are adding UI complexity where there doesn't need to be any. What about going down to a single "embed" and then if there needs to be options for that specific embed type, they get inferred from the embedded content URL? |
|
@melchoyce Having the repetition increases the amount of work needed here significantly, it would require that blocks can belong to multiple categories, which isn't supported at all at the moment, and needs a lot of work on the tabbing code too. Is that something we can live without for now, or should I start that work? |
|
@aaronjorbin Discussed at length here: I still think single embed would be a more intuitive approach :) |
|
@notnownikki In that case, we can do without the repetition. |
|
Going through these... we should remember that Cloudup can embed both video and images, so the code to support repetition will need to be done at some point, if we go with this approach in the end. |
|
Testable in #2123 - comments welcome! |
|
This is probably one of the things that should see some serious user testing. Maybe one of the most common complaint from users I've read around so far is "way too many embed blocks". |
|
So I'm looking at #2123, and it's still so... busy. The more I use it, the more, I'd like to see a UI like the one wireframed here: #1325 (comment) But, with a few tweaks. So, the user would start by going to the inserter, and embed blocks would be in their own category on the blocks tab. But, we don't have a block per embed, we have a block per media type. "Embed Video", "Embed Audio", "Embed Social Media", "Embed...." etc. When the user selects one, they get the url entry UI, with a list of what video/audio/social sites we support. That would cut down on the amount of embed blocks, and still allow users to discover what we support. Sound like it's worth a wireframe and experiment branch? |
|
Can you move all embeds to inline, as some kind of select with autocomplete. As Posts list under Link. To reduce confusion and errors you can show embeds list directly when User insert block, on default. With few of them most used visible. |
|
Two thoughts:
|
|
There are 35 embed blocks. I am afraid it wont work as it is now. Bloggers do use embeds often. Serious small or bigger companies, almost never. |
|
I've pushed up a branch demonstrating what I mean, having an embed block per media type. You choose if you're embedding video, audio, documents, etc. and then you get prompted for the url, with a list of places that we support embedding from. Seems cleaner to me. Branch is at #2125 if you want to see how it looks. |
|
Oh, #2125 also gets rid of the embed tab, because it drastically reduces the number of embed blocks, they can fit in with the rest of the blocks. |
|
Gif showing #2125 in action:
|
|
How would you handle how each service offers up embed code using this model? For example if I want to embed a YouTube video or Facebook status, I am presented with code using What about keeping it as is, but maybe only showing the bigger services (e.g. Facebook, Twitter, Instagram, etc.) and a link at the bottom that takes the user to the Admin panel (if they have that capability) and allow them to turn on some of these others and turn off the ones they don't use? |
|
Same flow from #1325, I think.
|
|
@nic-bertino yeah, all it changes is having an embed block per media type, to get the user clicking them, and once they have, they see the list of all the places we can embed from. I'm concerned that a single embed block might not be obvious, but I think that showing the media types we can embed is enough to get them clicking, and keeps the amount of embed blocks in the menu down to a minimum. After using it for the past day, I think it's definitely a better user experience than having a block per site and categorized. I've marked both PRs as needing design feedback. |
|
A block per media type seems like it adds a layer of abstraction that could be confusing (should I pick "social media" for Twitter?). I suggested before just showing the most common ones, and making the rest invisible unless you search, or unless you paste a url for that resource. |
|
Hiding them unless you search or paste a url doesn't help us with discoverability. As I said before, if I want to embed something from kickstarter, and i see the embed blocks listed and there's no kickstarter, I'll think that I can't embed things from kickstarter. It's mystery meat all over again. |
|
Perhaps we do just need a single block, "Embed external content" (or something along those lines) and have the list of supported sites listed on the edit UI. |
|
Either that, or display the most common, and have a button to display the rest. |
|
@notnownikki Along those lines, search could be primed to highlight the embed option if you search for "Kickstarter" (or the other terms). That might help with discovery at the inserter level. |
|
@nic-bertino for a single embed block, that might help. The thing is, you might get a percentage of people use search to try and fine blocks that don't appear in the list, but who here has tried to find a block that doesn't appear? Here's an example: we're missing a lot of widgets right now. We only have one entry in widgets. Who here actually searched to see if any other widgets existed? Or did you see the list and think, "Oh, there's only one widget." We can't rely on search for embed discovery. We certainly can't rely on people pasting urls and hoping that they work, because that's exactly the problem we're solving - people don't know what urls will work. We have to have some way of telling the user "If you want to embed stuff from other sites, click here. Now you've clicked it, these are the sites we can embed stuff from," without them having to guess or hope a search returns things that aren't listed. |
|
Now i realise I've just described the current embed block tab, with 35 options listed. And it's too noisy. So, this is why I think the media type embed blocks are a compromise. They get the user into the edit UI where we can list things in a less noisy way. From that UI, we can say "Can't see the site you want to use? Click here for the full list!" You know, if they want to embed a tweet, they're going to click social media. We can list twitter on that edit ui. if they want to embed a video from twitter, and they click the video embed block, well we CAN embed videos from twitter, so we can list twitter there too! |
|
finally in this rant's series ( 😉 ) it solves the Cloudup problem. You can embed video and photos from Cloudup. If you click "Embed video" we'd list cloudup. If you click "Embed image" we'd list cloudup. |
|
Lots of good discussion here, and great initial ticket. Thanks Mel. There are many ways to solve the "too many embed blocks" problem. We've tried a few of them, including a separate tab. Categories is another, though perhaps we should just have two categories, "Common Embeds" and "All" (or a better label). I think this is probably the first thing we should try, just two categories in the embed tab. This makes us arbiters to what is "common" and what isn't though, and I'm not sure that's a great place to be. I would suspect we end up with a pretty western leaning set of defaults, which feels uncool. On a meta level, it seems a bit unfair to leverage this as a critique specifically on Gutenberg. These features are already in WordPress, we are simply surfacing them, like the back of a fence. Our goal is to make it easy for you to discover what you can embed in WordPress, and to make sure you never have to paste a URL and hope it works. This is the problem we are trying to solve. But actually removing embed block aliases, I strongly feel, should be a last resort. Fixing the "mystery meat embed discovery" is an explicit kickoff goal. It is part of the vision of Gutenberg, that you should only have to learn a single interface, the block interface, and know how to do everything. By removing blocks even though "they are there", we are watering that down. And so before we do this, we should consider everything else we can, to make sure the inserter is scalable, including the ability for a user (or plugin) to hide blocks manually. |
|
I don't see the "common" designation being something arbitrary though or anything WP imposes. It can be by sheer usage world-wide. It could be by sheer usage by locality if it could somehow be linked to the installation language (e.g. Eng-US gets the top 5 SMNs in the US while French gets the top 5 in France and Japanese gets the top 5 in Japan and so forth). I still really like the idea of giving the user the option, be it in the admin back-end or a UI option in the Gutenberg screen itself that allows them to turn on/off embed blocks. While the list is manageable now, there are some on there I haven't heard of on there and others that I will probably never use. They just clutter up the list for me. Also, since people seem to sneeze and create a new social app and there will be developers adding more (I assume there are hooks for plugins to add embeds) that list has the potential to get real big, real quick. |
|
What if we user tested a couple versions to see which works best? Version 1: Current FWIW, I think for Generic embeds, the video embed should show up when you search for a supported video product like YouTube, the audio embed should show up if you search SoundCloud, etc. |
|
Does anyone know which service requires/prefers a copy/paste of code for embeds? Testing something like embedding tweets is relatively straightforward, but we should write a task to test those more complex embeds. |
|
@nic-bertino These are all the site with oEmbed supported by core: https://codex.wordpress.org/Embeds#Okay.2C_So_What_Sites_Can_I_Embed_From.3F Anything outside of that list, you'd need an actual embed code with an iframe and whatnot, instead of just an URL that turns into an embed. |
|
Do the current embeds just grab code from the source cite and return the |
No, the current system uses the oEmbed system to embed content. The list that Mel provided above describes every single service that is hardcoded into WordPress as being an acceptable embed that will work out of the box. If a service is not on that list, pasting a URL from that site won't do anything, it will just show the URL. |
|
First thing first to say. Do not get over excited about all this. If you dont have ideas how to make it better leave it as it is now, and move on other tasks. |
|
What does everyone feel about this now? Personally I still feel some categorisation would be good to look at getting in. |
Thinking:
Common
Audio
Video
Social Media
Images
Blogs and Documents
There is some repetition, which I think is okay, to help folks find the embeds they want? I also may have missed some.
The text was updated successfully, but these errors were encountered: