-
-
Notifications
You must be signed in to change notification settings - Fork 4
Privacy mode by default UI #54
Comments
@cjeria the mock you added to the figma looks good! (pasting below because i had to do some weird webGL thing to open the figma file) I think we can make the copy a little clearer. Something like:
Button: Could we also include an |
From design sync
|
When the user can't connect to a dapp, but a dapp is trying to.. this prompt opens automatically, right? To pro-actively tell the user what's happening and guide them towards action. As discussed earlier, I am assuming that the user doesn't have to self-initiate opening the Metamask modal. |
@omnat Unfortunately, the user will have to open the MetaMask extension to see this prompt (it's not a popup). We've discussed other options like using a pop up instead (like the Connect pop up) which sounds like it's feasible to do, however, the reason we decided against it if I recall, was that it was too similar to the proper Connect Request UX. Looking at all methods for accomplishing the same goal (connecting to a dapp) we have:
Seems redundant IMO and we should consider unifying them. |
This looks really great @cjeria ! Maybe bold the first line rather than "Privacy Mode"? Even though it's big and yellow, good to be super clear about the topic. |
Could we also add a |
cc @danfinlay @whymarrh this look okay to y'all? |
The current design is very wordy, and is tucked at the bottom of the window, and yellow, all of which I think combine towards making it seem unimportant, and easy to ignore. Since MetaMask is an account manager, and its primary usage is logging into sites, I think we should treat this UI with more primacy. I'd rather we embrace the patterns of usual account menus and just replace this whole yellow box with a "Log In to [SITENAME]" button, closer to the top of the popup. Technical QsAlso I'm not sure we are able to identify the currently open tab's URL without requesting a new permission, so we might also need to design a flow for how we ask for the new |
All that said, if this is just MVP, and we're about to revisit this for login-per-site, then I would say go ahead with it. At that point, we'll also want the ability to let the user select the account to sign in with, and so an account list might be the better "you're not logged in" view. Maybe something like this, from MetaMask/metamask-extension#3383 |
so @danfinlay you're ok with the design for MVP? with the suggestion that we make it more visually prominent if possible? I do want to get this in production separately / before log-in per site Also, we should consider the flow where the user has MetaMask locked -- would they type in their password, then click "share my address" ? Needing to request a tab permission would be super not ideal - @danfinlay you saw whymarrh's response here (MetaMask/metamask-extension#6384) right? |
Yeah, particularly because:
I hadn't seen the latest, but it still appears aligned with what I'm saying: While we can "detect if this site ever touched it", we don't know what the "current selected tab" is, so we can have a list of sites that have tried to access accounts (a method Whymarrh and I seem to agree is already imperfect, and has false positives), but we can't know which site a user is looking at when they open MetaMask. |
I think it'd be safe to just show the yellow notification if the user has any legacy dapp open in any tab to err on the side of over-communication & awareness |
So if there are multiple "legacy detected" dapps (these are any dapps that check accounts before calling |
I have a hunch that this current design will work just fine, but we won't know until it's tested in the real world. I don't think @bdresser was suggesting that the notifications will stack up per legacy dapp, there would only be one if the tab you are currently on is a legacy dapp. If two tabs are legacy dapps still only show one notification but with the corresponding URL of the tab/dapp you're focused on. If that's not possible, we could instead show something like "3 dapps would like to connect to you're account" and expand to show which dapps with a ✔️ or ❌next to each. In any case, I'd push for a coded up prototype of this design first to test its functionality and iterate on the UX from there @whymarrh |
This was the point we were discussing, we can't detect what your current tab is without an additional permission, and requesting it might benefit from some extra design consideration (do we want to let the user know why they're about to be asked for a new permission?)
This is more realistic, and we might want design for that, and the subsequent screen where the user selects which sites to log into. However, (and I feel like a broken record) this legacy dapp detection is not perfect (it has false positives), and that means this warning will appear for sites that are "doing everything right", and I think that's unfortunate. It paves our basic dapp support into hard-to-avoid jank. One way to make this whole thing feel less janky is to avoid terms like "privacy mode" and "this app doesn't support X", and just say |
Really want to avoid an additional permission - our active installs took a big hit last time. I'm in favor of loosening the copy, but still think it's wise to tell people this friction is because we're trying to protect their privacy. How about:
I don't think false positives are a huge risk because if everything works smoothly, the user will likely not decide to open the extension from the nav-bar and they'll never see this message. |
Here's one of the latest ui design for this. Feedback is welcomed! |
|
Took another pass at this notification and created a light version for comparison. They are both intended to stand out and encourage user engagement. Would like to hear feedback about which direction to move forward with @omnat @bdresser @danfinlay |
I don't have feelings on staying in the design system vs doing something outside of it, but I do think the user should be able to interact with the wallet behind/around the modal - so for that reason I favor the functionality shown in A @cjeria |
I am assuming this applies to current dapp that user is on (active tab). So if 2 legacy dapps are open on 2 tabs, only the active tab dapp connect request is shown in extension. Also assuming these requests don't pile up ("3 dapps are requesting you to share your address") - only the one in which user has context for (i.e., active tab) Are the above 2 assumptions correct?
|
I like the functionality of A, but could we do it while avoiding spending time extending the design system? This is going to be a temporary thing until login per site. Also I’m curious what the x button or ignore should do. Is there another way to log in after dismissing these, or is it permanent? Kinda seems like we might want to make it non-dismissible. |
I second @danfinlay re: login-per-site, and I also think we should keep in mind ocap permissions with respect to the amount of effort put into this. "Sharing an address" will be just one permission among many in the not-particularly-distant-future. |
@danfinlay @omnat given that only about 30% of DAU are completing on-chain tx, there is definitely a usecase for folks opening the extension without sharing their address ( I realize they may interact with dapps outside of just submitting tx, but point stands). Users may also need to switch accounts or networks. I think people should definitely be able to interact with the extension even when the popup is showing.
@omnat yes! good call on tooltip copy, how about
Re: design system, I don't think the dev overhead to style the buttons differently is huge effort |
I think there's a happy middle ground between A and B options per the feedback provided above (thank you team!). The X was to dismiss this alert since I expect users will get annoyed seeing it if they decide not to connect. Here's a simplified iteration using a flash alert component (defined in the design system) with a share button. There no dismiss option and no new components to be created just for this. Alternatively, however, we could just do this same design in the dark mode style if that seems better for this specific use-case? |
Love the update! Would also be cool with dark mode your call! Still think the copy should remain "Share your address with dappname.com" – the inclusion of another verb makes it a litttttle bit more confusing imo. But it's a weakly held opinion so I'm cool w this if you want to keep. |
Only last thing is that we should remove the last line in the tooltip because although I get that it's saying our default protects your wallet activity, it sounds like clicking "share" will protect your wallet activity, which it doesn't. Also @cjeria where does this final version live in the team Figma? Other than that, good to go! |
Updated tooltip language @bdresser Link to the figma file |
Design: https://www.figma.com/file/foWeMNl8hQNDnxBjf2fFcbhd/privacy-mode-notice?node-id=0%3A1
Dev: MetaMask/metamask-extension#6352
The text was updated successfully, but these errors were encountered: