Description

Now that nearly every theme/site has a responsive design, the lack of a user-oriented UI for previewing a site on different device sizes is a common complaint. Yes, it's as simple as resizing the browser window, but many user's don't think of that.

I've prepared a conceptual patch that replaces the Customizer's "collapse" link with a series of buttons that change the size of the preview window to emulate different device sizes. This would ideally integrate with #29949, providing a new full-screen/collapsed mode that's a bit more user-friendly, and could potentially offer the ability to have a "sticky" full-screen mode, where the Customizer controls pop out over the preview window instead of shrinking it.

Many of these ideas have been explored in the WordPress.com skinning of the Customizer, largely unsuccessfully (depending on who you ask). But I think a carefully considered approach here could be a big benefit for core.

Many of these ideas have been explored in the WordPress.com skinning of the Customizer, largely unsuccessfully (depending on who you ask). But I think a carefully considered approach here could be a big benefit for core.

I'd argue that responsiveness is one of the things that .com gets right in many ways. I have to say I really like your initial approach much better, though.

I'd argue that responsiveness is one of the things that .com gets right in many ways. I have to say I really like your initial approach much better, though.

Sorry, I should have worded that better. I think my general complaint is the overall reskinning and especially the pop-over controls behavior (essentially a sticky full-width preview mode), but I definitely like the idea of the responsive toggles, hence this ticket :). The fact that pretty much none of .com's customizations have even been proposed for core after nearly three years indicates that there are major issues with the overall approach there, I think, not to say that the core version doesn't have issues.

Many of these ideas have been explored in the WordPress.com skinning of the Customizer, largely unsuccessfully (depending on who you ask). But I think a carefully considered approach here could be a big benefit for core.

I'd argue that responsiveness is one of the things that .com gets right in many ways. I have to say I really like your initial approach much better, though.

(Adding WordPress.com responsive demo for future reference.)

Note that the WordPress.com Customizer skin has been ​reverted, except for the Device Preview plugin, which I agree is a nice addition.

As an aside, we've got a VIP client for whom we're going to be extending the Device Preview plugin to change the current previewUrl when the selected device changes so that the selected device can be passed as a query var for the URL loaded in the Customizer preview, allowing us to properly preview an adaptive (non-responsive) theme, i.e. when jetpack_is_mobile().

Any device preview functionality added to the Customizer should allow a theme to indicate whether it is completely responsive, or if it has adaptive elements that necessitate a URL change when toggling between desktop/mobile.

@folletto's design is now implemented in the ​Customizer UI Experiments plugin for ease of testing and iterations. If anyone wants commit access there, let me know and I'll add you.

We need to figure out what to do in terms of the colors of the buttons, as we can't go too light on the disabled state while meeting accessibility/color contrast guidelines. For now I kept the collapse button as a separate arrow, since that was just redone in core to be more accessible. @designsimply has mentioned in the past that the "collapsed" text tends to do very well in user testing, although I would like to simplify to just an icon if we can find the right icon. The design of that could use tweaking to better match the device-preview buttons. I'm also not sure about the background color - it's a bit strong even at the darkest WordPress gray, and clashes badly with dark themes. We won't be able to make it look good with every theme here, so we need to decide whether it makes more sense to go dark, light, or in the middle depending on how we want to contextualize the preview. I'm currently leaning toward trying the admin bar background (the tinted version of #222).

While I entirely agree that text would make it super clear, I also think that this specific feature isn't critical, so even if it's slightly more obscure (being just an icon) it's ok. :)

I agree we need a proper icon tho. :)

I did some super quick sketching, reusing the same shape icons we already use elsewhere. Four ideas:

The color isn't solvable in that regard. To be visible everywhere, requires a color fill on one edge of the brightness spectrum and a border on the other edge. Which leads to a series of usual solutions, but can't really be worked around. The idea as the above is to have a design that looks detached enough on same-color (i.e. adding the shadow to the white-on-white) and is nice even if contrasting on inverted-color (i.e. white-on-black fill).

Wee need design and accessibility review on the plugin version. If it's okay, I can make a merge patch for 4.4. I think we should split changes to the collapse button to a separate ticket since the current deisgn doesn't change that component.

