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 📔

6. Remove column sorting

Previously, in the web interface you could click column headers to sort items:

We decided to remove the table header. Reasoning:

• Simplicity, reduce clutter.
• Flexibility: without column headers we can show any information we like.
• Consistency: mobile doesn’t have sorting.

7. Action names, 0 ETH, ‘n/a’

Previously, we displayed n/a in the amount column for settings changes, contract interactions and Safe app transactions. There was no particular reasoning behind this. It is the equivalent of 0 ETH amount:

This was changed to ‘0 ETH’ after Layout redesign user tests 💡. With the release of data decoding it was changed to action name for contract interactions (or the number of actions for multisend):

Reasoning:

• Action name is more useful than ‘0 ETH’.

8. Transaction statuses

Possible transaction statuses are success, failed, cancelled (not shown in the first version), awaiting confirmations, awaiting your confirmation, awaiting execution and pending (see Safe transaction states 📔). Awaiting statuses were changed from grey to orange. They now have a dot. These statuses require action and the dot highlights it:

9. ‘Pending’ status

There can only be one pending transaction at a time and it’s always in the ‘next’ section:

Pending is specific to the device, only the executor sees it. There’s no pending on mobile because there’s no execution on mobile. Pending transaction is shown as ‘awaiting execution’:

10. Remove identicons on mobile

Previously, mobile app displayed identicons in the tx list:

This was reused from the legacy app. We decided to remove them. Reasoning:

• More uniform layout. The new app has new transaction types. Some types have an identicon and some haven’t, which resulted in ‘jumpiness’ and clutter.
• Consistency: web interface doesn’t show them.

11. Date and time format

Previously, we displayed the exact timestamps everywhere: ‘Dec 17, 2020 - 12:46:48’. We decided to show time in the queue in ‘... ago’ format. The exact date is shown on hover (web only):

Time intervals for queued transaction are:

• < 1 min difference → just now
• < 1 hour difference → x min ago
• Less than 24 hours difference → 1 hour ago | x hours ago
• More than 24 hours difference → 1 day ago | x days ago

The date shown is creation date everywhere.
History shows hour and minute. Date is shown as a section header. The exact time is shown on hover (web only):

Reasoning:

• This was recommended after Layout redesign user tests 💡.
• The exact second when a transaction was created is not important.
• In the queue we don’t have a date as a section header so hours and minutes won’t make sense.
• In history we have dates as section headers so showing something like ‘Dec 17, 2020 - 12:46:48’ would result in duplication.

12. Quick actions (web only)

Quick actions are buttons with which you can confirm, cancel or execute a transaction. They are shown on hover:

Reasoning:

• No need to open tx details to perform an action. Especially handy when the user has many awaiting transactions.

There are no quick actions on mobile.

13. Number of confirmations

For awaiting transactions we show how many owners confirmed:

Reasoning:

• No need to open tx details to see how many confirmations are needed.

14. Token logos

Previously, there were no token logos in the web interface:

We decided to add them because we have space and it’s easier to identify which token has been sent:

There are no token logos on mobile because there is little horizontal space.

15. Transactions with the same nonce

Transactions with the same nonce are grouped.

The alternative was to show them as separate transactions but add alert icons next to nonces:

Grouped version was chosen because:

• Transactions are associated with each other visually.
• With alert icons it looks like an error, while same nonce transactions are not always a result of an error, they can be initiated to cancel a transaction.
• 'Separate' version is not easier to implement.

Transactions with the same nonce are sorted by creation date.

User tests – insights, changes after user tests

tbd

Changes after release, metrics

tbd