Re: [Taler] Taler Android UX

[Christian Grothoff]

On 4/7/20 7:09 PM, Torsten Grote wrote:
> On 2020-04-06 11:34, Christian Grothoff wrote:
>> I don't think we'll have the withdrawal screen _actually_ twice if the
>> first one becomes the exchange-selection screen, as it should.
> 
> So far I thought that selecting an exchange should be optional as we can
> make a reasonable choice for users on first use and pre-select the last
> used one later.
> 
> Or do you really want to make users go through exchange selection (and
> complicated fee structure review) for each withdrawal?

We could consider doing it only the first time, and then having (on the
'confirm withdraw') screen have an button to "select another exchange".
That way, once the user has accepted the ToS, it's a
"one-click-withdraw". So:

First time:
- bank trigger (QR code, link on Bank-site)
=> Exchange selection => Tos => confirm withdraw
- back to
  + bank site (WebEx wallet) /
  + transaction history for affected balance (App)

Second time:
- bank trigger
=> confirm withdraw
 ---> Optional: Exch. sel. => Tos => confirm withdraw
- back to
  + bank site (WebEx wallet) /
  + transaction history for affected balance (App)

WDYT?

>> https://docs.taler.net/taler-merchant-api-tutorial.html#the-taler-order-format
>>
>> specifies (AFAIK optional) 'merchant' with name, address and
>> jurisdiction.  You can likely use the 'name', make it a
>> link/selectable/touchable, and if selected show a dialog with the full
>> name, address and jurisdiction data.
> 
> It looks like the Merchant is required to be in the contract terms, so
> we *could* show it as the most prominent information in the transaction
> summary:
> 
> https://docs.taler.net/core/api-merchant.html#the-contract-terms
> 
> However, at least at the moment, the contract terms are not attached to
> the history events the wallet gets from the core.

-> Florian? ;-). Maybe at least grab the
   merchant's name from the contract?

>> I read Florian's bug in part as asking this question. He basically asks
>> if we should have some 'ground rules' for the fee structure, as opposed
>> to making the fees completely 'anything goes'.
> 
> If ground rules and a big warning if they are broken by an exchange is
> all you can do, then yes please.

Well, 'big warning' may be an understatement (we could make it a
protocol violation and refuse to deal with the exchange). But the real
question is what those 'ground rules' should *be* (to improve UX while
maintaining sufficient flexibility).

>> That said, the current fee structure is even MORE flexible than this,
>> and that MAY be too much.
> 
> If there's a way to make the fee structure less flexible, so that humans
> don't need to worry too much about it, that'd be great.

I suspect we _could_ try to condense it down to basically 'one number'
reflecting like the scalar of the logarithmic price, *if* we strictly
require (approximately) logarithmic pricing as the 'rule'. But, I worry
people may understand logarithms about as well as exponential growth
;-). And even this doesn't answer the question of what _cost ratio_ we
should require (or apply? or show?) for the different kinds of
operations. Anyway, I'm far from having a clear idea here.

>> I think we
>> may want to for now just show the full fee structure (like the
>> WebExtensions wallet can do)
> 
> Interesting. I tried to find out where the wallet gets the Coin Fees
> from, but could only find the Wire Fees.

The /keys response of the exchange includes four fees for each denomination.

> Btw. it looks like the WebExtensions wallet and the exchange let you
> withdraw KUDOS without needing to accept the ToS. IMHO both should
> enforce that.

Of course. The problem is that we are (still) lacking man-power for the
WebExtensions wallet. Job applications welcome ;-).

>> Torsten, do you have some existing notes based on the e-mail(s) I sent
>> you about those features [sync/backup] that might help Belen here?
> 
> I'll start dedicated threads here about sync and backup, so we can keep
> those discussions separate.

:-)

-Christian

signature.asc
Description: OpenPGP digital signature