Customizer: Add indicator when additional widget areas are hidden

[shireling]

In the Customizer the only widget areas available are the ones visible on the currently loaded page. Accessing other widget areas requires navigating to a page where the user can see the missing widget area.

While this makes sense, it's sometimes confusing for users - they see only that the widget area they need is missing.

A note indicating there are other widget areas are available, and they the user can change pages to see them might ease this part of the flow a bit.

[lukecavanagh]

@shireling

You can edit and manage any of the available widget areas in the Customizer.

[lukecavanagh]

Customizer Widgets

[westonruter]

@lukecavanagh I think he knows that. What @shireling is saying is that there is no indication that there are other widget areas in use on the site. When zero widget areas are used in the preview, then there is a notification. But if there is only one widget are used in the preview, but there are others registered, then he is suggesting there should be an indication that others are available by navigating to other parts of the site.

At the very least, the message that now appears when no sidebars are displayed could be adapted and put into the help text for the panel.

[shireling]

Yep @westonruter, that's exactly what I meant :)

[MatheusGimenez]

Maybe can we think of leaving it with low opacity the hidden widgets, perhaps?

[karmatosed]

I think related to this, but a case that causes issues in themes is a hamburger menu for example with widgets. This is hidden as closed, you can literally add widgets and unless open won't see. You're sending them to nowhere visible.

I am wondering if a low hanging version of this is a hidden state indicator and/or an 'other page' indication (unsure if same)? Further building on this could be scroll to section (if hidden down page), preview refresh to page when on different page or even slide out menu.

I would add a +1 to avoiding any instance where suers are wondering where they added a widget.

[westonruter]

So I think the patch needed here is for the notification to appear at the top when there are sidebars hidden due to not being contextual/active to the current template being previewed. @karmatosed do you agree? Are you saying something more should be done? Given some sidebar X we can't provide a link in the UI to navigate to a template that features the sidebar because it's unknown which templates would have the dynamic_sidebar() calls in them.

[karmatosed]

I see a notification I guess as step one. It's useful but maybe at some point later we should explore going further?

I also think the case goes a little beyond just this instance. A hidden menu is another great example. Or even a hidden sidebar under a hamburger menu slide-out panel :) Which many themes have.

[westonruter]

This is a good first bug to get feet wet with customizer JS API. There is already a notification that displays when there are no widget areas in the preview, so the needed patch would extend that to show another notification when there are some widget areas sections that are not active.

[gma992]

Replying to westonruter:

This is a good first bug to get feet wet with customizer JS API. There is already a notification that displays when there are no widget areas in the preview, so the needed patch would extend that to show another notification when there are some widget areas sections that are not active.

I'm trying to get that notification to show up using a custom page without widget areas but I'm unable to see it (shows up for a second when the customizer loads but disappears immediately), examples:

• Custom page with zero widget areas: ​https://cloudup.com/caQZhxkb4jf
• If I get rid of one of them only (the sidebar widget area) it shows correctly the remaining two: ​https://cloudup.com/cSdT5Zxz4cp

Maybe I'm misunderstanding the expected behavior?

If I'm on the right path we're looking at src/wp-admin/js/customize-widgets.js, and the notification that should trigger when there are no widget areas in the preview is:

'noAreasRendered'  => __( 'There are no widget areas currently rendered in the preview. Navigate in the preview to a template that makes use of a widget area in order to access its widgets here.' ), 

[ahortin]

Has there actually been any user testing on this? I don’t believe that its very good for usability or UX, by hiding options from users, even if there is a small icon notification or something similar.

Why are you forcing people to navigate to different pages in the preview area, just so that they can edit the widgets? You’re making the whole process considerably slower by forcing people to navigate to multiple pages. If I want to add widgets to a particular sidebar that isn't actually being previewed, I should be allowed to do this.

Instead of hiding the sidebar and/or showing a notification when the preview isn't showing that particular sidebar, and then forcing people to navigate to another page before they can edit that sidebar, why not show ALL the sidebars ALL the time, and simply show a notification advising people that the current sidebar wont be displayed on the currently previewed page. This way you give people the choice. If they want to see a preview of the widgets, they can navigate to another page, and if they don't care about the preview, then they can still update the sidebar.

By hiding panels and forcing people to navigate to specific pages, just so that they can update their theme options, not only makes updating your site considerably slower, but makes using the Customizer more complicated and confusing for the end user.

[westonruter]

Replying to gma992:

Maybe I'm misunderstanding the expected behavior?

@gma992 Looks like you're using Twenty Fourteen as the basis. It turns out that is_active_sidebar() will also cause a sidebar to be considered active for a given template, in addition to a dynamic_sidebar() call. When that function is called, the is_active_sidebar filter applies. The widgets component in the customizer listens for that filter to sniff-out for whether a given sidebar seems like it will be referenced on a given template, and in that case, it will mark the section as active. This is to handle the common case:

<?php if ( is_active_sidebar( 'sidebar-1' ) ) : ?>
    <div class="the-sidebar">
        <?php dynamic_sidebar( 'sidebar-1' ); ?>
    </div>
<?php endif; ?>

However, themes also often use is_active_sidebar() to toggle certain body classes. I suppose the it would be beneficial to only start listening for is_active_sidebar() after the get_header action since it seems that the majority of the issues related to is_active_sidebar() this accidentally.

In any case, at the moment if you remove the additional is_active_sidebar() calls then that should cause the sidebar sections to not be contextual and thus you would get the noAreasRendered notice.

For more conversation in relation to Twenty Seventeen, see ​https://wordpress.slack.com/archives/core-themes/p1484243304000235

[westonruter]

@gma992 nevermind, 39087.experiment.diff​ is a proof of concept for what I had in mind. The get_header action is no good because it fires before the header is output. So the only halfway-working hack is to listen for the body_class filter to have been applied (not pretty), but that still doesn't completely do the trick for Twenty Seventeen because there are additional is_active_sidebar calls in the wp_calculate_image_sizes filter. So Twenty Seventeen would still need patching:

src/wp-content/themes/twentyseventeen/functions.php

@@ -477 +477 @@
                 $sizes = '(max-width: 706px) 89vw, (max-width: 767px) 82vw, 740px';
         }
 
-        if ( is_active_sidebar( 'sidebar-1' ) || is_archive() || is_search() || is_home() || is_page() ) {
+        if ( is_archive() || is_search() || is_home() || is_page() || is_active_sidebar( 'sidebar-1' ) ) {
                 if ( ! ( is_page() && 'one-column' === get_theme_mod( 'page_options' ) ) && 767 <= $width ) {
                          $sizes = '(max-width: 767px) 89vw, (max-width: 1000px) 54vw, (max-width: 1071px) 543px, 580px';
                 }

[zoonini]

As someone who supports users daily – both on WordPress.com and self-hosted sites – this is consistently something that causes confusion and frustration. I completely agree that hiding widget areas based on whether the Customizer preview supports them is not intuitive.

I'd encourage exploring the route of displaying all widget areas, regardless of what happens to be in the preview pane, rather than making users click around to figure out what type of page or post happens to support the widget area I'm trying to access.

In another scenario, as a user, when I go to set up my widgets, I may not yet have created any posts – or pages with templates that support certain widget areas. Not being able to add my widgets at this stage because I can't locate the right post or page in the preview pane is extremely frustrating and inefficient.

[westonruter]

Notice when there is 1 non-rendered widget area

[westonruter]

Notice when there are two (or more) non-rendered widget areas

[westonruter]

Navigating between no widget areas rendered, to some, to all

[westonruter]

@zoonini how about not-rendered-widget-area-notification.mov​? When there are widget areas registered but not rendered, 39087.1.diff​ will then show one-non-rendered-widget-area.png​ when there is one widget are not rendered and two-non-rendered-widget-areas.png​ when there are two or more not rendered.

This would be a quick win and could be part of 4.7.4

[melchoyce]

@michelleweber has also been encountering this issue recently while helping new users, and pinged me to chat about it. She suggested some copy changes to your patch, @westonruter:

Your theme has 2 other widget areas, but this particular page doesn’t display them.

You can navigate to other pages on your site while using the Customizer to view and edit the widgets displayed on those pages.

With these copy changes in place, I'd love to see this in 4.7.4.

I'd like to also reconsider contextually showing things as a whole, but we can look at that in another iteration.

[westonruter]

@melchoyce @michelleweber How about these?

• 2-sidebars-not-rendered.png​
• 1-sidebar-not-rendered.png​
• no-sidebars-rendered.png​

I made “Customizer” lower-case.

See 39087.2.diff​.

[ahortin]

I still believe hiding options from users is a really, really bad decision. Displaying the message "There is 1 other widget area registered for this theme but they are not shown on the current page" is pretty much useless if the user doesn't know where the widget area is, and if it's a new theme, this is most likely going to be the case.

I can't stress enough, you're making things harder for the end user by hiding options and making them search for them, or possibly, navigate to multiple pages just to find where the widget is so that they can edit it.

In Microsoft Office 2000, MS implemented a new feature called "Adaptive Menus". The idea was that the top-level menus would only show a subset of commonly used commands and the rest were hidden. MS got absolutely hammered for this decision, by usability experts and end users, which is why they dropped it a couple of years later.

To quote a leading usability expert, "Interfaces that temporarily hide the UI elements to emphasize content often increase the interaction cost, cognitive load, and the number of attention switches." - Nielsen Norman Group (​https://www.nngroup.com/articles/zen-mode/)

As I mentioned in a previous comment above, instead of hiding the sidebar and showing a notification when the preview isn't showing that particular sidebar, why not show ALL the sidebars ALL the time, and simply show a notification advising people that the current sidebar wont be displayed on the currently previewed page. This way you give people the choice. If they want to see a preview of the widgets, they can navigate to another page, and if they don't care about the preview or if they don't know where the sidebar is, at least they can still update the sidebar with something.

@westonruter On a side note, your not-rendered-widget-area-notification.mov video above doesn't work. I tried downloading the file and it wont play in either VLC or Quicktime.

[westonruter]

Replying to ahortin:

@westonruter On a side note, your not-rendered-widget-area-notification.mov video above doesn't work. I tried downloading the file and it wont play in either VLC or Quicktime.

I just uploaded it to CloudUp so you can stream it (this is prior to the string changes in 39087.2.diff​): ​https://cloudup.com/cRcortKFjAR

[michelleweber]

@westonruter, my preference would be to capitalize Customizer; it's a proper noun. Other thoughts:

I'd love for these -- in the absence of just being able to see all my widget areas at all times, which would be my preference based on my work with users -- to have added context. So in no-sidebars, that would mean also saying "The page you're currently viewing has no widget areas," and on the other two, it would mean including the instruction on navigating while in the Customizer.

(My experience is that this is pretty (or: very) confusing for folks, and that it's not terribly intuitive (1) that you can continue to click around your site with the Customizer open and (2) that the Customizer wouldn't just be showing you all your widgets.)

[westonruter]

Replying to michelleweber:

@westonruter, my preference would be to capitalize Customizer; it's a proper noun.

I don't feel strongly about this. My understanding is that “customizer” is not supposed to be capitalized, as I think the desire was for it to not become a proper noun but a generic tool. There have been discussions in Slack about this, for example: ​https://wordpress.slack.com/archives/C02RQBWTW/p1470890054003385

That being said, there are at least 4 strings that use “Customizer”. I don't feel strongly either way.

Other thoughts:
I'd love for these -- in the absence of just being able to see all my widget areas at all times, which would be my preference based on my work with users -- to have added context. So in no-sidebars, that would mean also saying "The page you're currently viewing has no widget areas," and on the other two, it would mean including the instruction on navigating while in the Customizer.

I see, so you'd like to have the “other widget areas aren't shown” message to include all of:

Your theme has 2 other widget areas, but this particular page doesn’t display them. You can navigate to other pages on your site while using the Customizer to view and edit the widgets displayed on those pages.

(My experience is that this is pretty (or: very) confusing for folks, and that it's not terribly intuitive (1) that you can continue to click around your site with the Customizer open and (2) that the Customizer wouldn't just be showing you all your widgets.)

My experience is that it is also confusing for there to be controls shown in the panel for which there is no way to preview. This has been why contextual controls, sections, and panels have been added via #27993 and #29758. The customizer is synonymously known as the “live preview” interface. If you make a change to a control and you can't see it in the preview, that is also disorienting, and #39389 is about improving the discoverability of this by scrolling the updated are of the preview into view.

[melchoyce]

Replying to ahortin:

I still believe hiding options from users is a really, really bad decision...

I agree, and I think we can explore this further. Adding some copy is a quick improvement that can make it into the next point release, and it's a start. Removing contextual preview will take more time, work, and conversation. Let's try to do that over the next month or two.

[zoonini]

I very much like @michelleweber's suggested wording for now, and really look forward to reducing confusion even more by no longer hiding widget areas at all in a future iteration, as @melchoyce suggests. When we get to that point, we can always add any wording needed to prevent any chance of the opposite form of confusion arising.

[michelleweber]

I see, so you'd like to have the “other widget areas aren't shown” message to include all of: Your theme has 2 other widget areas, but this particular page doesn’t display them. You can navigate to other pages on your site while using the Customizer to view and edit the widgets displayed on those pages.

Yup. Ideally, with a line break between the two sentences for a little breathing room; I know this is a lot of text in a pretty small space.

[westonruter]

Here's a video depicting the latest patch 39087.4.diff​: ​https://cloudup.com/ie73e0UIAhL

Let me know if 👍🏻 to commit.

[melchoyce]

I think when you're on a page with no widget areas, but your theme has them on other pages, we should drop the "other" and still say:

Your theme has [x] widget areas, but this particular page doesn’t display them.

Edit: In addition to the other paragraph :)

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/219

[westonruter]

OK, last screencast for latest patch (39087.5.diff​): ​https://cloudup.com/i4Xlb8SNUI8

If anyone has dev feedback for the patch, please comment on ​the PR.

I'll plan to commit it tomorrow.

[westonruter]

Fix qunit tests

[westonruter]

In 40312:

Customize: Show notice in Widgets panel when there are additional widget areas not rendered in preview.

This extends the existing behavior which only showed a message only when there were no widget areas rendered in the preview. The number of non-rendered widget areas is indicated. Also removes needles deletion of wp.customize.Widgets.data.l10n property which hindered plugins.

See #33567, #33052.
Fixes #39087.

[westonruter]

Re-opening for 4.7.4 consideration.

[westonruter]

For 4.7.4 commit, add props to @michelleweber for copywriting.

[ocean90]

[40312] doesn't work for languages which have more than two plural forms. If you're not sure about any i18n changes please request feedback in the #core-i18n channel and we're happy to provide feedback.

There's a pending ticket (#20491) to implement a proper JS API for i18n. Until that's ready we have to use workarounds. One example is [31941].

The new strings should also use curly quotes, see ​https://make.wordpress.org/core/handbook/best-practices/spelling/#quotation-marks.

I'm currently -1 on adding this to 4.7.4 due to string changes.

[westonruter]

@ocean90 thanks for the feedback. You're absolutely right about the translation problem. How does 39087.6.diff​ look for a workaround?

As for the strings not using curly quotes, these strings don't technically have quotation marks but rather have apostrophes for the contractions, so APOSTROPHE (U+0027) seems more appropriate. That being said, if we were to use non-ASCII characters in these strings, there is also the issues encountered in #32875 with the difficulties encoding unicode characters in JSON which resulted in [34087] [34233]. Is there an updated best practice for that? The workaround would be to just go ahead and use HTML entities, but then this would mean p.html( string ) would have to be used instead of p.text( string ), or likewise {{{...}}} in templates instead of {{...}}. I know that's not frowned upon in core, but normally I'd flag this as an opportunity for an injection vulnerability.

[ocean90]

Replying to westonruter:

As for the strings not using curly quotes, these strings don't technically have quotation marks but rather have apostrophes for the contractions,

You're totally right, sorry! What I meant to say was that we should use HTML entities instead. Keep in mind that translators might insert HTML entities as well. I agree that using p.html( string ) should be avoided but wouldn't html_entity_decode() help here? We did the same in [32885] and [32822].

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/220

[westonruter]

Replying to ocean90:

I agree that using p.html( string ) should be avoided but wouldn't html_entity_decode() help here? We did the same in [32885] and [32822].

Apparently it does work: 39087.8.diff​ ​PR

I was somewhat fuzzy on what would happen on a site that uses a non-UTF8 charset, with that data getting passed passed into wp_json_encode() since json_encode() requires UTF-8. But I suppose then this is what wp_json_encode() fixes in its calls to _wp_json_convert_string()?

All that being said, does 39087.8.diff​ get a +1 for 4.7.4?

Aside: To me it seems APOSTROPHE (U+0027) is still better (more semantic) to use for apostrophes than LEFT SINGLE QUOTATION MARK (U+2018). But I suppose that's just my opinion.

[swissspidy]

Quick glance at 39087.8.diff​:

• The inline comment in WP_Customize_Widgets should use /* … */ comments for better readability. Also note the missing space after the word PHP.
• We usually use %s and number_format_i18n() for such placeholders

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/220/commits/7c4ac38a4aafc681eaa428074764633f37ad16ce

[SergeyBiryukov]

39087.9.diff​ is better than [40312], but still doesn't account for the fact that some languages use singular form not just for 1, but also for 21, 31, etc., where "it" doesn't work.

If a string is meant to be used for exactly one item, we should explicitly check for that, see the second example on ​https://codex.wordpress.org/I18n_for_WordPress_Developers#Plurals

I can refresh the patch to address that in a few hours if no one beats me to it :)

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/220/commits/0ac53f63fa18e9792168e853c01e92d6624c1e1e

[westonruter]

Replying to SergeyBiryukov:

39087.9.diff​ is better than [40312], but still doesn't account for the fact that some languages use singular form not just for 1, but also for 21, 31, etc., where "it" doesn't work.

How's ​this?

[SergeyBiryukov]

Replying to westonruter:

How's ​this?

Exactly what I had in mind, thanks :)

