Problem/Motivation

The mockups used to create the media library (#2796001: [prototype] Create design for a Media Library / #2828538: Produce high fidelity screens based on Media prototype) are about 2 years old. In the meantime a lot has happened. While working on media library issues we sometimes run into the fact that features are missing from the old mockups, or the technical/architectural choices for the media module force us to make changes.

Proposed resolution

It might be time to take a good look at all the designs we have and update/improve the existings mockups and designs.

Remaining tasks

  1. Agree on list of assumptions in #3
  2. Define the user flow and design each step
  3. Finish final design in https://www.figma.com/file/VNkUIvfbcGr9Jmez3iRXJBjb/Media-widget-field.
  4. Agree on designs and create issues to implement each step

User interface changes

  • Media entity reference widget
  • Media library modal

Screenshots

Also see the latest video of the library in action: https://www.drupal.org/files/issues/2019-02-15/media-library-magic-20190...

Media library grid view, shown when the library is opened.
Media library grid view.

Media library table view.
Media library table view.

Media library remote videos.
Media library remote videos.

Media library add form.
Media library add form.

Media library with selected items.
Media library with selected items.

API changes

-

Data model changes

-

Release notes snippet

-

Comments

seanB created an issue. See original summary.

seanb’s picture

The design progress can be viewed in Figma (work in progress!): https://www.figma.com/file/VNkUIvfbcGr9Jmez3iRXJBjb/Media-widget-field

A proof-of-concept was started to make it easier to discuss some of the changes. Dropping the progress so far as a patch, plus a short video to give an impression of what it looks like.

seanb’s picture

The designs and PoC were discussed in the weekly UX meeting on 2018-12-11:
https://www.youtube.com/watch?v=W2rFglOW65Q

We made a list of assumptions while creating the designs. Mostly copied this over from #2834729-100: [META] Roadmap to stabilize Media Library. Feedback on the designs and assumptions is very welcome.

-----------------------

While sprinting on the media library in Barcelona, the team decided to discuss our assumptions regarding the UX and designs, and make them explicit. So here they are, in no particular order:

  • We assume that users have not been trained or instructed on how to use the media library.
  • We assume that most of the time, users want to add media to the library, rather than reuse items from it. So, although we need to support reuse, we can optimize the UI for the adding media use case.
  • We assume that the media library does not have thousands upon thousands of items in it with tons of complex metadata; in that case, we assume users will use a DAM or other tool more powerful than Media Library.
  • When adding media, we assume that users know what media type they are trying to add. So the burden of disambiguation is on the user, not Drupal.
  • We assume that most sites don’t have an excessive number of media types. We are designing for a site with maybe 5-10 distinct media types, each of which has a clear and well-defined function.
  • We assume people don’t mind clicking a button to bring up a modal, in which they can do media stuff. This is necessary due to technical limitations that are pervasive throughout Drupal core.
  • We assume that everything you do in the media library modal affects canonical media items, not individual embeds or references. What happens in the media library “stays in the media library”.
  • Conversely, anything you do to media items that are linked in a field widget, or embedded in formatted text (not in the modal) is affecting that particular reference/embed, not the canonical item. Nothing ever crosses this boundary. In other words, we are assuming that users see the media library as the canonical, absolute place where media items “live” in their Drupal site. If something is deleted from there, it’s gone from everywhere. If something is changed from there, it (or at least its defaults) are changed everywhere. And we are assuming that users see individual references/embeds/usages as part of the “host” entity, rather than as a canonical thing unto itself.
  • We are assuming that people don’t mind making a few more clicks, as long they are always completely entirely clear on what they’re doing. This is consistent with the “don’t make me think” principle. They’re not counting clicks. If they know at a glance where they need to click, they will click. We will strive to keep the number of clicks as low as possible, but we will favor clarity over a low click count.
  • We assume that users want to add captions to media that is embedded in formatted text. So we are assuming that if media items have a caption field, users will want to override it on a per-usage basis. We are also assuming that captions are distinct from alt text and serve a different function, which means users will want to override alt text as well.

Overall, we want to build a terrific media library that offers an excellent out-of-the-box experience for relatively simple use cases. Media management is a very complicated problem space, and it's impossible to build something that will please everyone and work for every situation. Complicated use cases, then, will probably need contrib solutions like Entity Browser, and we're comfortable with that; the points above, then, are what we believe constitutes a "relatively simple" use case, and what we intend to optimize for.

marcvangend’s picture

Good to see your designs and thoughts, thanks for sharing! A couple of questions/remarks came up while looking at the Figma link.

  • Regarding the add-media modal where only a single media type is available (https://www.figma.com/proto/VNkUIvfbcGr9Jmez3iRXJBjb/Media-widget-field?...) : I assume "single media type" means that the media field was configured to accept only media entities of a single type (eg. image). I understand that you have hidden the vertical tabs in that case, since there's no choice to be made. However that also removes the clue for the user that they are looking at the media entities of a single type. If we would add some kind of heading which contains the media type, I guess that could prevent users thinking "It's broken, where are my video's?"
  • Regarding the delete-interface: Should it even be an option to delete media here? When a user is creating content, we must guide users to their goal, not distract them. Deleting media entities is not needed to complete the content creation task. The "delete" link clutters the interface, and may be misinterpreted as "remove these media items from this node" or "clear the selection". Also, the red "delete" link does not make clear it is about the currently selected item, or all selected items on the current tab, or about all selected media entities (in the mockup, a video entity is also selected on another tab). IMHO the delete action does not belong here.
seanb’s picture

Thanks Marc!

If we would add some kind of heading which contains the media type, I guess that could prevent users thinking "It's broken, where are my video's?"

I agree! Good point.

Deleting media entities is not needed to complete the content creation task.

A case was brought up where someone could upload the wrong file by mistake containing sensitive information. In this case it seems quite important to immediately be able to correct that mistake.

For the rest I think you raise valid points and we should make sure we get this right. Deletes are permanent so it is extremely important users instinctively know what it means to delete something here. We should at the very least have a confirmation step where you see all the items you are about to delete stating these will be deleted everywhere in the system, not just the reference in this piece of content.

marcvangend’s picture

A case was brought up where someone could upload the wrong file by mistake containing sensitive information. In this case it seems quite important to immediately be able to correct that mistake.

OK, I see the point. Still I don't think that warrants a delete option the way it is designed now, allowing users to also delete existing media that is already referenced from other content. If it's only about the (edge) case above, I guess the modal where newly added media is edited (https://www.figma.com/proto/VNkUIvfbcGr9Jmez3iRXJBjb/Media-widget-field?...) would be appropriate. If we add a delete link (or icon) to each new media item, it would be much clearer to the user what they are deleting. Since we can be pretty sure that we are not breaking references and the user still has the source file on their computer, a confirm step wouldn't even be needed.

Here's a quick mockup of what it could look like with delete-icons:

Clicking the icon would mark a media item for deletion; the deletion can be handled when the Save button is clicked.

seanb’s picture

I like the idea in #6. We already have a screen where you can review what you have just created and fill the required metadata, so using this screen to be able to remove anything you didn't mean to add sounds like a good idea.

Knowing the difference between changing the canonical media item or changing metadata for the specific instance/usage is a hard concept and we might make it easier if we remove changing / deleting canonical media items. I'd love to hear more opinions on this though!

dennis cohn’s picture

StatusFileSize
new35.98 KB
new48.13 KB
new33.74 KB

We assume that users have not been trained or instructed on how to use the media library.

I think this is because normally you only see an upload field on the first screen right? You have to switch tabs to see the media library.
We can change this by open the media library instead.
Then editors will see all the images and maybe they will look for an image that the can use.

But I also think the in the most cases you want to upload new media.
I don't like the idea that we have an upload area/dropzone AND the media library in one display. The modal is not so big so if we put the dropzone and the library in one display it's so tiny/small not so useful in my opinion.

Also I don't see the benefits of the vertical tabs on the left. I need to click on the left on, for example, remote video, and then I see only the remote video's in the library? Isn't this where the filter is for? And again, the modal is not so big so if we put vertical tabs on it, the library gets even smaller.

In my opinion, we need just one dropdown button to add media. When you click on it you can select the media type that you want to display. When you selected the media type that you wanted to add, you will get a new display with all necessary fields for this type of media. whether it's a dropzone, or only an url field for the youtube url...you name it..
You can have a better error handling cause you know which type of media you must upload... if you make one magical upload field like some other screens in Figma, this would be hard.

I've added some fast mockups to explain my idea better.
Also I moved the filters, grid/list switch on the same height as the add new media button. This will also save us some space! :)
Media screen 01

Media screen 02

Media screen 03

seanb’s picture

Thanks Dennis. I think #8 also looks really nice.

There are a couple of reasons we introduced the tabs:

  1. One of the assumptions we made is that most media fields have only 1 media type configured for the field. In this case the vertical tabs are not needed and hidden. I wouldn't call the vertical tabs an edge case, but I still think they would be hidden most of the time.
  2. Editors mostly want to add new media, so we want to show the input field directly to save an extra click.
  3. Editors need a quick overview of what they would be able to add, so the tabs provide a nice way to show the available options. The tabs also allow us to hide the other filters by default.
  4. Different media types have different input fields, so we need a way to switch the input fields.

That being said, we probably need more people to weigh in on this. Do we want to use the precious screen real estate to optimize for re-use or do we optimize for new media? Do we want to optimize the number of clicks and show a lot of options, or do we initially hide some things behind a button? These are important decisions to make.

We also talked about having a tab with all media. At least for this 'All' tab, the dropbutton would definitely make sense imho.

One last thing.

The modal is not so big so if we put the dropzone and the library in one display it's so tiny/small not so useful in my opinion.

When you drag something over the modal the whole modal should be the drop area, so the initial dropzone area is just to show the user it is possible. The drop area is actually much bigger, so that would hopefully make this easier to use.

dennis cohn’s picture

That being said, we probably need more people to weigh in on this. Do we want to use the precious screen real estate to optimize for re-use or do we optimize for new media? Do we want to optimize the number of clicks and show a lot of options, or do we initially hide some things behind a button? These are important decisions to make.

In my opinion you shouldn't combine these in one very small modal form.
If we asume that editors will most likely want to add new images, let's focus on that part and make a nice clear button to use exising media item from the library. Or ask something like: 'Add new media' or 'Use existing media'. Which take you to the upload form/dropzone or to the media library. (ofcourse with the posibility to 'Add new media' if you're in the media library and 'Use existing media' if you're in the upload new media screen.
I don't mind clicking one time extra if I get a clear/nice way to add some new media/re-use media after that.

When you drag something over the modal the whole modal should be the drop area, so the initial dropzone area is just to show the user it is possible. The drop area is actually much bigger, so that would hopefully make this easier to use.

I don't think people will understand this. Yeah, we, developers/designers will know that. But most editors are still looking for a button "add media'. I've worked with a lot of editors and they're not really familiar with a 'fancy' dropzone.
It's hard... I think the experienced people will understand that you can drop your files there... but will the unexperienced people also understand that?

But if you already decided that the dropzone and media library happens in the same modal form... What's do we need to decide now?

seanb’s picture

@Dennis Cohn, thanks for the feedback. I think you make a valid point that there might be some value in not trying to offer tabs, the 'add media' form AND the existing items in the same screen. That is basically the thing we are currently struggling with. Do we have a separate screen for that, which means extra clicks, or do we go for the current design where we proposed having everything directly visible?

But if you already decided that the dropzone and media library happens in the same modal form... What's do we need to decide now?

I don't think we have actually made a decision on this. Every solution has its own advantages and disadvantages. I think we need more opinions before we can make a decision.

seanb’s picture

Issue summary: View changes
StatusFileSize
new3.67 MB
new800.65 KB
new280.87 KB
new548.14 KB
new761.24 KB
new576.1 KB

Attached a new video and screenshots. Also updated the IS.

seanb’s picture

Issue summary: View changes
marcvangend’s picture

Wow, this is looking really slick, thanks Sean. I'm very happy with how the delete option turned out, easy to find when you need it, but subtle enough to get out of the way when you don't.

leo pitt’s picture

That is basically the thing we are currently struggling with. Do we have a separate screen for that, which means extra clicks, or do we go for the current design where we proposed having everything directly visible?

In my experience it's not at all unusual for media items to have more than one field, and quite easy to envisage scenarios where a media item could have multiple fields. E.g. image file, alt text, caption, link.

In my opinion it's important that the solution allows for media bundle configs that are a bit more complex. While I guess we are aiming for an MVP here I'd be concerned that otherwise there's a risk that it just won't be flexible enough for a lot of scenarios...

jonathanshaw’s picture

I think that often an editor will not be sure whether they need to add a new media or reuse an existing one; therefore it is really good how you've done it: they are not forced to choose between those options prematurely, but instead there is a prominent way to add new media right in the place where existing media are displayed.

The most problematic thing I see is the filters for the existing media. These are complicated and poorly labelled, as well as relatively unimportant. I think the best solution might be to collapse them initially behind a 'Filters' link, or to have them in the left column under the tabs.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

webchick’s picture

Curious if any of the folks here giving great feedback have feedback on this aspect of the behaviour #3041147: Preserve the selected items across multiple uses of the media library.

phenaproxima’s picture

Status: Active » Fixed

Well, folks...the Media Library is UI-complete in Drupal 8.7.0, and therefore the designs we came up with in this issue have been implemented. I discussed this with @seanB and @Gábor Hojtsy and we agree that this case is pretty well closed. If we need to make UI changes in the future, we can deal with those in other issues.

But as for the complete redesign...it is done! Let's close this one out, and a big thanks to everyone who participated!! Congratulations to all; we really delivered on this one. :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.