A quest for web3 accessibility

A story about our journey to attain web2 accessibility in the web3 world

In 2018 the world of Web3 took its head out of the protocol rabbit hole and woke up to accessibility. It’s not that we’ve been ignorant to the topic but it finally bumped up our list of priorities. It’s gone from a Lukewarm talking point, to sizzling hot.

Coinbases Connie Yang::: Why design is the killer app for crypto and ENS’s Beltran:: Web3 Design Principles are two of the best. I personally took inspiration from Beltran’s piece & TTT concept, highly recommend both.

So far we’ve seen that adoption of Web3 apps has been directly proportionate to the quality of the UX regardless of how trustless it is. Augur took the top spot from Cryptokitties this year for the most popular dApp. It’s easy to see how they are head and shoulders above the rest at this insurmountable task of making Web3 easy.

Zinc (zinc.work) is in the identity & reputation space (obvious disclosure, I work at Zinc). We face most of these general Web3 design challenges. Such as transaction transparency, exposing where data is stored, what’s permanent/what’s not and who might see this public chain ±±±±. Some are key design challenges to our identity & reputation.

The primary benefit of the technology we’re choosing to build on is TRUST. To expose this benefit to the user we have to be transparent in everything we do but abstract away complexity. This is tough, since blockchains are complex, mythical beasts to the average user. Beltran introduces this Trust through transparency concept, stating; “If it isn’t transparent it can’t be trusted!”. This resonated with me when thinking on the Web3 accessibility challenge. The challenge of exposing benefits of the underlying technology whilst ensuring Web2 level UX. Many web3 companies seem to use blockchain as their headline differentiator. To justify shouting about the technology we’ve chosen to build on we must expose it’s benefits. Nobody is choosing to build on a blockchain for speed or ease of use! Not yet anyway…

Identity & Reputation system design considerations

I’m going to highlight some generic benefits of building web3 identity & reputation systems. Then I’ll explain the design principles we considered when informing users on what they need to know to realise these benefits. Then show some real dApp snapshots… some more relevant than others. All through transparency.

Identity app benefit:: create immutable identity proofs, then share proofs without exposing any of your original data.

1. The user needs to know where their data is stored.
2. The user needs to know what data is being shared.
3. The user needs to know who has access to where their data is stored.
4. The user needs to know what is visible when they share a proof.

I like this example from Aragon because they don’t withhold any backend information. You can edit the Node you connect to and you get the feeling you’re in control of your data.

http://aragon.aragonpm.com/

Identity app benefit:: Have true ownership and control of your data in a decentralised network rather than have it sitting on centralised servers.

1. The user needs to know where their data is stored.
2. The user needs to know exactly what control they have over their data.
3. The user needs to understand the permanent nature of the proofs before they are created.

An example of transparency in transactions when signing into Bloom. Too often, we cannot tell what we’re signing or exactly what is being shared in the transaction.

“Please sign text so you can sign-in” Bloom.co

Reputation app benefit:: portable reputation, transferable across the web.

1. The user needs to understand why they don’t currently own their web2 reputations.
2. The user needs to see that they can access and remove data if they wish to know they are not tied to a new evil (new data monopoly)
3. The user needs to needs to be aware of the open nature of the system.

Zinc‘s block explorer exposes each individual users identity contracts resolving ENS names. It’s a human readable way of saying to users, the proofs you collect here are on the public Ethereum net. Zinc can’t censor you, you can connect to these contracts and port these proofs anywhere.

https://zinc.work/

Reputation app benefit:: Monetise and gameify social reputations through digital assets.

1. Users need to understand when they are exchanging value.
2. Users need to be educated on the value their social profiles have and who profits from this value currently.
3. Users need to be informed what they are signing or transferring in human readable text.

Gitcoin do great job of gamifying and adding incentives mechanisms to social systems & reputations. They use a ranking system with a leaderboard to show which users are open source stars.

https://gitcoin.co/

Reputation app benefit:: verified, uncensored information, feedback you can trust.

1. The user needs to understand the permanency of proofs.
2. The user needs to be exposed to all the verification measures to understand the validity of data.
3. The user needs to be warned about the open and permanent nature of information before they are asked to submit data.

Zinc also demonstrates transparency in transactions with the message signing (ala Bloom). In the example profile below you can see each work proof’s (reference) provenance is transparent with a blockchain logo that links though to the data transaction.

https://zinc.work/

These dApps tend to score well since they achieve trust through transparency. They expose the backend and explain it in an easy to understand way. This is a tightrope though and most dApps lose their balance and fall either side of this. When this happens, the trust benefit falls by the wayside too. It’s a thin tightrope between two mountains on a gusty day in 2018. Most dApps pre 2018 would under design and expose too much complexity for the average user, which had really killed dApp accessibility. Some fall the other side and over design. They cut corners on the trust and end up with something identical to a Web2 app.

With shared public backends we have an opportunity to win users trust through transparency. If we don’t exercise this opportunity, we might as well be using web2 tools. Wielding web2 tech, you can hardly say “here are our logins, have a poke around our redshift. Feel free to kick the tyres on our S3 buckets. Go ahead and take a DB admin role for a spin over the next few months.” Sounds outrageous, but we do have this opportunity with web3, so let’s exercise it! Let’s make it easy for users to interact with contracts and see that transaction histories cannot be censored.

Once we learn to walk this tightrope and we see others successfully pass across, knowledge sharing will become easier. We can build tools, bridges and standardise this tricky approach. If we can work together on this task it’ll be for the greater good for all of Web3.

The article is an endorsement of Zinc it does represent dApp use advice. If you have any questions ask us here, follow us on Medium, Twitter or read more at >> https://zinc.work<<

A quest for web3 accessibility was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.