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

[belen barros pena]

I've put together a diagram showing how I think the withdrawal process looks like based on the discussions you've had this week. Thought it may help us think things through.

There are only 3 screens: "pick exchange", "ToS" and "Confirm withdrawal". The diagram shows how the navigation between screens happens based on certain conditions (e.g. the existence or not of a default exchange for the withdrawal, the ToS of the default exchange changing, the user wanting to select a different exchange and so on). Let me know if this matches what you have in mind.

If we are all happy with it, I could start designing the screens.

PS: I wouldn't worry too much about the very first withdrawal scenario for now. Let's agree on the main flow first, and then we can discuss how we need to design the "out of the box" screens to support users the first time they do a withdrawal.

Cheers,

Belen

On Wed, 15 Apr 2020 at 13:25, Christian Grothoff <address@hidden> wrote:

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.

withdrawal_flow.pdf
Description: Adobe PDF document