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

Consider allowing all media to show in the media library regardless of block type #2439

Closed
jasmussen opened this issue Aug 17, 2017 · 6 comments
Labels
[Feature] Blocks Overall functionality of blocks [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later

Comments

@jasmussen
Copy link
Contributor

Got this feedback from a user.

It’s really confusing to not see video files in the media library at all, when I try to insert a video as an image. I get that maybe we’re going to teach people that there are different kinds of media (though I think that might be a bad idea) but I’d rather have had the video files appear in the media library, but just be grayed out? Maybe that’s just me.

This is a solid observation.

We're sort of straddling the line between old and new, by having a flow where the current media modal is used as is. Which means people used to this modal opening from an "Insert Media" button will be surprised to see that it's been limited to just images (if clicked from the Image placeholder button) and videos (if clicked from the Video placeholder button).

In the very long term, the idea is to have the media library sort of live in the placeholder itself, taking the modal out of it. But in the mean time, it seems like a confusion worth addressing. (#2128)

Question: Should we make it so the media library is never filtered for filetypes when you open it from a placeholder, and let the block change type depending on what you insert?

This would essentially make the gallery, video and image placeholder blocks be almost aliases of each other. That is, if you insert an image placeholder block and select a video, it transforms to a video block. Or, if you insert only a single image into a gallery block, it becomes an image block.

This would also tie into the ticket @mkaz opened about dragging an image onto another image to create a gallery (can't find the ticket).

@jasmussen jasmussen added [Feature] Blocks Overall functionality of blocks Design [Type] Question Questions about the design or development of the editor. labels Aug 17, 2017
@paaljoachim
Copy link
Contributor

paaljoachim commented Aug 17, 2017

I think that is a very good idea Joen!
When the user inserts media one must not force the user to select the correct block but instead have the blocks so flexible to notice what the user wants and change depending on the selection they make.

@anna-harrison
Copy link

I think this makes a lot of sense. A possibly nice side effect is that it would allow us to collapse a lot of different media-type-blocks into one (i.e. why have image and video and ...). Why not just have paste link/insert media?

@jasmussen
Copy link
Contributor Author

jasmussen commented Aug 21, 2017

A possibly nice side effect is that it would allow us to collapse a lot of different media-type-blocks into one (i.e. why have image and video and ...).

We could theoretically combine the blocks into a "Media" block, and ensure the media block had search keywords for video, gallery and image. But I suspect it would still be better to have alias blocks for each, even if the block is the same under the hood.

Part of the idea is that every block can have a placeholder state. This will be used for template building in the future. You could end up building an entire post or page layout using just placeholders, which the user could then "fill out like a form"; image here, video there, gallery here, and suddenly they'd have the same layout they saw on the theme demo page.

Why not just have paste link/insert media?

Directly related to above, we are levelling the playing field for blocks and providing a unified interface so you only have a single interface to learn, and then you know how to do everything. In this case you only have to learn how thoe inserter works, and then you know how to insert not just images, videos and galleries, but every other block we offer.

As it exists right now, I do realize it is sub-optimal: insert image block, click button on placeholder, pick image in media modal, press done.

This is one more click than the previosu flow: click add media button, pick image in media modal, press done.

However it is this way because we can't rewrite the media modal in the scope of Gutenberg. A future enhancement to the media flow should be to not have a modal at all: insert image block and see available images directly in placeholder, pick image, done. This would be the same amount of clicks, but let us have the benefits of the placeholders and the unified inserter interface.

@hedgefield
Copy link

Good points. I think either flow would have its merits, but maybe the best way is a combination of the two - when you insert an image block and open the media library, it pre-filters images (either by removing other media or indeed graying it out), but you always have the option to clear the filter if you feel like video or audio would fit better, and selecting those would transform the block accordingly.

Applications like Photoshop etc also limit the types of files you can import in a certain context, but they always offer the possibility to show all file types if you're convinced you need something else. But they can't do on-the-fly context transformations like we can with blocks though! So that's a cool opportunity.

To make it as flexible as it sounds though, it needs to be really fool-proof. When you edit an image block and select a video instead, the image must be discarded, as well as any settings related to an image block that might have been customized. What happens to a gallery when you edit it and select a video? Does it discard the images? Is a mixed-media gallery possible? I think the flexibility would be a big win, as long as the spec is solid.

@jeffpaul
Copy link
Member

This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs.

@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 22, 2018
@jeffpaul jeffpaul added this to the Bonus Features milestone Feb 22, 2018
@jasmussen jasmussen removed the [Type] Question Questions about the design or development of the editor. label Apr 2, 2018
@jasmussen
Copy link
Contributor Author

As a bit of repository management, I'm going to close this ticket and file it in the "Ideas" project so we can revisit this in the future: https://github.com/WordPress/gutenberg/projects/8

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 [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later
Projects
None yet
Development

No branches or pull requests

5 participants