Customizer: Should we stop contextually hiding features?

[melchoyce]

This is a continuation of the conversation in #39087.

If something doesn't appear on a page you're previewing, it gets hidden in the Customizer panel. For example, if your archive pages have a sidebar, but your static pages do not, you will not be able to edit your archive sidebar. It will be hidden until you go to an archive page.

The same goes for contextual theme options. For example, you can't assign sections to your homepage in Twenty Seventeen unless you're on your homepage.

This is often very confusing for folks new to WordPress, as evident in the previous ticket linked above. I think we should change this behavior, and I'm interested in hearing what others think.

[Travel_girl]

Same here. I saw it quite often, that people where looking for an option that there have seen earlier at the same page.

Maybe we could display this unavailable option in a grey or make a little note, where you can see this option in the front end.

I'm not sure, if you should display all option without any notification or the difference in the layout, because this could overload the customizer and confusing the user as well.

[westonruter]

Note that contextually controls, sections, and panels are were developed in #27993 and #29758. The default implementation was that for them to be contextually shown. So this is why widget area sections become hidden when the widget area is not shown in the preview. This isn't the only option, however: if you have the Widget Visibility module of Jetpack enabled and you configure the widget to not be displayed on a given page, then the widget will not be hidden from view but is rather given less opacity (grayed) to indicate it is not currently previewed. Something like this could be done for inactive sidebars, but yes, “this could overload the customizer and confusing the user as well.”

One thing for sure is that the behavior for what happens when a control/section/panel becomes inactive needs to be configurable when registered, and it should default to completely hide the item since this is the behavior that existing theme and plugin authors expect. If a control/section/panel should be grayed out instead of hidden, then it could be registered with show_deactivated => true where it defaults to false. This flag would need to be taken into account by the existing logic for expanding/collapsing since when a section deactivates by default it gets collapsed if it is currently expanded.

[michelleweber]

I would like to +1 this as many times as I am allowed. My experience with new folks is that this is quite confusing and contrary to expectation, particularly when it comes to widgets, and I see increasing numbers of people (on wp.com) with text widgets full of placeholder content that they don't know how to change because the widget is on single posts only, and they only ever open the Customizer from their home pages.

[sami.keijonen]

This is tricky one. I have had also other feedback when not using contextually hiding widgets for example: "I'm adding a widgets but I can't see them on the preview. Theme is broken".

Could the preview automatically go to that page where there are widgets?

[westonruter]

Replying to sami.keijonen:

This is tricky one. I have had also other feedback when not using contextually hiding widgets for example: "I'm adding a widgets but I can't see them on the preview. Theme is broken".

Exactly. In the live preview interface, if something can be edited which is not displayed in the preview, it defeats the whole point. So if an inactive control _is_ displayed, there will have to be some very explicit messaging/indicators to communicate that they would be making any modifications “blind”.

Could the preview automatically go to that page where there are widgets?

Unfortunately not. In the case of a widget area, for example, it is unknown which templates will have the required dynamic_sidebar() call to display the widget area, and so we cannot know which URL to take the user to either. This is a side effect of themes largely being procedural rather than declarative.

[Travel_girl]

This is tricky one. I have had also other feedback when not using contextually hiding widgets for example: "I'm adding a widgets but I can't see them on the preview. Theme is broken".

This was my concern as well. So we should not display the non available Widget-Areas and Settings like the available ones.

So what about grey then out and write the note, that this setting has be edit on an other view. I think it would be better also to point to the site, where you can edit, but if this is not possible the grey out would at least help to understand how the customizer works.

Could we point to the template, where the widget is displayed?

[zoonini]

I'd like to strongly advocate for letting users access all widgets at all times.

I've helped thousands of users set up their sites over 7 years, on both self-hosted and WordPress.com sites.

While I've literally never heard a user confused or complain that they couldn't see a widget in the preview pane (while I'm sure it could happen), I've heard - hundreds of times - users confused at why they couldn't access a widget area they were trying to set up.

Think about this scenario, as just one example:

A user is setting up their site and wants to set up all their widgets. They may not have created all their pages or added any posts yet, nor assigned specific page templates.

They first want to set up widgets. They open the Customizer, but they don't see all their widget areas. "I just want to set up my sidebar," they say. "Why can't I see all the widget areas in the Customizer?"

They see a message about not all widget areas being displayed on all views, but don't know what it means. They have no other pages to navigate to in the preview pane, even if they wanted to.

We now have to explain that, no, it's *their* workflow that's wrong. They need to finish setting up their pages, figure out which templates to assign – and understand which widget areas are connected to those templates – and only then can they come back to the Customizer, figure out which page has the template they just assigned, and navigate to it.

But wait! Even if they do all that, let's say they haven't added those new pages to their menu. They still have no way of accessing them in the preview pane and so still no way of setting up those widgets! Again, we have to guide them - "No, I'm afraid you still can't set up all your widgets -- need to add specific pages to your menu first."

Can you see how frustrating and agonizing this is for users? It really makes people want to tear their hair out and give up on WordPress.

There is a simple way to get around the small risk of users who might be confused by not seeing a widget in the preview pane, which is putting a small piece of wording below a widget section that's not currently being previewed. This is much, much, less frustrating for users than anything that involves preventing users from editing widgets under certain conditions.

[sami.keijonen]

@zoonini: That all makes sense. In general do you see any good way of using 'active_callback' for sections in the Customizer? Or should all the sections just be there always visible. Could be a little out of topic so don't have to answer it:)

[zoonini]

@sami.keijonen I can't think of a situation where it helps users to hide settings in the Customizer. :)

[danielbachhuber]

In observing this conversation, it seems like there are two viewpoints:

1. Customizer controls should always be shown, because it's confusing to new users when they're sometimes missing.
2. Customizer controls should be contextually shown, because they're distracting when they're not relevant to the current view.

I'd suggest that both viewpoints are correct, depending on the use case.

If you're a new user, of course it's going to be confusing to have some settings conditionally displayed, because it assumes you know how/why/when they're shown vs. hidden.

If you're an enterprise client, of course it's going to be distracting to have 50+ sidebars shown when they don't need to be. You use WordPress on a daily basis, and only want to see the controls you need to see because everything else is mental overhead.

In this discussion, it seems like it'd be helpful to present a point of view based on the use case you'd like to optimize for, and acknowledge how your solution might solve the other use case too.

[zoonini]

There is another use case as well:

3. Customizer controls should always be shown, because it's inefficient to not have them all available when setting up a site – whether you're a new or experienced user.

It's definitely not just new users who find the current implementation frustrating and time-consuming. It's particularly inefficient for anyone – new, experienced, or somewhere in between – who's setting up their site for the first time, or someone who just wants to add a widget to a page that hasn't yet had a specific template applied.

Daniel's comment gave me an idea. What if there were a setting for "enterprise clients" or anyone else who wanted to turn off the ability to have all settings/widgets displayed in the Customizer? That would still provide a way for "power users" to maintain the status quo.

You use WordPress on a daily basis, and only want to see the controls you need to see because everything else is mental overhead.

Do most people add/edit widgets and other Customizer settings on a daily basis?

[danielbachhuber]

Do most people add/edit widgets and other Customizer settings on a daily basis?

Ah, that's another important qualifier: are we looking at this from the perspective of users setting up their sites (as a one-time or irregular task), or users customizing their site on a regular, if not daily, basis?

Personally, I can't say definitively what "most people" do. I suspect there's many shades of grey, depending on the type of user.

[shireling]

Ah, that's another important qualifier: are we looking at this from the perspective of users setting up their sites (as a one-time or irregular task), or users customizing their site on a regular, if not daily, basis?

I'd say both are important. To me, a new user who is likely to get frustrated and give up on WordPress as a whole would benefit a lot more from seeing all widget areas than an experienced user would suffer from having work through a list.

If a user is customizing their site on a regular, if not daily, basis they are likely going to gain a level of familiarity with their individual theme and the respective widget areas/settings. They will still succeed. The new user who can't make widgets work and leaves will not.

This is a different approach and would likely be more challenging but what if there were a toggle in the Customizer? The setting could be a choice between "Show all widget areas" and "Show only this page's widget areas" - with the former being the default on new sites.

When set to the latter, display a note that there are other widget areas that aren't shown. This way you'd have:

• New users seeing all widgets
• Experienced users having the ability to hide them and replicate the current setup if needed
• A contextual notice to go with the setting for anyone who toggles it and forgets

Perhaps add an additional contextual note on specific widget areas that aren't visible on the current page as well?

[karmatosed]

I have seen time and time again in usability tests showing something that is hidden cause issues for a user. We have to be so careful to look beyond our headspace with this. Sure we know its hidden, that the widget area is behind that slide out section, yet most users do not. This doesn't help them, it makes them feel stupid - lets not do that. I have heard so many times in usability tests a user apologise when its not their fault they don't get the 'WP way' - the frustratingly awkward bad experience WP way.

As far as the solution, my concern with graphically disabling is we then have to do so that users get what that really means. We can maybe test this. I do however think just stopping doing this is a good step one.

[westonruter]

One of the use cases for contextually active controls is for them to be dependent on other controls for whether or not they should be shown. For example, the Static Front Page section has controls for page on front and page for posts. These are hidden (deactivated) when the radio button for “Your latest posts” is selected. When switching to “A static page” these two page dropdown controls get activated. So we can't just universally start showing all inactive controls/sections/panels. Instead, we need to look at specific instances of contextual items to decide how they can be better presented to the user when they are deactivated.

The example that comes up most often is the sections for widget areas (sidebars). If we showed widget area sections regardless of whether or not they are used in the preview (whether they are contextual or not) the behavior for a deactivated widget area section could be the showing of a notice at the top of the section indicating that the widgets may not be displayed in the current view; this could make use of #38794.

Additionally, we could change the ordering of the widget area sections so that the active ones are always listed at the top, followed by inactive ones at the bottom. I think there should also be some indication on the collapsed inactive widget area sections.

[dlh]

I'd like to follow up on @Travel_girl's question:

Could we point to the template, where the widget is displayed?

For those who have conducted user tests with the Customizer: Are there scenarios when it would be helpful to display a notification that includes something like "Visit a page on your site where you can preview this setting"?

As a developer, a sketch of the technical workflow could be:

1. I could tell the Customizer a URL where my control could be previewed (e.g., sample_permalink_callback).

2. I also could tell the Customizer whether the link should display (e.g., the preview is visible; no page exists; doesn't make sense to suggest a link...).

3. The Customizer would use (1) and (2) to determine whether to display the notification, and it would navigate the preview to my sample URL if the user clicks the link.

Perhaps this has already been suggested and rejected, or it's technically infeasible (or maybe it's already possible).

[westonruter]

@dlh I think your second point is captured by the current active_callback API. The first point, introducing a callback function where a developer could indicate a URL where the control/section/panel could be managed seems like the primary new piece. For the third point, I think whether or not the control/section/panel is displayed even when not contextual would need (per my previous comment) to be an opt-in thing, and this opt-in could signal that a notification like you describe could be shown.

My main concern with this is developer adoption. If the main use case is indeed widget area sections, then developers would have to work out a sample URL for where templates get chosen that render the given sidebar. That seems like it could be somewhat of a tedious task to ask of theme developers.

[JoshuaWold]

#40520 was marked as a duplicate.

[JoshuaWold]

Based on the discussion here, as well as on #40520, I've created 3 wireframe options.

• Option 1 - Seems like the simplest option, just add a note separating contextual widgets from the rest.
• Option 2 - The other widget areas are open by default, but you can collapse the accordion to avoid "business". Not sure technically feasible this is though.
• Option 3 - @shireling suggested a toggle to show/hide the other widget areas. This might make sense to combine with Option 1. The question would be, where would we put it?

cc @westonruter and @melchoyce

[westonruter]

Replying to JoshuaWold:

• Option 3 - @shireling suggested a toggle to show/hide the other widget areas. This might make sense to combine with Option 1. The question would be, where would we put it?

To me it seems like option 2 implements the show/hide idea quite well. The accordion of inactive sidebars would actually have some parity with what is proposed in #27404 for adding inactive widgets to the available widgets panel.

Option 2 would require some creative styling for the inactive sidebar sections, but I think it's doable if it provides the best UX.

[ahortin]

I've been saying this for months and ​months. The Customizer shouldn't be hiding panels from users. It's bad usability and makes using the Customizer even more confusing. You're making things harder for the end user by hiding options and making them search for them, which in turn is going to force them to navigate to multiple pages just to find where the widget is so that they can edit it.

As I've mentioned in other tickets about this very issue, 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/)

I even bought this up as an issue on the ​Alpha/Beta forum for 4.7. Not in relation to widgets per se, but the Twenty Seventeen Theme Options do exactly the same type of thing, hiding options from users when you weren't on a specific page.

It's clear from other peoples comments above, that this is already causing confusion for people.

Option 1 from @JoshuaWold above is what I suggested on another trac ticket. Instead of hiding the sidebars (and showing a notification when the preview isn't showing), show ALL the sidebars ALL the time, and simply show a notification advising people when a sidebar wont be displayed on the currently previewed page.

[Travel_girl]

I also think, that option 2 shows the best UX, as Option 1 is not clear on the first view. Ant I totally agree with @ahortin, that it would be less confusing for the end users.

[lukecavanagh]

Option 2 in the mockup seems like the best of the options for the end-user.

[zoonini]

I'd encourage us not to change the widget order in the Customizer depending on the view. Doing that places an unnecessary extra cognitive burden on users.

Instead, I would suggest:

• Keeping the order of widget areas the same on every view (i.e. not pulling out unpreviewed areas and displaying them separately at the bottom)
• Perhaps displaying the names of un-previewed widget areas in a different way, such as italicized text
• Including a note at the top of each individual undisplayed widget area (after you open it), like: "“To view this widget area in the preview area, navigate to a view that displays it”"

[michelleweber]

I heartily +1 all of this. I'd suggest some language tweaks to try and keep things less formal/friendlier, like:

“To edit this widget, visit the page that displays it. (Yes, you can move around your site while the Customizer is open!)”

(For many of the new folks I work with, it doesn't occur to them that they can click around on their sites while the customizing panel is open, which contributes to the confusion.)

I'd encourage us not to change the widget order in the Customizer depending on the view. Doing that places an unnecessary extra cognitive burden on users.

Instead, I would suggest:

• Keeping the order of widget areas the same on every view (i.e. not pulling out unpreviewed areas and displaying them separately at the bottom)
• Perhaps displaying the names of un-previewed widget areas in a different way, such as italicized text
• Including a note at the top of each individual undisplayed widget area (after you open it), like: "“To view this widget area in the preview area, navigate to a view that displays it”"

[danielbachhuber]

(For many of the new folks I work with, it doesn't occur to them that they can click around on their sites while the customizing panel is open, which contributes to the confusion.)

This has struck me as a fundamental way the Customizer is different than options pages in the WordPress admin. It could be the one underlying source of the symptoms, and worth additional UX consideration.

[JoshuaWold]

Thanks everyone for the great feedback! Based on the comments, and chatting with @zoonini, I’ve created 2 more options on the wireframe. To reiterate:

OPTION 1

Shows all the widgets that I can currently preview at the top, and has a separate section below showing additional widgets in the theme, but that can’t be seen on the current page.

Benefit: Clearly shows which widgets are available on this page and which aren’t.

Challenges: Widgets will move up and down as I navigate the site, requiring that I re-read the widget titles when I load a new page.

---

OPTION 2

Similar to Option 1 with benefits and challenges. One additional benefit is I can hide the widgets that aren’t on this page by closing the accordion.

---

OPTION 3

We could put a toggle somewhere in the Customizer that hides all widget areas that aren’t available on your page. It would be helpful to understand what user would benefit from this, and whether this is a real need. Also, if we did proceed we’d need to figure out where to put it.

---

OPTION 4

Shows all the widgets that I can currently preview, as well as the widgets that aren’t showing on this current page.

Benefit: Widgets will always stay in the same place in the customizer, so I’ll get used to where they are and it will be easier to navigate between them.

Challenges: It’s hard to differentiate the active from the available/not-available widgets. Just having italics may not be enough.

---

OPTION 5

As with Option 4, it shows all the widgets that I can currently preview, as well as the widgets that aren’t showing on this current page.

Benefit: Same as option 4, with the addition of the icon for knowing which widgets are NOT available to preview on this page. It’s easier to differentiate the two.

Challenges: The eyeball icon doesn’t mean anything until I read the message, it may be enough to click the eyeball and then see it again on the next page. The eyeball also adds some noise to the customizer, and could be distracting.

---

TL;DR

I think some combination of Option 4 or Option 5 might make the most sense at this point because of the benefits they offer.

Note: @michelleweber and @danielbachhuber raised some great points about needing some kind of message that indicates you can move around in the customizer. I agree with this and believe it would be helpful to discuss! However, for the sake of this ticket I’d recommend we not address it yet, and instead bring it up in a separate ticket.

[alexvorn2]

I like option 5.

[melchoyce]

Great work on these, @JoshuaWold :)

I think some combination of Option 4 or Option 5 might make the most sense at this point because of the benefits they offer.

I agree. I think we'll figure out which one feels right once we have a higher fidelity mockup or prototype. Are you interested exploring these further & tackling some of the challenges you mentioned?

[JoshuaWold]

@melchoyce thanks! :)

Yes, I'm interested in working on Options 4-5 and creating something higher fidelity or interactive. I'll work on that next, as well as keeping an eye on any additional feedback in the meantime.

[melchoyce]

Awesome 🙌

[zoonini]

I think some combination of Option 4 or Option 5 might make the most sense at this point because of the benefits they offer.

Agreed! Nice work so far.

I think we should also modify the wording from "To edit this widget, visit the page that displays it." to something like "To preview this widget, visit a page that displays it." (props @melchoyce for that suggestion) We don't actually want to stop people from editing those widgets, only indicate that they won't see the widget in the preview pane until they navigate around the preview to the right place.

Looking forward to the next iteration!

[ahortin]

Nice work with those mockups @JoshuaWold

My preference would be Option 4. I think those eyeball icons on Option 5 make things confusing. I would've thought that if it had an eyeball icon, that means I can see/preview that widget, whereas the mockup seems to indicate the opposite.

I wouldn't bother about italicising the Widget Area names (in Option 4) as they're almost indistinguishable from the non-italicised names anyway, so they don't add much benefit to the UI.

@zoonini brings up a good point, which I've also mentioned before, it's important that you don't actually stop people from editing the widgets, just because they're not currently shown in the preview. Kathryn's suggestion of changing the wording is a great idea and makes it clearer that they can still edit the widgets, they just wont see it previewed until navigating to another page.

[lukecarbis]

Nice work @JoshuaWold. I find the icons (in the Widgets list) in Option 5 visually distracting, but I do think that including an icon with the warning message (when editing the Widget area) works really well. I think a mix of 4 and 5 works best.

[westonruter]

I think the notification should be implemented via a section-level notification API provided by #38794.

[celloexpressions]

I think this ticket is asking the wrong question and approaching the issue in what may not be the most effective way. When there are too many options, users are overwhelmed. When users can't find options, they are overwhelmed. Contextually hiding options solves one problem but makes the other worse, and removing the current functionality does the opposite. The experience still isn't great either way.

To actually fix both problems, we need to look beyond the current assumptions. It was mentioned above that users don't think/know to click around to preview different aspects of their site. That's the point of the customizer, and something that we should work to encourage more actively. If user's aren't actually using the preview, there is of course no reason for them to be using the customizer. And they would of course be annoyed that it only takes up a small part of the screen because they aren't using the preview that takes up most of their screen. If we show options that aren't shown in the preview, we work against the whole purpose of the customization/live preview experience.

We've already started placing more emphasis on the preview. Visual edit shortcuts are the first step there, and inline editing should follow soon. If we turn the approach to the experience the other way around - encouraging interaction primarily within the preview/on the site and treating the customize pane as secondary, the question of whether controls should be contextual within the pane is much less important. If control navigation is more fundamentally rooted in the preview, pane-based navigation could potentially be greatly simplified to only focus on global elements that aren't contextual to specific parts of a site. Pane-based navigation for widget areas doesn't really make sense because it's very disconnected from where those areas actually are on the site.

I think it would be more productive to rethink this issue by focusing on the preview first, and then circle back to reworking how global contextuality should work.

[ahortin]

@celloexpressions This is completely wrong. Regardless of whether people navigate within the preview window or not, hiding options from them is horrible usability. In previous comments I've made, I've mentioned where companies like Microsoft (who literally spend hundreds of thousands of dollar on investigating usability), and leading usability expects both agree that hiding options from end users is extremely poor usability. Even if you have edit shortcuts in the live preview, if a sidebar is not visible on the current page being previewed, they're not going to see those edit shortcuts, which makes them absolutely useless.

By hiding options you're expecting the user to navigate to every single page in the live preview, just so they can find all their sidebars. That's just ridiculous! If a theme is showing a different sidebar on a Single Post page, as an example, the only way they're going to find it currently is if they actually navigate to the single post in the live preview. Not only does it force people to make unnecessary clicks, it clearly slows down their workflow as they have to navigate throughout their whole site just to find every single sidebar.

You shouldn't be determining how people choose to update their theme options. By hiding options from them and forcing them to navigate their whole site just so they can edit them, that's what you're doing.

[ahortin]

• Removed original comment. Misread it as 5.0, thinking it was referring to the WP version.

[westonruter]

Replying to celloexpressions:

If control navigation is more fundamentally rooted in the preview, pane-based navigation could potentially be greatly simplified to only focus on global elements that aren't contextual to specific parts of a site. Pane-based navigation for widget areas doesn't really make sense because it's very disconnected from where those areas actually are on the site.

I think it would be more productive to rethink this issue by focusing on the preview first, and then circle back to reworking how global contextuality should work.

It's good that you raised the issue of local vs global content. This is something that @melchoyce and I have been talking about being a key challenge that we'll need to tackle in the interface. For example, how can a user be clued in that a given element is only shown on a particular page (e.g. featured image) versus an element that is shown on every page (e.g. header image). How can they be clued in that a widget area is used on every page template versus a widget area that is only shown on the search results template?

The local vs global distinction then brings us to scalability concerns for controls: changing the page template would have a local scope vs global scope, but we wouldn't be showing in one customizer section listing out controls for the the page templates for every single page that you may have on a site. Discoverability seems to be the central problem here. Users may not feel it is intuitive to navigate around the preview to discover controls related to different areas of the site, while at the same time listing out all possible controls for every single setting on a site regardless of the context will hurt discoverability due to users being overwhelmed with a huge number of options (e.g. theme options admin pages).

So it seems like there is some third way in between these two. I don't know what it looks like. I recall talk of being able to “zoom in” and “zoom out” as a metaphor to work on local vs global settings, which would then possibly be a way to seamlessly access the post editor during customization, but this is an area that needs a lot of design work.

/cc @melchoyce

[westonruter]

See also #27405 (Widget Customizer: Fade out sidebar sections that lack any rendered widgets)

[JoshuaWold]

What would be the best way to decide how to proceed on this ticket? I've held off on any further prototyping of Options 4 and 5 (https://core.trac.wordpress.org/attachment/ticket/40432/Widget%20Options%20v2.png) since I'm not sure how we wnat to move this forward. Thanks!

[westonruter]

@JoshuaWold perhaps a discussion in a #design meeting?

[JoshuaWold]

@westonruter great idea. Tammie just validated that we'll make this part of our agenda at the next design meeting. (Context: ​https://make.wordpress.org/design/2017/07/07/bringing-back-office-hours/)

[joyously]

This discussion includes most of the reasons why I do not like the Customizer.
I review a lot of themes. The first thing I do after activation is set up widgets -- in the admin page, not the Customizer. It is easy to see all the widget areas and drag the widgets I want to the areas I want. One of the comments I give to theme authors is to improve their widget area descriptions so that the user can tell when and where they are shown (no preview needed and it's a requirement to document theme features). I also have told authors that I put widgets into an area, and visited all the pages and never saw those widgets, so they should not register the widget area until it is enabled, because that is confusing for the user to configure a widget area and not be able to see it on the site.

At the end of my review testing, I go into the Customizer to test that all the options work and have default values. But I don't ever go to the Widgets section due to how it works (and I've already configured them).

[JoshuaWold]

We discussed this ticket today on Making WordPress #design Slack channel: ​https://wordpress.slack.com/archives/C02S78ZAL/p1499962031146714

Agenda

• Decide on next steps for this ticket and how we can move it forward

Notes

• In order to really figure out the best way forward we need a clickable prototype.
• We had some discussion about the overall benefits/negatives of this ticket, and ultimately settled on testing it out to validate.
• The eyeball symbol could cause some visual clutter, but it’s the best icon we can think of for now, especially since there is precedent for it in WordPress admin
• Eventually when this is built we’ll have some media folks test it and see if it works for them (@jeffpaul we might have some folks we could also run this by)
• Once the prototype is complete Tammie will create a Make blog post and encourage feedback

Next Actions

• Create a higher fidelity clickable prototype with based on Options 4 and 5 (https://core.trac.wordpress.org/attachment/ticket/40432/Widget%20Options%20v2.png).
• Add at least a dozen widget areas in the Customizer panel for the sake of the prototype
• Show a fake preview with the visible widgets displayed in the Preview area

cc @westonruter, @melchoyce

[melchoyce]

This came up again as an issue from one of our support folks at WordPress.com:

Most users feel lost on how to get the sidebar widget appear in customizer, on themes that do not have it on the front page. We then need to guide them to click on a page on the right side that does have a sidebar. This seems less intuitive. A better approach may be to have perhaps a grayed out widget area that is currently not visible on the page live on customizer. Maybe a label on that about what template within the theme, the widget appears on the theme . This could be similar to the widgets that get grayed by visibility rules.

[ahortin]

This just confirms what I've said over and over again, hiding options from users is extremely poor usability. It's literally been proven time and time again by huge software companies such as Microsoft.

Having a message like..

Your theme has 8 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.

..is pretty much useless. It doesn't tell the user anything of value, other than there's other widgets somewhere on the site. It doesn't give people the option to edit those widgets since they're hidden, and it doesn't tell the user where they can actually find these other widgets, which basically forces them to navigate all over their website (in the preview) until they find them.

The fact that so many people don't realise that they can actually navigate to other pages within the Customizer preview is even more reason why these widgets shouldn't be hidden. It's a fantastic way of making people frustrated and confused. They'll browse to the blog page on their website, and either see an empty sidebar or a few default widgets, then they'll go back to the Customizer and not know how to edit the widget areas because they aren't being displayed (assuming the blog isn't on the homepage).

This is one of the reasons why everyone prefers to use the original Widgets page to edit their widgets. They can see every single widget area that's on the site. Not only that, you don't have to constantly go back 'n forth to multiple panels just to update them all, which makes updating them significantly faster and less frustrating.

[melchoyce]

What if we stopped contextually hiding things in trunk and see how it does by Beta 3 or 4?

[westonruter]

Only if the things hidden are limited specifically to sidebar sections. The active API is specifically defined to be about hiding/showing things that are not contextually relevant to the current URL being previewed, or for any other condition. For example, the new Publish Settings has an active state that is tied to whether theme previewing is being done and whether or not there are unsaved changes. Additionally, in Homepage Settings, the homepage and page for posts are contextual based on the choice for what to show on front. So if we wanted to override the behavior of contextually hiding panels, sections, and controls then this would have to be done on a case-by-case basis.

[melchoyce]

Replying to westonruter:

Only if the things hidden are limited specifically to sidebar sections.

That makes sense, it's what I was thinking.

[ahortin]

Here's one more example of why it's such an issue hiding sidebars. This is a screenshot from a post someone made just yesterday in one of the WordPress groups that I belong to, on Facebook.

​https://cl.ly/0u0C0m2k2h3Q

He obviously has no idea that you can actually navigate the Customizer Live Preview, and after explaining to him that he can, he's still not going to have any idea where to navigate to because he doesn't know where the widgets are located.

So basically, he has two choices. He can exit the Customizer and go to the more useful Appearance > Widgets page where he can actually see everything, or, navigate to every page on his site in the Customizer until he finds them.

[daviedR]

Replying to celloexpressions:

If we show options that aren't shown in the preview, we work against the whole purpose of the customization/live preview experience.

Then why do we have "Homepage Settings" (or formerly known as "Static Front Page") section always active on customizer regardless of what page are currently previewed? If you use the same principle, the section should be inactive when not previewing home page. Why is it active on all previewed pages?

---

Users who are not familiar with a new theme, would probably don't know how many available sidebars and where it would appear. That's why the "Widgets" section should list all the available sidebars like what "Appearance > Widgets" page does. The theme developers could put a nice description to help users find out about each sidebar and where it would appear.

Or, as a theme developer, I could optionally add a custom control into each sidebar section. The control would act as a link with this text: "View pages with this sidebar". Then we can use custom JS and take advantage of this: wp.customize.previewer.previewUrl( url ) to set the preview URL to any page that showcase the sidebar.

I agree that the contextual hiding in "Widgets" panel should be disabled. It doesn't help anybody in that case. The contextual hiding could be used in other cases.

[westonruter]

Replying to daviedR:

Then why do we have "Homepage Settings" (or formerly known as "Static Front Page") section always active on customizer regardless of what page are currently previewed? If you use the same principle, the section should be inactive when not previewing home page. Why is it active on all previewed pages?

The Homepage Settings can be shown unconditionally because we know the URLs for the homepage and the page for posts. As of #30677, when you try changing the homepage, the Customizer preview will automatically refresh to show you the new homepage you just selected. The same happens for the page for posts.

Widget sidebars are different because we have no idea the templates in which a sidebar will appear, so we do not know which URLs to navigate to in the preview when a user starts to interact with the sidebar.

Or, as a theme developer, I could optionally add a custom control into each sidebar section. The control would act as a link with this text: "View pages with this sidebar". Then we can use custom JS and take advantage of this: wp.customize.previewer.previewUrl( url ) to set the preview URL to any page that showcase the sidebar.

Yes, this is great. And it should absolutely be done. However, it requires a theme to support it. When registering a sidebar, there could be an additional parameter to indicate which kinds of queries the sidebar will appear on, and that could then feed into such a control (or actually a notification containing a link) to display in the sidebar section.

Nevertheless, I don't expect this to be given high priority. The work being done on Gutenberg and migrating from widgets to blocks and block-driven templates will allow for this problem to be solved since then be able to query for where on a site a given widget (block) appears and then navigate to its containing page automatically. At least, this is what I anticipate will be possible.

[daviedR]

Okay, let's see how it is going with the upcoming Gutenberg.

By the way, I got a quick fix for disabling the sidebar's contextual hiding. You can define the active_callback argument on each sidebar section to always return true. This should be hooked into wp action, because WordPress defines the sidebar sections inside wp action.

add_action( 'wp', 'mytheme_disable_widgets_contextual_hiding' );
function mytheme_disable_widgets_contextual_hiding() {
    global $wp_customize;

    if ( empty( $wp_customize ) ) {
        return;
    }

    // Sidebar ID: mytheme-sidebar
    $wp_customize->get_section( 'sidebar-widgets-mytheme-sidebar' )->active_callback = '__return_true';

    // ... Do it for other sidebar IDs too ...
}

This will make all sidebars visible on the customizer.

[ahortin]

Replying to westonruter:

Nevertheless, I don't expect this to be given high priority. The work being done on Gutenberg and migrating from widgets to blocks and block-driven templates will allow for this problem to be solved since then be able to query for where on a site a given widget (block) appears and then navigate to its containing page automatically. At least, this is what I anticipate will be possible.

Can we please get this issue sorted sooner rather than later. This is causing issues and frustration for people today and has been ever since the decision was made to hide things. Can we please get it fixed in a 4.9 release rather than having to wait till Gutenberg is released (which currently doesn't even have a release date).