Problem/Motivation
While working on #2831274: Bring Media entity module to core as Media module we identified UX issues with the metadata mapping UI on the Media type form. We agreed to solve this problem in a follow-up.
Proposed resolution
- Offer automatic creation of fields.
- Don't allow same field to be selected for more than once
- Update UI and potentially add checkboxes to opt-in
- If mapping to existing fields, we might want to filter target fields by their data type
- Should we describe metadata attributes?
More info: #2834608: Media entity UI review
Remaining tasks
- Decide on solutions.
- Implement changes
User interface changes
Media type form will be updated.
API changes
None.
Data model changes
None.
Comment | File | Size | Author |
---|---|---|---|
#22 | metadata-fields-checkboxes.png | 214.84 KB | yoroy |
Comments
Comment #2
Gábor HojtsyWe discussed this in great detail in Berlin and @yoroy suggested this along with a video (copied from #2834608-3: Media entity UI review):
We discussed this would not be required for initial commit of Media module. We did not discuss if this would be needed for Media to be stable or not.
Comment #3
tkoleary CreditAttribution: tkoleary at Acquia commentedSo we did something similar to this with RDF UI module for Drupal 8 where we have a wizard UI for creating field mappings before the entity type is created.
Here's a quick demo video I made of the flow.
In the case of media we could have a bunch of metadata field types that we could arbitrarily organize into 'entity archetypes' like 'Video embed' or 'Social media post' but with all of the remaining types thrown in at the bottom under 'other' so the arbitrary organization would not be resrictive.
This is somewhat similar to what Roy suggested, but it's something we already have good example Drupal 8 code for so presumably easier to execute.
Comment #4
Gábor HojtsyFirst of all we plan to ship with default media types for images, documents (local files) and remote video. Those could have fields for metadata added by default if we believe that those are the 80% use case. I don't think the media team believed that the metadata fields should default to get created on new types, so that needs some thoughts for the default shipped types as well. If we have those default fields, people who are happy with the built-in types which would be a relatively sizable audience will never need to cope with the mapping UI. I think we need the mapping UI to be better nonetheless.
Comment #5
tkoleary CreditAttribution: tkoleary at Acquia commented@Gabor Hojtsy
Yes, I agree. So if we have a set of metadata fields that are provided with the default types, then our MVP for create a new type could start with a UI similar to the RDF UI create entity where the list of possible metadata fields contains all of the ones from the default types.
Comment #6
Gábor HojtsyWe may be talking past each other but I think we already have that? If you look back at the UX review video at https://twitter.com/drupalux/status/808952925938679808 then you'll see that we have all the metadata elements lined up for the corresponding media type. (Look at Marcus' demo towards the end of the media section). Is that not what you are looking to have?
Comment #7
tkoleary CreditAttribution: tkoleary at Acquia commentedSort of but not completely.
Right now there's just the label and the select. What I would hope to see would be something more like the RDF UI version where I have the ability to configure the mappings as well as all the 'data type' at least the form widget. Also the 'Enabled' column is a much more explicit affordance that not all fields are required and avoids the problems with 'skip' I commented on in the other issue.
Comment #8
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commentedData type is implicitly defined with the mapping. If a given field is mapped to an entity field of a certain type (string for example) it can't be anything else. We updated metadata API to allow us to pass type information with fields, which will enable us to only show combinations that make sense.
How would metadata mapping on a separate page work from UX perspective? Let's say we remove that part from media type form entirely and add another local task next to it. That local task would then potentially show something similar to RDF table from your demo. This way we hide this complexity from users that don't want to deal with it.
Comment #9
tkoleary CreditAttribution: tkoleary at Acquia commentedI like the idea of simplifying the flow for users who do not want/need to configure metadata fields, but ideally it should not necessitate pulling the user out of the type creation flow. That could be accomplished by adding a checkbox "Add metadata fields" which would be unchecked by default and when checked would expand the fieldset with the field mappings.
We use this conditional configuration pattern on node/add for "create new revision".
Comment #10
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commentedMetadata mapping is not necessarily part of the type creation flow. It is more like an advancement and it is not required for type to fully work.
Comment #12
phenaproximaMarking for UX review, based on #2831936-140: Add "File" MediaSource plugin.
Comment #13
Bojhan CreditAttribution: Bojhan commentedNot sure what to review, slash mentioned a solution that seems like a good in-between and would need some development to see what it could look like.
Comment #15
marcoscano#2862467: Add complex field mapping to media module is highly related
Comment #20
xjmComment #21
yoroy CreditAttribution: yoroy at Roy Scholten commentedIf it still holds that you can create types with good enough defaults without having to explicitly map things, then the first move here would indeed be to move mapping to its own tab. As for what kind of UI is offered there is then the next decision. I'd suggest to start with moving over the existing UI :)
Considerations when mapping is in it's separate tab:
- Whether to offer "set mappings" as an optional route from the initial type creation workflow (just a "Save" button or a "Save" button and a "Save and map metadata" button?) Or with a checkobx as @tkoleary suggested in #9, or…
- Which if any UI pattern would be an improvement over what's currently there. I haven't looked at the details and variations of what mapping entails.
Moving mapping things to its own tab would give us the space to figure out the details, so start there?
*Edit*: https://www.drupal.org/project/drupal/issues/2862467#comment-12454546 has details on how mapping works.
Comment #22
yoroy CreditAttribution: yoroy at Roy Scholten commentedHad a closer look at this.
- It doesn't make sense to offer metadata mapping in the workflow for creating a new media type. When setting up a new media type, the main task is setting and configuring the media source and its corresponding field. There simply is no way to create the "destination fields" for metadata aspects beforehand. You have to save the initial media type before you are even in a position to create fields that can be mapped to metadata aspects.
- There's no guidance on which type of field to create for a given metadata aspect. I *probably* shouldn't create a date field for storing the MIME type, but that's all left to the human to figure out, but the system could (should) help here. File size as a number? Widht? Height? No fun in having to figure that out :)
- The current field mapping UI lives under the "Edit" tab of Field UI. The current workflow for creating a new field (say, a short text field for storing the MIME type) sends you back to the "Fields" tab of Field UI. There's a disconnect there: you have to switch between tabs at the start of creating a "destination field" and one more at the end.
Not in scope but very related: these metadata aspects seem similar to how content entities bring along their own out of the box fields like published status, authored by, authored on, etc. Good to have around but I didn't explicitly ask for them. With content types, these fields sort of mess up the "form display" and "display" tabs in Field UI, while not even listed on the Fields tab. This is confusing. This is related because these metadata aspects are another family of fields that aren't really fields (yet, in this case).
As for possible improvements
### Don't even offer to map metadata during intial setup.
You simply can't map metadata for a media type that hasn't been saved yet. The one default mapping that is offered is filename to title (name), because title fields are a given in all cases. Even this apparently a questionable default, if I understood correctly the Umami team has explictly configured their profile to not do this.
### Explore if/how we can ship with sensible default destinations fields
It would be a lot easier for many if the user interface could offer to automatically create a sensible field for a given metadata aspect. Conceptually it would be as simple (I know, it's not :-) as presenting a list of checkboxes for each available metadata aspect. Check, check, check -> Create fields for these. Whether that then happens completely under the surface or if that kicks off a more focussed "add field" workflow (in a modal?) is something to discuss, explore. One way this might work is to present these checkboxes in a "waiting room" fieldset at the bottom of the Fields listing in Field UI:
Comment #23
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedRe. #22
There's a small gotcha to this. When a new media type is created, media_library form/view displays are created automatically. The decision to show or hide the entity label depends on whether it was mapped on the "add media type" form.
If we remove mappings from this form, we'll need to rethink how to handle that decision. One way might be to map the name field by default behind the scenes, but not map any other metadata. The entity label is the one field we can be sure will actually exist. In most cases, the name field should probably be mapped andhidden from the media_library form display, but we could let media source plugins specify their own default mapping for the entity name.
Comment #24
yoroy CreditAttribution: yoroy at Roy Scholten commentedAh, looks like that could be (part of) the rationale behind mapping the file name to the title field by default, thanks.
Also: We discussed this issue at the #3122673: Drupal Usability Meeting 2020-03-26. Video: https://youtu.be/ssqkdTqFn4Q , this was the first topic we discussed so start at the beginning :).
Comment #25
seanBThanks yoroy! Just watched the UX meeting recording. I also did some investigation on how to improve this in #2862467-10: Add complex field mapping to media module. The ideas are kind of similar. Interested to see what you think about the ideas in there, there are some things (like multiple field type support) that make it even more complex.
Not sure yet if we should close 1 of the issues as duplicate, we might want to first improve the UI with what we have (no support for entity reference fields for example), and add complexity later.
Comment #27
phenaproximaComment #29
volkswagenchickAdding
NorthAmerica2021
andEasy Out of the Box
tags for visbility.DrupalCon NA is April 12-16 with a focus on EOOTB on Wednesday, April 14.
Thanks
Comment #32
joachim CreditAttribution: joachim at Factorial GmbH commentedSome issues which are either related to this / children of this / quick fixes while this gets figured out:
- #3249880: Media type form element for 'Field with source information' shows inconsistent field labels
- #3251647: Field mapping options in media type form are not sorted correctly