For Drupal 8.3, we want to ship with a media library that allows displaying and selecting from a listing of previously-uploaded images. (And expanded later to also cover videos, audio files, documents, etc.)

This issue intends to compare/contrast different approaches both within and outside of the Drupal ecosystem, with the aim to arrive at a validated design we can turn into one or more core patches.

Current media library in core

Drupal 8 ships with a media library, in the form of a basic administrative view:

List of files

Files are listed in a simple table, exposing their raw file names, but with no visual representation of what the image looks like.

This library of pre-existing files is not accessible from the content author's experience; when adding an image to the WYSIWYG editor, the only option is to upload a new image:

Upload new image.

Prototype

prototype

Requirements

What then do we want to see in a new media library experience?

  • Accessible to content authors, not just content administrators
  • Allow users to see a listing of previously-uploaded images when adding a new image.
  • Visual representation of images (e.g. grid of thumbnails)
  • Allow selecting from a previous image when inserting an image into the WYSIWYG editor.
  • Must not regress accessibility features of current image UI (e.g. required alt text)
  • Provide basic filtering options (e.g. search by file name)
  • Simple enough spec to implement by January.
  • Anything else?

Prioritized user stories

Here prioritization is simply based on the heuristic "If the user need 1 is not being met, it's either impossible, or makes no sense to try to meet user need 2" eg. if my need calls for a media browser, without a media browser I can't have a media browser with a grid view.

Stories that should be covered by the MVP are prefixed with an "*".

Content authors

  1. * 'When I add media to a piece of content I want the media to be available when I want to add it to another piece of content so I don't have to upload it again.'
  2. * 'When I add media to a piece of content I want to browse thumbnails of the media files if they are visual (eg. video, image) so I don't have to guess or remember what I named things'
  3. 'When I add media to a piece of content I want to see the the things most recently added or edited by me already at the top of the list so I don't have to apply filters or scroll or page through many files to find what I need'
  4. * 'When I add media to a piece of content I want to be able to filter the list of files with autocomplete so I can quickly find what I'm looking for"
  5. 'When I add media to a piece of content while quick editing I want to be able to see what it looks like in place without having to close the editing widget so I'm not constantly going back and forth between edit and preview modes."
  6. "When I add media to a piece of content I wan to be able to scale, crop, or rotate images I am adding so that I don't have to open them in an image editing application, edit, re-save, and re-upload them just to make a simple change."
  7. * "When I add media to a piece of content I need to be able to browse files by (maybe hierarchical) categories related to my business, so that I can quickly find what I am looking for"
  8. "When I add media to a piece of content I want to be able to add content I've seen on Facebook, Twitter, Youtube as easily as uploading media from my own computer."
  9. "When I'm dealing with media I've seen on Facebook, Twitter, Youtube etc, I want it to 'just work' and not have to deal with techie jargon like 'embed codes'"

Content editors

  1. * "When I browse media in my site I want to be able to view the media as either a grid of thumbnails or a list so that I can scan through large quantities of files without having to do a lot of paging"
  2. "When I browse media in my site I want to be able to enlarge or reduce the size of the thumbnail images so that I don't have to open each one to see it in greater detail"

Site builders

  1. * 'When I add media to my site I want to be able to add multiple files at once so I don't have to upload files through the UI over and over or figure out how to manually put things in the file system"
  2. "When I add multiple media files to my site I would like it to be as fast and simple as possible whether the files are coming from my computer of from another remote source"
  3. "When I add multiple media files to my site I would like to "bulk fill" some fields with the same value so that I don't have to repetitively fill the same field with the same value over and over for many files"

Media library options in contrib

@todo

Media libraries of competitors

WordPress

WordPress

@todo

Goal

The goal at this stage is to arrive at an implementable spec, so let's start by exploring ideas!

CommentFileSizeAuthor
#101 source-entity-field.png62.84 KBkiboman
#101 insert-uploaded.png41.49 KBkiboman
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick created an issue. See original summary.

Bojhan’s picture

Title: [prototype] Create validated design for a Media Library » [prototype] Create design for a Media Library

Validated is no requirement of Experimental.

What about Kevin's initial designs? We did a lot of reviewing of that in the past.

GTamas’s picture

I think is very important part in cms. We should not use in overlay windows.
Important for the real editors. This could be a major part of the cms.
Fast and easy search or create something new. I go even further… this should be based on the editorial part.
What do you think?

cosmicdreams’s picture

Oooo here's a place I can help.

Sitefinty: http://www.sitefinity.com/digital-asset-management

Uses a desktop application to make it easy for the asset management tasks to be separated from the site management tasks. Uses the folder paradigm to give asset managers a way to remember where specific kinds of files are stored. And they provide tools for making alterations for assets.

Kentico:

http://www.kentico.com/product/all-features/web-content-management/media...
http://www.kentico.com/product/all-features/web-content-management/files...

Provides Drupal-like centralized management of files and asset selector grid displays. Can be integrated with external DAM systems for those cases where the client has already invested in those. .Net based so it has fancy features like WebDAV.

slashrsm’s picture

Media library can appear in different contexts. It can be a standalone library page where users can browse, search, modify, ... This is conceptually very similar to admin/content.

It can also be used as a tool to insert media in some other piece of content. Currently there are two most obvious cases of this: referencing media from a field and embedding it into WYSIWYG.

All those usage examples have slightly different requirements. When using a standalone library there is usually no concept of selecting/inserting. On the other hand there might be ability to execute bulk operations on media items, which probably won't be the case in "inserting" context.

When using media library in inserting context we obviously need to make selecting a primary and most obvious action. On the other hand there might be less filters compared to standalone library and similar simplifications. There is also difference between reference field use case and WYSIWYG. Field can generally accept arbitrary number of items (but we should respect cardinality) while WYSIWYG embed accepts just one.

We also might want to present other information along the thumbnail (filename, type, ...).

It is likely that we won't be able to cover all this cases in 8.3, but we should keep them in mind. Mocks can go a step further from MVP in my opinion.

AFAIK Kevin created library mocks in the past. Maybe we could start with that and iterate.

ciss’s picture

I'd like to provide a few positive and negative examples from Scald as food for thought:

Library:
The listings view itself delegates responsibility for the preview representation: Each media type ("atom" type in Scald lingo) defines a library representation and as such is responsible for generating the thumbnail/preview content. This might be image style derivatives for image files, file icons for documents, generated previews of the first page for PDFs, and may just as well use text excerpts for e.g. quotes, HTML for tweets etc.
This proves to be incredibly flexible, but when listing different item types falls short in terms of sorting/filtering items, as columns are (or should be) essentially limited to shared/similar properties of these types.

Adding/selecting items:
Whenever a Scald field (atom reference field) is included on an entity form Scald will automatically load a simplified library view in a side pane from which items can be dragged and dropped into fields. This allows quick access to media items, but has two major shortcomings:

  1. It breaks with Drupal's navigation concepts.
  2. Scald fields can be limited to certain media types. Since all items are listed all the time (except when you actively filter them), users may try to drag items onto fields that do not support a certain type.

