[Page Footer] Add Contact Support and Feedback CTAs

[souredoutlook]

Problem Statement

The only place where we currently direct folks to support is on our landing page for docs.

When we experimented with the User Feedback feature from Sentry we noticed many folks were interacting with the widget like it was a Support widget which leads us to believe it could be a really big enhancement to add more avenues for contacting support from docs.

Solution Brainstorm

We'd like to propose adding a CTA to contact support in the footer of every docs page. Like so:

This link when clicked should open our web widget - similar to how it works with Sentry's app:

This will help us know what page the individual wrote in from - which should add some context to their support request.

This widget can be added to the docs site as a script. I can supply the script when it's ready to go ahead. One caveat is that in certain browser security configurations this script will be blocked from loading the required config to display the correct forms and fields (this is due to tracker blocking).

We have a remedy for this where we make a request for a resource we know is blocked by tracking - then if it it fails we render a fallback, or if it succeeds render a button that will open the widget (by default the widget should be non-visible to Docs users - unless they click the button that will call zE.show()

Finally, we should consider add the feedback widget back to the docs site but disambiguate whether we want folks to report bugs through github or to give feedback on the page with the widget.

We do this on our help center now and in order to prevent the widgets from clashing (if both are simultaneously open) we have our widget open in the center of the page, like so:

[getsantry[bot]]

Assigning to @getsentry/support for routing ⏲️

[getsantry[bot]]

Routing to @getsentry/product-owners-docs for triage ⏲️

[a-hariti]

We might be able to work around the tracker blocking by proxying the script through our domain?

[souredoutlook]

The issue with proxying the script through our domain is that the script itself is making requests for additional resources at the blocked domain

[a-hariti]

We can install a service worker to intercept the requests and proxy them

Not sure if it would kick in before the ad blocker though

[souredoutlook]

@a-hariti Here's how it shows up in Firefox:

AFAICT our application wouldn't have access to this request for a few reasons:

• it's being made from an iframe
• PerformanceObserver doesn't register this event either

I'm in talks with Zendesk about either getting themselves removed from the tracker list (unlikely) or modifying their widget to use the hostmapped URL - which would not be blocked (the same resource is available at support.sentry.io for example)

We've been experimenting with the following:

• make a request for the resource and observe if it fails
• if it fails render a link or alter the behaviour of the click event to open a new tab with the request submission form

Seems to be an alright UX.

Happy to chat through this live some time! would be nice to meet :)

[a-hariti]

I think opening a new tab could work as an alternative if it's not subject to blocking itself

The first two options both take control away from us and would probably delay the implementation indefinitely

[souredoutlook]

@lizokm as a stop gap I think adding the content to the footer and opening help.sentry.io in a new tab would be a great first step.

If we get the go ahead from Security to use the widget - it can be run cookie-less here by using the config setting outlined here: https://developer.zendesk.com/api-reference/widget/settings/#cookies

[lizokm]

@a-hariti - This has been approved by our legal team so we can go ahead and add it after we're done implementing the new UI. Their only stipulation was to add a script that ensures that no cookies are being dropped. Here's what they said:

If we have the following script loaded before the widget script it will prevent trackers from being dropped: