Phase 3: Collaboration > Media Library

[ramonjd]

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

Design

Scope

i1

• Use DataViews to implement Media screen in site editor. Allow searching/filtering by:
  • Author
  • Upload date
  • File size
  • Media type (image, audio, pdf, etc.)
  • Attached/unattached.
• Media details view, potentially using DataView Forms.
• Uploading via Add media button and drag and drop.
• Deletion.
• Custom fields.
• Image editing. (Reuse block editor components.)

i2

• Categories and tags support. Some investigation took place in Site editor: 🥝 Media library proof of concept 🥝  #53788.

Completed

• List View: Add media previews to list view for gallery and image blocks #53381

Related reading

• Media Library - Make WordPress Core post
• Site editor: 🥝 Media library proof of concept 🥝  #53788
• DataForm component #59745
• Tracking: Client-side media processing #61447
• Media workflows around patterns #58172
• DataViews for Posts, Categories and Tags #62371

[antpb]

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]

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]

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]

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

• Default views (e.g. 'All media', 'Images', 'Video', etc.)
• Default layout (grid or list).
• Primary actions.
• Fields to include (mockups are based on wp-admin, but it might be nice to include things like file size/type).
• Which fields should be visible by default.
• What filters users can enact.
• Default setting for 'per page' view option.

[noisysocks]

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]

Use #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]

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

[noisysocks]

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.

[youknowriad]

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

[fabiankaegy]

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]

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]

do you have a design for the details view?

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

• 'Categories' and 'Tags' are new, and can probably be omitted initially.
• 'Caption' and 'Alt text' can open dialogs similar to editing a post excerpt.
• 'Comments' should link to a filtered view of the Comments table.
• 'Attached to' could open a modal containing something like a searchable listbox. We might reuse the UI you see when creating a template for a specific entity.
• Template panel would be the same as posts pages. This isn't built yet. The current interface would be okay in the interim.

[youknowriad]

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 #59745

[noisysocks]

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:

[jameskoster]

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:

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:

[mrkdevelopment]

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]

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

[mtias]

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]

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

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

[rmorse]

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]

@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]

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.

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]

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: #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.