Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UX for archived token balances #1438

Open
piyalbasu opened this issue Aug 22, 2024 · 8 comments
Open

UX for archived token balances #1438

piyalbasu opened this issue Aug 22, 2024 · 8 comments
Assignees

Comments

@piyalbasu
Copy link
Contributor

piyalbasu commented Aug 22, 2024

Tasks

Preview Give feedback
No tasks being tracked yet.
@piyalbasu piyalbasu assigned piyalbasu and sdfcharles and unassigned piyalbasu Sep 19, 2024
@sdfcharles
Copy link

@sdfcharles sdfcharles changed the title UX for archived token balances [DESIGN] UX for archived token balances Nov 21, 2024
@piyalbasu piyalbasu added design and removed design labels Dec 2, 2024
@JakeUrban JakeUrban changed the title [DESIGN] UX for archived token balances UX for archived token balances Dec 9, 2024
@piyalbasu piyalbasu reopened this Dec 10, 2024
@piyalbasu piyalbasu removed the design label Dec 10, 2024
@JakeUrban
Copy link
Contributor

@sdfcharles I only see designs for extending TTLs, and we have a separate task for that (#1689). What is the UX for when token balances have been archived?

@sdfcharles
Copy link

Updated designs here: https://www.figma.com/design/C3G0a4Gd6RQyplRBppGDsL/Freighter-(SDS-v3)?node-id=2932-3383&t=NNZIouOPrlmRWQS4-1

Included states for when a token balance is archived and a notification on the home screen when a token balance has been archived

@JakeUrban
Copy link
Contributor

Thanks @sdfcharles, but I'm not sure if we want to even inform a user that their balance is archived, because they actually won't have to explicitly restore their balances before they can use them after protocol 23 is live.

After protocol 23, if a transaction involves an archived entry, it will automatically be restored when the transaction is executed, and all the user needs to do is make sure their fee is high enough to pay for the restoration.

What that means for us is that regardless of whether a transaction is sent to freighter from a dapp or a transaction is initiated from within freighter, we can go about our normal signing and submission flow without having to do anything different in our UX for transactions that use archived entires.

@aristidesstaffieri
Copy link
Contributor

Thanks @sdfcharles, but I'm not sure if we want to even inform a user that their balance is archived, because they actually won't have to explicitly restore their balances before they can use them after protocol 23 is live.

After protocol 23, if a transaction involves an archived entry, it will automatically be restored when the transaction is executed, and all the user needs to do is make sure their fee is high enough to pay for the restoration.

What that means for us is that regardless of whether a transaction is sent to freighter from a dapp or a transaction is initiated from within freighter, we can go about our normal signing and submission flow without having to do anything different in our UX for transactions that use archived entires.

Do you think that it makes sense to inform the user of why their fee is higher than without the accompanying restore operation, or will the fee difference be negligible?

Maybe only more sophisticated users will even notice this but I feel it could be weird to prepare a tx that you might do often and have it sometimes have a higher fee than other times.

@JakeUrban
Copy link
Contributor

Yea I would think ideally Freighter would give you detailed info on why your fee is what it is, but I don't know if we can do that for all transactions yet. I don't see any details on cost provided in RPC's simulation endpoint response definition. Maybe this something already discussed on the platform team? cc @mollykarcher

So maybe for now we can do something specifically for when transactions restore archived entries. As for what level of detail to provide, I'm not sure. I would think just some UX acknowledgment that the fee is higher due to restoring necessary entries would be sufficient, as opposed to actually providing the entires that are being restored as a result of executing the transaction.

@aristidesstaffieri
Copy link
Contributor

Yea I would think ideally Freighter would give you detailed info on why your fee is what it is, but I don't know if we can do that for all transactions yet. I don't see any details on cost provided in RPC's simulation endpoint response definition. Maybe this something already discussed on the platform team? cc @mollykarcher

So maybe for now we can do something specifically for when transactions restore archived entries. As for what level of detail to provide, I'm not sure. I would think just some UX acknowledgment that the fee is higher due to restoring necessary entries would be sufficient, as opposed to actually providing the entires that are being restored as a result of executing the transaction.

Yeah agree I think it makes sense to just at least have some sort of by-line or copy that informs you that "fee is higher than usual because you need to restore your entry before using it" but maybe in not so many words 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants