Notifications in the web interface are often cryptic, not clearly relatable and non-retrievable

[johannesmoormann]

Part 1: Define the problem

What problem are you trying to solve?

Notification messages in the web interface from prompts to error messages are:

1. Cryptic e.g. error codes that are not understandable and actionable such as GS013
2. Not clearly relatable in the sense of do not have a clear relationship to a certain action/transaction
3. Non-retrievable in the sense of only displayed at the moment they occur for a few seconds without any option to view them again locally

The three addressed problems might be split up into individual problem statements.

What is your hypothesis?

If we solve the problems mentioned above, users will have actionable and informative messages leading to fewer support requests, less gas wasted and less time wasted.

What value does this bring to our customer and/or our mission? What is the goal?

Apart from the improved metrics mentioned above, having locally retrievable notifications can offer up new feature options.

How do we measure it?

No. of support requests in regards to error messages
Gas wasted

Links:

• Notion document outlining the problem statement. Note: the following is a duplicate of the information found there.
• Contract error codes
• List of manually dispatched notifications
• Notification centre wireframe

Part 2: Shaping the problem

Problem Owner

@iamacook

Non Goal(s)

• Replace currently emitted notifications.

Solution

Solution 1

An overview of all currently existing notifications can be found here. Not all are seemingly dispatched in the codebase. Each type of transaction has a notification ‘flow’ from requesting a signatures through to successful execution.

General

Our current notification package is forked, customised and the implementation is hard to follow. We will need to update the package and adjust the current implementation, although we already have a reference implementation in web-core](https://github.com/5afe/web-core/blob/main/services/useNotifier.ts).

Pros:

• Solves tech debt of using older, forked Notistack package: v0.95 → v2.0.5.
• Example already exists and should be relatively easy to implement.
• We will gain a better understanding of the current notifcation abstraction.

Cons:

• We may have to change some notification styling.

Refactor PR is already in review.

Cryptic

5afe/safe-react#3879 is already covering the problematic ‘GS013’ error which leverages the already existent decodeMessage function. However, there could be other errors that aren’t ‘decoded’ correctly.

We could move the decoding of error messages inside enqueued notifications. If an error code is detected within the notification element, it translates it to a human readable format.

(Johannes) Identify key error messages that should be decoded and focus on them

Pros:

• Errors need not be individually decoded.
• All notifications containing error codes are automatically decoded.

Cons:

• Text containing ‘GS###’ is deemed an error code.
• GS013 is not clear as it relates to internal transactions.

Not clearly relatable

As multiple notifications are dispatched per ‘event’, i.e. several notifications are enqueued per transactions: requesting a signature through to success, referential information need be displayed with it.

We could add links or clarifying details such as a transaction’s deeplink or safeTxHash (requested already: safe-global/safe-wallet-monorepo#704) to notifications.

Pros:

• Notifications will be clearly relatable.

Cons:

• Not all notification has a point of reference.
• Most existing notifications will need to be updated to include these.
• The current notification logic will need to be extended.

Non-retrievable notifications

Notifications are currently displayed and upon expiring/closing them they disappear and are no longer accessible by the user.

We could add notification cache, as in web-core](https://github.com/5afe/web-core/blob/main/store/notificationsSlice.ts#L6-L12) and integrate a ‘notification centre’: an icon in the header that opens a popper with said cached notifcations.

Pros:

• Notifications will be retrievable.

Cons:

• Unless we store notifications in a database, we will need to restrict the number of notifications we persist, per-browser.

Overview

Rough Scoping & Timeline

Once the current notifications have been analysed and linked to the 'relatable' information, this should take no longer than a few days to implement. The result will be:

• A refactored notification system, using already available improvements from web-core.
• Notifications that are much easier to implement and allow for granular data, i.e. links to be included.

The notifications that already exist can then be tested as they would normally be. A list of these are already accessible in our codebase.

Risk(s), Key Trade Offs & Decisions

// For example, were there any alternatives considered? What are the value, usability, feasability and business risks and how could we address them?

Concept Mocks

Open Questions

• What notifications are currently missing?
• What current notifications need more clarification? How can they be improved
• How should handle notifications that currently just render thrown errors?

[tschubotz]

• Cryptic e.g. error codes that are not understandable and actionable such as GS013

Is there already a list of the notifications or cryptic messages that need to be improved or will that part of the shaping phase?

[TanyaEfremova]

@tschubotz As far as I know, here is the list of error codes