Receive screen layout tweaks proposal

[GBKS]

I love the addition of BOLT12 in the latest version of the app. The receive screen is getting a little cluttered, IMHO, so I'd like to propose some adjustments to the layout and interaction model, for your consideration.

First, the critique:

Then the proposal, which puts all formats in a swipeable carousel and removes the BOLT12 overlay:

And some details on the proposed changes:

The information design of the receive screen is difficult because it has to present all these payment requests with very different properties. Creating a consistent layout lets users focus on the content rather than having to analyze each screen and figure out what's what. The quick summary of properties reduces the need to understand technical terms and makes a practical, contextual decision easier.

Hope it's helpful. Please reach out with any questions and feedback.

The use of "Lightning address" in the mock-ups will probably come up... I know, not ideal... naming is hard 😀

[dpad85]

Thank you for this work, there are a lot of great points.

Our initial version had the Bolt12 QR code in the carousel alongside the others, but we changed that because it made the screen complex and users were less likely to notice and understand this new option.

Grouping the 2 Lightning options together (Bolt11 & Bolt12) makes the flow simpler. First you need to decide whether to receive on-chain or via Lightning. Both options have very different tradeoffs and use cases. Once you've made that decision, if you pick Lightning, you will probably always use Bolt11 for now (except to give your contact to a friend). In the future, once Bolt12 is well supported in the ecosystem, Bolt12 will become the default (receiving with Bolt11 will be deprecated).

So I think we'll keep the Bolt12 screen separate from the rest (maybe not as an overlay though, note that on iOS it's different, Bolt12 simply replaces the Bolt11 screen). But the other suggestions look good.

The use of "Lightning address" in the mock-ups will probably come up... I know, not ideal... naming is hard 😀

The naming for Bolt12 is hard, I have not found a good solution between "Offer", "bolt12", "static invoice", "reusable payment request"... "Lightning address" sounds good but it just adds to the confusion between the LNURL-based standard, UMA, BIP-353, and probably others.

In any case I think all these technicalities should be hidden from the user. We should not try to find a good name. It should just be called "Lightning" and this "Lightning code" should be reusable, agnostic and universally understood, whatever lies underneath. The user should not have to think about it.

[GBKS]

Thank you for the thorough response.

I totally understand the complexity that the lack of a clear standard presents. The more elegant we can manage this transition phase towards one, the better. At the moment, when there are so many differences out there, we have to pick a good default but also allow for flexibility in case the default does not work for the counterparty.

Our initial version had the Bolt12 QR code in the carousel alongside the others, but we changed that because it made the screen complex and users were less likely to notice and understand this new option.

Not sure if the solution you ended up with is less complex. I understand the desire to make sure users notice this new feature. Once the novelty has worn off and the "New" tag is not appropriate anymore, are you planning to move things around?

Regarding naming, I totally agree. From a very practical perspective, it might be helpful to think of the scenario where you try to pay someone and need to communicate how. If both people understand "lightning address" and can arrange a payment, no matter how accurate it is on the technical side, then that term does the job it's meant to do (just like no one thinks about what IBAN stands for). Not even thinking about how that works across languages...

May I ask why Android and iOS are different? Is that just a matter of rolling thing out first on one platform and then follow up with the other? Or do you try to make OS specific adjustments to match their human interface guidelines?

[swedishfrenchpress]

I understand the desire to emphasize the new feature by grouping it under the Lightning umbrella and not hiding it behind a scroll carousel. Could we find a middle ground by introducing a tab navigation for Lightning? This would allow you to also have that "new feature" badge pointing to the toggle option, and when the feature gets old it could just be removed without impacting the UI and muscle memory fo the user. Tabs would allow the user to switch between Bolt 11 and Bolt 12 on the same screen without having to adjust the fields or placement of other buttons. Then the user can simply swipe right for on-chain.

[GBKS]

Sorry, I totally missed your last comment. I've done a few more explorations that I'd like to share that are in the same vein.

Here's a 9-minute video explainer of the design thoughts.

And updated designs. There are a lot of ideas in there, but I'd say two of the primary goals are hiding technical terminology as much as possible, and to clarify the information design so it's very obvious what each element is and does. The video lays this out in more detail.

In these designs, there is a primary button to pull up a list of address options to choose from. These options are presented by the unique benefit of each address type, rather than their technical or feature name. This is much more explicit, but also a little more text and UI compared to bitcoin/lightning tabs (where users need more technical understanding to be able to fill in the gaps). This could be worth user-testing with non- or new-bitcoiners to see how it resonates with them.

Curious to hear what you think.