[Profiler] Profile upload dialog with customizable PII removal

[digitarald]

UX for https://github.com/firefox-devtools/profiler/issues/1802 Team: @canaltinova, @gregtatum, @fqueze and @digitarald.

Background: The profiler needs to keep users from accidentally sharing data that they are not aware of but provide user choice to include more data.

Guiding principles (from the PRD):

• Share everything by default for Nightly/Custom builds (with a warning for the unaware)
• Share no PII by default everywhere else
• Keep it understandable for technical users

Designs

Diverging stage to find the right interface for users opting into sharing more data and understanding their choices). When converging, we can tweak the copy for labels, descriptions and warnings.

Greg created a prototype, in which users uncheck options to include more data: Deploy preview

Harald's mockups are exploring the direction of checking boxes to share more data:

cc @violasong @fvsch for input.

[fqueze]

Thanks for starting this discussion Harald!

Random thoughts when looking at the provided mockups:

• Checking boxes to have more data included seems more natural to me than unchecking things.
• I like the idea of including information about how much data will be included like on the mockup at the top right (ie. '4 hidden threads', '3.1s outside the time range', the names of the add-ons, the hostnames, ...). I think if we decide to do it, it doesn't have to block the rest of the design and we can keep it for a follow-up.
• I like the idea of showing the size of what will be uploaded, but for me this doesn't have anything to do with sanitization (the size of the file doesn't relate to the amount of PII shared), so rather than showing this information at the top of the list of checkboxes, I would prefer showing it close to the Publish button. If we replace the current cryptic error message we have when the upload fails because the file is too big with a message that says that; having the info about the size of the upload will nicely make the error actionable!
• Having the checkboxes in 2 columns (bottom left mockup) is harder to process for me.
• The (i) icon in the bottom right mockup looks nice.
• I dislike the "Download" button in the bottom right mockup. The word "download" would make me worry that my data is already online somewhere. And even if we word it differently (eg. "Save"), I don't see the point of sanitizing PII out of a profile that's going to be saved locally. I mean, I could make up some unusual use case where that would be nice, but I can't think of any that deserves such a prominent position in the UI.

[digitarald]

I like the idea of showing the size of what will be uploaded, but for me this doesn't have anything to do with sanitization

Agreed, it probably should be a combination of both showing what kind of data gets removed per category and making it less prominent. The choices are not about reducing the size, but stripping private data. I did like how the data removal summary can be a header for the section, but a more privacy focussed stat would make more sense.

The (i) icon in the bottom right mockup looks nice.

This section could be informational and wrapped in a photon's relevant helper style. Those don't seem to have icons though, but can either have a Learn More link or tooltip (Relevant).

I dislike the "Download" button in the bottom right mockup.

Good one; sounds indeed like it's already in the cloud. Probably just needs some better copy; like Save. This might clash with renaming the label in the top-level button to "Publish"; but maybe it is not that important as secondary option.

[digitarald]

@violasong to help with your backlog prioritization, we are aiming to land this work before the end of Q2 and the backend work is nearly completed; so only frontend remains.

[violasong]

Sounds good! I like where the mockups/comments are going, and will respond in more detail soon.

[digitarald]

@violasong we have a profiler planning meeting tomorrow and I'll be PTO for 2 weeks after that – would it be feasible to have some initial input by EOD today? Happy to jump on a chat to provide more context if needed.

[digitarald]

Other thoughts that might be considered in the UI, adding to the notes before:

• Give users more context when needed to understand some of the technical and complex options that don't relate to "tangible data" (hidden threads, time ranges, etc)
• It might make sense to hide the complex options field for release users (vs pre-release dev audience), similar to what @gregtatum implemented, so users are not overwhelmed with making decisions for 6+ checkboxes. A spin on Greg's UI would be showing a checkbox ala "Opt-in to include additional data …", which then unfolds the additional options.

[violasong]

Yes! Will look at it this morning

[violasong]

Here's what I would suggest based on the above points:

-- Share Performance Profile

Upload your profile and make it accessible to anyone with the link. By default, your personal data is removed.

v Include additional data that may be identifiable

• [ ] Hidden tracks
• [ ] Hidden time range
• [ ] Resource URLs
• [ ] Screenshots

[Cancel] [Save] [Publish]

--

• I think having a short title helps with cognitive load. Calling it "Share Performance Profile" ties it in with the button wording.
• Shorter intro paragraph and secondary title
• 'Positive' checkbox options so fewer double-negative issues
• Info icon looks good too!

[digitarald]

Thanks @violasong for the input!

I think having a short title helps with cognitive load. Calling it "Share Performance Profile" ties it in with the button wording.

Makes sense. The recent wording we picked is "Publish", which felt more correct to the action and in line with other tools like Invision and Figma. But it sounds like your recommendation is mostly about reflecting the button label in the title.

v Include additional data that may be identifiable

Would you recommend to hide that section by default or just receive a "section" styling?

[violasong]

Ah, not sure - do you foresee these options used like 5% of the time or 30%+? Is it important to list out all the options for discoverability in case the dev is missing something? It’s not too much info if we just have 4-5 checkboxes, so maybe I’d err on default-visible.

On Wed, Mar 27, 2019 at 12:27 PM Harald Kirschner notifications@github.com wrote:

v Include additional data that may be identifiable

Would you recommend to hide that section by default or just receive a "section" styling?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/firefox-devtools/ux/issues/54#issuecomment-477314162, or mute the thread https://github.com/notifications/unsubscribe-auth/AADauo6Syf-aXuEyIcPxIN7wMN0DyvtXks5va8YOgaJpZM4bsDAd .

[julienw]

Hey, I filed an issue in https://github.com/firefox-devtools/profiler/issues/1957 after this was implemented because I found the way checkboxes work confusing. Especially sometimes checked means filter out and in other locations it means include.

[digitarald]

It’s not too much info if we just have 4-5 checkboxes, so maybe I’d err on default-visible.

Seems like that is the way forward until we get more checkboxes. Related https://github.com/firefox-devtools/profiler/issues/1957#issuecomment-484491272 had a great idea on how to conceptualize the removal of hidden information and private data.

Here's what I would suggest based on the above points:

@violasong how would this be worded for Nightly, where we want to share everything by default. Just pre-opening the section and having the checkboxes checked might be enough.

[digitarald]

v0 landed, closing for now.