Improve the Customize experience on mobile

[celloexpressions]

The Customizer currently works on mobile, despite what you might think. Utilizing the "collapse" function, it's possible to change settings and switch back and forth between the controls and the preview window. But the experience doesn't work on every device (there are some scrolling issues), and could be much smoother and more intuitive.

The controls part of the Customizer is already mobile-optimized - at 300px wide, it works quite well on mobile and the only major issues are with things like the widget-adder that pop out of the main control panel. Similarly, the preview works down to tablet-sized devices with responsive themes, although it continues to be squeezed to unrealistic widths on smaller devices.

We should look at revamping the Customizer experience on smaller devices - anything smaller than about 620px wide can't realistically be used in the standard controls/preview mode. For this ticket, the goal is to make the cosmetic tweaks necessary to streamline the Customization experience on mobile, most likely by hiding the preview at a certain point and highlighting the ability to switch between the controls and the preview.

[celloexpressions]

First pass, as a plugin (mostly CSS)

[celloexpressions]

Adds a way to exit adding-widgets, adds swiping left/right to show the controls/preview (can't swipe over the preview, though). jQuery mobile is creating a ton of bugs; would probably just extract the functionality we need (swipe events).

[celloexpressions]

Low-framerate screen capture, but you get the idea. Most of the random formatting regressions are jQuery mobile's fault. All interactions with touch, Chrome on Win8.

[celloexpressions]

On a smaller screen (also, higher framerate).

[celloexpressions]

Bundle a stripped-down version of jQuery mobile (touch events only), add swiping to back out of panels.

[folletto]

After a discussion on #28979, porting here the relevant piece to keep the conversation going:

Reporting my comment from the other thread:

The most important point imho is that the cognitive load of slide-ins is lower than accordions, not higher, this for a moltitude of reasons:

1. The number of clicks is identical
2. The positioning is preserved both in the navigation AND in the customization panel: fixed positioning helps people with spatial memory to recall items, creating visual trust.
3. Slide-ins separate also clearly navigation from content. It won't be a mix of navigation and content, like the accordion (note that this isn't something new, many accordion solutions ask for a uniform set of content, like all menu, instead of mixed one. The same recent Google Material Design manual outlines accordions for menus only).
4. Moving sections rely on our spatial memory overall, while things that fold/unfold will keep moving the whole page up and down: I click an accordion, content appears in between, suddenly the "next" item is way below, moving it as a target.
5. It's easier to scan a pure list of items, instead with an open accordion the menu is disrupted.
6. An open slide-in is clearly just that, thus helping the user to focus on that content, instead of having first to separate it from the context. It's a cleaner solution.
7. Not to mention the potentially improved elegance of keyboard navigation... (left-right-esc). ;)

This doesn't mean that accordions are bad overall, clearly, however they must be very carefully isolated from context, and used where possible not as navigation but as exploration (i.e. not menu-with-content, but already descripting items with "more"). ;)

I'd note also in regard of #27406 that slide-ins are a better solution regardless of their use as a multi-layer hierarchy, or not. In other terms: if we could instantly convert all the accordions to slide-ins right now, it would still be an improvement even without implementing a multi-layer structure (even if I'd personally find it the natural step forward).
I've seen your work there... I think it was the right direction... and reading the thread does look to me that there was agreement on that being a better solution, no? :)

Plus, all of this, good for desktop, would be just bliss on mobile. ;)

And celloexpressions:

Lots of great points here. I think the biggest thing is separating navigation from content; that would facilitate changes like what I proposed in #29158 to make the Customizer feel more like wp-admin. My remaining concern would be wasted vertical space within Customizer sections that only have one or two controls, but that's something that developers could adapt to.

So, in the context of this specific ticket, would be great to experiment a solution that consolidates both desktop and mobile using slide-ins instead of a mix of slide-ins and accordions. ;)

Would be a big win in consistency and usability of the customization experience. :)

[dancameron]

Nick,

After a little bit of work this morning I was able to clean things up and post the plugin on github (​https://github.com/dancameron/mobile-customizer/tree/master) for review.

Here's a quick run-down, if you remember anything else we discussed yesterday (at contributor day) please add it.

Swiping
I removed swiping in my version. Not because I couldn't get it to work but with the design I currently have it's completely unnecessary (IMO). If swiping returns it should be to pull the customizer section out (expanding it) with handle, whether that's the icons or not. IMO swiping the controls in from off screen isn't intuitive with iOS and ASAIK other mobile OSes having a swipe from left offscreen gesture translate to going back--which would cause false swipes and a bit of frustration for the user.

Changes...

Icons

• The customize controls have icons now but may need additional attention since some could have better relations with another dashicon that I'm not aware of.
• Clicking an icon in the collapsed view opens the section.

Title and Description Section
At first we discussed the edge case of long site titles, etc.. Instead I ripped this section out since that space is too valuable to show something the user should already know.

Preview

• I like the current layout of the header but don't like the look of the "Preview" link since it's surrounded with what looks like two buttons. You saw what I had originally done with making it a Preview a button but with the Save button changing width it ended up being a rabbit hole I didn't want to dive into. I also understand that a designer might look at this and want to completely change the UI.
• A UI I thought about doing was moving the preview below the menu items and making it a full width button. The problem I had with this is that a long menu would not show the preview button above "the fold" as well as there would be no link to close the preview.
• The context of the icon should change when in a preview state, since the open eye still shows.

Header
I cleaned up some spacing and sizes. I think the background should not be black; the issue I expressed yesterday is that the user may think that the header is the admin bar, not the customizer, if the color schemes match.

Widget Panels
Added a simple trigger to close the panel if the user selects preview. IMO this is a better UX trade-off: since jumping back to the beginning wouldn't confuse the user, instead it may frustrate them that they need to click widgets section again...at least they know where they are.

Next Step
There's possibly a few bugs that need to be resolved but I'd like to get to a point where our direction is agreed upon; no sense in finalizing something that will end up moving in a different direction. In my completely biased opinion I believe this looks good but appreciate any feedback in making it better and possibly added to core.

[ocean90]

Replying to dancameron:

Nice work so far! Also I share your concerns about swiping.

[celloexpressions]

This is looking great, Dan!

Replying to dancameron:

Swiping
I removed swiping in my version. Not because I couldn't get it to work but with the design I currently have it's completely unnecessary (IMO). If swiping returns it should be to pull the customizer section out (expanding it) with handle, whether that's the icons or not. IMO swiping the controls in from off screen isn't intuitive with iOS and ASAIK other mobile OSes having a swipe from left offscreen gesture translate to going back--which would cause false swipes and a bit of frustration for the user.

I agree, swiping to open the controls could cause issues and we have diect tap targets anyway. We'll probably want to do swiping to back out of panels still, but let's break that out to #29593.

Icons

We now have a dependency on #28504 for this. This approach addresses the primary concern there that the icons aren't necessary due to the lack of a collapsed state. We should consider leveraging this new view (without the header) for the collapsed mode on larger screens as well, as (as you noticed yesterday) the current collapsed UI is practically invisible.

Title and Description Section
At first we discussed the edge case of long site titles, etc.. Instead I ripped this section out since that space is too valuable to show something the user should already know.

This is probably okay; I'm generally not a big fan of hiding things on mobile, but it's just the main customizer help sentence or the theme preview name/description, which could also be redundant. The other option would be to only hide it in the collapsed state; that would cause some vertical icon jumping but might be okay. Related: I think we need to make it overflow-y: hidden also since getting a scrollbar on collapsed icons looks strange.

Preview

Agree that this part will need some more work.

Header
I cleaned up some spacing and sizes. I think the background should not be black; the issue I expressed yesterday is that the user may think that the header is the admin bar, not the customizer, if the color schemes match.

Let's also try making the icons be on an #eee background instead of #fff to match the rest of the frame. This could all change if #29158 happens in some form, so let's not worry too much about it.

Widget Panels
Added a simple trigger to close the panel if the user selects preview. IMO this is a better UX trade-off: since jumping back to the beginning wouldn't confuse the user, instead it may frustrate them that they need to click widgets section again...at least they know where they are.

Actually, we should definitely do this because it wouldn't make sense to have icons on sub-sections in panels. So the icon view is only really useful if we bump out to the top level anyway. Maybe a bit disruptive, but for good reason.

Next Step
There's possibly a few bugs that need to be resolved but I'd like to get to a point where our direction is agreed upon; no sense in finalizing something that will end up moving in a different direction. In my completely biased opinion I believe this looks good but appreciate any feedback in making it better and possibly added to core.

This is definitely a good start! There are several minor UI things (and places where we can simplify/remove animations that shouldn't be seen), but I agree that we should finalize the direction before making it pixel-perfect. I'm going to leave those notes in a separate comment.

[celloexpressions]

Next steps/general plan of action:

1. UI/UX feedback. Currently a plugin that should work on 4.0 to facilitate broader testing on mobile devices when thinking about the experience this provides. No major concerns with putting that plugin on a production site temporarily, either.
2. Based on feedback, either clean up this approach or try another idea from scratch.
3. Once it's looking pretty good in plugin form, convert to a core patch, code cleanup, etc.
4. Iterate patches until it's ready for a first-run, then potentially do additional testing and changes as needed in core.

4.1 timeline hasn't been discussed yet, but I'd estimate that we have about a month or two to get this into 4.1. In the meantime, I've indicated on #28504 that that's a dependency on this.

[dancameron]

Replying to celloexpressions:

Next steps/general plan of action:
...
4.1 timeline hasn't been discussed yet, but I'd estimate that we have about a month or two to get this into 4.1. In the meantime, I've indicated on #28504 that that's a dependency on this.

Thanks Nick. Let me know if there's anything that I could do to facilitate this.

[folletto]

I can help on UX here. ;)

I think that @celloexpressions' concept above is a good starting point. To build on that I'd analyze the user flow in a mobile context: if you think about it, the flow is around "make a change and see what it means".

This translates loosely to a flow that is like this:

• Open customizer
• Open a panel
• Make the change
• See how it went
• Make an adjustment to the same panel
• See how it went
• Go to another section
• Repeat

This means that we have a sort of "toggle" between change and result of change, which on mobile follows the same pattern of the UI prototype above.

With this in mind, I feel that we should optimize for both these moments: change and see.

I'm attaching an idea here that hopefully has minimal UI impact, using the top bar as a reference. The idea is that when you change something you can switch to preview and back to customizer quickly. The customizer takes the full screen, so you're well immersed, while the preview page has only a clear and simple bar at the top that either goes back or publish.

Note that while this adds a single tap vs the idea of keeping the icons on the left side when previewing, it is well balanced by some benefits that I feel weights more than the single tap we spare:

1. Gives us the proper, full width preview, which is what I want to see on mobile.
2. Still has the full customizer one tap away, which in case of adjustments (likely) is the same one tap away I would get either way.

I hope this helps. ;)

