biancadanforth
commented
4 years ago Re: Consent and survey UI/UX decisions
I know we will talk about much of this more tomorrow, but I wanted to reply at least to answer @akohlbre 's questions from #4 (sorry for the long delay):
Is the main benefit of pageAction+bypass over PopupNotifications that the former makes it easy to use custom html?
That's certainly one of the benefits. Another is a much simpler privileged API to worry about, since we'd just need a way to bypass the user interaction requirement in the API, rather than having a more complex API that has to basically re-implement all of the behavior and UI using internal Firefox APIs.
In general, I am strongly in favor of keeping this extension as close to a pure WebExtension as possible (i.e. little to no privileged code). It will be simpler and more robust that way.
That said, we have prior art for the PopupNotifications.jsm approach, so this page/browserAction approach makes sense only if we feel that the built-in doorhanger UI is inadequate in some way and if we plan to have either a pageAction or a browserAction.
Which reminds me (thanks @mythmon): One thing to consider if we keep with the PopupNotifications.jsm approach: this doorhanger is per-tab, i.e. not global. So if you switch tabs or switch windows, it will hide until you make that tab active again, and it will be implicitly dismissed if the tab it was opened in is closed. Maybe that's fine, but it's just something to keep in mind.
At this point we really just need UX folks to make the call as to what is the best option.
One more thought -- I occasionally see notifications in the bottom bar ... Any opinions?
This is from the browser-data-submission-info-bar, which uses the notificationbox widget. I'm not sure what the persistence is of this (cross-tab, cross-window, …) or where all this has been used.
Here's a WE experimental API example for it, though I think this might display at the top of the page.
I personally dislike any notification bar approach for the reasons previously mentioned elsewhere: they are easy to spoof by webpages, and they aren't very noticeable. Ultimately however, that's a UX call.
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.
In my experience, survey writers provided me with a URL to hard code in for a survey hosted externally. It may depend on the survey platform used, but from what I've seen, the survey at that endpoint could be updated at any time, as long as the survey author(s) don't change the URL for the survey.
Condensing #48, #31, #16, #4, and #18 to here.
Performance and requirements evaluation (#18): some previous evaluation in https://github.com/citp/web-science/pull/43#pullrequestreview-331674942 and https://github.com/citp/web-science/issues/46#issuecomment-571420843. We should continue and expand testing on the newest version of the extension.
Consent and survey UI/UX decisions (#31, #16, #4): based on https://github.com/citp/web-science/issues/4#issuecomment-573853928, I think we're going to go with the
popupNotificationsUI (stub implementation in 72a7aef and being tracked in #55). We still need to decide on language, images, and exact behavior of the notification (timing, where links lead). Also see discussion in comments on https://github.com/citp/web-science/pull/43#discussion_r361034054.Integration and interaction with Normandy (#48): how exactly will consent, installation, and removal work -- which parts will be handled by this extension vs Normandy?
Telemetry: which kinds of Telemetry events should we use, how will they be handled on the backend, and how should encryption work? Also see https://github.com/citp/web-science/issues/17#issuecomment-562670097.