feat: finalize metrics modal and icon

[lidel]

The cookie button introduced in #309 is placed in a very unfortunate, prominent place.
It looks like an important item related to gateway checks:

An easy fix would be to move it to top bar, we already have github icon there:

[SgtPooki]

@juliaxbow @whizzzkid what do you think? I placed it where it is to purposefully get folks attention :) but i figured these issues would come!

I originally wanted it in the top right; theres previous patterns on sites to place it in the bottom right, and there's reasons against all places we could put it without a global site configuration gear or something.

For sites/apps unlike webui/desktop where we dont have a config/settings page we'll need a standard for where it goes. This should be a blocker for ipfs/ipfs-gui#105

[juliaxbow]

+1 to moving it away from its current location where it looks like it's related to reading the gateway checker. While i'm not opposed to including it in the menu, in the absence of a footer (due to infinite scroll/loading of gateways) I think our best options are:

1. Including a line of text explaining current settings and a link to change/opt out of current selection.

2. A widget in a fixed position on the bottom left or right hand of the page. It would look something like:
   https://user-images.githubusercontent.com/58958327/206096978-26bb1a75-a8d0-4548-a6ca-b7aa8fc84647.mov

For sites/apps unlike webui/desktop where we dont have a config/settings page we'll need a standard for where it goes. This should be a blocker for ipfs/ipfs-gui#105
@SgtPooki agreed, and also given the convo today around default opt-in we'll need to update the language and selection options. Will look at this in a few hours

[whizzzkid]

@juliaxbow I actually relate with the floating cookie icon on the bottom left, can we have that @SgtPooki?

[juliaxbow]

Circling back. If we move towards the floating cookie icon, I suggest we do shift to a modal box vs banner as previously proposed. This also addresses #341. By clicking on the cookie icon, users can opt out of non-necessary metric collection and click a link to learn more about what information we're collecting. If we have a privacy policy (I don't think one exists yet) we should link to that as well.

Note: As we're still defining necessary vs non-necessary metrics (ipfs/ipfs-gui#125, ipfs-shipyard/ignite-metrics#2) toggles in the prototype below are generic "All Cookies" vs "Strictly Necessary" but this can be changed once we've determined categories. In the prototype below, users would need to click "How we use cookies" to determine what falls under strictly necessary.

LMK if we want to go in this direction and I will send over design specs.

cookie.recording.mov

[SgtPooki]

in the absence of a footer (due to infinite scroll/loading of gateways)

We could still fix the header to the bottom of the viewport even with infinite scrolling, but I like the new design (continue below)

As we're still defining necessary vs non-necessary metrics

I think we've got a strong signal and precedence (thanks to @lidel's comment at ipfs/ipfs-gui#125 (comment)) that allowing users to opt out of metrics (for now) is a good step forward.

If we decide that users should not be able to opt-out in the future (due to lacking metrics we need to make decisions) we can update the necessary metrics toggle to be disabled. I think one great point from lidel is that many users may not care, but we should get a good signal on that.

Speaking of, I've just added a sub-task in ipfs-shipyard/ignite-metrics#2 for this

LMK if we want to go in this direction and I will send over design specs.

@juliaxbow I like the new design. I propose the following to address item 4 from "Current planned solution" in ipfs/ipfs-gui#125:

1. Modal is open by default for users who have never seen it. (new & existing users will get this)
   • Closing via X or "close" button will update consent according to toggles selected
2. Toggles are enabled by default
   • Note that upon pageload: only "necessary" consent is registered via the countly sdk, but the modal will have "all" enabled, so if the user just closes or clicks the X, then they will be "opted-in" to "all" metrics.
3. "how we use cookies" could be rephrased to be "See more about our telemetry collection" or similar
   • Link should lead users to Define basic metrics and patterns for consent & collection. ipfs-gui#125 or notion page documenting process and history of the metrics decisions behind the new modal and cookie logo
