Re: [Taler] Taler Android UX

[Christian Grothoff]

Dear all,

On 4/6/20 5:04 PM, Torsten Grote wrote:
> On 2020-04-05 06:45, belen barros pena wrote:
>> We can do this if 'Settings' can have many sub-screens in the future,
>> but maybe a Hamburger-menu would be more discoverable. We will need at
>> least "settings" for:
>> - Auditor list (current list of auditors, removal option)
>> - Exchange list (current list of exchanges, removal option)
>> - Synchronization list (devices synchronized, removal,
>>   maybe rebalance)
>> - Key escrow (Anastasis) provider selection / configuration
>> - [developer mode, wallet-reset, ...] (optional, already there)
>>
>> Belen: it can be done in any of the 2 ways, but since the hamburger menu
>> is likely to stay, you can just leave the “settings” there. Once you
>> have a list of all the settings that must be included, we can work
>> together on the design of those screens.
> 
> It might indeed make sense to list all features that are planned, to
> decide the navigation pattern. Is the above list complete? 

Maybe for v1 ;-). It doesn't include things like setting budgets,
visualizing expenses, etc. and other things to help users manage their
money that Belen and others may come up with. That said, I think it
includes all features we know we must have for version 1.

>> *** Position of the TOS screen on first transation with exchange ***
>>
>> Belen: I saw the new video showing the implementation for this, and it
>> looks like changing the order results in having to show the withdrawal
>> details screen twice. It may not be a bad thing: it’s just an observation.
> 
> Alternatively, the transaction could be approved when accepting the ToS,
> but this feels a bit indirect.

I don't think we'll have the withdrawal screen _actually_ twice if the
first one becomes the exchange-selection screen, as it should.

> It is probably possible to get more information about the merchant. At
> the moment, I only have a merchantBaseUrl in the JSON data.

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.

>> *** Fee structure ***
> If I understood this correctly, this seems to be one of Taler's biggest
> UX challenges as money tied to exchanges is counter-intuitive and not
> exactly human-centered design.

Absolutely, because we can't design the fees for humans as they are
expected to closely match technical costs (to thwart resource exhaustion
attacks, and allow the business to charge lower fees by matching actual
costs, as opposed
to dramatically over-charging in some areas to cover worst-case costs in
other areas without fees).

> I wonder if there are no fixes on the Taler side for this that do not
> require big conceptual changes. For example, could the exchange fee
> structure be made less flexible to hide the fact that money is tied to
> exchanges?

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'.

> Like all exchanges need to charge the same or no payment
> fees, but can differentiate with withdrawal fees (as this is where
> exchanges seem to be visible to the user)?

I think identical fees goes to far, as different providers may have very
different cost structures. That would also violate the 'enable
competition' objective of Taler.
Similarly, doing away with a fee in one area categorically is a problem
because then you must over-charge in other areas just in case
"malicious" users behave abnormally and skew the ratio between the
different operations.  I also do believe the protocol should be able to
provide proper economic incentives, which means fees should be *able* to
align with costs.

That said, the current fee structure is even MORE flexible than this,
and that MAY be too much. Still, this is a hard problem and I think we
may want to for now just show the full fee structure (like the
WebExtensions wallet can do), and address the question of how to do it
better to the point where a few more of us actually understand it ;-).

>> *** Design work going foward ***
>>
>> I think as I learn more about
>> the project and the design requirements, we could switch to work on
>> design before doing implementation work. We spend some time up front
>> discussing the design and drawing little pictures ;) but we implement
>> something we are all satisfied with on the first go, rather than
>> developing and then making changes based on my reviews. Saves a ton of
>> time and effort :)
> 
> Would be great if we could switch to that model!

Well, if Belen can provide designs fast enough, that's great. Anyway,
for Anastasis I've already urged the students working on it to create
Belen-style pictures to bootstrap that discussion.

For Sync and the other "Settings" features (see above), I suspect we
(Florian, Torsten, me) need to first deliver some better idea as to what
we want to do here before Belen can assist with
design-before-implementation.

Torsten, do you have some existing notes based on the e-mail(s) I sent
you about those features that might help Belen here?

Happy hacking!

Christian

signature.asc
Description: OpenPGP digital signature