Either user the WP Admin color scheme accent color (active button color) on the active one -or- make the grey of the inactive icons lighter.

This because the round circle looks a bit off (not used anywhere else), clashes with the top border, and adds visual noise. Using just color in that way I think it's also doable in terms of accessibility because it's something discoverable. If however we want a shape marker also, let's use a highlight line, like this (still accent color, 3px):

---

While I just did UX / design review, not browser testing, I however noticed that the collapse/responsive bar disappears on certain screen sizes... wider/taller than I would have expected make it disappear. Not a big issue, but 1024x800 (a small desktop screen, but still desktop) disappears. If we can update this, we should make the responsive buttons disappear at decreasing width (i.e. don't show tablet size if it's smaller than a tablet).

@celloexpressions color alone cannot be the only indicator, I'd recommend a shape marker whether it's an outline at the bottom or a circular thing. Both the shape and the inactive icons should have a sufficient color contrast.

This because the round circle looks a bit off (not used anywhere else),

For the focus part this is probably going to change :) see #33808. Not used anywhere as "active" indicator though.

I would like to add my 2 cents to this discussion. @celloexpressions said that previewing and customizing could be as simple as resizing the browser window, but I think some use cases are forgotten here.

First, @westonruter mentioned adaptive websites that needs a full page refresh to load different markup for small screens. But I would like to go a little bit further. As a theme author, I want to let user decide the layout of their site in the customizer, and this layout can be different for small and wide screens. So changing the size of the preview window could also toggle some controls that are specific to the screen size.

Let me take an example : in Bootstrap 3 grid system, you can define columns using classes like col-md-4 (that will make a 4/12 width column on medium size display) and col-xs-6 (that will make a 6/12 width column on very small size display). So I would like a slider to define the number of columns on medium size display, and another slider to define columns on a very small size display. Adaptive website would have the same needs : some controls in the customizer could be only for the mobile version of the site.

Second : how will you determine the sizes breakpoints ? Will you use iPhone / iPad / iMac typical display sizes ? But we now have plenty of different display sizes. So that could be nice to let theme author define the size breakpoints themselves (there are the one that know which size needs previewing). I would even add a new requirement : why not enable people that have medium size displays to preview their site on a wide display ? That's possible if you extend the size of the iframe and use scrollbars.

For the record, both Firefox and Chrome propose a user interface to test the responsiveness of a website. Even if those tools are targeted to a tech-savvy audience, we could get some inspiration from it.

Both tools have a drop-down menu to let user choose a predefined size (Firefox just give sizes, whereas Chromium propose device names). There is also the possibility to manually enter a specific size.

This type of user interface would allow theme and plugin authors to add custom sizes easily. That would also remove a misunderstanding : the only thing that is previewed here is the screen size. The website can behave differently on a real mobile device (ex: videos and audios, form controls, ...)

I think that there should be default breakpoints defined for Desktop, Tablet, and Mobile. The configuration for each breakpoint could include the label, icon(?), width/height, and whether entering the breakpoint requires a refresh (i.e. it is adaptive not responsive):

(Something we haven't talked about yet is previewing different device orientations, e.g. landscape instead of portrait.)

The theme can then filter this list of defaults based on which breakpoints it supports.

I should also note that customizer transactions (#30937) will make it possible to pop the preview frame out into a separate window, and make it easier to view the pending setting changes using those responsive previews, or even on other devices entirely.

The feature should be simple. Portrait-Landscape usually makes the theme fall into the intermediate buckets (i.e. a landscape tablet is basically a desktop, a landscape phone is basically a portrait tablet). This feature is meant to be a quick preview, not a technical tool.

On desktop, where this feature shows, you are going to have a resizable window, so if you really need to, you can just resize the window. Or use the Inspector as shown above. In other words: this feature is meant to be quick, if you want precision, you already know and have better tools to do that, and we shouldn't replicate these tools (I know, already discussed above, but I'll still point it out ;) ).

