search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10k stars 4.02k forks source link

Phase 3: Collaboration > Media Library #55238

Open ramonjd opened 9 months ago

ramonjd commented 9 months ago

Tasks that are a part of the Phase 3 Media Library work described here.

Design

Media

Scope

i1

i2

Completed

Related reading

antpb commented 8 months ago

Hello! in a recent Media component meeting we decided to start flagging trac tickets with phase-3-media-triage so we can in a future meeting discuss the impact of the Media Library revamp relative to the flagged issues. We see a lot of opportunity in this initiative to solve longstanding Media issues that have been held back by either backbone of the overall data structure of media items.

One that I was just reviewing for instance: 42751 gives us a really good indicator of plugins that are extending the current media library frames. We could check for anyone deregistering the mediaelement css.

More to come as we parse through trac. Just wanted to share our efforts to help align our component focus with this initiative. Please feel free to join any future Media component meetings ( Every Wednesday at 15:00 UTC ) we'd be very open to changing or alternating the time if the current one isn't good for anyone working on the project.

Flipback8 commented 5 months ago

Allow us to organize media in Folders which we can also color code and bake the functionality of these two plugins into WordPress Core. https://wordpress.org/plugins/enable-media-replace/ https://wordpress.org/plugins/post-types-order/

Also add an option to download all media.

Competing products: Happy Files:https://happyfiles.io/

FileBird:https://codecanyon.net/item/media-folders-manager-for-wordpress/21715379

Take inspiration from Eagle Application for some great media filtering ideas: https://en.eagle.cool/

shoelaced commented 4 months ago

Would love to have the ability to control responsive image cropping. Here's a great example of why: https://youtu.be/fp9eVtkQ4EA?si=3ApM7CS569t0iQqB&t=614

Basically: Please bring back the thumbnail editor and further allow isolated edits to all of the other image sizes.

jameskoster commented 3 months ago

I updated the designs in the OP based on the latest data view work. We should decide:

noisysocks commented 1 month ago

Sat down with @andrewserong, @ramonjd, and @tellthemachines and had a go at scoping this into actionable tasks. I've updated the description.

@jameskoster – do you have a design for the details view?

youknowriad commented 1 month ago

Use https://github.com/WordPress/gutenberg/issues/55083 to implement Media screen in site editor.

@noisysocks I think we shouldn't be overloading the site editor with media screen (same for posts), we want to instead try to replace to "Media" menu item top level in WP-Admin with a site editor like experience.

I know it's harder but if we add media, posts... to the site editor, the site editor won't make sense anymore under appearance and we should ideally keep its scope about "design/appearance".

Granted that "pages" is misplaced with this logic but I believe it should ideally move as well and both "Media" and "Posts" constitute good opportunities to start exploring this.

noisysocks commented 1 month ago

@youknowriad Yeah true, this is probably an opportune time to start moving things out.

noisysocks commented 1 month ago

Thinking out loud. The problem with replacing WP Admin → Media is that it means we need a level of feature parity before making the switch. I'd like to ship this functionality iteratively if possible so that we're getting continuous feedback.

Maybe an option is to have the Media library button open the new DataViews media library in a modal, or something. That way it gets testing and we can build confidence in it.

Screenshot 2024-05-17 at 14 22 20
youknowriad commented 1 month ago

I think we should just start as an experiment to enable, and once we reach close to feature parity, remove the flag.

fabiankaegy commented 1 month ago

I know priority wise this is going to be one of the last pieces. But a very common thing we do today in the media library / media library modal is extend the available field for a given piece of media to store additional image metadata to post meta. Things like image credit come up very often etc.

noisysocks commented 1 month ago

Yes good point we'll need to support custom fields. Are they added via attachment_fields_to_edit? I'm not sure how it works. edit: yep, here's a good reference. Fortunately it looks a lot more structured than post custom fields which were a nightmare to support in the block editor...

jameskoster commented 1 month ago

do you have a design for the details view?

Do you mean the Inspector panel? If we follow the principles outlined in https://github.com/WordPress/gutenberg/issues/59689 then we end up with something like this:

media details
youknowriad commented 1 month ago

Another thing I wanted to mention here, is that it's important to stop creating custom components for all these "inspectors" and instead start exploring a more systemic approach like outlined here https://github.com/WordPress/gutenberg/issues/59745

noisysocks commented 1 month ago

Do you mean the Inspector panel? If we follow the principles outlined in #59689 then we end up with something like this:

Sorry, I meant the page that appears when you click on an image. It looks like this in the current media library:

Screenshot 2024-05-20 at 09 31 40
jameskoster commented 1 month ago

Ah yes. I don't think this is 100% concrete so I would welcome feedback, but my expectation is that you'd be taken to an Editor instance with image editing tools, something like:

Image editor

The actual flows for cropping and scaling would need some design exploration.

Other media; audio, archives, sheets, probably may not need a dedicated editor with these tools. Such files would be modified via Inspector:

audio
mrkdevelopment commented 1 month ago

I think splitting the side bar a bit would make sense.

  1. Title, Descriptions, alt and caption are all text base information. These could be one popover for editing (and would be easy in that cause to add to for AI description generation).

  2. Attached, comments, category and tag are related fields. Again, could be one popover for all values.

  3. File fields (size, format, dimensions, filename) these are all generally not edited.

The reason I like a single popover is it will save clicks. When you edit a title, alt text and description - opening and closing multiple popovers would be a pain and takes a lot more time.

Ideally the side bar would be big enough to have tabs and you would not even need to open a popover.

noisysocks commented 1 month ago

Thanks @jameskoster. Should be enough to start getting the rough shape of this built behind an experimental flag 👍

mtias commented 2 weeks ago

I really think the details panel should be a separate tile, like the side by side view we have for the preview. This is also what we had been discussing for "quick edits" replacement.

jameskoster commented 2 weeks ago

A separate tile makes sense. Theoretically this enables the Details panel to be invoked from the side-by-side view as well.

Media

It could also be worth exploring greater structural alignment between data views / full-screen editor.

rmorse commented 1 week ago

Is there a discussion somewhere where it was decided that all the new UI coming to the project (which looks great btw) would be dropping support for a persistent wp-admin sidebar?

I find it frustrating to have to click that back arrow, then again on the WP/site icon, and wait for the page reload, just to load the admin sidebar UI so I can navigate around.

jameskoster commented 6 days ago

@rmorse you may be interested in this post, which touches on navigation (and personalisation thereof). I agree that a critical detail to get right in the design is facilitating quick-access to the top-level of navigation.