Customize: collapse suggested and previously uploaded header images with accordions

[celloexpressions]

The custom header image control takes up quite a lot of space, which is why header videos are, somewhat confusingly, placed before the image control. We could improve this by collapsing the suggested and previously-uploaded images by default, making the headers/labels expandable/collapsable. That would allow larger image collections here without taking up too much space.

Alternatively, other ways to show these collections should be considered, such as in the media modal. Eventually, we'll want this UI pattern to be able to expand to be used in other media controls.

[folletto]

Two things for this discussion:

1. I'd try to avoid an accordion-like approach as we already moved away from that elsewhere, or, if we do, let's try to find ways and be clear about its usage. In this specific instance, I'd for example explore a "More at the end" approach of some kind instead of making the headers foldable.
2. Can we maybe use a drill-down approach? (i.e. a menu like the top level one saying "More..." or "Past media..." that opens a new panel with just the list) This should be especially effective if we expect longer lists.

[celloexpressions]

Sure, it doesn't necessarily need to be an accordion. The key is making it take up less space by default. My initial though it that the titles can become button elements with arrow icons, and on click the contents slideToggle. Something simple that can be done in the interim until the header image control is brought back into the cropped image control and previous images are available to other control instances.

[westonruter]

I recall @melchoyce talking about wanting to implement similar UI as was implemented for the video widget, where an uploaded video and a URL can both be supplied in the media modal.

[folletto]

Customizer Header Media i2

[folletto]

Added a i2 design to address this issue (and more).