I disagree with "let theme author define the size breakpoints " exactly because "we now have plenty of different display sizes". The theme adapts to screens, not the other way around. Thus the responsive UI is something that exists independently from the themes, and should be set at proper sizes determined by industry averages. Themes should not have any bearing on the responsive UI. This will have also the ripple effect of helping more theme authors to see the industry averages, exactly because we provide a good way to preview them.

That said:

why not enable people that have medium size displays to preview their site on a wide display ? That's possible if you extend the size of the iframe and use scrollbars.

I agree. This is definitely something I'd go for, even if likely in a separate issue and discussion, because I'd still start with this UI and then work to achieve that.

The logic behind that would be to have the controls always visible (so, no hiding) but then it detects the screen size and defaults to that, and the other options then will grow/shrink accordingly.

So changing the size of the preview window could also toggle some controls that are specific to the screen size.

This could be very useful, and should be a separate ticket imho to discuss it. ;)

I agree with @folletto - at least for a first pass we should strive for simplicity. Core sets the breakpoints, there are only a couple of options, etc.

If the screen is larger than mobile (I believe google/andriod considers 600px wide to be the standard phone/tablet distinction point) but the preview less than, say, 1024px, I think it would make sense to introduce scrollbars in the preview so that a larger preview can be seen.

In terms of allowing sites to force a refresh if needed or have different sets of controls, perhaps sending an event to the preview and the controls when the size button is selected is enough. Then, themes and plugins can listen for that event and react accordingly depending on their specific needs.

The scope of #34051 could be covered here in the context of devices where you're narrower than a reasonable minimum laptop size (although this would probably need to be default behavior and could thus introduce complexity). However, I'm not sure that forcing horizontal scrollbars on the frontend by default is the best idea - that could seem equally broken to triggering tablet mode in certain situations depending on the theme. It may be better to split that off as separate.

@folletto Huge +1 to allowing desktop views on medium or even small screens via giant scrollable frame. This will be super important for those creating or more likely modifying sites entirely on smaller devices. I've been noodling on good ways to do this. Getting a good view of everything at once is still important so maybe a scaled down version might be something to consider. That said, for this particular initial implementation, it should be kept as simple as possible. Everything I've seen above looks pretty nice so far.

Not related to design choices: had a quick look at how this was implemented on wp.com and from a semantic/accessibility point of view I'd recommend to use elements that natively support keyboard interaction (e.g. buttons) instead of <span>s :(

I've just refreshed the plugin to use clearer focus styles within the circular box-shadow language. Can anyone with opinions here test that out and offer suggestions as to whether we should stick with that direction or try the underlines as suggested by @folletto above? I think the circles work nicely and are a good option in terms of accessibility.

In terms of doing a larger scrollable preview on smaller devices, it's definitely worth exploring, but I'm not sure whether it makes more sense to land a basic version first and then explore that as an extension, or make it part of the initial proposal. Anyone have specific thoughts on how we might define how that works - maybe defaulting to "tablet" mode if the device is within certain range limits and then forcing it larger when the desktop icon is clicked?

If we're ready to move forward, I can convert the plugin to a patch (device-preview component only). Related, I can add anyone who wants to play with the code to that plugin's committer list. Also, I saw some mockups from @melchoyce that moved these around; I'm thinking that the bottom of the controls is the best spot for now and they should be easy to move if other design changes facilitate that later on.

@celloexpressions thanks :) played a bit with the plugin, and I'd suggest to consider some improvements.

1 - Ideally, in the markup the buttons should be before the "Collapse Sidebar" button simply because when navigating through elements using the keyboard and a screen reader I would probably assume the "Collapse Sidebar" being the last control in the UI.

2 - Consider to add a hidden heading before the buttons to identify this section

3 - Probably I wouldn't use a11y.speak() here. There is the need to give feedback about which of the buttons is the currently active one and feedback after a button is pressed. I'd probably use ​aria-pressed. Here's how the buttons are announced now using Firefox+NVDA:

The buttons are now announced as toggle buttons and the active one as "pressed". When activating one of the buttons, NVDA will announce the state change saying just "pressed". I'd also like to hear the accessibility team opinion and will ask the team to have a look at the plugin.

