Re: [Taler] Withdrawal Flow (was: Taler Android UX)

[Christian Grothoff]

On 4/14/20 5:11 PM, Torsten Grote wrote:
> On 2020-04-10 04:00, Florian Dold wrote:
>> But my bigger problem right now is that the big picture is not written
>> down coherently anywhere.  It makes it rather difficult to discuss and
>> keep track of what the current consensus is, as well as what the
>> rationale for getting there was.
> 
> I know the problem ;)
> 
>> Can we please write this down in a new design document in docs.git?
>>
>> Torsten, would you mind starting with this?
> 
> I can try, but also don't know the full picture, yet. So how about I do
> a rough sketch here and if there's agreement, I turn that into a design
> document?
> 
> 1. user requests withdrawal from bank or cashier
>    gets shown a QR code or clickable taler withdraw URI
> 2. user scans QR code with wallet or clicks link that opens in wallet
> 3. wallet takes user to a screen summarizing the withdrawal:
>    a) withdrawal amount
>    b) withdrawal fee
>    c) selected exchange with button to change it
>    d) back button that cancels
>    e) Review ToS button or Confirm button (depending on whether the ToS
>       for the selected exchange have been accepted)
> 4. user clicks "Review ToS" button
> 5. ToS are displayed and use clicks accept
>    * back button brings user back to 3
>    * accepting ToS brings user back to 3 with Confirm button
> 6. user clicks "Confirm Withdrawal" button
> 7. user is brought to transaction list that shows pending withdrawal
>    * snackbar confirms that the withdrawal was accepted
> 
> If the ToS were already accepted, 4 and 5 are removed from the flow.
> 
> An issue with that flow is that the user sees the withdrawal summary
> screen two times (according to Belen that might not be an issue).
> Christian's preferred flow would avoid this issue by forcing the user to
> select an exchange first and then show the ToS after the selection.
> However, when the ToS change, that flow has an issue as well.
> 
> The above flow handles ToS changes gracefully by just inserting step 4
> and 5 again.
> 
> So to me it seems we need to decide first if we force exchange selection
> (at least on first withdraw in that currency) and if so, how we handle
> ToS changes in the flow.

The above could be OK if the exchange's fee structure is sane for
denominations that are audited by a trusted auditor, or if the exchange
is trusted.

If the above does not hold, we either need to add a stern warning
("click here to use untrusted exchange this time anyway"-checkbox) or do
force the exchange selection dialog between step 2 and 3 (where we also
do have such a warning before selecting an exchange that lacks
trust/auditing).

I think in the (in practice hopefully very rare) case that the exchange
does not have a sane audited denomination structure and is not
configured to be trusted, _forcing_ exchange selection first would be
best, as it nudges users towards changing to a more trustworthy
exchange, instead of clicking away the warning.

signature.asc
Description: OpenPGP digital signature