Git Product home page Git Product logo

Comments (2)

tjanez avatar tjanez commented on May 27, 2024

Here is an example for the Reclaim escrow transaction type:
Undelegate Txn confirmation

(All general suggestions for the Add escrow transaction type also apply here.)

  1. Type. This one should be in-sync with the "Reclaim" button under "Active delegations". While I like the "Reclaim" word, would it perhaps be less confusing for the users to use the term "Undelegate" as a direct antonym to delegate?

  2. From and Validator. That is confusing. I would use "From" for the validator address since the user is undelegating (reclaiming) tokens from that account. The "From" field, representing the user's account, should be renamed to "To" as this is the destination of undelegated/reclaimed tokens.

  3. Amount and Shares. There is always a possibility of a discrepancy between the approximated amount and the actual number of shares. Would it make sense to clearly indicate that this is an approximation? Would it perhaps make more sense to also merge the Amount and Shares fields into one field (and show this is actually the same thing)?

from oasis-wallet-web.

Esya avatar Esya commented on May 27, 2024

First comment

  1. Type. Should the "nice" transaction type / name (something that is translatable) be shown first and the raw transaction's method name (e.g. Add escrow) be shown in parenthesis?
    Something like:

    • Type: Delegate (Add escrow)

    The full description (e.g. "Delegate your tokens to a validator and earn rewards") could be shown via a mouse-hoover tooltip?

In terms of UX/UI I'm not a big fan of tooltips, first because on mobile they're super clunky, but also because it requires additional interaction from the user, here I wanted to match the actual transaction names that the users would see on their ledger, but I'll do :

Delegate (addEscrow) - with the description under it

  1. Validator. Can this be renamed to "To"? In principle, one could make a delegation to a non-validator node. And this makes it consistent with the Oasis Node CLI which shows:

Yeah, makes sense that way

  1. Balance. Do you think users will find this field useful? In principle, the Preview transaction is a dialog, so the Total balance of an account will be visible in the background. Moreover, I was a bit confused if the balance should be interpreted as the balance before executing this transaction or some "preview" balance that will be the effect of executing this transaction?
    I would consider removing it.

I will specify Balance before the transaction and make it appear only for transactions that modify the available balance (so addEscrow and transfer). It's both an extra redundancy to make sure that the user knows which wallet he's doing the transaction from, and also because on mobile the transaction modal is full-screen so you don't see the balance "under" it

  1. Gas. Can you rename this to "Gas limit" and change the units to so it is shown as 272? This will make it consistent with the Oasis Node CLI and what the Oasis Ledger app shows.

Will do !

Second comment

  1. Type. This one should be in-sync with the "Reclaim" button under "Active delegations". While I like the "Reclaim" word, would it perhaps be less confusing for the users to use the term "Undelegate" as a direct antonym to delegate?

Undelegate does not exist in english and "reclaiming a part or your whole delegation" makes sense from a user's perspective - plus it matches the wording used in the documentation

  1. From and Validator. That is confusing. I would use "From" for the validator address since the user is undelegating (reclaiming) tokens from that account. The "From" field, representing the user's account, should be renamed to "To" as this is the destination of undelegated/reclaimed tokens.

Using from is problematic for translators, because if in english you can "send from" and "reclaim from" that won't work in other languages. I get that it can be confusing

I'll change it to something like Active wallet instead of from (for the originator), and then if the recipient/target is not necessarily a validator, then it's more appropriate to use Delegatee or Account.

  1. Amount and Shares. There is always a possibility of a discrepancy between the approximated amount and the actual number of shares. Would it make sense to clearly indicate that this is an approximation? Would it perhaps make more sense to also merge the Amount and Shares fields into one field (and show this is actually the same thing)?

I'll see what I can do UX/UI wise but it does make sense

from oasis-wallet-web.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.