Smart Contract Events are the notification of web3 technology. When certain meaningful conditions happen within the smart contract, the smart contract emits an “Event” and writes logs to the blockchain that a Dapp frontend or other smart contracts can process. For example, if a person were to transfer an ERC20 token, the token’s smart contract would then emit the “Transfer” event which contains all the data related to the transfer.

Transactions and other actions take time to perform, which is why Events can be used to help speed up the process of reading transaction statuses. By subscribing to events from a smart contract, you can then update both the transaction and frontend UI state.

For developers, events are one of the most crucial elements of Ethereum. Unlike in traditional web development where a server response is provided in a callback to the front-end, Ethereum relies on the emitted events and logs. What action should be declared as an Event needs to be thought out at the beginning as it helps ease the development of external systems that rely on the smart contract.

To design a better experience of smart contract events in your DApp, provide users with transparency when data is pushed to the user via smart contact events.

While events are mostly used by developers as a data source, the web3 principle of transparency dictates that it isn’t really transparency if it requires effort from the end user to find, see, understand and verify the data.

In order to provide a better experience for end users, clarify the source of the data (smart contract event) and also make it accessible to the end user to read and verify, even if they are just for the purposes of fulfilling the roles required for the developer.

As mentioned at the very beginning, smart contract events are the equivalent of notifications for web3 and Dapps in general. Therefore best practices for designing alert notifications in web2 are also applicable here, specifically in regard to what and when to send a notification.

Make event notifications and messages timely and relevant. Messages that interrupt users should only provide information that is important and relevant to the current user flow.

Similarly, as with the current notification UX, having too many notifications pop up simultaneously can cause frustrations and distractions. To avoid this, we should put them in a separate list that users can access when they want, either via a side panel or a notification badge menu.

Typically, whenever you are receiving data in the front-end, it means that you’ve subscribed to an event. While having transparency for all events is important for the user to fully understand what is going on, too many events equal too many notifications.

Having a way for users to control what kinds of events they would like to subscribe to or unsubscribe from will make this experience much smoother. The goal here is to put control into the user’s hands.

Allow users to set up notifications to their preferences. We can do this by providing them with ways to filter specific events or customization what kind of notifications they would like to receive or even allow for them to mute certain events notifications for a certain amount of time.

Some ideas for filters you can implement are:

• whether it contains Ethereum / tokens

• Specific addresses (user’s own address or a specific address)

• Specific time frames (between timeX and timeY)

• Specific blocks (blockX and blockY)

While smart contract events are unique to web3, the UX principles behind how to notify users on these events remain the same as those in traditional web development. The difference here is that as transactions happening on the blockchain are permanent, designers need to provide more transparency than just the typical “processing payment” notification.

UX designers can take a page out of the design pattern that provides users with a more explicit breakdown of processes, like those found in from financial, supply-chain, or e-commerce interactions.

Smart Contract Events are the notification of web3 technology. When certain meaningful conditions happen within the smart contract, the smart contract emits an “Event” and writes logs to the blockchain that a Dapp frontend or other smart contracts can process. For example, if a person were to transfer an ERC20 token, the token’s smart contract would then emit the “Transfer” event which contains all the data related to the transfer.

Transactions and other actions take time to perform, which is why Events can be used to help speed up the process of reading transaction statuses. By subscribing to events from a smart contract, you can then update both the transaction and frontend UI state.

For developers, events are one of the most crucial elements of Ethereum. Unlike in traditional web development where a server response is provided in a callback to the front-end, Ethereum relies on the emitted events and logs. What action should be declared as an Event needs to be thought out at the beginning as it helps ease the development of external systems that rely on the smart contract.

To design a better experience of smart contract events in your DApp, provide users with transparency when data is pushed to the user via smart contact events.

While events are mostly used by developers as a data source, the web3 principle of transparency dictates that it isn’t really transparency if it requires effort from the end user to find, see, understand and verify the data.

In order to provide a better experience for end users, clarify the source of the data (smart contract event) and also make it accessible to the end user to read and verify, even if they are just for the purposes of fulfilling the roles required for the developer.

As mentioned at the very beginning, smart contract events are the equivalent of notifications for web3 and Dapps in general. Therefore best practices for designing alert notifications in web2 are also applicable here, specifically in regard to what and when to send a notification.

Make event notifications and messages timely and relevant. Messages that interrupt users should only provide information that is important and relevant to the current user flow.

Similarly, as with the current notification UX, having too many notifications pop up simultaneously can cause frustrations and distractions. To avoid this, we should put them in a separate list that users can access when they want, either via a side panel or a notification badge menu.

Typically, whenever you are receiving data in the front-end, it means that you’ve subscribed to an event. While having transparency for all events is important for the user to fully understand what is going on, too many events equal too many notifications.

Having a way for users to control what kinds of events they would like to subscribe to or unsubscribe from will make this experience much smoother. The goal here is to put control into the user’s hands.

Allow users to set up notifications to their preferences. We can do this by providing them with ways to filter specific events or customization what kind of notifications they would like to receive or even allow for them to mute certain events notifications for a certain amount of time.

Some ideas for filters you can implement are:

• whether it contains Ethereum / tokens

• Specific addresses (user’s own address or a specific address)

• Specific time frames (between timeX and timeY)

• Specific blocks (blockX and blockY)

While smart contract events are unique to web3, the UX principles behind how to notify users on these events remain the same as those in traditional web development. The difference here is that as transactions happening on the blockchain are permanent, designers need to provide more transparency than just the typical “processing payment” notification.

UX designers can take a page out of the design pattern that provides users with a more explicit breakdown of processes, like those found in from financial, supply-chain, or e-commerce interactions.