Re: [Taler] Taler Android UX

[Torsten Grote]

Hi Belen,

thanks a lot for your great work!

I respond to some points below.

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? Those could
indeed all be part of a larger settings screen that splits up into
sub-screens. The settings wouldn't need to be hidden behind an overflow
menu, but could be added to the action bar directly (to be easier to
discover).

If there's more top-level features, there's also other navigation
patterns such as a bottom bar.

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

> *** Transation history screen ***
> 
> Using Revolut as an example, one
> of the neo-banks in the UK: they provide multi-currency accounts. So
> each account can have one or more currencies, and each currency has a
> set of transactions.

Great that you have an overview of what other wallet apps are doing. Do
you happen to have a screenshot of that revolut balance view?

Do you think we should add list icons behind the balance so that the
history is easier to discover?

> *** What information to show in the transaction history list ***
> 
> First, they all group the transactions by date, to avoid repetition.
> Second they show the merchant and the amount as the most important
> information per transaction. Some also include a brief transaction
> category. I would tend to follow the same pattern.
> 
> You transaction type (e.g. withdrawal, payment, refund etc) would be the
> equivalent to those transaction categories. The question I would have
> is: what’s your equivalent of the merchant? Because the transaction
> summary looks like something different: it seems to provide exactly what
> you bought (e.g. “Essay 17: the right to read: a dystopian short
> story”), and not where you bought it from.

Also interesting: These apps don't show outgoing amounts in red, as
payments seem to be their main use-case. They only show incoming amounts
in green with a plus as those are probably more rare.

Since we have lots of transaction types (even more in dev mode), before
changing what is the most highlighted text at the top, we should define
that for all types.

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

> *** Pending events ****
> 
> Belen: I would need to see a pending event in order to design for this.
> My initial assumption was that it would be shown in the transaction
> history for each currency, just marked as “pending” until they complete.
> But as I say I would need to see one :)

Pending events are how things are implemented under the hood. They used
to be shown in a long list below the balances. Everything you can do in
the app (and more) can result in a pending event that sticks around for
days or longer.

> Belen: I guess I assumed we would be showing such “longer running”
> operations in the transaction history screen as well, identifying them
> as “pending” or similar and through some visual cues. If I could get a
> screenshot of how a pending transaction looks like, and perhaps the json
> data attached to it, I could work on a more detailed design.

Showing the ones that relate to transactions in the transaction history
specially marked would make sense. There's just some details that need
to get sorted out such as which events to really surface in the UI,
attaching amounts to the events, how to sort things and how to
transition pending events into history transactions.

> *** Confirm transaction and transaction details screens ***
> 
> Belen: A few sample contracts of different levels of complexity would be
> really helpful to design something that works well for most scenarios.

The information that can be included in the contract terms is documented
here:

https://docs.taler.net/core/api-merchant.html#the-contract-terms
(scroll also down to Products)

Another way to test things is to install the PoS app and buy a more
complicated order.

Here's a video showing that process:

https://peertube.co.uk/videos/watch/82844212-5dbf-4455-bad0-8a54d1689abf

> *** Fee structure ***
> 
> Belen: happy to work with Florian on that one. Is this the bug?
> https://bugs.gnunet.org/view.php?id=4117

I am just beginning to understand this myself, but it seems that the
money you withdraw/top up is tied to the exchange provider that you are
using. So it is possible that you choose an exchange that has very low
withdrawal fees to save money, but when you later buy something, the
very same exchange charges you big fees for your purchase.

Also it seems to be possible that you withdraw money from three
different exchanges and when making a bigger purchase requiring all that
money, three different exchanges charge you different fees for your
purchase.

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.

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? 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)?

> *** 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!

Kind Regards,
Torsten