Scaling using Loom Network’s DAppChains — Part I
It was not long ago that we have seen usability problems raised when many users interact with an Ethereum application — to be more precise, when a great deal of users request changes to the state of a Smart Contract. CryptoKitties was the first game to raise awareness to this problem by slowing down the entire network, back in December ’17.
When the network gets congested with pending transactions, fees tend to reach high values as well. There is an increasing need for scaling solutions to solve this problem, as the number of transactions and fees increase.
Developing applications to interact with Ethereum Smart Contracts has been a complicated challenge for both User Interface (UI) and User Experience (UX) fields. Transactions take time to get mined and processed by the network; this poses an incredible usability challenge, given that we live in the age of quick & easy.
This is the first part of how Bityond plans to use Loom’s DAppChains in order to build a scalable decentralized application without sacrificing security. This article explains the current plans for user interface and experience.
UI/UX dilemma
Usability is a qualitative attribute that assesses how easy and pleasant an interface is to use, and is defined by five different qualitative components: learnability, efficiency, memorability, errors and satisfaction.
There are currently numerous questions when designing the interface and experience for an application that will interact with a permissionless blockchain, like Ethereum. I have debated this topic in some of the projects I have been involved with, particularly with Bityond.
We have asked ourselves how the interface should look like when a user has sent a transaction that can fail or succeed. Should the application block and wait? Or do you allow the user to keep interacting with the application?
Forcing a user to wait for a long time consists of a major experience problem. On the other hand, allowing the user to keep interacting with the application, risks a possible change of the application state, once the operation is completed. Both cases may lead to an inconsistent interface or unexpected interface changes.
When discussing DApps’ UI/UX, I have gathered four “principles” to have in mind when designing the interface and experience when dealing with Ethereum transactions. Here’s the list:
- [A] Transactions take undefined time to get processed.
- [B] Transactions can either fail or succeed.
- [C] Transactions’ progress is undefined.
- [D] Users can start multiple transactions at once.
Visibility of system status is one of the 10 heuristics for web usability. This heuristic is particularly important for applications that depend on the state of the blockchain. For the visibility of transactions’ status, one would easily recommend progress indicators. Progress indicators can be a bad choice if they block the UI or show inconsistent information, which is fairly common given that transactions’ progress is unknown.
Understanding all 4 principles, I have proposed a simple UI pattern for Bityond.
Transactions have essentially three different states: pending, success and fail. For each state, UI shows the number of transactions that fall in each state.
A status bar can be incorporated in UI to show transactions’ state. This can coexist with other persistent menu actions, like messages. The Transaction State can disappear after a time threshold.
The Bityond icon once clicked, exposes history of current and past transactions, as seen below.
I believe that this is an effective way to present transactions’ state and history. The UI can suffer changes, but the logic behind it must persist.
Challenges
I’m aware that sometimes, the best interface is no interface. Nevertheless, bear in mind that the UI presented is strongly focused on the economic model.
Rewarding users
Users are rewarded when completing actions. For example:
- Signup
- Login (per day)
- Signup (w referral)
- Complete 90% of profile
- Create an organization
- Create a project
- Create a job
- …
The UI communicates this very clearly. Once an action is completed, the rewarding process takes place and the progress is shown on the status bar.
Transfering tokens
BYT is a generic ERC-20 token. It can be kept, sold or used. When the user wants to transfer his tokens from his Bityond wallet to another wallet, he has to sign and approve a transaction with an Ethereum wallet, like Metamask. The progress is also shown in the UI.
Platform governance
Participating in the platform’s governance is one very important aspect of Bityond, as I mentioned here. The progress can be consulted with the UI solution presented in this article.
Wait, there’s more…
This was the first part of “Bityond: Scaling using Loom Network’s DAppChains”.
On the next installment, I will explain why Loom Network’s DAppChains are the best solution for Bityond and how it will be implemented.
I hope you’ve enjoyed this piece,
