Tense in Activity

Tokenscript Design
1

This has been discussed so many times in our UX sessions that I think I should take it to the TS design stream of work and "anchor" this topic here, so we come back to it whenever we are curious about it.

Current design

Typically, an activity based on an Ethereum event is rendered after the transaction resulting that event is written into the blockchain. In the future, it's possible to allow an action to be written with anticipated events so that activity can be rendered even for transactions not yet written to the blockchain, albeit with uncertainty, since there is no way to know for sure if the anticipated event will occur as the result of the transaction. Furthermore, there is no way to enforce the TokenScrupt author to write such anticipation.

with tense or nominalised

A TokenScript author can write an activity like this, with tense:

  1. ETH deposited to AAVE contract
  2. WETH sent to my.best.buddy.ens

Or he can write an activity like this, nominalised:

  1. Deposite of 3 EET to AAVE contract
  2. Send 3 WETH to my.best.buddy.ens

It's entirely up to them (the TokenScript author). AlphaWallet or TokenScript has no way to verify or enforce one over another, so it's also possible, for example, AAVE chooses to use the 1st style and WITH chose to use the 2nd style, like this:

  1. 3 ETH deposited to AAVE contract
  2. Send 3 WETH to my.best.buddy.ens

However, currently, TokenScript doesn't provide the facility of changing tense depending on the status of the transaction. So let's suppose the said two activities are in transactions not yet written to the blockchain, and the TokenScript author has the courtesy to write that anticipation, you will see this:

  1. [PENDING] 3 ETH deposited to AAVE contract
  2. [PENDING] Send 3 WETH to my.best.buddy.ens

Or this

  1. [REJECTED] 3 ETH deposited to AAVE contract
  2. [REJECTED] Send 3 WETH to my.best.buddy.ens

The first item in each set looks weird (is it pending or is it deposited? is it rejected or deposited?) The second item looks okay.

There is no way TokenScript can enforce one way or another, but we can recommend authors which style to use, with tense or nominalised. @tomek IMHO is the best person to provide such a recommendation. Once he sets the tone, all example tokenscripts will be following it.

Alternative design

Alternatively, TokenScript can be designed to allow activities to have multiple sets of views (each with its view and item-view), one for each status. The possible states are:

  • pending
  • done
  • failed
  • rejected (yes, that is different than failed)
  • gone-stale

Unfortunately, we already have many views. Each activity has two views (item-view and view, a 3rd guide is on the way), and each view has a few language versions, resulting in a 2×n matrix of views. If we add status on top of this, we will end up with a 3-dimensional matrix. Such a design would strike me as an example of 'over-design', which would result in it rarely being used and a burden to maintain for those who decided to uses it.

Suppose we do go this route (which I think would be an overdesign), we will have something like this:

Deposite to AAVE Actions a user can take
Pending Depositing 3ETH to AAVE Wait
Failed Failed to deposit 3ETH to AAVE Depends
Rejected Rejected 3ETH deposit to AAVE Redo
gone-stale Tried to deposit 3 ETH to AAVE Redo
2

My suggestion: By default, any incoming or out-coming transaction can be written in a Past Simple tense.

So:

  • Received ETH instead of "Receive ETH"
  • Sent ETH instead of "Send ETH"

The way they sound in item-view and view should be the same.