Closed minibits-cash closed 1 month ago
One of the points we could focus on in payments UX is a little broader than minibits-only flows.
There are some paradigms that were set by early wallets that unnecessarily split UX by the underlying protocols that I think should be abandonned not only in our implementation.
The most visible one is to have payments initiation split to 4 options (send+receive and transfer/topup called melt/mint in the protocol). I believe non-expert people get confused immediately no matter which wording will be used.
Proposal is to morph ecash and lightning payments into two usecases (Send + Receive) and provide very clear payment initiation UX. User should select the end result he/she wants to achieve and should not care so much about over which protocol it will be settled.
Thank you for sharing the structure. I've been reflecting on the way Minibits has been organized and considering the user's perspective. I concur with the framework. Broadly speaking, I perceive two main rails for executing payments on Cashu:
Receive: Redeem a Cashu token to obtain ecash. Top up ecash by settling a Lightning invoice.
Send: Generate and dispatch an ecash token. Either 'Cash out' or 'Send bitcoin' via a Lightning invoice.
The methods such as requesting funds from a contact, sending funds to a contact, or settling a Lightning invoice are essentially varied interpretations of actions that slot into the four categories mentioned. An enhancement for Minibits could be streamlining these multiple payment methods into fewer categories as possible.
On the Home Screen, the user currently sees four distinct options (not counting the scan button, which I view as a versatile tool and believe should remain unchanged). These are:
Your suggestion to consolidate ecash and lightning payments into two primary functionalities (Send and Receive) seems like a step in the right direction.
I began brainstorming with some lo-fi sketches on consolidating the various send/receive options under the primary send and receive action buttons. I hit a snag with "top up" as it necessitates users choosing one of three options. One possibility might be to display all functionalities on a single screen after the user specifies the top-up amount. I'm uncertain if this offers the best UX, but it's my initial approach. I'll revisit this after some rest and a fresh perspective. In the meantime, please share any thoughts, feedback, or impressions.
First iteration of the new payments initiation UX is now released as 0.1.2-beta.8. Update is installed over the air, from the update manager. On top, some bugs fixed and the first rudimentary version of recovery from the local backup released.
Looking forward for the feedback.
This issue is dedicated to the ongoing UI / UX review of Minibits Wallet.