Improve the user consent experience

[jonathanmayer]

Ideas...

• Present a browser action that leads to a consent page. The user should have options along the lines of I'm Interested, No Thanks, and (optionally?) Remind Me Later.
• The user should have an option to withdraw consent at about:addons.

[jonathanmayer]

@biancadanforth makes this good point:

• It is not possible to proactively show a browserAction popup from a WebExtension to the user.
  • This was an intentional UX design choice by the WE API team. Other experiments have opened a page in a new tab or badged their browserAction button to draw attention to it, so that the user clicks it.

The pageAction and sidebarAction APIs follow the same approach.

A few other possible directions that come to mind:

• Use the Shield template's introductionNotificationBar API.
  • Pro: in-browser notification, doesn't require a persistent icon in the toolbar or a surprise tab open.
  • Con: hooks into privileged APIs, which we've been trying to avoid.
• Use the notifications API.
  • Pro: same as above, except not quite an in-browser notification (and might be confusing for some users).
  • Con: depends on the OS and user configuration of browser notifications.
• Provide the UX on the Firefox Home page (i.e., on launch or a new tab).
  • Pro: same as above.
  • Con: some users have a different launch page or new tab page.

[jonathanmayer]

Chatted with @akohlbre about next steps. We're going to work with the Mozilla folks to develop a conceptual design for the study-specific consent UX flow, then resume implementation. (Re-opening the issue and dropping the Friday milestone to reflect the current status.)

Our tentatively preferred approach is:

1. The study extension is installed in a Pioneer user's browser (via Normandy).
2. The study extension prompts the user to learn more about the study via the Shield template's introductionNotificationBar API.
   • If the user dismisses the prompt, the study extension is uninstalled. (TBD: we might include an option like Ask Me Later.)
   • If the user chooses to learn more about the study, a new tab opens with an informed consent page, built as an options page for the study extension.
3. On the informed consent page, a user can consent to the study, decline to participate in the study, or close the page. (TBD: we might want an Ask Me Later option here too.)
   • If the user declines to participate or closes the page, the study extension is uninstalled. (TBD: we might want to handle closing the page differently.)
   • If the user consents, the study begins.
4. A user can learn which studies are active by going to about:studies, which would be linked from the Pioneer extension entry in about:addons.
   • If the user wants to review or withdraw their consent for a study, they can click a link in the entry for that study's extension to reopen the informed consent page.
5. On the informed consent page, the user can review their prior consent and withdraw their consent.
   • If the user withdraws their consent, the study extension uninstalls. (TBD: we might want to try to delete associated data from the backend.)

[jonathanmayer]

From the December 6 call with Mozilla:

• We should also think about door hanger designs, like the well vetted design for the DNS over HTTPS rollout: https://github.com/mozilla/doh-rollout
  • That implementation used the PopupNotifications.jsm module: https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/PopupNotifications.jsm
  • We're not sure what the current support status is for these non-WebExtension privileged APIs.
• We should prepare example screenshots or wireframes for the design options that we're considering.
• We should discuss options in a follow-up conversation with Mozilla's design team.

[biancadanforth]

• We should also think about door hanger designs, like the well vetted design for the DNS over HTTPS rollout: https://github.com/mozilla/doh-rollout
  • That implementation used the PopupNotifications.jsm module: https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/PopupNotifications.jsm

The main difference here is that the DOH experiment was less an experiment and more what we call a feature rollout. It was prototyping a feature that has now landed in Firefox.

Here's the DOH popup for reference:

This is the notification we use for for a lot of permanent Firefox features (e.g. form autofill, plugin notices, storage permissions for offline apps, etc.). So there is definitely a design question: Can we bootstrap off this Firefox notification UI for a temporary, research-only study?

[jonathanmayer]

Pushed an implementation of UX mockups with the WebExtensions API, XUL appendNotification API, and PopupNotifications API.

https://github.com/citp/web-science/blob/ux-mockup/

[biancadanforth]

@akohlbre , I know this is primarily a UX discussion, so I don't have answers for everything, but below are my thoughts to some of the questions you posed in your ux-mockup branch.

For both consent and surveys

• Which of these two (or other) designs

Either option is technically feasible.

There is also a third option if we wanted to have a custom popup design: a proactively shown pageAction popup (thanks to @Rob--W for the info). The nice thing about this approach is that the popup could be implemented just like any pageAction popup: with standard HTML and JS. Though it would require writing an experimental API to bypass the user input that is normally required to open the popup. We would also need to decide when this pageAction button would be shown.

Regarding the current list of options, I would vote against the notification bar (appendNotification), mostly because any website can present similar UI, and I don't think this UI is all that common in Firefox these days.

In terms of technical feasibility, my recommendation is the PopupNotifications.jsm option if that meets our UX needs, as it would be the easiest to implement, and it presumably already meets Firefox design guidelines. We also have a recent example to draw from in the DNS-over-HTTPS study.

• Language for the main text
• Language for the buttons (yes, no (and later?))
• Icons
• If using PopupNotifications, which UI element it's anchored to

As you have depicted in your mock of the popup, these are anchored by default to the transient Info icon. If we don't want a more persistent toolbar button (e.g. browserAction or pageAction), that seems like the most suitable element.

For consent

• Where buttons lead (options page? external SUMO page?)
• Process for overall consent vs. per-study consent

For surveys

• Where buttons lead (directly to survey platform? info page, then platform?)
• Whether surveys are baked-in and scheduled, or can be deployed dynamically

Can you elaborate a bit by what you mean by "baked-in and scheduled" and "deployed dynamically"? My experience with surveys sounds like it's the former, where the URLs are hard-coded into the extension.

[akohlbre]

Thanks @biancadanforth!

There is also a third option if we wanted to have a custom popup design: a proactively shown pageAction popup (thanks to @Rob--W for the info). The nice thing about this approach is that the popup could be implemented just like any pageAction popup: with standard HTML and JS. Though it would require writing an experimental API to bypass the user input that is normally required to open the popup. We would also need to decide when this pageAction button would be shown. Regarding the current list of options, I would vote against the notification bar (appendNotification), mostly because any website can present similar UI, and I don't think this UI is all that common in Firefox these days. In terms of technical feasibility, my recommendation is the PopupNotifications.jsm option if that meets our UX needs, as it would be the easiest to implement, and it presumably already meets Firefox design guidelines. We also have a recent example to draw from in the DNS-over-HTTPS study.

This is helpful -- using something that distinguishes us from any website makes sense. Is the main benefit of pageAction+bypass over PopupNotifications that the former makes it easy to use custom html? If so, I agree with you in leaning towards PopupNotifications, since I think the UI options there are enough for us, and I'd rather stick with established designs when we can.

One more thought -- I occasionally see notifications in the bottom bar, like: I'm not sure how those are implemented or whether it's something we might like or be able to use. Any opinions?

As you have depicted in your mock of the popup, these are anchored by default to the transient Info icon. If we don't want a more persistent toolbar button (e.g. browserAction or pageAction), that seems like the most suitable element.

Great!

Can you elaborate a bit by what you mean by "baked-in and scheduled" and "deployed dynamically"? My experience with surveys sounds like it's the former, where the URLs are hard-coded into the extension.

Yeah, essentially that, and that was my assumption. I could imagine situations where researchers realized something they'd like to survey on after the study had started running -- if there were a mechanism to let them push a survey later on, it could be useful. I think there's probably not enough need for that to justify trying to create our own.

[akohlbre]

Closing to move into #61.