New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open Waters: Four UX/UI Simplification Ideas for Ocean Protocol #4

Open
lrtrct opened this Issue Jan 22, 2019 · 0 comments

Comments

Projects
None yet
2 participants
@lrtrct
Copy link

lrtrct commented Jan 22, 2019

Open Waters : Four UX/UI Simplification Ideas for Ocean Protocol

Abstract

Perceived lack of clarity or usage complexity can be a big adoption barrier. Ocean Protocol is a multi-faceted and complex innovation, which, if not designed and explained simply, could leave potential adopters aside. I would like to propose four simple, but effective, improvements ideas to the current protocol design to lower onboarding friction/lower the perceived complexity adoption barrier.

One could assign these proposals to the UX/UI of the project because they address usage simplicity, but they are enabled by core protocol design choices.

Motivation

Ocean Protocol is a brilliant project to promote data sharing across borders, organizations and teams. It is made up of the combination of several technologies to orchestrate a complex market for data and AI models in a decentralized way. The design of the system is very elegant, but like many disruptive innovations, it is difficult to grasp for most people. Looking at the overall context of the project, this is not surprising; even experts disagree on what is a blockchain and become quiet when discussing game theory. What’s more, the protocol is made of many ‘moving parts’ or ‘optional parts’ (e.g. Fitchain integration) which are super exciting add-ons for the most involved, but may be confusing to the less intellectually invested.

This leaves a lot of possible adopters who could benefit from this new open data/AI market out, wondering ‘what is this protocol, what’s in it for me and is it simple enough to use’.

The motivation of this Enhancement proposal is to simplify the specifications of Ocean Protocol on key design aspects in order to make them more intuitive to potential adopters.

Specification

Proposal 1 – Impose a standard pricing for data sets in ‘Ocean’ Token

It would be difficult to compare different data sets based on curation markets if all these data sets are sold at different prices in different currencies.

Prices will be taken into account by curators, who will then make their bets on dataset considering i) the quality/usability of the data set and ii) its price. The impact of price makes it relatively more complex for data consumers to navigate across different data sets.

In addition, a very high-quality data set may get little voting because of its high price; but for very specialized data (e.g. genomics) with very few users willing to pay large sums of money for data sets, then it makes sense that this data set is so highly priced. However, most curators would not be able to accurately assess the value of that super specialized data set (e.g. using price as salient/intuitive element in cognitive heuristics). The ‘wisdom of crowd’ may or may not deliver perfect equilibrium for assets that are very niche/narrow (e.g. estimating the weight of a pig is accessible to anyone, estimating the weight of the universe is not).

Finally, in the current protocol design, price may be dynamic, auction-based and/or discriminatory, which would make things even more difficult to compare across data sets.

Proposal 2 – Adopt a clearer unit nomenclature for curation markets

The nomenclature adopted by Ocean Protocol in the white paper considers ‘Ocean tokens’ as main utility token powering the network and ‘Drops’ as service tokens related to single data sets or services.

The problem with this is that the two are semantically related; ‘Drops’ are components of water, and water is a component of oceans. In parallel, it is not clear if ‘Ocean’ token will be the smallest divisible unit or if it will have cents, thousandths or another smallest non-divisible unit. If it’s the case, it would make sense to use water related semantics like ‘Drops’ to those components of the ‘Ocean’ for the sake of conceptual simplicity.

This would beg the use of a different naming for ‘Drops’ which does not imply that it’s a divisible part of an ‘Ocean’ token, but that it’s something else relating to a particular dataset/AI service.

Proposal 3 – Unify ‘Drops’ starting price for curation markets

For the sake of comparability, ‘Drops’ should have a pricing expressed in direct relation to ‘Ocean’ tokens. I couldn’t find documentation on the scale considered aspect in the white paper and FAQs besides the charts that of the white paper that start at 0.1.

In my opinion, ‘Drops’ should all use the same starting point in the spirit of enabling easier comparability across data sets for curators and users. By using the same scale across data sets, we may remove unnecessary adjustments to get fair comparison of price across data sets.

Also, by removing the impact of the scale factor by using a common origin (and later by imposing limits on the bonding curve shape), we can explain Ocean Protocol more simply to everyone without having to provide a list of academic references to understand all different concepts of curation markets; i.e. the more people vote on this data set, the more useful it is. Period.

Proposal 4 – Restrict bonding curves shape

Restricting flexibility to modify bonding curves can enable a more efficient curation market. First, because it reduces the risk of pure speculative behaviours (and therefore reliance on a token curated registry) by standardizing/limiting the steepness of ‘Drops’ price curves. Secondly, and most importantly, it makes curation even across datasets, enabling fair comparison for someone looking to compare different data sets.

