Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
TLDR: The goal of this post is to get feedback on our first user-flow models on synchronous and asynchronous transactions. This will help move our wallet design forward. We’re specifically looking for feedback on:
Thanks everyone for your help and engagement. We’re excited to move the project forward.
Schedule Note: We'll get into a regular posting rhythm within the next week or so.
@gavinmcdermott and I have been working on a user interaction model for the Grin wallet. We’re focused on designing a desktop wallet for the “next 10%” of users. These people may have a light technical understanding but are not necessarily developers, and they’re people that may have completed a cryptocurrency transaction in the past.
Early Design Principles
1. Abstract away complexity. Grin transactions are actually quite complex compared to Bitcoin transactions, but most users don’t need to be exposed to the details.
Practical Assumptions (that impact UX)
1. Most transactions will happen asynchronously. (Implications: this will require an external transaction relayer service)
The user-flow diagrams (below) surface the minimum required user inputted information and actions to complete a transaction. There’s a lot of assumptions we’ve made here and many questions we have. We'd appreciate your feedback and questions.
Transaction 1: Synchronous transactions. Both sender and receivers wallets are online.
Transaction 2: Asynchronous transactions.
We believe most transactions will happen this way because sender and receiver may not be online at the same time, or users don’t have access to static IP addresses, and firewalls or secure networks getting in the way, etc. All that is to say, asynchronous transactions require a relayer between the sender and receiver.
Nice, thanks a lot for sharing this!
@lehnberg thanks for the response. On your first point, you're absolutely right. These diagrams are just to confirm the minimum information and action required on the part of a user for a transaction. The flow for these diagrams is likely not optimal.
On the second point, I think it's a great idea to visualize the transaction as it's composed.
Lastly, on the third point, I'm also in agreement with you here. It'd be ideal to have a notification for inbound transactions.