Nested dialogs:
The above mentioned library pane allows adding new media items on the fly. Doing so opens up the atom add form inside a jQuery UI overlay. Now here's the catch: There's an atom type "gallery" that allows you to compose gallery atoms from image atoms. In order to create a gallery on the fly, you need access to the library pane - which at that point is overlayed by the add form for the gallery and as such inaccessible.

tkoleary’s picture

FileSize
33.77 MB

Here's a video showing some work I did on this 2-3 years ago. Most of the ideas here still hold up.

I've done more recent designs on individual components that I'm digging through now, but this is a good place to start.

tkoleary’s picture

FileSize
22 KB

@cosmicdreams

This shot from Sitefinity is good. More best practice image manipulation than what's in my video.

tkoleary’s picture

@ciss

The above mentioned library pane allows adding new media items on the fly. Doing so opens up the atom add form inside a jQuery UI overlay. Now here's the catch: There's an atom type "gallery" that allows you to compose gallery atoms from image atoms. In order to create a gallery on the fly, you need access to the library pane - which at that point is overlayed by the add form for the gallery and as such inaccessible.

Yeah, there's a few key things we might take from this.

  1. Whatever solution we develop needs to have the flexibility to move between different dialogs that may be coming from different modules. Outside-in *might* be part of the solution for this.
  2. The ability to add things "on the fly" needs to be something that is possible across the board in Drupal, hopefully be adding something like inline entity form in 8.3.
  3. A file entity alone might not be sufficient for the task of creating something like a "gallery item" which may really need to be it's own full node if it has unique requirements like a long-form description or other custom fields that are more about it's display as a full page than it's meta data. This model is close to what other systems like squarespace do where there's a gallery item content type that includes a file entity and other fields.
ndf’s picture

#7 looks amazing to me!
It really works that you see the interactions because it is a video.