Also, I saw some mockups from @melchoyce that moved these around; I'm thinking that the bottom of the controls is the best spot for now and they should be easy to move if other design changes facilitate that later on.

Agreed. ​The referenced mockups are an exploration I'd consider separate from the initial goal of getting device previewing into the Customizer.

I'm going to convert the plugin to a patch and incorporate the latest feedback regarding accessibility and providing hooks for themes to respond to preview size changes with JS. Then we can do any user testing and adjustments that we want to additionally consider before getting a first pass in.

I reopened #34051 to track the idea of forcing a larger size than available, so that we can treat that as a separate enhancement to make after the initial ability to preview smaller sizes from larger devices is introduced. Discussion on that approach can start there now.

31195.2.diff​ brings this back into patch form with the accessibility improvements suggested above and the finalized design. I started adding the way for developers to hook into changes but it's not quite working yet. In terms of UI and accessibility though, it's pretty polished.

One issue I'll note is that when navigating to different pages with the mobile preview, the reloaded/new page briefly shows up under the active preview when it loads. Transactions will be changing the behavior there anyway, so I think it's fine to leave for now.

@afercia I tried adding <h3 class="screen-reader-text"><?php _e( 'Device Previews' ); ?></h3> right inside the devices div, but it caused the expand/collapse animation to break and I'm also not sure whether it's better or not. The rest of the general customizer buttons (help, save, close, collapse, etc.) don't have headings, so it seems like it may be confusing to only have them for this one section (although these three buttons are more directly related than any of the others).

One issue I'll note is that when navigating to different pages with the mobile preview, the reloaded/new page briefly shows up under the active preview when it loads. Transactions will be changing the behavior there anyway, so I think it's fine to leave for now.

One issue I'll note is that when navigating to different pages with the mobile preview, the reloaded/new page briefly shows up under the active preview when it loads. Transactions will be changing the behavior there anyway, so I think it's fine to leave for now.

I'd just suggest to not use the circle because clashes with the borders all around it. We can instead use the accent color "indent" for the selected item:

This allows both the shape marker useful to make it accessible, repeats a pattern we started using, and the user color (in the screenshot it's orange assuming the user has that color scheme, would be blue by default).

So ok, looks to me not all the accent colors were adjusted for contrast. Note also that the ring gray, since it's a 1px round, in practice renders at a lighter gray due to anti aliasing (b4b4b4) with a contrast of 1.79 : 1.

Dunno. 4.49 in the default color scheme looks close enough to 4.50 to me to be used, and seems definitely better than the anti-aliased ring even in this context. If that doesn't work, we can just revert for the highlight gray, still with the rectangular tab.

Should the hover/focus style match the active style, or do we want to differentiate those? The current patch uses the standard focus highlight color on hover/focus (although there is no shape change so this isn't great for accessibility).

For reference, I attached a screenshot of Press This UI, which is another UI that uses the same language suggested above. The full accent is used for keyboard navigation (focus) and the light one is for selected states. It doesn't seem to have hover states, so we might just use the rectangle also to indicate a hover.

I added two mockups of how we might apply the press this border/background color for hover style to these buttons (I think the border should be one pixel narrower, at 4px). For the Customizer in core, the blue seems a bit too distracting (since we try to avoid introducing color here, with the save & publish button being the only colored element). I think the gray version could work well here though. Anyone else have thoughts on this?

I don't think the light gray background on hover is enough for hover/focus for accessibility (the Customizer back and close buttons are an issue that continues to be stalled in #29158). @afercia please correct me if I'm wrong - but we need to do more than that, right?

So. The point is that the behaviour should be the same for the x and the responsiveness toggles. I personally think we shouldn't make it different. Until it gets solved for both, I'd complete this ticket keeping that aligned, and then find a solution that stacks well for both the instances (x and preview on top bar, collapse and toggles on bottom bar).

Let's not introduce a new feature with an inaccessible design. There are many issues tying up a more accessible solution for the close button (in particular, the auto-focusing behavior that draws excessive attention to it), not to mention lack of movement on #29158, so tying this design to that would likely ensure that it remains inaccessible for several releases.

Instead, if my color-inversion gray proposal is too much for the device preview buttons, does anyone have other solutions for the hover/focus style there? We could use the active marker, but then there wouldn't be anything other than color for the active item being focused. That may be a good compromise, though.

I'm fine with that. I'm just saying that it should be the same solution, otherwise it starts getting way to many different styles all over the place, which is not ideal for a whole set of other reasons (and for everyone, using accessibility or not).

if my color-inversion gray proposal is too much for the device preview buttons, does anyone have other solutions for the hover/focus style there?

Note that it's not too much for keyboard active, it's too much for hover. ;)

Different solutions could be:

The active is full dark, the hover is shaded (this assumes that hover doesn't have to be accessible since the mouse is over it, and we have to make sure that it never gets full dark in mouse interactions)

The active/hover one is shaded and the icon gets bigger.

The active/hover one is shaded and gets the same bottom rectangle as the selected one.

The active/hover one is shaded and gets a half height (2px) bottom bar

The active/hover one is shaded and the icon animates up (transition/jump) a few pixels.

I like the idea of playing with the size of the bottom border since it's there anyway. Either make it 4px for focus and 2 for active or the other way around (thinking that it may be weird for the active tiem to get shorter when it's hovered/focused). We can animate it to add emphasis and potentially even use the blue for focus as a secondary differentiation, in addition to the light gray background.

While we're probably technically not quite there for distinguishing active vs. active and focused, I think this is good enough for now since focus and active styles are both independently clear relative to the normal display. I'll incorporate i3 into the next patch.

While we're probably technically not quite there for distinguishing active vs. active and focused, I think this is good enough for now since focus and active styles are both independently clear relative to the normal display. I'll incorporate i3 into the next patch.

Ok, let's merge a couple of ideas. I've attached i4 that uses two different styles for hover and active. That should make keyboard navigation, which I feel it's more important since lacks cursor, clearly different.

Same note as before: it's important that the active state doesn't "bleed" into the hover one. :)

