Add content to Requesting page on toggling unified payment requests

[Bosch-0]

From @moneyball on Slack

I think the design guide and possibly this BIP21 micro-site should address how best to handle copy/paste of on-chain addresses and LN invoices in the UI, particularly with the presence of a unified QR code.

1. Are the 2 copy options present on the same screen as the QR code? (drawback being that 100% of users see a myriad of options and for those who will be scanning, they’re shown unnecessary complexity)
2. Or is copy options part of a menu the user needs to click/tap? And are both options shown at that point?
3. Or is one option (on-chain or LN invoice, perhaps based on a wallet’s user base/use cases) is shown on the QR code screen, and the other copy option is buried in a menu?
4. Other?

Would love to see visuals of this in the guide along with rationale/tradeoffs.

I'd suggest the below

Ideally have a settings option on the generated QR page that lets you disable the unified QR code and when you go back to the QR it has a toggle for Lightning / On-chain (the old design we had in the guide). Users who disable this are probably more advanced and won't be confused by the terminology imo

Would also be good if you could disable this in the global settings, preferably in a more advanced settings section

[moneyball]

I think that is a good design, but that speaks more to the QR code. I'm curious about the treatment of the copy/paste options. For example, if a user wants to withdraw bitcoin from their custodial wallet to their non-custodial wallet, and both wallets are on their phone, they can't scan the QR code being displayed on their phone. Instead they copy either a bitcoin address or a LN invoice and paste it in the other app. Hence the options I outline above for how/where to display those.

[GBKS]

If this is something that becomes fairly common to use, we could use a swipe interaction to switch between the 2 or 3 most common payment request formats, like in the image below.

Labels would need to be very clear and obvious.

The Share and Copy buttons would share and copy whatever is shown above. The Share button would launch the native share sheet, which provides all the common options a user expects (favorite contacts and apps, airdrop, copy, save to files, etc). Since the Share sheet already includes Copy, a dedicated option may not be needed. Tapping the QR code could also copy (or full-screen the QR code for best ease of scanning).

We also need to figure out how to integrate NFC sharing, as shown in a screen here.

We'll probably always need a settings button for some specific options, but those are ideally just fringe cases.

So as far as options go, we seem to have a few layers:

1. Defaults (what you see when you land on the screen)
2. Quick-access to common alternative formats (swipe)
3. Settings button (menu for per-transaction options)
4. Application settings (adjust defaults in 1.)

[bradwrage]

I explored this early one. Something to consider is that some people will have a hard time understanding what QR to use and when. With that in mind I'd recommend leaning into the single QR that just works with some way (not as prominent) to surface your addresses to copy if needed.

[GBKS]

Makes me thing that we should also provide guidance on the "Scan" screen. When an app reads a QR code that it can't make sense of, it should provide clear info on what is supported, so the user can then more easily resolve the situation.