taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] Taler Android UX


From: Christian Grothoff
Subject: Re: [Taler] Taler Android UX
Date: Mon, 13 Apr 2020 17:34:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 4/10/20 9:00 AM, Florian Dold wrote:
> Christian: I'm not sure what you're arguing for here: Either (a) the
> user should always have the *possibility* to change the exchange in the
> withdrawal flow or (b) the user should always be *forced* to see the
> list of exchanges (where the default is selected) and click "next".
> 
> I agree with (a) but not with (b).

(a) is what I intended as well. Anyway, this is still not quite clear
for me.

Given the **first-time** withdrawal flow, I think it is logical to start
with (i) the 'pick exchange', (ii) 'accept ToS', (iii) 'confirm withdraw
with withdraw fee', and finally (iv) history balance/pending.

For **subsequent** withdrawals (once there is a default exchange with
accepted ToS), the sequence would be
(iii) 'confirm withdraw' with a special action/button to 'change
exchange provider' which then goes to (i), if applicable (ii), then
again (iii) and finally after confirm again to (iv).


Now, for the messy case: Suppose the ToS of the default has changed.

Possibility (1): we begin with (ii) ToS changed, please accept, then go
to (iii) and (iv).  But here it becomes tricky: suppose in (ii) the user
doesn't like the new ToS and want to change the exchange? 'back' seems
to not be right to move to the exchange selection dialog (i), and first
'accepting' the ToS to then switch exchange is also illogical.  So we'd
need an extra button in (ii).

Disadvantage: The ToS-dialog would now need a button to "change exchange
provider" (that is otherwise not present), and go to (i) -- which in the
other cases was NOT needed at all.

Possibility (2): We move (ii) in this case *after* (iii) -- after all,
the ToS change detection requires an HTTP request and it might be good
to hide the latency of that request and immediately jump to (iii). Then
after (iii) we'd play (ii) upon 'confirm', and the 'back' button goes
back to '(iii)' which has the 'change exchange provider' button to go to
(i) --- without having to 'accept' the ToS.

Disadvantage: This may confuse users as the order is different than
usual, and the real final confirmation this time is only upon accepting
the ToS.


Possibility (3): If the ToS changed, we start with dialog (i) [exchange
selection] even if we have a default exchange for the currency.

Disadvantage: Extra dialog even if not necessary, and much harder to
hide the latency from the HTTP ToS request as we need that answer first
before even showing anything.


Other choices? Which one should we do?

Happy hacking!

Christian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]