There isn't a clean way to differentiate between hover and focus styles in CSS without making the focused element hidden from mouse interactions as far as I know. Ie, whenever one of these buttons is clicked, it will receive focus which would give it the blue background, and that would stick until the user clicks somewhere else. It's probably better to scale back the focus styling to match the hover styling rather than hacking in a way to prevent the buttons from receiving focus when clicked.

Can we spin this into a feature plugin? The trac thread is getting long enough that parsing the state of the effort and what's left is non-trivial.

It was in a plugin, but the UI is ending up with more changes after we moved back to patch form. Other than this UI issue, I need to implement some technical feedback from westonruter to facilitate developers hooking into preview size change actions, and then I'll post a revised patch.

It was in a plugin, but the UI is ending up with more changes after we moved back to patch form. Other than this UI issue, I need to implement some technical feedback from westonruter to facilitate developers hooking into preview size change actions, and then I'll post a revised patch.

31195.3.diff​ contains the revised design as well as previous adjustments from westonruter (updated screencast attached). I think we're looking pretty good here; I'm going to try to get a make/core post out about this tomorrow for broader feedback barring any major issues with this patch.

31195.3.diff​ contains the revised design as well as previous adjustments from westonruter (updated screencast attached). I think we're looking pretty good here; I'm going to try to get a make/core post out about this tomorrow for broader feedback barring any major issues with this patch.

I would be more worried about the ratio of text to background (#191e23 to #ddd, 12.36:1) and border to page background (#0073aa to #eee, 4.49:1) than border to focus background. Ultimately, users should be able to see the icon even when hovered/focused, and on focus at minimum the presence of a marker where there was previously background should be discernible even if it can't be distinguished from the adjacent background color change. Per the previous discussions, there are a few compromises here but I think there's a pretty good balance of considerations here now.

The DocBlock summary should use a third-person singular verb. A trick for getting this right is imagining how the information would be read in the context of the developer reference. Instead of "Get previewable devices.", should be something like "Retrieves a list of preview-able devices."

The declaration should have a public access modifier, and the DocBlock should contain an @access public tag

There are two remaining issues I see before this is ready for committing:

If I filter customize_previewable_devices to make tablet or mobile have the default flag, then the iframe is not initially sized accordingly.

When previewing tablet or mobile and the preview iframe is not 100% height, there is a momentary doubling of the iframe when navigating around the site. This is the same issue discussed above in comment 43.

In regards to the doubling issue during navigating, the culprit can be found in this line of customize-controls.js:

This is called when the Ajax request to fetch the preview's contents finishes, but before the refreshed iframe's load event is triggered, which is when the old iframe is removed. Notice how the iframe is appended to #customize-preview as opposed to replacing the DOM element of the existing preview. I believe this is intentional, as if the new iframe fails to load, then the old one can remain in place. Ultimate the problem is that there is momentarily 2 iframes in the document, during the time between the Ajax request returning and the new iframe window triggering load. The quickest fix I see is to just make sure the iframe is absolutely-positioned so that the two iframes can momentarily overlap each other instead of momentarily stacking on top of each other:

With apologies for the drive-by comment: is using in as the measurement unit for the viewports deliberate? I imagine it is and understand the semantics - just if we're going to keep it that way, I'd love to see inline comments about it so we don't look at it later and wonder why it's that way. :)

I went with in for two reasons - most device screen sizes are measured in (diagonal) inches in the US, so these sizes were roughly derived from a hypothetical device, and because that ends up being a pretty large unit that keeps us away from the precision of pixels. It's intentionally a fairly ambiguous size that isn't tied to pixels partially to minimize code-based reliance on specific pixel breakpoints when designing responsively and using the Customizer preview (I think I used pixels for mobile because 320px is generally a fairly standard lowest width, but that could also be changed). Of course, it could be changed very easily, or a code comment could be added.

The position: absolute and default class on the preview should be pretty quick fixes, and I don't do unit tests, so I'm passing this off to finish up and commit.

Running the full suite of unit tests has a failure on Tests_WP_Customize_Manager::test_customize_pane_settings. I have confirmed that it's not due to the new tests in my patch. I am looking into it further.

Customize: Add a user-friendly way to preview site responsiveness for desktop, tablet, and mobile.

Introduces WP_Customize_Manager::get_previewable_devices() with a customize_previewable_devices filter to change the default device and which devices are available for previewing. This is a feature that was first pioneered on WordPress.com.

This looks really good. My only comment would be to make the hover and focus styles different. The simplest way to do that would be to remove the bottom border on the hover state. I mocked it up in 31195.10.diff​

I also changed the transition so it only applies to the background. It looked kind of janky on the border because it is such a high contrast change.

Is there a particular reason to make the hover and focus styles different? I'd be hesitant to make further changes to those at this point after the extensive back and forth that we already went through to agree on the current styles. That being said, I'd prefer to have the border for both and drop the background change from the focus styles. I'd also say that a higher contrast change would call for a longer transition, if anything, since no transition at all is more jarring.

I also just noticed - should we be running api.trigger or api.preview.send instead of only api.set when the device value is changed? Not sure whether themes can hook into the value change binding from the preview.

Is there a particular reason to make the hover and focus styles different? I'd be hesitant to make further changes to those at this point after the extensive back and forth that we already went through to agree on the current styles. That being said, I'd prefer to have the border for both and drop the background change from the focus styles. I'd also say that a higher contrast change would call for a longer transition, if anything, since no transition at all is more jarring.

@celloexpressions an argument I see for letting the focus and hover styles be different is that if they are the same, then when you click on a different device there are two that have the same blue border. If the focus has a different style, then it is clear that there is one that is in an intermediate state (the one being clicked). I'll leave this up to you guys to finalize :)

I also just noticed - should we be running api.trigger or api.preview.send instead of only api.set when the device value is changed? Not sure whether themes can hook into the value change binding from the preview.

You mean instead of api.previewedDevice.set()? No. There is no need to trigger an event for this change because if any plugin is interested in the change to the previewedDevice, they just need to add a listener on that Value, e.g.:

Customize: Add a user-friendly way to preview site responsiveness for desktop, tablet, and mobile.

Introduces WP_Customize_Manager::get_previewable_devices() with a customize_previewable_devices filter to change the default device and which devices are available for previewing. This is a feature that was first pioneered on WordPress.com.