search

WordPress / gutenberg

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

Phase 3: Collaboration > Media Library #55238

Open ramonjd opened 1 year ago

ramonjd commented 1 year 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 1 year 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 9 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 9 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 8 months ago

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

noisysocks commented 6 months 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 6 months 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 6 months ago

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

noisysocks commented 6 months 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 6 months 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 6 months 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 6 months 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 6 months 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 6 months 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 6 months 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 6 months 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 6 months 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 6 months ago

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

mtias commented 5 months 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 5 months 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 5 months 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 4 months 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.

james-tyner commented 4 months ago

Hello @jameskoster! I appreciate the level of care you're putting into this process.

My primary experience with CMSes is at large news publishers, and I've heard complaints from many photo editors over time. I have some thoughts/questions re: how to ensure the Media Library experience is fast and intuitive for people who spend all day in it.

First: Are there plans to support both a list view and a grid/thumbnail view for assets in the Media Library? Looking at the mockups above, I'm not sure where I would find the toggle to switch between those. (To be fair, I'm not well-versed in the new/upcoming WordPress design system…)

The two views would support different types of users. In a large newsroom, users who are trying to identify the best image to add to an article would likely seek it out using the thumbnail view, while photo editors who are working with photo metadata might prefer the list view if it reveals more metadata without clicking. So it would be good for users to be able to choose one of the two views and have that choice persist over time.

Second: I agree with @mrkdevelopment that minimizing the number of clicks required to edit the key metadata is really important, especially for people who spend all day working with those fields. I'd like to add that it would also be valuable for those fields to be more readily scannable, and it seems like the current designs only make visible, at most, a few dozen characters before clicking.

image

I wonder if the visible text can be expanded a bit more without disrupting the layout, and I'm curious to know what we could expect the UI to look like once a user clicks on one of those fields. I'd especially advocate for the entire caption, description, or alt text to be made visible at once upon clicking, rather than requiring additional scrolling to read — I know the scrolling and/or dragging required to read longer captions in the currently live Media Library design is frustrating for photo editors.

Captions and descriptions are sometimes written to include additional information for internal purposes, so it's important that the entire text of those fields is easy to access.

Third: As @fabiankaegy noted, it's common to add custom fields to these media items. If we end up grouping fields together in different media views, it would be valuable for developers to be able to specify where those custom fields should appear/not appear so they're grouped and ordered logically with each other and with the core fields. (This may be something that's easy to do already that I'm not familiar with)

Thank you for all your work on this 🙏

jameskoster commented 4 months ago

Are there plans to support both a list view and a grid/thumbnail view for assets in the Media Library?

Absolutely. To your point about where to find those controls, a change was recently merged to make this more obvious: https://github.com/WordPress/gutenberg/pull/63205

I wonder if the visible text can be expanded a bit more without disrupting the layout

For now the plan is to follow the design patterns as implemented in the Inspector component. So to view a value you'd have to click it to open the associated popover. These details can change though, and may need to as this UI proliferates out of the full-screen editor context.