#7@ File UI
The filter widget (kitten / add filter /refresh) seems very useful. Personally I prefer it over a strict folder-like hierarchy (#4).
#7@ Authoring
The meta-data on the right side for single images seems very useful too.
Right now it disappears when selecting multiple images. Is it possible to keep the meta-data form visible? Maybe with the (V) icon per image for "multiple images that will be inserted" and a border for the one image with the "metadata-form"?

ciss’s picture

@tkoleary I agree that a gallery composed from other media is a high level concept that should not necessarily be covered by a media management UI.
Which underlines the importance of clearly outlining what qualifies as "media" and which functions will explicitely not be supported by the core UI (e.g. composed media).

I like the idea of separating media items by type, as shown in the Wordpress screenshot. While it translates smoothly to the simple preview grid shown in the screenshot, it requires more effort for a column view. We'd need two variations:

  1. The main view that lists all types of items. It provides only the basic common properties: title, media type, created, changed, author (note that I've intentionally not used the term "uploaded" and "uploader").
  2. The type specific view: In addition to the common properties it also lists type-specific ones. Some examples (the types listed might be controversial, which is intended):
    • Image: file type, dimensions, file size
    • Video (local): file type, dimensions, duration, file size
    • Video (remote): source, dimensions, duration
    • Audio: file type, duration
    • Document: file type, file size

    Can we provide the ability to switch between a thumbnail only and a list view? If we avoid HTML tables and instead use e.g. Flexbox this should be simple to implement and even allow for mobile friendly adjustments.

I'd also strongly advise against focusing too much on images. In my opinion every image-specific feature should be checked against two points:

  1. Does this feature translate to other media types
  2. If not, can it be added in a way that won't interfere with other types?
tkoleary’s picture

@ndf

Right now it disappears when selecting multiple images. Is it possible to keep the meta-data form visible? Maybe with the (V) icon per image for "multiple images that will be inserted" and a border for the one image with the "metadata-form"?

That's one of the things I have more detailed designs for. Digging around to find them now.

We spent some time working on this at Drupalcon Prague.

webchick’s picture

I think the focus on images is just to get us something we can implement by January (code freeze for 8.3). Fully agreed that whatever is built needs to be a basis for further media types in the future, however. :)

cosmicdreams’s picture

FileSize
149.51 KB

Beaver builder:

Seems to provide a general bucket for assets but it does have a nice search feature for finding photos. Looks like it filters on the name of the file.

beaver builder

cosmicdreams’s picture

FileSize
590.55 KB
109.45 KB

Craft:

Provides a large bucket of files in either list of grid displays. Also simulates the concept of folders by allowing you to place images in specific buckets. The purpose of the buckets is for organization but also to contextually provide a subset of photos where needed.

asset library - context of a specific bucket

asset library - showing all buckets

tkoleary’s picture

@cosmicdreams

"simulates the concept of folders by allowing you to place images in specific buckets. The purpose of the buckets is for organization but also to contextually provide a subset of photos where needed."

This is a nice enhancement, but of far more immediate value would be having two default filters/sorts applied; 'updated by current user' and 'sorted most recently updated first'.

The effect of this would be that if I added media a an hour ago or yesterday, it should be at or near the top of the list when I open the modal rather than me having to scroll around or apply filters to find it.

ciss’s picture

Perhaps we can define a few concise user stories that should be covered before talking about implementation details. Makes it easier to check if we're still on topic later on.

pbuyle’s picture

https://www.filestack.com/ basically provides file picker as a service with support for multiple sources and cropping. Their UI is simple but effective. Probably worth looking at for inspiration. It uses a overlay, but its responsive and works on phone.

tkoleary’s picture

Here's a start

Content authors

'When I add media to a piece of content I want the media to be available when I want to add it to another piece of content so I don't have to upload it again.'

'When I add media to a piece of content I want to browse thumbnails of the media files if they are visual (eg. video, image) so I don't have to guess or remember what I named things'

'When I add media to a piece of content I want to see the the things most recently added or edited by me already at the top of the list so I don't have to apply filters or scroll or page through many files to find what I need'

'When I add media to a piece of content I want to be able to filter the list of files with autocomplete so I can quickly find what I'm looking for"

'When I add media to a piece of content while quick editing I want to be able to see what it looks like in place without having to close the editing widget so I'm not constantly going back and forth between edit and preview modes."

"When I add media to a piece of content I wan to be able to scale, crop, or rotate images I am adding so that I don't have to open them in an image editing application, edit, re-save, and re-upload them just to make a simple change."

Content editors

"When I browse media in my site I want to be able to view the media as either a grid of thumbnails or a list so that I can scan through large quantities of files without having to do a lot of paging"

"When I browse media in my site I want to be able to enlarge or reduce the size of the thumbnail images so that I don't have to open each one to see it in greater detail"

Site builders

'When I add media to my site I want to be able to add multiple files at once so I don't have to upload files through the UI over and over or figure out how to manually put things in the file system"

tkoleary’s picture

@ciss

I like the idea of separating media items by type, as shown in the Wordpress screenshot. While it translates smoothly to the simple preview grid shown in the screenshot, it requires more effort for a column view.

Since it's presumably going to be a view I would keep it as simple as possible and let site builders customize it in some of the ways you suggest.

Can we provide the ability to switch between a thumbnail only and a list view? If we avoid HTML tables and instead use e.g. Flexbox this should be simple to implement and even allow for mobile friendly adjustments.

Certainly. D8 distros like Lightning are already doing this.

I'd also strongly advise against focusing too much on images. In my opinion every image-specific feature should be checked against two points

I don't necessarily see a conflict there. Images may have attributes that audio files do not, but I don't think we would make mime-type specific attributes part of the UI (columns in the default table view for example).

Having said that, there is a design problem that needs to be solved of what representation do you show of a non-visual piece of media in the thumbnail view. There are a variety of approaches to this we'll need to explore (good examples are Box.com and Google drive).

There is also a question of whether we should create a higher level taxonomy that simplifies discovery by grouping mime types into larger categories (I believe we should). Those categories might look something like:

  • Images
  • Video
  • Audio
  • Documents
  • Social media posts

Something like that would provide a more 'blunt" tool for users who 'don't quite know' what they are looking for. For example 'I need an image of nature, I know I have a bunch of nature images on the site but I'm not sure which one will look good here'. In this case auto-complete is useless because I have no idea of file name, mime type of jpeg is too narrow because the image I want may be a png, and I can't necessarily assume that useful tags have been added.

cosmicdreams’s picture

@ciss and @tkoleary:

It seems you're both ahead of me in this process; talking about strategy and making user stories. If I can jump back a few steps in this process and try to describe what I see is common in the examples posted, I would put together these findings:

In review of stock Wordpress, Beaver Builder-enabled Wordpress, Craft and Sitefinity, all offer:

A grid or list view of previously supplied assets
Mechanisms for filtering / searching that list
A way to select, then signal your intent to include the photo into whatever you're doing.

Some provide the ability to access detailed metadata about the assets
Some provide tools to manipulate the images.

----

It is my opinion that if we were to plan a feature set that implements all of the things that are common (an MVP) we would simply provide an entity browser that is very similar as it is now, just make the user action of selecting a photo and the intent to include the photo more clear.

If we want to go above and beyond this common feature set we could find ways to manipulate photos before they are used. And store / list metadata. But that seems to be beyond what we need to do (in my opinion)

lussoluca’s picture

Talking with customers about media libraries (in last couple of years) and the main requirements of big and structured offices are:

  • file system like navigation
  • multiple upload of assets with some fields in common (like author) and some fields specific for asset (like title)
  • upload files with ftp (or automatically imported from other sources) and then used as assets in websites
  • ability to (re-)use assets in both WYSIWYG and fields

Maybe these user stories could be implemented in contrib but IMHO core should provide a framework to implement them easily.

Bojhan’s picture

I would argue that product management needs to provide guidance on the key functionalities we wish to include. We should have a clear picture of the MVP.

tkoleary’s picture

@lussoluca

This is great information, but we should capture it as user stories that describe needs rather than jumping to solutions, even if they are suggested by the user.

Users will always suggest what they "think" they need or what they have seen elsewhere. They will never suggest something they have never seen, but which may be an innovative leap forward.

file system like navigation

The user story here could be "When I add media to a piece of content I need to be able to browse files by categories related to my business, so that I can quickly find what I am looking for"

And/or "When I add media files to my site I need to be able to put them into categories that relate to my business so that authors can find them more easily"

multiple upload of assets with some fields in common (like author) and some fields specific for asset (like title)

This one could be "When I add multiple media files to my site I would like to "bulk fill" some fields with the same value so that I don't have to repetitively fill the same field with the same value over and over for many files"

upload files with ftp (or automatically imported from other sources) and then used as assets in websites

I think this one is simply "When I add multiple media files to my site I would like it to be as fast and simple as possible whether the files are coming from my computer of from another remote source"

ability to (re-)use assets in both WYSIWYG and fields

I think we already have this one captured in: 'When I add media to a piece of content I want the media to be available when I want to add it to another piece of content so I don't have to upload it again.'

To me that one assumes that the WYSIWYG and file field browser will both trigger the same dialog.

tkoleary’s picture

@bojhan

I would argue that product management needs to provide guidance on the key functionalities we wish to include. We should have a clear picture of the MVP.

Sure. The prioritized list of user stories is a good way to inform that decision.

lussoluca’s picture

@tkoleary I agree with you, user stories are better. I just want to stress on one point:

The user story here could be "When I add media to a piece of content I need to be able to browse files by categories related to my business, so that I can quickly find what I am looking for"

should be:

"When I add media to a piece of content I need to be able to browse files by (maybe hierarchical) categories related to my business, so that I can quickly find what I am looking for"

tkoleary’s picture

@cosmicdreams

Re:

  • A grid or list view of previously supplied assets
  • Mechanisms for filtering / searching that list
  • A way to select, then signal your intent to include the photo into whatever you're doing.
  • Some provide the ability to access detailed metadata about the assets
  • Some provide tools to manipulate the images.

Coming at this from the direction of what is provided by other systems is another good angle on the problem but we can still extract user stories from these (though we should be careful because the user sets may diverge.)

The user story I see here that's not already captured is: "When I browse media files I need to be able to select multiple files first, then choose the content i want to add them to so that I don't have to leave the file browser, open the content then open a dialog just to see the same files I was just looking at."

tkoleary’s picture

Issue summary: View changes

Added user stories to issue summary.

tkoleary’s picture

Issue summary: View changes
Leo Pitt’s picture

Agree that User Stories are an important first step before prescribing solutions. I'd like to add a couple:

  • "I want to be able to add content I've seen on Facebook, Twitter, Youtube as easily as uploading media from my own computer."
    [Users should not, in my opinion, be presented with different workflows for local/remote media]
  • "When I'm dealing with media I've seen on Facebook, Twitter, Youtube etc, I want it to 'just work' and not have to deal with techie jargon like 'embed codes'"
kiboman’s picture

kiboman’s picture

I completely agree with the approach to to define the major user stories first.

In addition I've made a quick review of other CMS's answers to our current issue. It is always usefull to see other solutions "live", so I gathered videos.
(HINT: turn the speed up at least to 1.5 :)

WORDPRESS
- view (select, filter, search)
- upload
- edit
- manage selected

JOOMLA
- view (select, folders)
- upload

Some ENTERPRISE CMS

(based on https://trends.builtwith.com/cms/enterprise/)

Adobe Experience Manager (EEM Asset Picker)
- view (select, filter, search)
- manage selected

SITE CORE | hmm
Life Array | Media

prabhu9484’s picture

Adding to @slashrsm on https://www.drupal.org/node/2796001#comment-11588181 - image file size and image file dimensions

webchick’s picture

That's insanely helpful, @kiboman, thank you!

tkoleary’s picture

Issue summary: View changes
ciss’s picture

I was wondering if we could create an supplementary table of the user stories somewhere that would allow us to extract certain aspects of each story and make them more quickly accessible/reviewable. What tool would be appropriate? Google Docs?

prabhu9484’s picture

Leo Pitt’s picture

Three things stand out for me from the Wordpress media Library:

  1. Idiot-proof drag'n'drop file upload (I think this is covered in the user stories already)
  2. An "edit media" screen with easy access to cropping, rotation, etc tools.
  3. The "restore original" button on the edit media screen, to revert back to the original file after saving edits.

So...

"When I'm editing media I want all the main editing options in one place so I don't have to hunt around for them".

"I want to be able to undo all my edits and restore the original version if I make a mess of things".

yoroy’s picture

We discussed this a bit during today's UX meeting: https://youtu.be/vRNPFs9fISk?t=6m58s

This is great research, thanks all! Feel free to add any new/different examples you may find, but also:

What about we transition toward sketches and mockups that are more Drupal specific? Take the prioritized user stories in the issue summary as a starting point and start sketching out high level flows and screens.

Napkin sketches are perfectly fine at this point.

kiboman’s picture

I've created a draft prototype according to our user stories and also using the competitors' best practices. There are 2 pages: 1. media selection (filtering, search, categories, latest, multiselect); 2. a draft version of the upload page.

Please feel free to add comment directly into the prototype or here too. I hope this can be a good starting point for us.

Any feedback is welcome :)

The live prototype: https://collaborate.uxpin.com/31e2ff3dcb6d3624e98d788d531d9529fbd70c7a#/...

Screenshots:
Media Library | Select Page
Media Library | Upload Page

pbuyle’s picture

Please include use cases for separated libraries. Basic use cases is to have a single library (files on the server), but multiple libraries is already a reality for some users. One is a special case of many. It easier to start with many and have special handling for one, than to start with one and then add support for many.

tkoleary’s picture

@pbuyle

Captured as a user story we could phrase that as:

"When I add media files to my site, if I have an external library I want to be able to see the files from that library in the same media browser as files local to my site so that I don't have to go to two different places to look for the file I need."

Is that about right?

tkoleary’s picture

@kiboman

Awesome!

This looks really nice. I love the simplicity and clarity of it. I left some detailed feedback and questions in the prototype.

kiboman’s picture

@tkoleary Thank you :)