4. rephrase "your cookie settings" description to be more generic for all projects.

[SgtPooki]

Note that I updated issue description in ipfs/ipfs-gui#125. @juliaxbow could we get a mock up of displaying all the toggles for features listed under "Metrics distinctions". i.e. the features listed at https://support.count.ly/hc/en-us/articles/360037441932-Web-analytics-JavaScript-#features-for-consent

I imagine we will need some expanding config of some sort so the initial banner isn't annoyingly huge. Can we have an expandable section in the modal that allows for toggling individual items on/off? or at least four toggles to represent the groupings in ipfs/ipfs-gui#125? i.e.

const necessaryFeatures = ['sessions', 'views']
const marketingFeatures = ['attribution', 'users', 'location']
const performanceFeatures = ['events', 'crashes', 'apm']
const trackingFeatures = ['scrolls', 'clicks', 'forms', 'star-rating', 'feedback']

also, we should probably update the "necessary" toggle to say "minimum" or something.

[juliaxbow]

"how we use cookies" could be rephrased to be "See more about our telemetry collection" or similar

• I changed to "our cookie and metrics collection policy" to keep consistent but can change if you feel strongly. Will look for other wording.

rephrase "your cookie settings" description to be more generic for all projects.

• What other projects are you referring to? Could do "manage metric collection" but that might be confusing to change terminology for users since we have a cookie button.

const necessaryFeatures = ['sessions', 'views']
const marketingFeatures = ['attribution', 'users', 'location']
const performanceFeatures = ['events', 'crashes', 'apm']
const trackingFeatures = ['scrolls', 'clicks', 'forms', 'star-rating', 'feedback']

• QQ Did you categorize these or is that from Countly?
• Are you tied to the naming convention here? Wonder if "marketing" is a misnomer for what we're seeking here.
• Included a dropdown in the prototype below but that will lead to a whole lot of toggles. I think we should group and limit choices, at least for some categories that are are less desired by us.

Cookie Modal.pdf

Primary Toggle; Arrow Icon; Buttons:
IPFS Jade
#3B8C90

Sub Toggle:
IPFS Turquoise
#47AFB4

Text; Metric category outline
IPFS Navy
#073A53

[SgtPooki]

"how we use cookies" could be rephrased to be "See more about our telemetry collection" or similar

• I changed to "our cookie and metrics collection policy" to keep consistent but can change if you feel strongly. Will look for other wording.

I think the term "cookie" is what is throwing me off. We don't technically use cookies at all by default; see https://support.count.ly/hc/en-us/articles/360037441932-Web-analytics-JavaScript-#sdk-data-storage. So "telemetry collection" is the most generic while being more factually correct. There are a number of callouts here:

1. We don't want to scare folks off by saying we are using cookies when we're not
2. we don't want to lie to users about storing data on their devices (they really don't care about the difference between cookies and local storage, do they?) https://law.stackexchange.com/questions/30739/do-the-gdpr-and-cookie-law-regulations-apply-to-localstorage is a decent read on this, though a little obtuse.

We don't use cookies and don't store user data, but the term "cookie" will immediately imply some sort of "user data storage." I would prefer we do not use the term cookie at all.

rephrase "your cookie settings" description to be more generic for all projects.

• What other projects are you referring to? Could do "manage metric collection" but that might be confusing to change terminology for users since we have a cookie button.

All of our projects. Ideally, the messaging we use should be consistent across ipfs-webui, ipfs-desktop, ipfs-companion, and all others listed at ipfs/ipfs-gui#105

I agree that the cookie button is confusing if we're not using cookies. Do you have an idea for another icon to indicate metrics collection? Maybe we don't use an icon at all, but a floating "metrics collection settings" text, or even a gear icon?

We should update this sooner than later.

