UX/UI: Enhancements for the 'Receive eCash via LN Invoice' Process #214
Replies: 7 comments 14 replies
-
|
I sounds good to me but I dont understand what amount is chosen when the invoice is created the very first time? I will take over some of your UI parts right away :) I though (while implementing the current behavior) that guiding the user step by step would make the whole thing self-explaining and abstracting steps away can lead to misunderstandings i would say. |
Beta Was this translation helpful? Give feedback.
-
Then the invoice is created the first time there is no amount. It's a empty invoice. Once it is scanned or invoice is pasted into another LN wallet the user should then enter the amount. Similar to how Wallet of Satoshi let's the user generate a receive LN invoice with no amount. The step by step approach is good for actions that aren't used very frequently, however when it comes to top offs and pay outs, the user will most likely be repeating these activities often. It could be very likely that they will become familiar with the process and don't need a step by step hand holding flow every time they want to top up. Even worse would be if they find it annoying to have to tap multiple times and go through some hoops if they just want to top off for the 100th time. |
Beta Was this translation helpful? Give feedback.
-
|
I find it confusing to select the amount after the invoice is created but this is just a Personal taste because I want to specify every info needed for the invoice before showing the invoice screen. I think the user gets used to the behavior provided by their app over time but some kind of poll might help here. Regarding the QR section, it is currently not recommended to attach any Element to its corners because it can affect the scanning and can make it unreadable for some cameras. |
Beta Was this translation helpful? Give feedback.
-
|
Given how important this is, and knowing we might be a bit biased, I think we should see what our users think. I've put together a side-by-side look at both processes. Why don't we show them to our users and ask:
https://github.com/cashubtc/eNuts/assets/78821053/300c84b9-96eb-4039-9806-781e1a8857af |
Beta Was this translation helpful? Give feedback.
-
|
yes, lets see what the users say and thank you for your amazing UX contributions! 🥇 ❤️ |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Poll results: Feedback from the Bitcoin Design Community: Saunter (@stackingsaunter): Christoph (@GBKS): Michael Hasse (@rabbitholiness): Considering this feedback, I've been reflecting on eNuts' identity as a wallet. Fedi seems to be avoiding the user of the term "ecash", simply referring to everything as bitcoin. With Fedi, it seems they're centered on collaborative custody (federations). So, while a user might be drawn to Fedi to delve into ecash or gain enhanced privacy, the real attraction might be its collaborative custody features. Given this, it's logical for them to avoid the usage of "ecash" and instead use "sats". Part of Fedi's onboarding includes establishing a username and joining a federation, which implies an account linked to a collaborative custody mint. In contrast, Cashu doesn’t recognize users in its protocol, only the issuance and burning of ecash tokens by the mint. After experimenting with Fedi’s alpha version, I didn't see any copy referring to acquiring ecash. Users simply generate a “lightning request” and receive sats. Taking the user's perspective - someone already equipped with a lightning wallet or knows someone who can settle a lightning invoice - they exchange lightning sats and get those sats in their Fedi account under a particular federation (a collaborative custody mint?). Given this workflow, Fedi’s decision to not use the "ecash" term seems justified. With Fedi, I think the benefits of transfering their sats from a lightning wallet to their Fedi account are clear: they see their sats in Fedi, and they know they're getting the advantages of the collaborative custody / federation. eNuts doesn't provide such an benefit per-se. I feel like an eNuts user isn't trying to facilitate the transfer of sats from a lightning wallet to a Cashu mint for the benefits that the mint provides. Instead, it's about converting those sats within a mint to generate ecash tokens and getting the benefits that ecash tokens provide. The mint just happens to the facilitator. Who exactly are we (eNuts) targeting? Are eNuts users individuals already well-acquainted with bitcoin and now eager to explore ecash? This is my perception, but I'd love to hear yours. With who I think our user base is, I think it's worthwhile to use the "ecash" terminology. We should embrace the idea of users exchanging sats for ecash, and then doing ecash transactions. We already give them the flexibility to settle regular LN invoices using ecash or transfer ecash tokens directly to another user. I suggest the following copy for receiving ecash:
What are your thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
Does that mean you'd also replace "sats" in the balance and amounts with "Ecash"? |
Beta Was this translation helpful? Give feedback.
-
I think it should be consistent across the application. So we pick one and use that unit as the denominator. |
Beta Was this translation helpful? Give feedback.
-
|
By that logic, shouldn't the lighting send/receive then also not use sats but instead "lightnings" or something like that? Looking at other approaches, I think it works well to think if it as bitcoin temporarily bridged to another system. Like "Bitcoin on the Lightning Network", or L-BTC being "Bitcoin on Liquid". It's still meant to represent the same thing (bitcoin), but in a different (yet closely linked) context/system with different properties (and risks). So maybe "Bitcoin on Cashu"? The action of moving the bitcoin to the other system would be more of a transfer, conversion, peg in/out, or bridging. |
Beta Was this translation helpful? Give feedback.
-
|
Could you perhaps use "ecash sats" / "ecash bitcoin" in some places, and in others where it's too long just "sats" / "BTC"? In the same way like USD can be digital or in cash. Bitcoin can be onchain or "in ecash"? That keeps the logic of ecash as a metaphor to physical cash, utilizes that sexy term, but also keeps familiar term (sats/btc) to most users. |
Beta Was this translation helpful? Give feedback.
-
|
It's a bit like asking "do you want to pay with cash or card?" Same money, different "carriers". And within cards, there are debit cards and credit cards (and within that VISA, Mastercard, etc). The terminology can be simple and consistent inside of the wallet (unless your wallet handles multiple layers). The external touch points are when the additional clarification is needed. |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate @GBKS perspective that ecash serves as a temporary bridge for Bitcoin on Cashu. This is why I favor the term "Top up"—it suggests that Bitcoin is being bridged into ecash. Regarding transaction history, I view the display of both lightning and ecash as ways to indicate the payment method for each transaction. In eNuts, users can send and receive funds using the Cashu protocol [ecash] or through the lightning network. @KKA11010 what are your thoughts these copy options? |
Beta Was this translation helpful? Give feedback.
-
|
I also like the term 'Top up' and I'm planning to include it in version 0.0.5. (Version 0.0.4 is already submitted to App Store Connect and is currently under review). What do you think about using 'Cash out' instead of 'Send Bitcoin'? This is because, while users can indeed send or receive funds via Lightning, it's specifically in connection to a mint that acts as a payment processor. Users can use Lightnign to pay invoices, but only if those invoices are 'related' to their Ecash balance. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not entirely clear on why payments via Lightning are tied to their eCash balance. I was under the impression that when a user cashes out or sends Bitcoin, they're essentially sending their sats to the mint, and then the mint settles the Lightning invoice. Nevertheless, I trust your expertise on the engineering aspect. I think the term "Send Bitcoin" is more appropriate because it encompasses various use cases, such as sending to a friend via Lightning, paying a Lightning invoice, or simply cashing out to one's own Lightning wallet. However, if the functionality of sending Bitcoin via Lightning through the Cashu mint isn't as reliable, or if there's a higher potential for issues, and we want to downplay this feature by using the term "cash out"—which suggests a simpler functionality—then I can support the decision to use the term cash out. |
Beta Was this translation helpful? Give feedback.
-
|
You know, I wonder if you need these modals in the first place. Clipboard detection can really simplify this. Except for picking someone from contacts or lightning addresses, all other payment request formats are impossible to manually enter.
For receiving, you might then be able to skip the modal and default to show a lightning invoice receive screen (with another small option to paste what's on the clipboard). For sending, people probably just want to pick the destination and then have the UI show the appropriate options. Might that work? |
Beta Was this translation helpful? Give feedback.
-
|
Clipboard detection for ecash tokens is already implemented for Android. It only works tho for tokens that are in mints which the user already trust. Otherwise it is a privacy issue to ping the mint (has to check if token in clipboard is spendable) Regarding invoice, it is a good idea and I think you can open a feature request in the gihub issues 🧡 Otherwise I will have to think more about your suggestions once I have some spare time. Thank you👍 |
Beta Was this translation helpful? Give feedback.
-
|
Echoing @KKA11010, the app already features clipboard detection for Cashu tokens. I like the suggestion of extending this functionality to include lightning addresses though! However, I still think we need the modals, or the ability for manual entry for the following reasons: User Autonomy in Input: Some users might disable the "Allow Paste From" setting across their phone or inadvertently decline the clipboard detection pop-up. In such instances, we must provide a fallback, enabling them to manually redeem Cashu tokens and input lightning addresses. User Experience Concern: Personally, I find unsolicited pop-ups or modals, (like the NIP07 authorization issue discussed on Discord) to be intrusive. I appreciate having control over triggering app actions and prefer that the app responds to my initiatives instead of autonomously proceeding. This is personal preference so I don't weight this to heavily though. |
Beta Was this translation helpful? Give feedback.
-
|
I received some partially related feedback from a user at the ecash hackathon. They shared that, even after spending time with eNuts and becoming acquainted with the 'Send' and 'Receive' options, they still hesitate, needing a moment to decide which button to press to execute their desired action. They believe this confusion stems from a combination of our copywriting and the icons used in the bottom slider. Perhaps we can enhance the clarity of these options? |
Beta Was this translation helpful? Give feedback.
-
|
You proposed some changes for the send/receive options text and icons in the bottom sheet which I will consider for the upcoming release. How do you want to further clarify these? |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure how to improve this more than the copy changes I've already suggested. I would like to back and jam on a few design options and then conduct some quick user testing / feedback. Could we hold off on making updates to these bottom modals for send and receive until then? |
Beta Was this translation helpful? Give feedback.
-
I've been exploring ways to enhance the user experience for the "receive cash via lightning invoice" process. Inspired by various Bitcoin wallets, I found CashApp's Bitcoin receipt interface to be the most user-friendly and relatable for a non-technical audience. Many design elements in my proposal are influenced by their UX, piggy backing off their proven success.
Upon pressing the "receive" button, users will notice simplified, jargon-free options. Instead of "Create Lightning Invoice," users will see "Top up". The "Paste & redeem Ecash" option is now "Get ECash", eliminating redundancy since 'Paste & redeem' is already mentioned in the description.
Selecting "Top up" presents the user with an LN invoice. The design here aims to expedite access by minimizing the number of taps required. We've removed the mint selector (if the user has multiple mints) and invoice amount entry, saving two taps.
By default, the system uses the user's preferred mint (set in settings), but users can switch between mints by clicking the mint name. On selection, a list of all user mints appears, with the chosen mint highlighted by a checkmark and the default mint indicated by a bank icon.
For custom amounts, users can click the "add amount" button. This leads to a simple input screen where amounts can be denominated in sats or fiat. Ideally, the text size would adapt to the number of characters input (fluid text?). After specifying the amount, an updated QR code appears, with the invoice amount displayed in green below. Users also have the option to modify the invoice.
I really believe this process of "getting ecash" is pivotal from a UX pov. We have to ease the friction at this stage, otherwise people will drop off. I believe it's worth investing in some user testing to really nail this. A straightforward A/B poll on Twitter for feedback combined with a hands-on usability test comparing our current system with this revamped one, we could yield some valuable insights.
WDYT? As always the door is open to pick apart the design, tweak it, improvement, remix it, etc...:)
Beta Was this translation helpful? Give feedback.
All reactions