The secret sauce of when to run transactions in the background are tight. The most important ingredient is that the user shouldn’t have to be present when the result of the transaction triggers. This often shows up when the transaction triggers a result primarily targeted at another user, in our case a reviewer. Other key ingredients are low stakes for errors, the ability to save a draft of work, and the ability to provide notifications when the users transaction is complete. The biggest risk with this method is when a transaction fails you could have betrayed the user’s trust. This is why notifications, drafts and low stakes are important. In those cases where the transaction does fail, the user needs to be notified and not lose any of the work they’ve already done, and have the ability to try the transaction again without impediment.

Tiered feedback

The alternative to background processing is to reduce the number of transactions and provide the maximum available feedback. In Solidified, our commitment to security and trust requires that all parties in an interaction have some stake. Some amount of tokens must be transferred for a submission, contract, bug or dispute. This means that the user must make the transactions before proceeding and therefore the platform needs to support the user through these slower steps.

When the user absolutely must stop, let them know that you’re working for them!

The most important heuristics to follow in these cases is are ‘Recognition over recall’ and ‘Visibility of system status.’ The user shouldn’t have to guess how large a transaction is necessary to complete their task, give them this information at the time of the action. Likewise, the user shouldn’t have to guess if their transaction is going well. The blockchain will not return a notification so the platform requires an aggressive schedule for pinging the ledger to make sure the user knows as soon as they’ve successfully achieved their goal. Also provide any intermediate feedback the system gets, for example: when a transaction is sent, an anticipation of timing (based on testing) and a clear sign of success when the transaction posts.

Celebrate success and be informative

While it is sometimes required, we first try to mitigate the need for user-to-platform transactions by having the slower process of the blockchain transfer be done outside our primary flows. We give each user a platform account from which the day-to-day transaction are pulled. This way, the user can make fewer, but larger, transactions and not interrupt her when she has a moment of excitement finding that critical bug! We also integrate with standard tools of the space, like Metamask. These tools allow us to pre-build transactions on the platform UI so we can give the user that critical feedback on what is necessary to proceed. Then, we feed just the critical transaction information to the tool.

Secondary use for background processing

Solidified features another situation that creates slow UI: 3rd party and internal tools. In order to maximize the users experience in our platform, we need to crunch a lot of code. Especially for complex contracts there is a long period running the code through tools. We want to hide these slow processes, but in this case we’re approaching it a different way.