Meantime I've been working on an updated version with new features.

Here is the current version (v0.6):

https://collaborate.uxpin.com/88c482d01079887fcd72e0aaaf8ea8afbfbf8f9d#/...

Updates:
1. List/Grid view
2. Modify items (Delete, Bulk operation)
3. Dropdown (Newest/Latest)

But let's resolve the comments in the first protype + add new ones to the current (0.6).

Leo Pitt’s picture

Nice prototype. Would those be folders on the left of the browser, or tags?

kiboman’s picture

@Leo Pitt Thank you.

I believe I believe we are on the right track.
In addition one of the biggest challenges we are facing now is to figure out how to handle this "folder", "tags", "tagging during upload", "remove from folder", "taxonomy" issue.
@tkoleary and @samuel.mortenson also shared their thoughts regarding this topic in the prototype (comments no2 and no3)

pbuyle’s picture

@tkoleary More like 'When I add media to a piece of content I want to see be to see media from all configured sources (uploaded files, ownCloud, Flickr, Instagram, Facebook, Google Drive, etc.).". A user should not have to first add a external media to the site before adding it to a piece of content. Ir should rather be a one-step process (user select the external media while adding it to a piece of content). Also, the UI should not care (too much) whether a source is external or not, to most users this is a technical details they don't care much about.

slashrsm’s picture

A user should not have to first add a external media to the site before adding it to a piece of content. Ir should rather be a one-step process (user select the external media while adding it to a piece of content). Also, the UI should not care (too much) whether a source is external or not, to most users this is a technical details they don't care much about.

I agree. Adding external media should be just another page where media can be added. It is technically similar to upload just with different UI.

At DDD Milan @MXT approached me and suggested a nice UX improvement for Entity browser. I seems like something that could be potentially considered as part of this issues too: #2755261: Add a splash TAB to entity browser to increase usability.

A lot of great ideas emerged in this issue, but it seems that we're having discussion in at least 3 places (this issue and 2 UXPins). We should try to avoid that and keep discussion in one place.

Leo Pitt’s picture

@slashrsm - for what it's worth, I'd absolutely concur with MXT's observation. I find content editors are regularly pleasantly surprised to be informed that there's a "Web" tab and that furthermore it is for adding content from Youtube (for example). If it's working properly, it shouldn't need to be pointed out at all. In part this is the motivation behind the user story of "When I add media to a piece of content I want to be able to add content I've seen on Facebook, Twitter, Youtube as easily as uploading media from my own computer."

tkoleary’s picture

@pbuyle

A user should not have to first add a external media to the site before adding it to a piece of content. Ir should rather be a one-step process (user select the external media while adding it to a piece of content). Also, the UI should not care (too much) whether a source is external or not, to most users this is a technical details they don't care much about.

Absolutely. That's what I meant.

webchick’s picture

Project: Drupal core » Drupal core ideas
Version: 8.3.x-dev »
Component: other » Prototype

Moving over to the new Drupal core ideas queue while we get this into shape.

RainbowArray’s picture

"When I add media to a piece of content, I want to be able to select a style for an image so I don't need to manually edit an image to take up the correct amount of space."

Allowing manual editing is fine, but in a lot of cases when setting up a site it's good to be able to provide a few different styles for images that can be placed in a particular wysiwyg. Technically speaking I'd define this as selecting an image style (or responsive image style when that's available). I don't know that we need to use those exact terms as a way of communicating, "hey, select the type of image you're trying to place."

Ideally it would be possible to limit the allowable image styles/responsive image styles for a particular type of body field, possibly at the text format level, with the option of providing an override for a particular field? "When I add media to a piece of content, I only want to see the styles that should be available for this content area so I don't accidentally select a style that doesn't work well with this content area."

gmclelland’s picture

Here is a video preview https://www.youtube.com/watch?v=nfGOoilNFow of the Media Manager module https://mediamanager.kongondo.com/ for http://processwire.com

Hope that helps.

prabhu9484’s picture

@gmclelland - awesome UX - so creative ! - thanks :)

Leo Pitt’s picture

@gmclelland the ability to edit an image and then "save as copy" or "save and replace" is good. Also the way the saved copies are linked to the original version as "variants".

I suspect we're getting ahead of ourselves however...

tkoleary’s picture

@Leo Pitt

I suspect we're getting ahead of ourselves however...

Yes, we are. We have a good deal more than an MVP as far as user needs go. I think it's a good time to talk about prioritization and what features are must haves.

webchick’s picture

There's a "Requirements" section of the issue summary which reads:

  • Accessible to content authors, not just content administrators
  • Allow users to see a listing of previously-uploaded images when adding a new image.
  • Visual representation of images (e.g. grid of thumbnails)
  • Allow selecting from a previous image when inserting an image into the WYSIWYG editor.
  • Must not regress accessibility features of current image UI (e.g. required alt text)
  • Provide basic filtering options (e.g. search by file name)
  • Simple enough spec to implement by January.
  • Anything else?

So we could use that as a starting point, perhaps.

prabhu9484’s picture

kiboman’s picture

Have you seen the Driesnote Dublin? Our prototype has been mentioned there :) https://youtu.be/eQLzrlMeySU?t=2548

chris_h’s picture

Another reference: https://www.drupal.org/project/visual_select_file is the best implementation of a lightweight, reusable Views-based media library for D7.

matsbla’s picture

Really happy to see this issue, thanks for great initiative!

I would love to see the Media library also save the alternative text! First of all because many times the image text don't change just because the image is re-used and it is redundant to re-add the same image text over and over again. I think such solution would really speak to the goal of "seamless" media editing experience. Example:

