Add modeless feedback dialog for each page

[vpicone]

Summary

Add the ability for website users to give low-friction quick feedback on each page.

Examples:

1. gatsby – bottom right
2. watson health – bottom right

Justification

Our current team objective is to:

Significantly scale the engagement, collaboration, and enthusiastic adoption of Carbon by IBM product teams.

Allowing per-page feedback will allow us to get real-time feedback on our documentation and components.

Desired UX and success metrics

Users can click an unobtrusive button to open a modeless dialog which allows them to give feedback (e.g. positive, negative, and neutral) as well as a comment. These survey responses should be viewable in a dashboard.

[mattrosno]

Who's the intended audience for the submissions?

GitHub issues are more than just bugs and feature requests. We have an issue template for question, "usage question or discussion about Carbon components". Would it make more sense to direct people to open an issue, or us have a GitHub bot that opens an issue on their behalf so there's greater visibility and the team can respond?

If powered by a SurveyGizmo form, how is the team to get notified so they can respond in a timely manner?

How can we power this by GitHub issues so the feedback form is useful to other sites using our Gatsby theme?

[vpicone]

@mattrosno the intended audience is anyone on our website, using our documentation. The key to these forms is removing as much friction as possible.

If powered by a SurveyGizmo form, how is the team to get notified so they can respond in a timely manner?

Submit to survey-gizmo, send an alert to carbon-support

How can we power this by GitHub issues so the feedback form is useful to other sites using our Gatsby theme?

Github issues (human or bot generated) isn't the right way to go about this for several reasons:

1. Signing into GitHub and filling out a massive template introduces a lot of friction. It also necessitates a response from the team. The advantage of these low-friction, low=commitment feedback dialogs is that there's no response expected. This is a distinct advantage compared to an ever-growing list of issues piling up on the monorepo.

2. It's not just issues, it's quick feedback/comments/reactions as well. Should we open an issue every time someone marks a document helpful? It helps us capture things that aren't serious enough to warrant a github issue.

There's a reason Gatsby uses this method as oppose to directing everyone to open a new issue: https://www.gatsbyjs.org/docs/ (bottom right).

[mattrosno]

If the intended audience of who receives the responses is just the core team and not all repo maintainers, and if SurveyGizmo's Slack integration lets us route responses to one of our channels, then this makes sense.

Ultimately I want to save this type of information in our backend as events so we can include it alongside other data we collect for reporting. But, until we spin up a backend, let's use what we have. (We can always backfill our backend with SurveyGizmo data if we eventually power the form ourselves.)

I'm wanting to use a new channel carbon-live for a live view of other events that we start to capture. For example, when a sub-system publishes a component, developer essentials badge is issued, etc. Maybe we start that channel with this data. Since it's not all actionable, maybe we don't want to put that all in -support to avoid noise there.

In terms of responding to the inbound, maybe we thread-reply to the Slack message to designate that you're replying directly, so we know when somebody's followed up if a follow-up is necessary. We can come up with some convention in Slack to not step on any toes as we reply to the feedback.

[vpicone]

@mattrosno our 'backend' would source data from a variety of places (notion, github, surveygizmo, etc.) I don't see the point of storing it all on a database. Those services allow you to query for past events/specific ranges and they do a much better job of it than we would rolling our own.

Either way, that sort of effort requires smaller efforts like this one.

[jeanservaas]

Feedback component visual specs

Specs

Animation

Obviously the new little guy is going to behave just like our back to top button; it will be sticky and basically just sit 8px above the other one.

In terms of animation, how are we doing panel animation?

I would try:

$duration-moderate-02 (240ms)

and standard expressive easing: cubic-bezier(0.4, 0.14, 0.3, 1)

also, in terms of choreography... we first grow the x value (width), then the y value (height) so it would grow like the first example on this page

https://www.carbondesignsystem.com/guidelines/motion/choreography

Responsive behavior

I spec'd this pretty fast so I don't have a view at each breakpoint, but I'm thinking it would respond like the Gatsby feedback component and hold it's size at each breakpoint and then respond like our dialogs at mobile.

Context

Closed

Open

Sketch file

gatsby_feedback_component.zip

[jeanservaas]

@mjabbink what do you think? Three options, it has to go at least 80 in any color spectrum to really stand out over a 90 background

Question 1: Color

Teal 80 with Teal 70 hover (icon stays outlined)

Purple 80 with Purple 70 hover (icon stays outlined)

Gray 70 with Gray 60 hover (icon stays outlined) — I think this is elegant

Question 2: Solid or outlined icon on hover (Ding Ding Ding)

[vpicone]

@jeanservaas should we make any changes to the colors of the back to top button? maybe inverted from the winky?

Maybe we should have the hover states disappear when opened, since your cursor is there it doesn't really look like anything happened with the button in particular.

[mjabbink]

I like the Grey 70. Teal is second choice but would need to see it in a page context.I don’t think you need to fill the icon though. Save that for last if needed.   Looks cool. I’m curious how many people will use this. Hopefully we gather useful feedback. Wanna also do think IDL and BC sites.   m  Mike AbbinkExecutive Creative Director, IBM Brand Experience & Design, IBM Distinguished Designer +1 917 291 7516   IBM     ----- Original message -----From: jeanservaas <[email protected]>To: carbon-design-system/gatsby-theme-carbon <[email protected]>Cc: Mike Abbink <[email protected]>, Mention <[email protected]>Subject: [EXTERNAL] Re: [carbon-design-system/gatsby-theme-carbon] Add modeless feedback dialog for each page (#771)Date: Wed, Mar 11, 2020 8:49 PM    @mjabbink what do you think? Three options, it has to go at least 80 in any color spectrum to really stand out over a 90 background Question 1: Color Teal 80 with Teal 70 hover (icon stays outlined)   Purple 80 with Purple 70 hover (icon stays outlined)   Gray 70 with Gray 60 hover (icon stays outlined) — I think this is elegant   Question 2: Solid or outlined icon on hover (Ding Ding Ding) —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.  

[mjabbink]

Lean on grey 79 but also think teal 80 can work

[jeanservaas]

@vpicone
Couple of tweaks after our crit yesterday (here's the new spec)

• we are actually going to go Gray 60 with the feedback button because Gray 60 is actually our secondary button color in the dark themes. So we might as well make it consistent rather than randomly going Gray 70.

• Also, the icon will need to stay white at all times, not pop up to white on hover, anything less than white on a Gray 60 background will not be contrast accessible.

• The outlined icon will go filled when the dialog is open

• there is no hover state when the dialog is open

• the back to the top button will stay as is... we're not changing anything to match

• the dialog will go full width in mobile per our dialog guidance

@aagonzales approved spec for modeless dialog in mobile

New spec

Confirmation

you know how we do inline loading confirmation? Can the check mark just animate on and then the dialog close?

https://www.carbondesignsystem.com/patterns/loading-pattern/#inline-loading

[vpicone]

For the focus, blue-60 (inverse-focus-ui) and gray-60 (secondary) don’t meet the contrast requirements.

I think we need to keep the white line inset that I have now?