Let’s explain the issue with an example. Let’s consider the same data set is offered twice. The first data set uses a bonding curve that starts at 1 ‘Ocean’ token with a slope of 0.1 extra ‘Ocean’ per extra drop. The second data set uses a bonding curve starting at 10 with a slope of 10.

Curators want to choose the best data set to bet on, and data consumers look to check the amount staked on these data sets as reliable proxy of the relative value of the data sets. Due to the different starting point (and slope), curators are more likely to gamble on the second dataset because it offers greater reward potential regardless of data quality. And therefore, data consumers cannot rely on the amount staked to drive their choice. The outcome would be the same is the first data set was better than the second one, only because of the impact of starting price and the bonding curve.

In general, speculators will stake more on data sets with steeper bonding curves because they provide a much higher marginal return (return potential per extra ‘Ocean’ token staked). This would significantly hinder end-users ability to use stake investment as a proxy for data quality.

End-users should not have to operate complex and different math/formulas every time they want to compare data sets.

Implementation

Proposal 1 – Impose a standard pricing for data sets in ‘Ocean’ Token

For priced data set, the price should be set in ‘Ocean’ tokens. This way, users can use this information in addition to curation market stakes to assess if a data set is worth purchasing or not (e.g. by adding the price of the data set and the number of votes in ‘Ocean’ token).

Conversion between other currencies (e.g. fiat) and Ocean token by intermediaries/gateways is totally fine. This way Ocean Protocol focuses on what it does best, creating an effective market for data and AI and leaves exchange rate between ‘Ocean’ and other currencies totally outside of the protocol. Again, in the spirit of making it easier for the user.

Another way to reduce comparison complexity due to pricing is to restrict the rules for data sets pricing, with the aim of enabling a unique and comparable price across data sets (e.g. only non-discriminatory price, per transaction) and to forbid other pricing options. Constraints in this context would help make the entire protocol easier to grasp and to use.

Finally having a pricing in ‘Ocean’ token would increase demand for ‘Ocean’ over time, effectively building the attractiveness of the network over time, and/or it could be used as a source of fee to pay for basic network infrastructure. But these latter considerations can be explored elsewhere.

Proposal 2 – Adopt a clearer unit nomenclature for curation markets

First, let’s reserve the ‘Drop’ unit to a fraction of the ‘Ocean’ token (if applicable) as this makes conceptual sense.

Tokens for service could use the nomenclature of recipients because they use some ‘drops’, ‘water’, ‘share of the ocean’ for the sake of the service. As an example, one could use ‘spoons’, ‘glasses’, ‘buckets’ or ‘jars’ to provide better semantics for what staking tokens are in relation to ‘Ocean’ tokens.

There could be much better and creative naming ideas out there, my intent is only to stir discussion.

Proposal 3 – Unify ‘Drops’ starting price across data sets

The exact pricing/scale of ‘Drop’s is somewhat arbitrary. But for the sake of ease of use I believe it would be advisable to use ‘Drops’ expressed in ‘Ocean’ tokens plain units, or in cents of ‘Ocean’ tokens (100 per ‘Ocean’ token) because pretty much all world currencies use the cent as lowest denominator.

If this is not precise/sensitive enough, we may use the lowest unit on the ‘Ocean’ scale and call that the ‘Ocean token’, not a multiple of it.

This can make a big difference; looking at Bitcoin, 'full bitcoins' and 'satoshis' are too far apart (and not by a multiply of 1000, like any other unit in SI) to be used together as units of measurement, making Bitcoin a sub-optimal unit of measure (need an example? Look at Electrum wallet base unit). Whatever can be made easy for end-users should be made easy for them.

Proposal 4 – Restrict bonding curves shape

Bonding curves should have the same shape across data sets, and possibly be absolutely identical across data sets. For the sake of simplicity, the slope can be linear so that it gives marginal decreasing returns (in %) based on the amount staked. It is intuitive and provides an incentive for ‘staking early’ once a data set was published.

The slope should be small positive, so as to limit speculation to a healthy level (steep slopes would introduce brutal shifts in prices appealing to pure speculators and not to data users).

In addition, I believe bonding curves should start from 0. I don’t personally think that it adds value for bonding curves to start flat; in fact, I would wonder if this particular shape makes curators less likely to invest broadly across data sets, but rather focus on the data sets with increasing ‘Drops’ price or very close to increasing ‘Drops’ price, hence creating a paralysis upon new data set publishing.

Open Questions & Notes

Obviously, these are just proposals, which should be fiercely reviewed/criticized, and fully validated with game theory, testing and experimentation before consideration. The idea is to spark dialogue and provide an external point of view, putting the end-user at the center of the reflection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment