Hi all,
I am cc'ing the mailing list so that the design discussions become open to all.
I've gone through your emails from this past week, and have tried to organise the issues discussed and reply as appropriate. Hopefully things make sense :)
*** Hamburger menu ***
Christian: 0:20 structure: you're missing some possibilities beyond pay and
withdraw, like receiving a tip, a refund and (not yet implemented)
synchronizing with another wallet, and adding exchange/auditor. And
those are just the settings. Visualization of expenses or setting
budgets or having a 'buddy' (see your literature review on helping
people with financial responsibility) would add even more pages. So this
may remove the hamburger, but only for this minimalistic wallet (which,
due -- to the lack of synchronziation/backup -- wouldn't even be legal
according to our contact at the ECB).
Belen: Yes, I see how, as the functionality grows, the application will need to grow with it :) Right now I have no visibility of the full feature set or the development plan, so I was mostly designing for what I could see in the video. The menu can definitely stay if you envision it will be needed.
withdraw, like receiving a tip, a refund and (not yet implemented)
synchronizing with another wallet, and adding exchange/auditor. And
those are just the settings. Visualization of expenses or setting
budgets or having a 'buddy' (see your literature review on helping
people with financial responsibility) would add even more pages. So this
may remove the hamburger, but only for this minimalistic wallet (which,
due -- to the lack of synchronziation/backup -- wouldn't even be legal
according to our contact at the ECB).
Belen: Yes, I see how, as the functionality grows, the application will need to grow with it :) Right now I have no visibility of the full feature set or the development plan, so I was mostly designing for what I could see in the video. The menu can definitely stay if you envision it will be needed.
Christian: 4:40 Hamburger is gone, only 'Settings': I'm not 100% sure about that.
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)
Now, we could have all of these accessible from some 'master settings'
screen, or via a hamburger-menu. I am not sure what is better.
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.
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)
Now, we could have all of these accessible from some 'master settings'
screen, or via a hamburger-menu. I am not sure what is better.
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.
*** Select exchange ***
Christian: 0:60: the 'terms & conditions' is not actually _always_ shown, but only on first encounter with this exchange + TOS. What is also missing (in
your version?) is the ability to _select_ an exchange. This is currently being implemented and will slightly change that arch of the process.
Belen: I would need to understand a bit more about this "select exchange" step. But we can wait until a first implementation is in place and then we can have a chat about it.
your version?) is the ability to _select_ an exchange. This is currently being implemented and will slightly change that arch of the process.
Belen: I would need to understand a bit more about this "select exchange" step. But we can wait until a first implementation is in place and then we can have a chat about it.
*** Position of the TOS screen on first transation with exchange ***
Christian: Here, Florian argued (successfully) that we should swap the TOS and Review-withdrawal (fees) screen, as users may care about the business
side (fees) more than about the TOS when picking an exchange. Anyway,
just a detail that might see more discussions later.
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.
side (fees) more than about the TOS when picking an exchange. Anyway,
just a detail that might see more discussions later.
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.
*** Transation history screen ***
Christian: 1:35: You propose to combine balance and transaction history, with the argument that the balance screen right now is pretty 'empty'. The reason
is that you are not using multiple currencies, and all your later
figures also fail to specify the currency. But please note that Taler is
a multi-currency system, and I do actually expect that many users will
have multiple currencies in their wallets. Swiss CHF, EUR, USD, Pounds,
whatever. So the balance screen will need to show the balances for the
various currencies, which already requires a list that scrolls.
Torsten: As you can see, you can now click the balance to get to the history. If
we already can't show the history below the balance, maybe this is a
reasonable compromise. If we stick with that, it would be nice to split
the history per currency and maybe remove it from the left-hand menu.
Belen: Yes, Torsten's suggestion sounds good to me. This opens up the question of the information structure. 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. I think Torsten is suggesting we take a similar approach, and we group transactions based on their currency. This is the way I would do things as well. This means we would have several “transaction history” screens, one per currency being used. You would access those screens by selecting the currency balance from the “balances” screen, exactly as shown in
is that you are not using multiple currencies, and all your later
figures also fail to specify the currency. But please note that Taler is
a multi-currency system, and I do actually expect that many users will
have multiple currencies in their wallets. Swiss CHF, EUR, USD, Pounds,
whatever. So the balance screen will need to show the balances for the
various currencies, which already requires a list that scrolls.
Torsten: As you can see, you can now click the balance to get to the history. If
we already can't show the history below the balance, maybe this is a
reasonable compromise. If we stick with that, it would be nice to split
the history per currency and maybe remove it from the left-hand menu.
Belen: Yes, Torsten's suggestion sounds good to me. This opens up the question of the information structure. 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. I think Torsten is suggesting we take a similar approach, and we group transactions based on their currency. This is the way I would do things as well. This means we would have several “transaction history” screens, one per currency being used. You would access those screens by selecting the currency balance from the “balances” screen, exactly as shown in
This design would mean the “history” screen should not show in the hamburger menu, which would list only 2 items: “balances” and “settings”. Also, the “history” screen should probably show the corresponding currency balance, since this is a critical piece of information. It could be shown in the top bar (see attached crappy sketch kudos_transactions.jpeg).
Christian: Additionally, I would expect we'll soon want a 'search' function to
search the transaction list. Such a 'search' operation could be easily
added in the menu bar (be it where the hamburger or your circle) sits of
a *separate* transaction history screen, but doesn't fit nicely with
your design IMO.
Belen: the way the search functionality works on android is, as you say, through a search icon in the top bar. When you tap on the icon, the whole top bar is transformed into a search input field with a “back” arrow on the left to exit the search mode. See
search the transaction list. Such a 'search' operation could be easily
added in the menu bar (be it where the hamburger or your circle) sits of
a *separate* transaction history screen, but doesn't fit nicely with
your design IMO.
Belen: the way the search functionality works on android is, as you say, through a search icon in the top bar. When you tap on the icon, the whole top bar is transformed into a search input field with a “back” arrow on the left to exit the search mode. See
That means it can fit in almost any screen displaying content.
*** Transaction confirmation with snackbars ***
Christian: 5:10 I'd actually plan on scrolling to the balance of the currency that
was just used, in case not all the currencies fit on the screen ;-).
Christian: 10:50 As with the payment, I'd again show at least also the amount with the snack bar, and probably place the snack bar either below the
affected balance or on the very top (unless we do decide to integrate
the transaction history, of course, but I think I explained why I don't
think that would work).
Belen: Assuming that we have a “balances” screen showing balances for each currency, and a “transaction history” screen per currency that shows the balance amount on the top bar, the right place to land people after completing a transaction and show the notification would be the “transaction history” screen for the corresponding currency, and not the “balances” screen.
was just used, in case not all the currencies fit on the screen ;-).
Christian: 10:50 As with the payment, I'd again show at least also the amount with the snack bar, and probably place the snack bar either below the
affected balance or on the very top (unless we do decide to integrate
the transaction history, of course, but I think I explained why I don't
think that would work).
Belen: Assuming that we have a “balances” screen showing balances for each currency, and a “transaction history” screen per currency that shows the balance amount on the top bar, the right place to land people after completing a transaction and show the notification would be the “transaction history” screen for the corresponding currency, and not the “balances” screen.
Christian: 7:59: If we put such a snackbar and get rid of the confirmation screen, I think given that we likely shouldn't try to put the full transaction
history, I'd consider putting a bit more information, like maybe the
product summary or at least the amount paid in addition to "Payment
done". But, how much information is certainly debatable.
Belen: the idea of the design was that basic transaction information would be in front of you, since you would be landing in the list of transactions, with the one you just did at the very top. That’s why the notification itself didn’t require much detail: it’s role was simply confirming to the user that the transaction had completed successfully. If we are going to do something different (for instance, landing people in the balances screen), then yes, we will probably need more details in the notification. But as I mention above, I think the right place to land people after a transaction is the corresponding "transaction history" screen, not the "balances" screen.
history, I'd consider putting a bit more information, like maybe the
product summary or at least the amount paid in addition to "Payment
done". But, how much information is certainly debatable.
Belen: the idea of the design was that basic transaction information would be in front of you, since you would be landing in the list of transactions, with the one you just did at the very top. That’s why the notification itself didn’t require much detail: it’s role was simply confirming to the user that the transaction had completed successfully. If we are going to do something different (for instance, landing people in the balances screen), then yes, we will probably need more details in the notification. But as I mention above, I think the right place to land people after a transaction is the corresponding "transaction history" screen, not the "balances" screen.
*** What information to show in the transaction history list ***
Christian: 2:15 You say we should have a separate screen for the transaction
details. This was actually always planned (but may not have been
implemented in your version yet). Now, I would still show more than just
purchase/withdraw/etc. plus an amount in the transaction history, just
to allow the user to more quickly find the right transaction (hence we
plan to show the transaction _summary_ there), but the full details will
indeed have to be on a separate 'transaction details' screen.
details. This was actually always planned (but may not have been
implemented in your version yet). Now, I would still show more than just
purchase/withdraw/etc. plus an amount in the transaction history, just
to allow the user to more quickly find the right transaction (hence we
plan to show the transaction _summary_ there), but the full details will
indeed have to be on a separate 'transaction details' screen.
Christian: 5:17 We were actually planning on folding the 'CHANGE' transaction into the respective 'payment' (to reduce # transactions). I also don't like only showing 'payment', as users may end up with a list of 100 payments
-- and how would they quickly find the one where they bought something
specific? Search is one possibility, but quickly scrolling should also
be possible, so I think just saying 'PAYMENT' here is just not good enough.
Belen: It may be useful to look at what others are doing when presenting transaction lists. For instance, here are some screenshots from transaction lists in Monzo
https://cdn.dribbble.com/users/20171/screenshots/2993791/monzo-for-android.png
Kard
https://techcrunch.com/wp-content/uploads/2019/05/Kard-screenshots.jpg
And N26
https://cdn.dribbble.com/users/58362/screenshots/2887875/ui-animation-ps.gif
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.
Torsten: Ideally, the obtained change transactions will be added to their
respective transactions in wallet-core, so they disappear from the
transaction/history list.
Belen: this seems like a good idea. Happy to work with you on the best way of displaying the “change” as part of a transaction.
respective transactions in wallet-core, so they disappear from the
transaction/history list.
Belen: this seems like a good idea. Happy to work with you on the best way of displaying the “change” as part of a transaction.
*** Pending events ****
Christian: Additionally, we have the snackbar (last event notification), the QR
code action button, and "pending events" providing notifications about
errors and events that are ongoing (like refreshes, etc.). You may
never have seen a 'pending event' if your network connectivity is good,
as they can go away quickly ;-). So IMO, with multi-currency, pending
events/errors + last event + QR-button, the "Balance" screen is not
nearly as empty as you may think. Hence, I do not think showing the
transaction history there makes sense -- I would only show a
notification about the _last_ action.
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 :)
code action button, and "pending events" providing notifications about
errors and events that are ongoing (like refreshes, etc.). You may
never have seen a 'pending event' if your network connectivity is good,
as they can go away quickly ;-). So IMO, with multi-currency, pending
events/errors + last event + QR-button, the "Balance" screen is not
nearly as empty as you may think. Hence, I do not think showing the
transaction history there makes sense -- I would only show a
notification about the _last_ action.
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 :)
Torsten: Apart from the multi-currency issue that Christian already mentioned, we are currently also planning to show longer running operations that
affect the balance below the balance itself. Think of withdrawals
waiting for actual wire-transfers for example. So in case you don't have an even better idea for where to show these kinds of operations, the balance list will be even fuller. However, it might still technically be possible to show a simplified transaction history below the balances. If you scroll down, it would scroll down the entire page content including the balances.
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.
affect the balance below the balance itself. Think of withdrawals
waiting for actual wire-transfers for example. So in case you don't have an even better idea for where to show these kinds of operations, the balance list will be even fuller. However, it might still technically be possible to show a simplified transaction history below the balances. If you scroll down, it would scroll down the entire page content including the balances.
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.
*** Withdraw vs. top up ***
Christian: 2:30 You suggest changing 'withdraw' to 'topup'. However, we DO want the user to have the analogy to an ATM withdrawal here! You're not doing the opposite, you take money out of your bank account and INTO your
(e)wallet. Taler is electronic cash, and really also in terms of the
legal logic, this should be equivalent to withdrawing (e)cash. Note that
there are _other_ ways to 'top up' your wallet (see tipping above) that
are not withdrawing from your bank account.
Belen: hehe, this is where we will never agree :) You can’t make people think the way you want them to think. People think in whichever way they want. And most of the time, they think that way for very good reasons, even if those reasons are not immediately obvious to us. The whole idea of human-centred design is premised on the assumption that forcing logic onto people through technical systems is bound to fail. Technical systems should instead take inspiration from the way people think and go about their business, so as to insert themselves seamlessly into their lives. Having said that, this is your call and I am happy to go with your gut feeling. Let's make sure to test the app with some users at some point (I’ll be happy to help with that). That will tell us if the “withdrawal” label is understandable to them and matches the way they think about the transaction.
(e)wallet. Taler is electronic cash, and really also in terms of the
legal logic, this should be equivalent to withdrawing (e)cash. Note that
there are _other_ ways to 'top up' your wallet (see tipping above) that
are not withdrawing from your bank account.
Belen: hehe, this is where we will never agree :) You can’t make people think the way you want them to think. People think in whichever way they want. And most of the time, they think that way for very good reasons, even if those reasons are not immediately obvious to us. The whole idea of human-centred design is premised on the assumption that forcing logic onto people through technical systems is bound to fail. Technical systems should instead take inspiration from the way people think and go about their business, so as to insert themselves seamlessly into their lives. Having said that, this is your call and I am happy to go with your gut feeling. Let's make sure to test the app with some users at some point (I’ll be happy to help with that). That will tell us if the “withdrawal” label is understandable to them and matches the way they think about the transaction.
*** Confirm transaction and transaction details screens ***
Christian: 7:11 Pay button with amount makes a lot of sense to me, as is removing the cancel button if you think that's more discoverable. For the rest
(showing total / fee), I actually think our current way of showing it is
more compact, and you are missing that the contract may have MANY more
details (think full shopping cart, plus possibly images of the products,
shipping address, taxes, etc.), so a compact way to show things can be
important. But your high-level points of removing 'cancel' and adding
the total amount into the 'pay' button should be implemented IMO. For
the rest, well, let's try to get some more, eh, comprehensive contracts
for you to play with ;-).
Belen: A few sample contracts of different levels of complexity would be really helpful to design something that works well for most scenarios. The idea would be to use the same design for both the transaction confirmation stage and the transaction details screen. The only difference would be that one will have a "confirm" button and the other will not. Reusing designs this way means less work for us, and delivers consistency for users, so we all win :)
(showing total / fee), I actually think our current way of showing it is
more compact, and you are missing that the contract may have MANY more
details (think full shopping cart, plus possibly images of the products,
shipping address, taxes, etc.), so a compact way to show things can be
important. But your high-level points of removing 'cancel' and adding
the total amount into the 'pay' button should be implemented IMO. For
the rest, well, let's try to get some more, eh, comprehensive contracts
for you to play with ;-).
Belen: A few sample contracts of different levels of complexity would be really helpful to design something that works well for most scenarios. The idea would be to use the same design for both the transaction confirmation stage and the transaction details screen. The only difference would be that one will have a "confirm" button and the other will not. Reusing designs this way means less work for us, and delivers consistency for users, so we all win :)
*** TOS screen ***
Christian: 8:48 TOS: I very much like how you show the TOS here with the
progressive-disclosure section-structure. This _will_, however, require
the wallet to do quite a bit of extra work to _parse_ the RST/markup/TXT
it currently receives to turn the TOS-Text it into this, but I do think
it is a great idea. But at least I would estimate that this will be
more work to implement than most of the other changes combined ;-).
Belen: that’s fair enough. I guess I was hoping that all TOSs would have a similar structure, or at least a set of compulsory, common sections that would be marked up somehow by the exchanges and could be used by the application to break down the content. I guess that’s not the case.
progressive-disclosure section-structure. This _will_, however, require
the wallet to do quite a bit of extra work to _parse_ the RST/markup/TXT
it currently receives to turn the TOS-Text it into this, but I do think
it is a great idea. But at least I would estimate that this will be
more work to implement than most of the other changes combined ;-).
Belen: that’s fair enough. I guess I was hoping that all TOSs would have a similar structure, or at least a set of compulsory, common sections that would be marked up somehow by the exchanges and could be used by the application to break down the content. I guess that’s not the case.
*** Payment button label ***
Torsten: as for including payment amount in button, I though there's
like a legal requirement to have it read "Confirm Payment". So can we
say "Pay 23.42 EUR" (or maybe shorten it with currency symbols if
available)?
Belen: Yikes! I never thought the regulation would be determining which labels we must use in buttons. That’s pretty specific. Are we sure this is the case? Also, is the regulatory text available anywhere? I am sure it’s really boring, but I should probably read it :)
like a legal requirement to have it read "Confirm Payment". So can we
say "Pay 23.42 EUR" (or maybe shorten it with currency symbols if
available)?
Belen: Yikes! I never thought the regulation would be determining which labels we must use in buttons. That’s pretty specific. Are we sure this is the case? Also, is the regulatory text available anywhere? I am sure it’s really boring, but I should probably read it :)
*** Fee structure ***
Christian: 10:20 Adding amount into the 'withdraw' button makes sense. You're missing a bit about the actually non-trivial fee structure that needs to
be shown (which is actually not shown nicely and a separate bigger
discussion Florian recently opened a bug for).
Belen: happy to work with Florian on that one. Is this the bug? https://bugs.gnunet.org/view.php?id=4117
be shown (which is actually not shown nicely and a separate bigger
discussion Florian recently opened a bug for).
Belen: happy to work with Florian on that one. Is this the bug? https://bugs.gnunet.org/view.php?id=4117
*** Design work going foward ***
Christian: We should then also implement the exchange selection, exchange list (settings), auditor list (settings) and maybe the even the
synchronization configuration dialog. Belen, would you be willing to do a second review after that?
Belen: certainly. You will just need to be a bit patient with me, since I can only put time into this at weekends. 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 :)
synchronization configuration dialog. Belen, would you be willing to do a second review after that?
Belen: certainly. You will just need to be a bit patient with me, since I can only put time into this at weekends. 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 :)
Torsten: Can we also contact you
with smaller specific UX questions or requesting reviews of implemented
proposals?
Belen: certainly. In fact, I think it would be much easier to work that way. Feel free to point me to bugs as well: I can upload the design materials to the bug, so that we have an audit trail of our design decisions.
with smaller specific UX questions or requesting reviews of implemented
proposals?
Belen: certainly. In fact, I think it would be much easier to work that way. Feel free to point me to bugs as well: I can upload the design materials to the bug, so that we have an audit trail of our design decisions.
Cheers,
Belen