[westonruter]

Use ’ instead of ’

[westonruter]

I chatted with @ocean90 about the use of “one” or “1” here, which was also brought up in Twenty Sixteen: ​https://github.com/WordPress/twentysixteen/pull/283#issuecomment-143795415

Numbers starting a sentence should always be written as words and not digits. Compare:

"1 reply is unread" vs "There is 1 unread reply"

The first is clearly not prescribed writing style.

In this case here for 39087.11.diff​, however, the digit “1” is appearing inside the sentence instead of at the start, so having number word is less of an issue. Normally in english numbers from 1 to 100 are written out as words, but in the case here we're talking about using “one” just for the case of a single widget area but using digits for all other numbers, so this is not consistent. For consistency and for space constraints (since 1 is shorter than “one”) we concurred on using the digit number “1” in this case.

[westonruter]

In 40330:

Customize: Improve i18n for strings in hidden widget area notices.

Amends [40312].
Props westonruter, ocean90, swissspidy, SergeyBiryukov, michelleweber for copywriting.
See #33567, #33052.
Fixes #39087.

[westonruter]

Re-re-opening for consideration in 4.7.4

[alexvorn2]

I think we need to show all Widget Areas (in Customizer), and for those that does not show on current page - just to add a notice that this Widget Area is not on the current page. What if the theme developer added a sidebar to an unknown page template, like search page, how would you know that you need to go to search page for adding widgets...?

I agree with comment number 11, https://core.trac.wordpress.org/ticket/39087#comment:11 that we need not to force people go to different pages.

[westonruter]

Further discussions about showing all sidebar sections regardless of whether or not they are displayed in the preview should be directed in a new trac ticket. This ticket is specifically about adding the indicator message for there being other widget areas available.

[swissspidy]

After the unforeseen change of schedule for 4.7.4, there is now not enough time left to get these string changes into this minor release without causing lots of trouble for translators.

On the one hand I might have backported [40330] sooner. On the other hand we now have zero string changes in this minor release, which is always a good thing.

[JoshuaWold]

I've created #40520 to continue the discussion about showing all the widgets in the customizer. Please comment on that ticket with feedback on the UI I've created.

Thank you!

cc @westonruter and @melchoyce