Taj Mahal

alt="Taj Mahal"

This image text will probably be re-used anywhere this image is used.

It would also make it easier for multilingual website building; at the moment the core support for translation of image text is poor. When adding a translation it is hard for a translator to even notice that they should double-click the image to translate the image text. An untranslated image text might give some scores for search engines, but it does not improve accessibility. If image text was part of a library the image text could be translated separately from the content, and also translations of image text could more easily be re-used.

It could of course be possible to over-ride a default image text, but I think even this overridden image text should be part of the library so it also could be re-used.

The image text could be set as the title instead of the file name, it would make the media library list look much nicer and the image text could then be used to index the image for media library search functionalities.

My last 2 cents:
The alignment of the image should not be set within the image adding UI, but by using the WYSIWYG. It is more intuitive, and the way it works now is again not good for multilingual websites: if an image is aligned to the right it also is default to align to the right for RTL-languages when adding a translation. It can be confusing for translators and images can easily end up being aligned incorrectly for RTL-languages.

slashrsm’s picture

I left a comment about the bulk media items editing in the last UXPin.

Past experience tells me that bulk editing field values for multiple items by copying field values from a single form isn't the way to go. As soon as you offer this to content creators they start abusing it any you'll end up with slideshows that have same caption for every image etc. Having multi-step editing worked way better though. I still offers better experience but also encourages content creators to actually produce meaningful content.

kiboman’s picture

FileSize
15.39 MB

I've created an analysis about how different mediums, tools are handling the thumbnail vs. image aspect ratio issue.

kiboman’s picture

@webchick: thanks for summarizing the MVP, it was really helpful for me.
I've modified the prototype to meet the MPV's requirements:
https://collaborate.uxpin.com/d1898715f5c8ee2ba4921393d2e520c98dc19019#/...

Gábor Hojtsy’s picture

Discussed this with @webchick after the ideas review meeting (where we only managed to discuss one idea unfortunately and it was not this one) and she clarified the process. According to her, we should get the media and UX team confident in this prototype first and then mark this RTBC based on that for review on the ideas meeting, and the ideas meeting would review the RTBC issue. So will try to push as much as I can for the review of this and feedback posted from both the Usability meeting and media meetings.

I hoped this can happen sooner, so if people can provide their feedback sooner, that would be nice.

Once again the feedback we are looking for now is if

(a) the MVP (minimum viable product) requirements listed in the issue summary are complete
(b) the prototype implements the requirements in a sensible way

Discussing requirements and more enhancements that are not possible to implement in 2 months are not in scope for Drupal 8.3. That said the library would ideally provide extension possibilities for contrib to be based off of, so contrib does not need to replace the library entirely, that would be bad :) But it does not need to implement anything but a first step. We can always improve that in the next releases.

Post your feedback with that in mind, go! :)

seanB’s picture

Nice work everyone! Here are some thoughts.

About the user stories
I think they are all valid. Some should be more important then others. I'm not sure if they are all needed for the first version.

Content Authors:
'When I add media to a piece of content while quick editing I want to be able to see what it looks like in place without having to close the editing widget so I'm not constantly going back and forth between edit and preview modes."
For the sites I have built this is not a big priority. Users mostly have a pretty good idea of what an image is going to look like while making crops and stuff.
"When I add media to a piece of content I wan to be able to scale, crop, or rotate images I am adding so that I don't have to open them in an image editing application, edit, re-save, and re-upload them just to make a simple change."
I think cropping and scaling should be enough for a first version.
"When I add media to a piece of content I need to be able to browse files by (maybe hierarchical) categories related to my business, so that I can quickly find what I am looking for"
This is nice for larger sites, probably shouldn't be the greatest priority. Being able to filter by bundle (image/video etc.) is a good start.

Content editors:
"When I browse media in my site I want to be able to view the media as either a grid of thumbnails or a list so that I can scan through large quantities of files without having to do a lot of paging"
Good defaults should go a long way. Imho this should also be a low priority.
"When I browse media in my site I want to be able to enlarge or reduce the size of the thumbnail images so that I don't have to open each one to see it in greater detail"
For most use cases users will know which (or wat kind of) image they are looking for, so while I like the idea I think it should be a low priority.

Site builders
"When I add multiple media files to my site I would like to "bulk fill" some fields with the same value so that I don't have to repetitively fill the same field with the same value over and over for many files"
I think image titles/alt text should be unique for images, so this is probably not the highest priority, it would be nice when tagging content though.

Prototype:
I'm not really sure about the 'Modify items' page yet, there should probably be fields for each image instead of editing them all at the same time (at least it seems that you are changing the title/alt etc for all selected)? I would expect to do cropping/scaling here as well.

Deleting items from the library is also something to think about. What do you do with all references to the content? There might be different permissions for different items (you can delete some, but not all of them?).

Selecting and filtering looks very nice. I'm not really sure about the term 'External content'. I think the term embedding is pretty obvious to most users. Just as long as you can do it by pasting a URL I guess (embed codes should be avoided if possible).

The tiles might be perfect for images/video, but using documents is important too. I guess switching between the tiles/listing could solve this, but I can live with this as a nice-to-have.

Other than that, I really like where this is going!

Gábor Hojtsy’s picture

Issue summary: View changes
Status: Active » Needs review
FileSize
171.21 KB

@seanB:

I'm not really sure about the 'Modify items' page yet, there should probably be fields for each image instead of editing them all at the same time (at least it seems that you are changing the title/alt etc for all selected)? I would expect to do cropping/scaling here as well.

Since neither multi-edit, nor cropping and slicing is part of the MVP in core, neither would be possible here. The prototype does allow you to multiselect and hit edit now, but in practice we could hide the edit button when multiple are selected.

Deleting items from the library is also something to think about. What do you do with all references to the content? There might be different permissions for different items (you can delete some, but not all of them?).

Would you do this as a different button though or through editing (which is where it is now btw :)?

I'm not really sure about the term 'External content'. I think the term embedding is pretty obvious to most users. Just as long as you can do it by pasting a URL I guess (embed codes should be avoided if possible).

Well embedding is when you are using a piece of media as part of something else. Since this is the media library, and you are adding something to the library (not necessarily to an entity), does that count as embedding? I don't think so. Embedding is when the media library is invoked from editing a post and you pick what to add to your post (which may be a mix or remote and local media). So in that case should the Insert Selected to * button be labeled embed? :)

The tiles might be perfect for images/video, but using documents is important too. I guess switching between the tiles/listing could solve this, but I can live with this as a nice-to-have.

Yeah we need to define if switching between types of display of the library on the fly is part of the MVP or not. It was not listed in @webchick's list for the MVP, which means we should update that list (in the issue summary) if we think that should be part of the MVP and then plan for it in the prototype. I think based on the core conversation @slashrsm presented in Dublin, the existing media library solutions deal with this problem by using icons for documents, eg. here is his screenshot of file browser:

slashrsm’s picture

FileSize
396.5 KB

(a) the MVP (minimum viable product) requirements listed in the issue summary are complete

Yes, I think that they reflect what we want to achieve. I suppose that it is clear that not all of them can be scope for 8.3.

(b) the prototype implements the requirements in a sensible way

I have concerns about multi-file field editing (see my comment #62). Solution that @Gábor Hojtsy proposed in #67 seems sensible. Should we update mock to reflect that?

The tiles might be perfect for images/video, but using documents is important too. I guess switching between the tiles/listing could solve this, but I can live with this as a nice-to-have.

Yes, this can be indeed a problem. I assume that contrib will have more issues with this than core as it will provide many more media types that will need to be included in the library. However, since we want contrib to build on top of core we need to think about this. If we want library that is based on thumbnails then default thumbnail images work fine. If case that we want to expose more information something along those lines could be used:

(This is library that D8 version of Media module provides)

phenaproxima’s picture

I think we first need to choose exactly which of the user stories are 8.3 targets before I can give feedback on whether the prototype implements them. As @slashrsm pointed out, there's obviously a lot there that cannot make it into 8.3, but I think we should be explicit about which ones we are aiming for. Otherwise, many of the user stories are missing from the prototype.

That said, all the user stories seem reasonable to me, as does the prototype. IMHO, it definitely covers the 80% use case, at least. If we could get that into core tomorrow, I'd be over the moon.

A few quick thoughts, in no particular order:

  • In the library, how can the user filter by the ones which are theirs, and the ones which aren't? I think we'll want some sort of toggle for that.
  • The prototype does not include any kind of hierarchical categorization, except a simple filter by type.
  • I find the "Modify items" screen a little unclear. Is this a spot to enter the metadata for all selected items, before they are used? IMHO, that should be a function solely of the "continue" button -- the one marked "Insert Selected to Page".
  • For that matter, I'd like to change "Insert Selected to Page" to simply "Use Selected".
  • I think "Recently uploaded" and "Newest first" sort criteria basically describe the same thing. Why not condense them into a single "Recently uploaded" criterion?
marcoscano’s picture

Thanks everyone for helping this move forward! It's exciting to see this much needed feature making progress to be in core at some point. I am ready to help as much as I can from my side :)

I agree with others that at this point it may have become a little bit confusing what is the "minimum" part of the MVP and what is "doable" by January. I personally would be strongly in favor of simplifying everything that needed to be simplified (as long as all "Requirements" indicated are met), in order to have a very minimal Media Gallery in 8.3, taking for granted that we will consider the other needs as well when building the minimal solution, in order to be able to easily extend it later on.

For example, IMHO a solution that covers user stories 1, 2, 3 and 4 from the "Content authors" group already meets all points indicated in the "Requirements" section, and would very likely be achievable in the short term. Perhaps it could even make sense to have more than one version of the prototype, aiming at different subsets of the user stories?
For instance
- "Prototype-1" covering User Stories 1 to 4
- "Prototype-2" covering "Prototype-1" + 8 and 9
- "Prototype-3" covering "prototype-2" + etc.

In any case, re the questions in #65:

(a) the MVP (minimum viable product) requirements listed in the issue summary are complete

IMO, If we are talking about the section "Requirements" of the IS, yes, it is a good minimum.

I would add though an important User Story that is not mentioned in the IS and @phenaproxima commented in #69: at some point it will be good to be able to differentiate "My Library" from "Global Library" (for authorized users).

(b) the prototype implements the requirements in a sensible way

Yes but could be simplified, basically considering what others have already said before (re multi-editing, external content, etc)

yoroy’s picture

Status: Needs review » Needs work

Feedback from UX meeting 25 October 2016:

The requirements for the MVP make sense and the prototype fullfills them. Our feedback is on some essential details:

How to get into the library?

We need to list the multiple ways you can enter this media library, to get a complete picture of where the library can be triggered to appear.

  1. Via Files tab? Is there a non-modal version of the library that could replace what’s now on the files tab in the content manager
  2. Via CKEditor?
  3. Via Image (Entity?) entity field?
  4. …?

Shortcut to directly upload a new Image

The current proposal optimizes the workflow for reuse of existing images.

What about wanting to directly upload a new image? Can we provide a shortcut to do that? What about dual links (on a field, in ckeditor) for adding images (files)? “Upload new image” and “Use existing image”.

Arrangement of buttons, filters etc. on the overview screen

The placement of buttons, filters, links etc. is non-standard. It’s ok to deviate from what we normally do but those exceptions have to be made deliberately. Example: our “create new” action is placed top left by default, where in this design those primary actions are placed top right. A refinement of this would be welcome.

Where to add/edit metadata?

  • Alternative text and Caption fields: is there only 1 alt/caption text per image or can the alt text be overridden per placement? (Do we need overrides per placement as part of the MVP? Probably yes?) How would that work? (This needs testing?)

    Lets explore ways we can solve for how to handle canonical alt texts/captions and that these can be overridden.
  • Alignment (left, right, center): ideally would not be metadata in the library

Usability testing

This feature is big. We need to validate that it does what it should do. Should we test a refined wireframed prototype or is there a quick way to build a Drupal prototype? Lets agree on an approach for this.

yoroy’s picture

If you want to listen back to the disccusion: https://youtu.be/U-uJA8b6zFA?t=1m6s

@kiboman: it would be good to hear if you'll be able to work on updates to the current prototype. Already a great job done of course, just wondering if you'll have time to incorporate some of the feedback mentioned above. Thank you!

Leo Pitt’s picture

A thought on the latest prototype - "Add external content". Will content editors "get" that this.

E.g. ultimately this is where people should click if they want to add a Youtube video. I'm not sure if the terminology "external content" is sufficiently intuitive. In the long run, perhaps some iconography would be helpful here to illustrate the kind of thing it encapsulates (e.g. logos of applicable services).

tkoleary’s picture

@Leo Pitt

I think this will come up in testing if it's a problem.

Bojhan’s picture

It would be great if we can move from a prototype, as yoroy points out, the amount of functionality is hard to deduce from a few pictures.

Gábor Hojtsy’s picture

@Bojhan: what would be the ideal form for this then? I think we want to avoid implementing it with Drupal first. Do you envision a HTML based prototype?

Bojhan’s picture

Oh, totally this doesn't need to be in Drupal at all - invision etc.

Gábor Hojtsy’s picture

Here is a current screenshot from the UXPin

kiboman’s picture

Oh @Gábor Hojtsy, that screenshot shows only an internal "under construction" crap :)

The current version is here:
https://collaborate.uxpin.com/2fb662b681778d258cd91ef1dc32a8eeb3e1bf83#/...

Drupal | Media Library; MVP Prototype V0.8

Turn on the "sitemap" on the left and you can access these pages also:
Files tab: https://collaborate.uxpin.com/2fb662b681778d258cd91ef1dc32a8eeb3e1bf83#/...
WYSIWYG: https://collaborate.uxpin.com/2fb662b681778d258cd91ef1dc32a8eeb3e1bf83#/...
(Image) entity: https://collaborate.uxpin.com/2fb662b681778d258cd91ef1dc32a8eeb3e1bf83#/...

Gábor Hojtsy’s picture

Issue summary: View changes
FileSize
110.46 KB

Slighltly more up to date screenshot:

kiboman’s picture

tkoleary’s picture

Some notes on Interface text.

  • In 'Add new media', 'new' is not necessary, simply 'add media' is fine.
  • 'insert selected to page' is verbose (I am unlikely to think i'm inserting the unselected) and too specific (it might be a custom block). Simply 'Insert' is enough.
  • (+Use custom here) is verbose. Plus icon and parens are not needed, nor is 'use' or 'here' as those are assumed. Simply 'Customize' in blue with underline is enough to signify 'this is a trigger that lets me customize the text that's here'
  • The 'customize' trigger should come after the text, not the label, since it's the text that is being customized.
  • The custom text field should have it's own explicit label, eg. 'Custom caption', it should have space above to separate it from the default text and it should be indented to show that it's a child of the default text and not a sibling.
  • '(+Don't use custom here)' same as above. All that's needed is an 'X' icon to the right of the custom text label.
  • If the red asterisk to the left of alt text means 'required' it should be on the right, we always put required on the right.
  • 'Enter your custom alt text here' is redundant, it's a text field, 'enter' and 'text' are implicit. 'Custom' is redundant, the user just clicked 'customize' to get this field to appear. It's also a placeholder, not a description or instruction, so it should be phrased as one. It can also further underscore the scope of the field eg. 'Caption for this insertion'.

In general, every additional word added to the page increases cognitive load, so we should try to be as simple and direct as possible.

tkoleary’s picture

@kiboman

Just re-read above. Sorry if it sounds like a vomit of nitpicks with nothing positive. Overall this is really looking great.

tkoleary’s picture

@kiboman

Couple of other things I just noticed.

  1. In the prototype the "modify" link has a bug
  2. 'Select an item' Is not necessary I think
  3. 'Search' Looks like it is disabled. Is that intentional? Also if the function is 'filter the list' we use 'Filter by keywords', not 'Search'.
  4. Even though this is a grid and not a table I'm leaning towards the idea that we should still use the table head style for choosing the sorts since that is what users will be familiar with. A select is confusing because in the table context it denotes filter, not sort.
  5. I think 'All categories' can just be 'All'
  6. rather than having a 'modify item' link, what about a pencil icon on the upper left of a selected thumbnail?

By the way, I *love* the way you have differentiated hover and selected states on the icons. It could not be more clear.

mtodor’s picture

Is it possible to combine drop file dialog with media selection?

So instead of "+ Add new media" button, just provide drop-down zone at top of dialog (it doesn't have to be high). When files are dropped, they will be populated in dialog and selected. With drop-zone at top you have sufficient space for mobile touch to open file browser and for desktop versions it can be even more improved, that drop-down zone expands (overlay) over whole dialog when drag-over is noticed. That will reduce number of clicks and improve user experience.

I know that focus is on re-usability, but we have to think about creation of new medias (upload) and make it easier too.

Also user should have possibility to reorder selected medias, I don't know is it planned to be solved in form where selected images are used or it will be part of selection dialog.

tkoleary’s picture

@mtodor

I like the way you are thinking but I feel like that may be overloading the UI a bit.

Also I think perhaps we can step back a little further and think about the entire flow.

For example, based on the current design, if I am adding an image from the media library to the body of a node I have a six step flow:

Add from library to node body

  1. Click the 'image' icon in the WYSIWYG
  2. Sort or filter the media list to find my image
  3. Select the image
  4. Click 'insert'
  5. Edit the caption alt. etc.
  6. Click 'insert' again

But if I'm adding from my computer it's nine:

Add from computer to node body

  1. Click the 'image' icon in the WYSIWYG
  2. Click the 'add media' button in the media browser
  3. Click 'browse'
  4. Select the image from my computer
  5. Click 'open'
  6. Select the image from the list in the media library
  7. Click submit
  8. Edit the caption alt. etc.
  9. Click 'insert'again

Compare that nine step flow to the current 4 step flow of adding from the file upload widget:

Add to node image field from file widget

  1. Click 'chose file'
  2. Select the image from my computer
  3. Click 'open'
  4. Add the alt text

It seems to me that the simplest and most direct way to handle this is to have the user choose at the WYSIWYG level. Eg. there would be two buttons in the WYSWYG toolbar, the image button, which would open the media library, and an 'upload' button (cloud with up arrow?) then the flow would be:

Add from computer to node body (rev)

  1. Click the 'upload' button in the WYSIWYG
  2. Select the image from my computer
  3. Click 'open'
  4. Edit the caption alt. etc. in the media browser dialog
  5. Click insert

This definitely simplifies the primary case where the user *knows* the image is not already in the library. Of course it is also a likely scenario that the user *thinks* the image is in the library but gets there and sees it's not.

There we might also be able to improve the flow where instead of just 'add media' we see more options, eg. upload, drag-drop, embed. That way the user who wants to drag drop images can go to the drop area, bit the user who doesn't can simply go directly to the computer (upload), removing a step.

mtodor’s picture

@tkoleary: to be honest, I'm not supporter of idea with two buttons in WYSIWYG editor.

That implies that user already knows, does suitable media exist in library or not. I would rather keep "one tool" for adding medias (to rule them all). Where workflow is:

  1. open library
  2. search for useful existing media
  3. if you can't find anything useful simply upload/create new one and use it

I'm also afraid that exposed create new media functionality in WYSIWYG editor will lead to, always creating new medias without even checking existing ones.

tkoleary’s picture

@mtodor

I'm also afraid that exposed create new media functionality in WYSIWYG editor will lead to, always creating new medias without even checking existing ones.

Ensuring that there are not duplicates is an application task that should not be front-loaded onto the user. If an item with the same file name is uploaded the flow should be:

  1. Show a message 'a file with this name already exists in the library' with options 'replace' or 'insert existing'
  2. If user clicks 'replace' replace the file and show edit caption alt. etc. in the media browser dialog
  3. If user clicks 'insert existing' load the existing file and show edit caption alt. etc. in the media browser dialog
  4. User clicks insert

Not that this needs to be part of the MVP, but it should be on the roadmap, and if that is the case it should cause us to think differently about the WYSIWYG button.

mallezie’s picture

Let's not track same files on filename but on sha code of the file.

tkoleary’s picture

@mallezie

Let's not track same files on filename but on sha code of the file.

Sure, however we track them we should prompt the user to avoid duplicates, not expect them to do that themselves.

kiboman’s picture

The updated prototype is here:
https://collaborate.uxpin.com/c9905d865a57bed1fc72be93a4e937f126dac889#/...

Main updates:
- Source: Image entity: Completely redesigned the "Select new / Drag&drop+upload / Extrernal content" sectiona and workflow
- Add new item: Drag&drop and browse "works"
- Insert: updated UI
- After "drag and drop" or "file, browse, upload": New page

tkoleary’s picture

@kiboman

Wrote a text plan:

And tested on two users.

User 1: Developer, Expert Drupalist
User 2: Non-developer, Intermediate Drupalist and content editor

Both tests were recorded, compressing for upload now and writing detailed report.

Quick take aways. Everything tested *really* well with only minor confusion around the sort/fileter/tabs and re-usable meta-data, as expected.

tkoleary’s picture

tkoleary’s picture

And here is the report.

serg2’s picture

Great user tests.

The customise/canonical metadata feature does seem to cause the most confusion when the users are questioned about it. I view it is as an advanced feature so I think that is okay. Those who have no idea can safely ignore(or not even notice) and those that are looking for it can easily find.

Gábor Hojtsy’s picture

I also had a feeling that the overridable metadata is not trivial to justify as MVP :)

tkoleary’s picture

@serg2

Those who have no idea can safely ignore(or not even notice) and those that are looking for it can easily find.

@gabor hojtsy

I also had a feeling that the overridable metadata is not trivial to justify as MVP

Yes, it is a very much an expert feature and I do agree that we could de-scope it from the MVP without significant impact on what we deliver.

The question is what does the MVP look like without it? Ie. do we make all meta-data particular to the insertion (no canonical version) or only one set of meta-data per entity (only the canonical version)?

Inspector508’s picture

Any time an image is used, the person adding the image should be able to provide custom ALT text. Multiple instances of an image in a single site should be able to have different ALT text values.

webchick’s picture

Status: Needs work » Reviewed & tested by the community

Based on the UX meeting earlier today, it sounds like this is done enough to escalate to the core committers for sign-off, and begin implementation. Moving to RTBC status, so we can review it on our Ideas Queue review call later in the week.

@tmweiss raises a good point, but I feel like there will be lots of picky details like that that can be worked out during implementation.

Gábor Hojtsy’s picture

While this is not an implementation issue, copying implementation notes here from the DrupalCon Dublin media meeting minutes to give some context:

Library will be implemented in a form of a view, which will ship as part of a core experimental module. We will use a special media entity view mode to render each item in it, which will give us enough flexibility and allow contrib modules to easily include additional media types into the library.

kiboman’s picture

FileSize
41.49 KB
62.84 KB

The solution for "multiple upload file vs. single item insert" is here:
https://collaborate.uxpin.com/c9905d865a57bed1fc72be93a4e937f126dac889#/...
Multiple file upload vs. single item insert

The solution for the issue "Entity vs. upload (drag&drop) vs. Select from the library":
https://collaborate.uxpin.com/c9905d865a57bed1fc72be93a4e937f126dac889#/...
Entity vs. upload (drag&drop) vs. Select from the library

Bojhan’s picture

I have been able to review this more thoroughly this time (inc. the videos), and it looks great. Thanks for all this work!

A few comments

  1. How do you expect the "insert" pattern to scale, the screen insert selected seems not optimised to handle uploading 5/6 images very well?
  2. Can we have a more clear signifier that things have uploaded successfully, you are now just adding additional metadata? Other CMS's do this too, and its a nice small achievement
  3. The button placement and labeling could be optimised "Cancel", "Save and insert" and "Save" all next to each other is a little ambiguous.

Overall I am quite pleased with the clean and overall look, hope that we don't see any big blockers to getting this done.

tkoleary’s picture

@bojhan

How do you expect the "insert" pattern to scale, the screen insert selected seems not optimised to handle uploading 5/6 images very well?

I'm going to assume that for multiple images the screen where users can customize meta data will look more like the screen where multiple items have meta added, ie. a list with internal scroll. But just FYI we agreed to de-scope customizing meta from the MVP in the last UX meeting.

Can we have a more clear signifier that things have uploaded successfully, you are now just adding additional metadata? Other CMS's do this too, and its a nice small achievement

Very good point. We should add that in the implementation phase.

The button placement and labeling could be optimised "Cancel", "Save and insert" and "Save" all next to each other is a little ambiguous.

Yes, that's what the testing showed also. The buttons should be aligned left as in all other core dialogs and the differences need to be more clearly worded, but those are refinements that can happen in implementation and should not block commit of this prototype issue.

tkoleary’s picture

Added this follow-up issue as part of 'plan'

#2828538: Produce high fidelity screens based on Media prototype

tkoleary’s picture

@kiboman

The solution for the issue "Entity vs. upload (drag&drop) vs. Select from the library":
https://collaborate.uxpin.com/c9905d865a57bed1fc72be93a4e937f126dac889#/...

This came up in UX meeting and we referred to a design that exists for Seven upload widgets that has never been implemented. Ideally this should incorporate styles from those designs.

There is already an open issue to implement those designs of which this should be part.

xjm’s picture

Very exciting to see this RTBC! Is the summary up to date? There have been over 100 comments that I suspect might not be summarized yet. I find myself nodding along to most of the summary but some things I have reservations about:

Simple enough spec to implement by January.

I think that's overambitious. We should take the time it takes to ship an experimental MVP. Right now "by January" basically means "over the holidays" so let's not artificially prioritize "simple enough spec" for that deadline. Instead, let's focus on making a minimum, viable experimental product.

In terms of the user stories, I'm totally on board for points 1-5 of the content author story. However, after that, I start to see things that don't necessarily belong in an MVP (and seem to contradict the "simple enough" part early in the summary:

"When I add media to a piece of content I wan to be able to scale, crop, or rotate images I am adding so that I don't have to open them in an image editing application, edit, re-save, and re-upload them just to make a simple change."
"When I add media to a piece of content I need to be able to browse files by (maybe hierarchical) categories related to my business, so that I can quickly find what I am looking for"
"When I add media to a piece of content I want to be able to add content I've seen on Facebook, Twitter, Youtube as easily as uploading media from my own computer."
"When I'm dealing with media I've seen on Facebook, Twitter, Youtube etc, I want it to 'just work' and not have to deal with techie jargon like 'embed codes'"

Similarly the second point for content authors:

"When I browse media in my site I want to be able to enlarge or reduce the size of the thumbnail images so that I don't have to open each one to see it in greater detail"

And then for site builders, I totally want all three of the points listed, but also don't think they belong in an MVP:

'When I add media to my site I want to be able to add multiple files at once so I don't have to upload files through the UI over and over or figure out how to manually put things in the file system"
"When I add multiple media files to my site I would like it to be as fast and simple as possible whether the files are coming from my computer of from another remote source"
"When I add multiple media files to my site I would like to "bulk fill" some fields with the same value so that I don't have to repetitively fill the same field with the same value over and over for many files"

Looking forward to seeing a demo of the prototypes today!

tkoleary’s picture

Issue summary: View changes
slashrsm’s picture

Issue tags: +Berlin media sprint
samuel.mortenson’s picture

Issue summary: View changes

@xjm I also found that many of the stories are probably not covered by an MVP, so I went ahead and marked stories with an "*" if I thought they were MVP-worthy.

samuel.mortenson’s picture

Issue summary: View changes
samuel.mortenson’s picture

I created #2834729: [META] Roadmap to stabilize Media Library, which I can start working on from an architecture perspective as we discuss MVP requirements here. To be clear no media-specific library (code) will be worked on until this issue is closed/finalized.

Leo Pitt’s picture

Hi - something that has been bothering me regarding the media library and it's fit in the Drupal ecosystem. Tell me if there's somewhere better to raise this; How is this going to fit with Entity Embed in the long-term? Do we envisage the two coming together at some point?

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

I think its technically more correct to mark this fixed in light of #2834729: [META] Roadmap to stabilize Media Library?

Status: Fixed » Closed (fixed)

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

phenaproxima’s picture

Component: Prototype » Idea
Issue tags: -D8Media +Media Initiative