1. Simplifies the "Header Media" page to a cleaner look, with the list of all the options clearly visible and with a uniform visual hierarchy.
2. Moved all the options of each of the two panels (Header Image, Header Video) to sub-panels with full explanations.
3. Removed the replication of the current selection between the list and the top item. Now the list is the selection.
4. The list adds a checkbox to add a clear visual cue of which item is selected.
5. The dotted area can be clicked or drag'n'dropped to add new images or videos.
6. Randomize is an option, thus has been changed from a button to a checkbox (what happens when selected isn't designed yet, but it will mark the list and the image differently).
7. Randomize now specifies the number of headers in the randomization, adding clarity.

This design thus addresses the space an confusion concerns of this ticket, also improving the overall visual hierarchy of the functionality and without introducing new design patterns makes it more modular for future additions.

[celloexpressions]

If we go that route, this should be implemented in the base WP_Customize_Media_Control and made optionally available to all media controls. There is an existing, distinct ticket for that change (allowing media controls to show previously-selected items), and discussion should be moved there if we want to go with anything more involved than a quick-fix for the current UI.

[melchoyce]

@folletto I think drilling down works pretty well here 👍

@celloexpressions Yeah, would be good to get this working with other media instances in the Customizer. @westonruter Do you think this should be a quick-fix for 4.9, and then we can look at WP_Customize_Media_Control later, or should we just go straight to looking at it everywhere in the Customizer?

[westonruter]

@folletto In i2 I'm unclear on how you go from the Header Media panel into the sub-panels for Images and Video. If I understand properly, it seems to be depicting a new Header Media panel and then a section for Header Images and Header Video, but instead of the section links on the panel being mere labels they instead have full controls?

@melchoyce I'm unclear of where else in the Customizer this would be applied.

[folletto]

In i2 I'm unclear on how you go from the Header Media panel into the sub-panels for Images and Video.

They open when the user taps on "Change " (image or video): the sub-panels are the UI to change the content.

If I understand properly, it seems to be depicting a new Header Media panel and then a section for Header Images and Header Video, but instead of the section links on the panel being mere labels they instead have full controls?

(We had a chat because I wasn't understanding the full implications of this. Summarizing...)

Apparently the way the current Customizer API is structured requires a sub-panel to have a specific kind of label in the panel that opens it (similar to what we have in the main navigation list, or in the widget list). This means that we don't have the flexibility to just load the sub-panel from anywhere.

This opens an API consideration for the future: it's important for the customizer architecture to be able at some point to "pop in" any sub-panel in a programmatic way, from any controller, with a single call, without mandating how it should look like. This is how any stack control works (see iOS UINavigationController from example). This is one of the reason we have a lot of customizer screens that try to cram content in a single column instead of breaking in sub-panel. It's a fundamental interaction that thus require a flexible and simple API. Given the considerations on the upcoming Gutenberg tho, it's not valuable to work on this now, as the architecture might change radically. It's still worth to point out since if even later we end up to load stacked panels, the API needs to be straightforward.

I will thus follow up this issue with a new design that doesn't require a rework of the current customizer sub-panel API, making it possible to implement this easily.

[westonruter]

Apparently the way the current Customizer API is structured requires a sub-panel to have a specific kind of label in the panel that opens it (similar to what we have in the main navigation list, or in the widget list). This means that we don't have the flexibility to just load the sub-panel from anywhere.

That's not absolutely the case. We can put anything we want in the label area with a custom section. My concern was more surrounding that there historically have not been controls placed in these locations. The API is written in a way where panels contain sections and sections contain controls. We've not had a situation where a full-on control is embedded in this context, outside of a containing section. There is, in fact, an issue (#38077) where we've prototyped allowing controls to be embedded outside of sections and outside of the traditional UI structure entirely. So that would need to be a dependency here. For a control embedded in a section label (technically the headContainer), and for any such detached controls, we'd need to override the focus method to skip trying to expand its containing section, since it wouldn't have one. Instead, it would need to expand the containing panel.

In the future the Customizer JS API and UI architecture should be made more flexible to allow for more complex flows as well. Adding a control to a section label can be done in 4.9, though it may not be the cleanest implementation.

[melchoyce]

Replying to westonruter:

@melchoyce I'm unclear of where else in the Customizer this would be applied.

Hah, good question. Background image support, maybe? Or maybe just people who've made their own custom theme settings.

[folletto]

In the future the Customizer JS API and UI architecture should be made more flexible to allow for more complex flows as well.

Thank you for the clarification! Yes, decoupling and making the stacking of panels a one-line call is a must have thing in the API in the future.

[folletto]

Customizer Header Media i3

[folletto]

Ok, added i3 of the design:

1. The control to open the sub-panel is now the basic, default customizer control, thus not requiring any extra work.
2. Requiring the sub-panel to have remove, now we have an explicit element in the list that says "No image" / "No video", which... actually seems better regardless due to being explicit.
3. Some minor changes such as the plus icon to the add area.
4. Everything else as i2 before.

[westonruter]

@folletto yes, i3 will make it much simpler to implement, as now the changes to the section labels are purely stylistic, essentially just previews for what the user will find when they expand them. What should these look like if there is no selected video or header image?

[folletto]

i3 will make it much simpler to implement, as now the changes to the section labels are purely stylistic, essentially just previews for what the user will find when they expand them

Ace!

What should these look like if there is no selected video or header image?

If there's agreement this is the way forward, I'll make these other states.
I didn't want to do the full mockup if we didn't pick it in the end. :)

[celloexpressions]

Replying to westonruter:

@melchoyce I'm unclear of where else in the Customizer this would be applied.

For WP_Customize_Media_Control and all children, with an instance parameter (my thought was to call it library) for controls that want to opt-in to facilitating switching between various previously-used settings for a control. Site icon (#32861, where a tab in the media modal or a slide-out panel are the most recent suggestions) and background image are probably the only other core controls that should opt-in.

I would encourage an exploration into other UI options such as the add-widgets fly-out panel, which may be more appropriate in terms of API convention. Regardless, the implementation of the current approach should be done as new functionality that happens within a control object as opposed to using a section. Single-control sections are discouraged, as the purpose of a section is to group multiple controls together. Rather, this should be implemented as a more complex control and can provide the illusion of sliding into another visual "panel" (like the add-menu-item control, particularly on mobile), use a modal, or potentially take a more inline approach to expanding to show additional items.

All of this should probably be happening in #36581 if we want to actually fix it. #36581 is an absolute prerequisite to doing this, at a minimum. I thought there was an additional distinct ticket to extract the library functionality back to the base controls, but that seems to be #36581 as well. Previously: #29211. This ticket was for an interim solution and can be closed (or the summary and description rewritten) if we go with the full fix, which it sounds like there's interest in doing. The quick fix being to hide the images as a space-saving measure, rather than improving the functionality more broadly. Any improvements to header images need to coincide with allowing those improvements to apply to all media controls, which will be straightforward once #36581 is complete.

[folletto]

Sketch source for "Customizer Header Media i2-i3"

[karmatosed]

As this has feedback, during the design triage going to remove the feedback labels for design.