Wp-calypso: Customizer: Publish Button is Confusing to Users who Haven't Launched their Site yet

[ivan-ottinger]

On screen-sharing support sessions with users, I have noticed that many of them get confused about the Publish button in Customizer.

When a user creates their WPCOM site, it is Private by default. Confused users are reluctant to save the changes they make in Customizer because they think the site is going to be launched (by clicking on the Publish button).

Steps to reproduce

1. Create a new WPCOM site and don't launch it yet.
2. Open Customizer and make changes.

What I expected

Button saying something like "Save changes".

What happened instead

The button label says "Publish".

Context / Source

anxiety-flow, #user-report

[sdixon194]

@Automattic/zelda

[ramonjd]

Would Save be more appropriate?

I get the impression we need to convey to users, who have already launched their sites, that saving here immediately publishes the changes to the live site.

Perhaps we could check for launch status and offer different copy?

[michaeldcain]

Related discussion: p58i-7Zr-p2#comment-42813

Perhaps we could check for launch status and offer different copy?

I think you bring up a good point, @ramonjd. I'd wager it's currently "publish" to convey the live nature of the change. We probably either need to update the label based on launch status (easier), or maybe handle this with some initial onboarding tip/tour messaging (harder).

I'd be curious to hear @dwolfe's thoughts. Also /cc @apeatling, since I'd imagine there's similar confusion in the button labeling for post publishing on private sites.

[apeatling]

I think the call to action "Publish" should change if the site is private. Same issue with post/page publishing: https://github.com/Automattic/wp-calypso/issues/35444

[zdenys]

Just wanted to confirm that it is very confusing for users. I notice this very frequently during Quick Start sessions. Latest just today 2494704-zen.

Save changes or just Save would be much better and less confusing than Publish, also considering that we are already using Save Draft.

Confusion exists not only for users who haven't launched their _Private by default_ site but also for those who just have set it as Private (hence the impacted audience is wide and I agree with @apeatling
that at least call to action "Publish" should change if the site is private). So IMHO update the label based on launch status may not be enough @michaeldcain.

I'd even say that the change would be helpful for all users (just like in the case with #34121 which also resulted from the observations during Quick Start sessions and removed some confusion once implemented), but maybe I'm pushing it too hard 😁

[zdenys]

Another case 2570336-zen reminded me of this reported issue. User saved changes as draft and was confused about not seeing them on the published public site. I explained how to save changes with Publish and make the entire site Private instead.

Would it be possible to add a tooltip for users (an ⓘ icon) that would link to the related support pages about saving changes in the Customizer vs making the site Private (while working on it for example).

Something like:

Click Publish to saves the changes and be able to see them on the site. This doesn't affect whether your entire site is Private or Public

@Aurorum, since you helped me in #36700 with adding a tooltip, is it something that can be done here too?

A tooltip doesn't affect the discussion about changes to Publish button mentioned above but at least would alleviate the confusion for some users.

I'm more than happy to ask other HEs for suggestions of a better/clearer copy for the tooltip text.

[Aurorum]

I'd love to, but sadly the Customizer isn't something that's open-source (I think), so it wouldn't be possible for me to create a PR for this issue.

[zdenys]

@ramonjd Any suggestion for the above? Who would be the best person to ping?

[ramonjd]

Any suggestion for the above? Who would be the best person to ping?

Both good questions, and thanks for keeping on top of it.

@Automattic/zelda has it on their backlog, but it's probably not going to get any eyeballs in the immediate future.

Changes would have to be made to a couple of wp-admin files on WordPress.com. The commit history for the relevant file is, however, kinda sparse.

The alternative is to file a bug on Trac internally, but it looks like that doesn't get much action either.

For example, on 8187-wpcom and 8119-wpcom, @lancewillett mentions that many of the Customizer's features are not in active development right now.

My guess, unfortunately, is that this particular issue would fall into the same category. Maybe @lancewillet could confirm?

Thanks!

[lancewillett]

Confirmed: this falls into both an un-owned and un-planned area of our product. We're working to replace Customizer completely with core Gutenberg's full-site editing experience.

[zdenys]

Another case 2584282-zen of a user who has a site being Private through Coming Soon plugin and they are still saving changes in Customizer as Drafts. It is confusing for them as they don't see changes in the browser outside of Customizer.

[zdenys]

Another case 16870384-hc

[zdenys]

Just wanted to quote Matt's words from the townhall pXkGC-32t-p2:

some of the struggles folks are having with even just… it’s not hard stuff. It’s stuff like okay, if a site isn’t launched yet but it says publish in the customizer or on a post, what does that mean? Am I publishing it or is the site still private and unlaunched? There’s some wording changes or small interface tweaks, or inline help, that we can get more places that interface. I think it would make a really, really big difference.

And there is nothing like doing some work to remind you of people’s incredible ability to skip over certain explanatory text and never read documentation. So you really need it as contextual and as close to whatever they’re doing as possible, even text at the top of the page, it’s better than nothing.

[ramonjd]

@adamziel What's the likelihood of @Automattic/zelda picking this one up?

Looks like it might involve fiddling around with customize-controls.js

[kwight]

I took a quick look at this today, but didn't have time to get very far. A couple of options come to mind.

On WP.com, we've subclassed WP_Customize_Manager; this would allow overriding customize_pane_settings() with additional logic to cover the private case. Another option could be filtering on current_user_can() for the $current_user_can_publish variable; this would treat the user as if they could save draft changes, but not publish ("Save Draft" may or may not be totally accurate, but it seems like it would be an improvement over the current situation).

[ramonjd]

On WP.com, we've subclassed WP_Customize_Manager; this would allow overriding customize_pane_settings() with additional logic to cover the private case.

Thanks a lot! Found this p2 thread for context: p58i-3w2-p2#comment-31163

[gwwar]

@Automattic/zelda @ramonjd are y'all working on this? @Automattic/manage can take this otherwise

[ramonjd]

@Automattic/zelda @ramonjd are y'all working on this? @Automattic/manage can take this otherwise

Hi @gwwar! Our little team doesn't have the bandwidth right now, so please go ahead.

Thanks a lot!

[gwwar]

I poked around a bit and it looks like overriding customize_pane_settings isn't necessary since _wpCustomizeControlsL10n in script-loader.php overrides these text values anyway. It also isn't a very good method to override since it's echoing a script instead of returning settings, which would mean we'd need to copy over most of the parent method which isn't ideal for maintenance.

https://developer.wordpress.org/reference/classes/wp_customize_manager/customize_pane_settings/

I'll probably add a little bit of extra JS to update _wpCustomizeControlsL10n keys like publish, published activate save when we detect a site is unlaunched in the customizer.

[gwwar]

Added D38338-code

[gwwar]

Fixed by D38338-code