Make "Approve" confirmation screen more informative

[bdresser]

"Approve" function calls are really confusing for users. (https://twitter.com/erinfrey/status/1027258104423931905)

We should consider creating a custom component for the "approve" function that makes the interaction clearer.

Basically, user is granting dapp permission to spend X amount at any time without asking confirmation. This is very common in dex sites. Sometimes this is accompanied by an immediate transfer, making it seem like the "approve" actually spent some money.

[bdresser]

could consider displaying a token balance (like on the home screen) with additional information that a certain amount has been approved for spending by other entities.

[bdresser]

From MetaMask/metamask-extension#6020 - even with our small warning, apps often ask for approval of large sums and we show a scary scientific notation value (cc @omnat )

[bdresser]

closing as part of #80

[bdresser]

relates to MetaMask/metamask-extension#6469 - could be a simple way to deal with the awful massive number

[omnat]

Per our conversation on this today: Approve is used in DEXes typically. When used in other use-cases, need to understand what's the context/ purpose there. To understand context, would be interesting to check in Matomo which dapps call 'Approve' function? How often is Approve function being called in conjunction with Confirm? (also useful for #110 ). wdyt @bdresser?

Stating 'Unlimited' is an option, but Bobby suggested a better alternative: What if we nix the insane large value or 'unlimited', instead just give a clear textual justification of why that permission is asked today - and how that relates to user action on dapp.
Open question: What should that copy be? Because the current text/copy is not really much more helpful either.

Questions we should address for this screen as suggested by Ryan (UX/Content designer):

[bdresser]

I actually think the warning label conveys some of the information you list at the bottom. We could update it to:

By approving this action, you grant permission for [ current dapp ] to spend your DAI

To me, this answers the "what," "who," and "consequence." Maybe a second sentence about "make sure you trust this dapp," but i always find those not very actionable.

Whta do you think we should do for the total? Like 0.01 ETH now (for gas), potentially up to [ your max DAI amount ] of your DAI.

[omnat]

2 most important things users need to see in this screen:

• A clear message / textual information on what this permission really is (can be inspired by 'Enable' context shown in Slack thread -- make it clear that specific spends will be subject to another explicit confirmation request from the (d)app
• Fee that this action will cost
  Inspiration for how to give context on 'Approve' https://consensys.slack.com/archives/G4V2HTG0Y/p1563496916087700

[cjeria]

Here's a fresh take on the approve screen.

I've divided this screen into two sections (top and bottom) with the intent to make it easier to decipher what's going on when a user gets prompted with an approve function.

Top half section

This section groups the "what", "who" and "consequences" in a concise and simple to read format, with an icon for the permission for affordance.

Bottom half section

This section is dedicated to displaying transaction details. I used a more common receipt-style format for easier readability.

Feedback welcome!

cc @rachelcope

[omnat]

I like! Good stuff @cjeria!!

1. Like the break down of the 2 sections! And like the idea of showing tx fee options and data in context of the pop-up. For the time being this is a modal within a pop-up window - perhaps if we move towards full-screen mode eventually, then it'll be a more standard modal interaction pattern.

2. What do you suggest info tooltip will show? I'd vote for additional info that with this permission alone this app/contract won't be able to spend [N] amount of funds.. Explicit confirmation will be required for transactions.

3. Suggestion to swap the position of 'Edit' and 'Transaction data'. So Edit is closer to tx fee (as that's what its editing), and tx details close to overall tx details

4. We are then moving away from 'Function' name on this screen, yeah?

[cjeria]

2. re tooltip

Exactly what I was thinking. The tooltip would have more info about this specific permission and would further answer what the "consequences" are by going one step further and explain "how" and "when" spending could occur.

3. Suggestion to swap the position of 'Edit' and 'Transaction data'.

Will try that.

4. We are then moving away from 'Function' name on this screen, yeah?

With respect to the surface layer (what every user-type sees), I don't see it as moving away from the function name, rather defining the function (approve in this case) in a more conversational/user-friendly way that a wider audience can understand.

Also the function name will be viewable in thedata section for our more technical users to see.

[omnat]

Also the function name will be viewable in the data section for our more technical users to see.

Good call! 👍

[omnat]

Information tooltip copy suggestion:
By Approving, you are authorizing this site to move your tokens on your behalf. Explicit consent will be asked before any action is taken on your funds. This authorization is on blockchain so it costs a network fee.

[ryancreatescopy]

Hi guys, sorry to jump in. Christian asked for my feedback, so here it goes:

First and foremost, such a massive improvement! But I have some additional ideas.

1. Can we abstract away the contract address? If we're pulling in Uniswap, can we just have it as "My account 1 -> Uniswap" – perhaps if a user wants to see the tx address they can get it via a tooltip or something. I just feel that the more we can abstract from this screen the better.

2. Does a user really need to know the [n] figure? OR rather, does it need to be so upfront? My current assumption is that this is both confusing and a little unsettling to describe an app as being able to spend your money.

So,
Less: This dApp wants your permission to spend up to 1,000,000 DAI
More: Approve your DAI for use on Uniswap

This makes it feel like you're in control of this situation rather than surrendering any future wealth. Yes, technically the contract can spend up to 1,000,000 DAI but this isn't really an easy concept to grasp for most users. Your DAI is a better way to think about it, in my opinion.

If it's true that "Explicit consent will be asked before any action is taken on your funds." (as per Omna's tooltip copy), I don't think we need the frightening figure at all.

Plus it's unlikely that you're ever going to have this astronomical figure so it's better to explain the immediate reason the user is doing this action: so you can use DAI on the app. The tooltip can then say something like "This will allow Uniswap to access your DAI when it needs to based on the actions you do on Uniswap. " MORE THOUGHT NEEDED FOR THIS FINAL COPY.

However if this action does grant the dApp permission to just spend your DAI whenever they want... we should definitely be a bit clearer with a warning. I guess I'm wondering why they need permission to spend a lot of my money.

Is it that it allows you to set up scenarios where you can setup a trade and you don't have to be present to confirm it as long as the conditions of the trade are met?

Maybe its more like: Uniswap needs your approval to access your DAI. This will allow them to [complete trades] once you've set them up. They will never spend your DAI without your permission. or something similar

With this approach, I'm not sure you'd even need a tooltip. There seems to be plenty of space on the screen.

All a bit difficult to explain in a comment... maybe we can have a call to discuss it further if you'd like any further clarification on my points. None of the copy I've suggested should be considered production copy, more of an indication of message... I'd need a little more info to write the real thing!

Hope this helps.

[bdresser]

Good stuff everyone! this is already a better screen than what's in production.

Can we abstract away the contract address? If we're pulling in Uniswap, can we just have it as "My account 1 -> Uniswap" – perhaps if a user wants to see the tx address they can get it via a tooltip or something.

In instances where we show sender & recipient address without listing the contract address, we've had users reach out with fear & confusion that what they see on Etherscan (their account sending to a contract address) did not match what they saw in MetaMask (their account sending to another account). The first is technically accurate, but the second makes sense intuitively. Totally cool with abstracting the contract address, but we should make it apparent/visible.

By Approving, you are authorizing this site to move your tokens on your behalf. Explicit consent will be asked before any action is taken on your funds. This authorization is on blockchain so it costs a network fee.

The bolded part above is not accurate. The whole point of "approve" is that future spends do not require additional consent. This is the consent!

Maybe its more like: Uniswap needs your approval to access your DAI. This will allow them to [complete trades] once you've set them up.

This is challenging - dapps have many different reasons for calling approve on your tokens, and we don't want too assume and misrepresent what's actually happening. Perhaps on the tooltip we can explain some common reasons for this call. "Uniswap needs your approval to access your Dai. This may allow them to fill an order while you're offline, to withdraw tokens as you use a service, or to hold as insurance. If you don't know why this dapp is asking for approval, do not proceed."

@cjeria love the visuals!

• does "Total Amount" need an affordance for like "Total amount right now but maybe more in the future" ?
• this kind of looks like a permissions screen! worth bookmarking to revisit later as permissions get more robust.
• the "This dapp would like your permission to spend x of your DAI" to me is the most important info on the screen – more important than Uniswap, and more important than the total amount (which will just be gas). Could we update the information hierarchy to reflect that? Maybe enough to just re-visit text sizes.

Last, I'd love to have some elegant way of truncating those huge values that dapps often request approval for without sacrificing accuracy. @danjm @danfinlay any suggestions on how to handle massive approval amounts? maybe we just drop the number, or include in the tooltip? "... permission to spend your DAI" ?

[cjeria]

Thanks guys! Good points made all around. There’s enough here for me to come up with another iteration or two of this design. I also think this is a great candidate for putting in front of our users to stress test all of our assumptions and make sure we’re clearly communicating what’s going on for the wide audience we are building for. Stay tuned!

[cjeria]

We have a few technical questions we need help understanding @danfinlay @danjm

• Why does approval require a figure like this?
• What does this number mean?
• How is this number generated?
• Who generates it?

cc @omnat @ryancreatescopy

[bdresser]

This number is generated by the dapp. They specify how much of the user's token they want to be able to spend. It's common practice to ask for this absurdly large number so the dapp won't have to worry about hitting the limit and won't have to ask for approval again.

EIP 717 is trying to move people over to using "unlimited" for this exact reason, but it's not widespread yet.

I think we should explore a way to represent this massive number as "basically unlimited" while still letting the user see the exact number if they need or want to. If we don't make the number available we're sort of misrepresenting the actual transaction. But (for obvious reasons) it's not the most helpful thing to lead with.

[omnat]

Per our design sync conversations, find latest designs here by @rachelcope
In version 2, Rachel did an exploration on gas fee options. Not for immediate implementation necessarily, but will be doing usability testing of it together with the new Approve designs.

Design: https://www.figma.com/proto/Emfl6CRPRtuQtzJEOJJ3hy/Approve-Screen?node-id=181%3A1948&scaling=min-zoom

Usability test preview: https://app.usabilityhub.com/preview/9e5db0d79c75

Will send out the link next week (weekend link will be lost). Still open for feedback!

[cjeria]

@danfinlay What happens when the dapp has spent custom approval amount? Do they get another approve screen?

[danfinlay]

The dapp can request approve as many times as they want, at the moment. In the future we may include a box for users to "ignore future requests from this site".

So for now, it's the Dapp's responsibility to monitor its allowance, use it, and request an increase as needed.

[omnat]

Next steps:

• User test with async usability test @omnat
• Dev-handoff by @rachelcope @cjeria

@bdresser should we add a "design ready" lane in extension workspace for designs we want to dev hand-off? or is just linking developers to design issues enough?

[bdresser]

the "ready" column in the extension board works well for this! when we do dev handoff (or when designs are done) just communicate that outwards and i can make sure the extension issue is updated accordingly

[bdresser]

omna did some user testing, designs have been updatedd -- @rachelcope @cjeria to post

cc @danfinlay

[cjeria]

Posting latest Approve screen designs.

Questions we had while designing these screens
https://docs.google.com/document/d/1bfIWUW0D50EHmkmWMj1-np-gsxPqeiDhUW7z-o8KpNg

and insights doc per @omnat's usability testing (incomplete)
https://docs.google.com/document/d/1bdfhSrqIOF3S01mjVE8OK6uGmQFTm555CvKs70tfux4/edit#heading=h.r87dcwaa4fev

[chriskalani]

Curious why you opted for a 2-step flow here instead of 1? Seems like the message in the first window could easily fit in screen 2. We should really try to reduce clicks if possible, especially when you consider that dApps already have an unnecessary amount of friction.

[cjeria]

Thanks for the feedback @chriskalani. Below I've added some insights our researcher @omnat has gathered so far for context on these new designs.

"When people understand at a glance of what’s the request, they found it pretty scary and felt it isn’t secure to ‘Approve’ this request."

“When they saw the ‘Edit permission’ screen, it was a bit of relief - a better feeling of security. People were still skeptical that how can there be no constraints on how this site gets to spend the funds!”

I've also seen, through usability studies, that some users (newbs) don't read through this screen so a bit of extra friction here isn't such a bad thing IMO. It's an opportunity to educate users on the implications of this (potentially dangerous) function. cc @danfinlay @rachelcope Thoughts?

[chriskalani]

This is what I mean:

[cjeria]

Nice. This is similar to other one-step designs we've previously explored. I think it's a good compromise for now. If users are wondering why there's a tx fee, they can click the "learn why" link to expand a tooltip (could use a copy edit pass @rachelcope).

Check out the updated version below.

[cjeria]

Some copy edits and minor tweaks in this latest version. Ready for dev hand-off.

[omnat]

Update

• Adding contract address details to Permission Request section
• Deleting the 0.00 amount detail
  @cjeria

[cjeria]

All set! Here's a screenshot of the latest updates and direct link to the designs

[pi0neerpat]

Hey yall, not sure if this is the place for outsiders to comment, but its the most relevant thread I found 🤷

We made the decision not to do unlimited approvals. Yet if someone inspects the approval, it looks like it is still unlimited. Prompt says "Unlimited" for only a 100 DAI approval.

Unlimited approvals are still very much a hot topic, so I don't think the design here should favor them.

[Gudahtt]

Hey @pi0neerpat, are you still seeing that issue? That looks like a bug, not an intentional design choice. Please open a new issue if you can still reproduce that problem. Thanks!

[Gudahtt]

These designs were implemented in MetaMask/metamask-extension#7271, so this issue can be closed now.