[folletto]

Customizer Mobile: customize with preview

[folletto]

Customizer Mobile: preview of the page

[celloexpressions]

I think we should go with @dancameron's concept on larger devices for an improved collapsed view, and go with @folletto's simplified approach on mobile. I think on smaller screens it'll come down to the horizontal space needing to be fully devoted to preview, whereas there's typically more space available vertically. We might run into space issues with translations on that, although sizing the labels like @folletto did should work.

Someone should create a new ticket for the icons-collapsed view and put @dancameron's work there, then we need either a patch or another plugin iteration for the mobile concept. At this point, it might be worth moving to patches and having people test once they get in.

[celloexpressions]

I've moved @dancameron's work to #29949, and converted the relevant part of his plugin code into a patch. That should be able to get into 4.1 without issues, and will make the mobile stuff a bit easier to implement. The collapsed view with icons is not displayed before 600px width in the patch there.

While the two-mode mobile approach is essentially what some of the earlier concepts posted on this ticket do, it needs refinement and a patch, so I'm going to move this off of 4.1 for now. With a patch within the next week or so, it could probably be back in 4.1.

[celloexpressions]

Fresh approach: just do a simple header with a toggle, no animation, nothing unnecessary.

[celloexpressions]

Fresh approach: simple header with a toggle between the preview and the Customizer controls, no animations or swiping.

[celloexpressions]

28784.diff​ is a simple solution here that makes most of the Customizer usable and a reasonable experience on small devices. Because this is so much better than the current setup, I think we could probably proceed with this without polishing every single thing, but feel free to iterate on the patch (I'm not planning on doing anything else here in the near future).

Notable issues are some weirdness with panel animations and elements that are supposed to be off-screen, and we need a solution for the add-widget panel and wide widgets that usually bump out of the customizer controls area.

[ryan]

​https://make.wordpress.org/flow/2015/02/03/vizrec-for-28784-improve-the-customize-experience-on-mobile-iphone-6-28784-diff-4-2-alpha-31325/

[ocean90]

28784.2.diff​ is 28784.diff​ plus the #available-widgets part. Still needs a cancel/back button.

[ocean90]

In 31384:

Improve the Customize experience on mobile.

Before: ​https://make.wordpress.org/flow/2015/02/02/a-peek-at-the-customizer-on-an-iphone-6/
After: ​https://make.wordpress.org/flow/2015/02/03/vizrec-for-28784-improve-the-customize-experience-on-mobile-iphone-6-28784-diff-4-2-alpha-31325/

props celloexpressions.
see #28784.

[ocean90]

Needs a cancel/back button for the available widgets panel.

[folletto]

I'm glad to see the simplified approach we designed above being pushed forward! :)

Does the cancel/back button you mention need some design scoping? If yes, mind adding a screenshot for the "before"? :)

[ocean90]

Replying to folletto:

If yes, mind adding a screenshot for the "before"? :)

I mean the button to toggle the available widgets section. Since the section will overlay the panel and the button we need something new here.

[folletto]

Above together with the design you've now implemented I did one that used a stacked back too, as alternative. Something like that might work. :)

I can't try the patch right now unfortunately, that's why I asked for a screenshot or two to design a couple of mockup proposals over these. Thanks. ;)

[ocean90]

Replying to folletto:

I can't try the patch right now unfortunately, that's why I asked for a screenshot or two to design a couple of mockup proposals over these. Thanks. ;)

I've attached two screenshots.

[folletto]

Thanks! :)

[folletto]

customizer-mobile-approach: modal

[folletto]

customizer-mobile-approach: header

[folletto]

customizer-mobile-approach: modal

[folletto]

I've attached three concepts, all with their pros and cons. I don't think there's a clear cut winner, but they all could work. :)

• Icon approach
• Header approach
• Modal approach

Probably the Icon approach is the simplest one in terms of both use and implementation, but not by much.

[ryan]

My reflex was to like the header approach, probably because I love context and that one has an Add a Widget header. My phone is distracting. I like a context reminder to help me get back into a flow. But then I thought I might expect the entire header, not just the arrow, to take me back with a tap. Tapping a header to go back doesn't make so much sense, so now I might have talked myself out of header.

The "You are Customizing" reiteration in the icon approach feels comforting, but I lose it on the last screen. This gives it a modal feel, which I tend to not like. I like the stacked UI both here and in header.

The modal immediately struck me as my least favorite, and it remains so. It did make me think about the "Save & Publish" button. Is showing it on the final screen (as the other two approaches do) appropriate? Should "Save & Publish" be ubiquitous? Would ubiquity make us use this button as a Save Draft, forgetting we're publishing every time we tap that button? After some gymnastics, I landed on, "Eh, showing it everywhere seems okay." :-)

I like the two stacked approaches better than the modal approach. Modals have a dead-end feel that I don't care for. Also, I tend to like headers. They comfort with easier reorientation when I jump back into the flow after chasing an out-of-WP distraction. So, a stacked UI with headers all the way through? Since I'm afraid that having the back arrow next to header label might frustrate me as I fail to not habitually tap it like one big button, I think I'd prefer back nav in the bar.

[ryan]

Also, the header approach shows both < and X. When I see these controls separately I wonder how much the X pops. Is it a synonym for < that goes back one or does it pop the full stack? Will I be accidentally popping the full stack all the time when I want to go back one? Having both introduces a choice that I've come to view as ambiguous and potentially perilous to my nav stack, my context. When I'm reorienting back into a flow I often go back one to get my bearings. Accidentally popping the stack and losing all of those frames of context feels like a loss. This along with possibly mistaking the entire header as a back button has me leaning toward the pure stacking of the icon approach.

[folletto]

Also, I tend to like headers.

In a sense, I prefer the header approach too exactly for the reason you just pointed out above. However, I also feel that the specific header outlined above isn't ideal. If there's a general preference for the header one I can explore that one more. :)

Note also that the header approach will work way way better if it's consistent across (i.e. changes also the "You are customizing" one). :)

Tapping a header to go back doesn't make so much sense,

Correct, but to an extent. I mean, the analysis is correct, but here we'll play with the fuzzyness of that UI element, like when you show a tiny icon but the tap area is bigger, in the same way, the header will be tappable but you go back. This is flexible tho: keeping the same UI we can play around on what's actually tappable keeping at the same time the same visual appearance. :)

< that goes back one

In the header approach, × closes customizer (the top bar is unchanged, stable, so gives comfort) while the < pops a single layer, as in standard stacked navigations like that.

[celloexpressions]

We still need cancel/back for adding a widget. Might need to switch this to a task.

[samuelsidler]

There hasn't been much movement on this ticket over the last six weeks. Where are we on getting a cancel/back button added? It's getting close to not making 4.2.

[ocean90]

In 31913:

Customizer: Use responsive button styles if screen is max-width 640px.

see #31794, #28784.

[ocean90]

In 31921:

Customizer: Increase initial-scale viewport specification to 1.0.

see #31794, #28784.

[DrewAPicture]

@ocean90: What would we conceivably need to finish up here to call this fixed? :)

[helen]

We need to figure out why the theme switcher "breaks" in iOS - it seems to be unable to position the panel correctly after one or two usages. We can open that in a separate ticket, or split off the back/cancel header stuff, which doesn't seem feasible for 4.2.

[ocean90]

In 31974:

Customizer: Make the available widgets overlay closable on narrow screens.

see #28784.

[ocean90]

Replying to ocean90:

In 31974:

Customizer: Make the available widgets overlay closable on narrow screens.

see #28784.

I figured out that https://core.trac.wordpress.org/attachment/ticket/28784/mobile-view-previewer-customize-acc-widgets-i2-modal-(flow).png actually was the easiest concept to implement. It avoids abusing the controls back button.

[ocean90]

In 31984:

Customizer: Improve the overlay close button for iOS.

see #28784.

[ocean90]

In 31985:

Customizer: Update selector, missed in [31984].

see #28784.

[ocean90]

This is done for 4.2. Issues specific to theme switcher are tracked by #31794.

[ocean90]

I said it's done.

[ocean90]

In 33150:

Customizer: Use the new dashicon for the Preview/Customize toggle in narrow screens.

see #30902, #28784.