Improve metadata mapping UI on Media type form

We discussed this in great detail in Berlin and @yoroy suggested this along with a video (copied from #2834608-3: Media entity UI review):

Exploring alternatives to the current metadata field mapping UI: https://drive.google.com/open?id=0Bz3wdj7xhdmUOS1ZNThnd0FiMFU

Gist is that when creating a new bundle, because of the current workflow the fields you want to map to can not be present yet, because the mapping ui is in the "Edit" tab, which you must pass first before you can get to the "Fields" tab where you can create new fields.

The video explores how to work around that while keeping the field mapping UI where it is now.

Another route to explore might be to move the whole mapping bit to the "fields" tab instead of the "edit" tab (if technically possible)

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.

So 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.

First 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.

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

We 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?

Sort 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.

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.

I 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".

Marking for UX review, based on #2831936-140: Add "File" MediaSource plugin.

Not 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.

#2862467: Add complex field mapping to media module is highly related

If 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.

Had 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:

Re. #22

- It doesn't make sense to offer metadata mapping in the workflow for creating a new media type

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.

Ah, 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 :).

Thanks 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.

Adding NorthAmerica2021 and Easy Out of the Box tags for visbility.

DrupalCon NA is April 12-16 with a focus on EOOTB on Wednesday, April 14.
Thanks

Some 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