@vilkris @sol you guys have obviously spent a LOT of time thinking about this and we appreciate all your hard work.
4 Likes
Well it’s hard to anticipate what possibilities we’ll have in the future and how they could affect the UX. But I do think many of those possibilities are still quite far away, so the Guided experience could serve users for a long time to come as it’s currently designed.
Of course nothing’s stopping us from first building the Primitive experience and then later on building the Guided experience. This just means some extra work overall.
We were counting on that haha. But yes some proper tutorials will have to be made to accompany the Primitive experience so I appreciate your willingness to help. Maybe we could even embed a link to a tutorial directly from Syrius.
1 Like
How does the UI deal with multiple htlcs created under the same hashlock?
Alice initiates a native swap and gives the ID to Bob, but Bob participates in a native swap two times. Maybe it takes to long for Alice to accept, Bob closes his window and thinks he needs to do it again effectivly creating two htlcs. Probably won’t happen often, just wondering how the UI deals with the situation.
Good point, Vilkris and I have discussed this as a possible scenario.
We can’t save Bob from making a mistake in the first place – fat-fingering his entry and submitting the wrong amount to Alice – but we can prevent him from submitting a second HTLC for the same swap.
The UI will not allow users to deposit two amounts for the same incoming swap.
Going one step further, we may also have to prevent Alice from re-using the same hashlock with the same recipient twice in a row.
Same logic for both cases: when creating an HTLC, check if timelockedAddress has already submitted the hashlock to hashlockedAddress.
1 Like
To add to Sol’s message, in a situation where Bob is using a CLI for example and there’s nothing stopping him from making multiple counter HTLCs with the same hashlock, Syrius would only use the first one for the swap and disregard any subsequent HTLCs with the same hashlock.
2 Likes
That’s a good thing, but you cannot prevent the situation from happening when someone uses the cli or the sdk directly. How will the UI handle multiple htlcs.
In our community call regarding the atomic swap layouts, we decided to move forward with the Guided experience.
A simple Figma prototype demonstrating the “happy case” swap flows is available here: Figma
Community members can try it out to get a feel of how the swap flows would work.
The design file for the protoype is here: Figma
2 Likes
I’m pretty happy with the swap flows/steps in general now, so I wanted to make another variation of the UI by replacing the full screen modal with a smaller more “uniswap-like” modal for the swap with further simplifications for the user.
The prototype for this version is here: Figma
The design file is here: Figma
5 Likes
Love the new look. You" will send and you will receive" is easy to understand, and ppl are already familiar with uniswap UI.
5 Likes
Very nice, I like the “uniswap-like” modal. Having the information neatly packed together makes it easier to understand.
5 Likes
I like the uniswap prototype. I think users will be accustom to this type of UI.
5 Likes
3 Likes
+1 for the Uniswap style
3 Likes
The uniswap flow is awesome, its simple, easy to use and looks great. Nice work
3 Likes
I like the revised uniswap style concept
3 Likes
Uniswap is the way imo. Hallelujah to the UX here
2 Likes
All the feedback here and on twitter has been the Uniswap type experience. Love this design and hope we can move forward with it given the positive feedback.
Looks like there’s a consensus that the uniswap style is the way to go. A big thank you to everyone who has provided feedback.
@sol and I will start the implementation work next and our first goal is to get the ZTS to ZTS swap flow working so that people can test it out.
Some updates have been made to the Figma design. The “P2P Swaps” list has been populated with swaps, showcasing different states the swaps may be in.
The swap modal was also updated - the hashlock and counterparty information was removed from the top of the modal and moved to be in the “Show details” section. This further simplifies the modal’s design.
8 Likes
Wonderful design!
2 Likes