Support chat using Zendesk Messaging

[klimeryk]

Well, this one is a doozy.

We're switching from Happy Chat to Zendesk Messaging for live chat support. This PR is big, but it's also the smallest I could get given the scope of the project. Any cleanup of Happy Chat code, old contact forms, etc. will be done as a follow-up. I want to keep this PR as easy to revert as possible if needed.

Proposed Changes

• Disable Happy Chat feature flag and any availability checks that trigger connections to the websocket.
• Load the Zendesk Messaging script instead.
• Authenticate using already established endpoint (just with type=zendesk).
• Check availability using the /help/messaging/is-available endpoint.
• Pass the initial chat data using Zendesk user fields.
• Use the support history to figure out if the user has ongoing conversations or not (thankfully, a Messaging conversation is a "ticket"!).
• Additionally, make sure the Zendesk launcher is visible if any unread messages are reported by Zendesk's APIs directly. This is a good safeguard and makes it more dynamic.
• If the browser is blocking requests to Zendesk, show a notice and link to relevant support doc.

Testing Instructions

The live chat support flow should feel the same up to the point where you click the chat CTA (Chat with us/Still chat with us). At that point, the Help Center should get hidden, while the Zendesk launch and widget should become visible.

Trying to show the Help Center should automatically minimize the Zendesk widget, to avoid clutter and confusing UI. The Zendesk launcher remains visible, so the user can come back to the conversation at any time.

If you have Enhanced Tracking Protection (or similar strict privacy settings and/or ad-blockers), you will see this notice when choosing the Live Chat support option:

Other support options should not show this notice, of course.

Verify that the Zendesk widget follows you on different paths in Calypso. Where Help Center is, the widget should also be there.

If you have an active, ongoing conversation, it should be detected and on refreshes the launcher should appear. If new messages arrive, it will be reflected with a count/notification on the launcher as well.

Verify these behaviors in different environments that Help Center has to work in:

• Simple sites
• Atomic sites
• Editor

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-ajp-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-67090

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-67090&env=jetpack

[matticbot]

This PR modifies the release build for editing-toolkit

To test your changes on WordPress.com, run install-plugin.sh editing-toolkit update/zendesk-chat-feature on your sandbox.

To deploy your changes after merging, see the documentation: PCYsg-mMA-p2

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~79 bytes added 📈 [gzipped])

name           parsed_size           gzip_size
entry-stepper       +355 B  (+0.0%)     +105 B  (+0.0%)
entry-main          +355 B  (+0.0%)      +95 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~4645 bytes removed 📉 [gzipped])

name                   parsed_size           gzip_size
happychat                 -16151 B  (-2.3%)    -4681 B  (-2.4%)
plans                        +34 B  (+0.0%)      +20 B  (+0.0%)
jetpack-connect              +34 B  (+0.0%)      +20 B  (+0.0%)
jetpack-cloud-pricing        +34 B  (+0.0%)      +20 B  (+0.0%)
checkout                     +34 B  (+0.0%)      +16 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~21469 bytes removed 📉 [gzipped])

name                                              parsed_size            gzip_size
async-load-automattic-help-center                    -75054 B   (-9.9%)   -21438 B  (-9.7%)
async-load-calypso-components-happychat               -2532 B  (-13.8%)     -300 B  (-5.4%)
async-load-calypso-layout-masterbar-checkout-tsx       +485 B   (+0.4%)     +107 B  (+0.2%)
async-load-calypso-blocks-inline-help-popover          +485 B   (+0.1%)     +104 B  (+0.0%)
async-load-calypso-my-sites-checkout-modal              +34 B   (+0.0%)      +18 B  (+0.0%)
async-load-calypso-components-jetpack-portal-nav        +34 B   (+0.1%)      +17 B  (+0.1%)
async-load-calypso-blocks-editor-checkout-modal         +34 B   (+0.0%)      +23 B  (+0.0%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[alshakero]

Reviewed, but didn't get to test yet. The majority are non-blockers, only one is actually a blocker, the rest all are optional.

[alshakero]

I would make showMessagingLauncher a string instead of a boolean and just pass it around.

[klimeryk]

I'm not sure I understand - could you clarify what are the benefits of it being a string and how that would make it easier to pass it around?

[alshakero]

This if is basically converting true to 'show' and false to 'hide'. I prefer

window.zE( 'messenger', showMessagingLauncher )

It's inspired by this https://kentcdodds.com/blog/stop-using-isloading-booleans

[arcangelini]

@klimeryk are there some steps to testing this with ZD chat in staging? I have tried just opening things as I would with HelpCenter normally, but I am getting an error:

FoundError: No Zendesk user ID found.
    at onmessage (index.js:474:64)

[arcangelini]

Wasn't able to test the changes, but read through. Everything seems to be good from my perspective.

As you highlighted before I do think this should prompt a general spring cleaning of Help Center to make it easier to understand and update since many decisions were made with happychat in mind.

[klimeryk]

@klimeryk are there some steps to testing this with ZD chat in staging? I have tried just opening things as I would with HelpCenter normally, but I am getting an error:

Thanks for testing! I'll reach out on Slack to get more info on which user you've used to test 🙇

[arcangelini]

Tested in Simple and Atomic, everything seems to be A-OK. One suggestion that I mentioned in Slack was that we redirect the user who HAS an active chat session before we give them the chat contact form. This way we prevent any confusions and that extra irrelevant API call to send the update-fields.

Not a blocker, but definitely something we should add soon after.

Also, since now the chat history is shared in the Zendesk ticket history the warning of a previous sumbmission may neeed to be re-worded or updated? Right now it think the user submitted a ticket when actually its an open chat. Again, this is just a thought and not blocking in any way.

[klimeryk]

Thanks so much for testing and sharing your feedback!

One suggestion that I mentioned in Slack was that we redirect the user who HAS an active chat session before we give them the chat contact form. This way we prevent any confusions and that extra irrelevant API call to send the update-fields.

Yup, definitely, I'll rework it so that if the user selects Live chat option, they'll immediately go to Zendesk Messaging. I'll do that in a follow-up PR, though, as we need to launch now 🙇‍♂️ I'll be on the lookout for any reports about the confusion around the notice and ask for feedback how/if we should it improve it as well - thanks for pointing it out!