Unified tx list: design decisions

Links
Uniform transaction list view #353 🐱
Uniform transaction list view (Transaction List v2) #820 🐱
Problem and proposal + kickoff meeting 🐱
Hypothetical press release 📆
2020-11-11 Refinement 📆
2020-12-01 Refinement 📆
Voting on Slack 📣

Platform: web, mobile

App version: iOS 2.8.0, Android 2.8.0, web: tbd.

Which problem do we solve?
See 4 Same view on all platforms (e.g. Transactions) 📆.

How does the feature fit into the product and larger product decisions?
See Uniform transaction list view #353 🐱

What are the metrics and KPIs we will be measuring for this feature?
tbd

Is there user research or quantitative data informing decisions made here?
#24 Safe Apps & Layout Redesign user tests insights 💡
#26 Safe Multisig Transactions user tests insights 💡
#29 Quick Transaction List tests insights 💡
#30 Rejections & Advanced Parameters user tests insights 💡

Screens

1. Queue

2. History

3. Only one next transaction

4. Nothing in queue

Main design decisions

1. Structure with two lists

Previously, there was a single list on web and mobile. Web had column sorting and pagination. Mobile had 2 sections – ‘Queue’ for awaiting transactions and ‘History’ for past transactions:

After several iterations and a quick round of user tests we chose a structure with 2 separate tabs: ‘Queue’ and ‘History’. ‘Queue’ tab has 2 sections – ‘Next transaction’ for a transaction that needs to be executed first (with the lowest nonce) and ‘Queue’ for other awaiting transactions. Reasoning:

• Faster implementation. Nonces in the queue are sorted ascending, in history they are sorted descending. Two different sortings in one list could cause problems with pagination and therefore are harder to implement.
• UX argument: it’s easier to find awaiting transactions than when there’s one list. It’s easy to see a transaction that needs to be executed first.
• Results of quick user tests: 4 out of 5 users preferred the version with 2 lists.

The alternatives were:

1. Switch between queue and history in the sidebar:

2. Fixed ‘Next transaction’ on top, tabs below:

3. Single list, next transaction on top, ‘Show more’ button to expand all queued transactions, history below:

2. Which tab to open first

Queue tab always opens first on session start. Switching Safes does not alter the selection of the tabs (on mobile only). Switch between bottom tabs resets the tab to the “queued” (Android only). Reasoning:

• This is predictable behaviour. There are no examples of apps which open different tabs depending on the content. Queue is more important. People probably check it more often than history.
• On mobile, ‘Settings’ and ‘Assets’ tabs work the same: on session start the first tab opens.
• This option won voting on Slack 📣.
• However, one person during Rejections user tests saw an empty state and didn’t notice there were two tabs (see insights 💡). People who participated in quick user tests didn’t see an empty state so their choice was probably not informed.

The alternatives were:

1. Always open history, no matter if the queue is empty or not.
2. Open history when the queue is empty, open queue if it's not empty.
3. Open the queue when it's not empty, but hide tabs (and thereby open history) when the queue is empty.
4. Remember your last viewed tab from the last session.

3. Remove pagination in the web interface

In the web interface you had to click through pages to see past transactions:

We decided to change it to infinite scroll. When the next page is loading, we show loading indicator. Reasoning:

• Simplicity: no need for additional clicks.
• Negative feedback from users (‘it looks like a database turned into UI’).
• Previous version didn’t show more than 200 transactions (so the total number was incorrect). Now we show all transactions.

4. Next transaction

When there are multiple awaiting transactions they have to be executed in a specific order. The one with the lowest nonce needs to be executed first (unless the nonce is missing, in this case the next lowest nonce is not the current Safe nonce, there is no Next transaction section). Calling it ‘next transaction’ and fixing it on top of other awaiting transactions is a way to highlight it.

‘Next transaction’ section performed well during Transactions user tests 💡. On mobile there were queue and history from the start but there was no next transaction because there’s no execution on mobile.

5. Sorting nonces

Previously, web and mobile had incompatible ways to identify a transaction which led to difficulties finding a specific transaction. Web interface had IDs (which is a different thing from nonces):

Mobile had nonces (for outgoing transactions only). At some point we had nonces in the queue only but then we brought them back to history:

The decision is to sort nonces in the queue in ascending order and in history in descending order:

Reasoning:

• See How should transactions be sorted 📔

User tests – insights, changes after user tests

#27 Signing On Mobile Insights 💡
Recommendations:
...

Changes after release, metrics

tbd