const necessaryFeatures = ['sessions', 'views']
const marketingFeatures = ['attribution', 'users', 'location']
const performanceFeatures = ['events', 'crashes', 'apm']
const trackingFeatures = ['scrolls', 'clicks', 'forms', 'star-rating', 'feedback']

• QQ Did you categorize these or is that from Countly?

The strings ('sessions', 'views', etc..) are countly features. the groupings ('marketing', 'performance', etc..) are my own categorization of those features.

• Are you tied to the naming convention here? Wonder if "marketing" is a misnomer for what we're seeking here.

We could re-categorize those if you think the countly features belong in a different group. See the descriptions at https://support.count.ly/hc/en-us/articles/360037441932-Web-analytics-JavaScript-#features-for-consent

• Included a dropdown in the prototype below but that will lead to a whole lot of toggles. I think we should group and limit choices, at least for some categories that are are less desired by us.

Thanks for throwing that together. Ok I totally agree.. limiting them to the groupings would be a lot less confusing and more simple to implement. Sounds like we need to do an audit of our groupings.

[juliaxbow]

Thanks for the clarification re: our use (or lack thereof) of cookies. Makes sense and I'll play around with alternatives today.

Re: Standardizing language

• I'll take on updating the language (for this issue and to align across ipfs-gui).
• QQ - Did legal get back with the privacy policy? I can steal verbiage from that, which is probably our best source of truth

Re: Modal design

• happy to make changes to design if you have feedback

[SgtPooki]

Thanks!

QQ - Did legal get back with the privacy policy? I can steal verbiage from that, which is probably our best source of truth

I meet with legal on Thursday the 5th at 9:30am PST to discuss privacy policy updates and creating a more generic privacy policy for all of our projects

[SgtPooki]

happy to make changes to design if you have feedback

I think the modal design you have, without the granular control, is going to be the best route moving forward.

i.e. Don't expand like this:

Leave like this:

So we could probably remove the borders, and the carrot icons

[juliaxbow]

Design

• Removed the dropdown and updated the design slightly (Figma file & screenshots below)
• New preferences window
  

Button options

• Agreed we should move away from the cookie icon since it's an inaccurate representation of what we're actually collecting.
• Option 1: Keep the floating icon in the bottom left, update with "metrics" icon. This is less intrusive but may not be as intuitive for users upon first viewing
• At 15 seconds in, video shows what happens for a second visit to the site

Metrics.Hover.Button.mov

• Option 2: Change to a floating button with text in the bottom right. This may block some gateway content but is explicit as to what action the user can expect. In this version, clicking on the button would bring the modal to the center of the page vs corner

Telemetry.Collection.Hover.Button.with.Text.mov

Flow (With hover metrics button)

Verbiage

• Addressing content in notion here

[SgtPooki]

@juliaxbow I really like the metrics icon, and I love the text in option 2. I think a mix of 1 and 2 where the icon used in option 2 is on the left would be great.

[SgtPooki]

@juliaxbow this issue was assigned to you, so I still left you on it, but I also assigned Dan because he's working on it now. Do you still need to have this assigned to you?

[SgtPooki]

Note that this task should only implement a single group toggle, so that it looks similar to

We will add additional toggles later as a part of ipfs-shipyard/ignite-metrics#36

Also take note of the potential grouping name changes in PR at ipfs-shipyard/ignite-metrics#35

[juliaxbow]

Since it's now only one option the toggle + language around customizing your preferences seem superfluous. Not a blocker but I'll get back with another mockup shortly.

It could look like "[ ] Allow collection of metrics and telemetry data for necessary features"

[SgtPooki]

We will be adding multiple toggles later, if not now, so I would prefer to keep the UI designed with that in mind

[juliaxbow]

I think a mix of 1 and 2 where the icon used in option 2 is on the left would be great.

If you like the button with text, we could also have it expand on hover so as to not take up too much space (especially in mobile). It would look like:

Expanding.Metrics.Hover.Button.mov

[SgtPooki]

I really like that one @juliaxbow