Designing Mutable UIs within the Context of Immutable Data Storage

Currently, there is a paradox between what is expected of web application user-interfaces (UIs), how they display data, and the underlying paradigm shift the introduction of immutability as a core principle that decentralized applications (dApps) present.

Photo by Tony Webster on Unsplash

By design, these new applications can share many of the same features on the frontend as their web 2.0 precursors. In fact, one of the end-goals is often to make the backend technology disappear, so that the average user, already accustomed to modern web applications, doesn’t need to understand all the complexities of the nascent underlying networking protocols any more than they might or might not contemplate the inner workings of TCP/IP during their day-to-day.

A seemingly obvious realization is that all users of computer applications inevitably will make mistakes, or want to retract various actions regardless of the platform. What isn’t so obviously is how to properly communicate this underlying shift so that users feel empowered rather than frustrated and/or confused.

Media and content networks are a perfect example for a case-study. Being able to edit or delete content exposed to users via a web application is something people are used to, and have come to expect. With web3 applications that upload content or hashes of content to ethereum there poses some new challenges. The complexity arises out of the fact that transactions mined into the ethereum blockchain are immutable moments forever transcribed into the blockchain’s history. Each blockchain event is not actually deletable by dApp developers or anyone else for that matter. This is a feature, not a bug, and an exciting one in the case of content ownership.

With that being said, understandably, developers and designers recognize the value of clean and functional UI with great UX as a guiding principle. So the idea we need to make transparent is that content uploaded to the ethereum network is represented as a stream of data in the form of immutable objects. Rather then the data of individual objects being directly mutated, new objects are appended to the chain. This is exciting for a variety of reasons.

Given that we communicate the reality of edits and deletions of data on the network, we can redefine how content publishing, ownership and disputes, when necessary work. In the short-term, UIs can handle this by allowing users to deactivate stale content while providing the option to replace it with a new version in the case of an edit. In the longer term it introduces a way to handle disputes of ownership or invalid data via a decentralized network. UIs can then simply verify the current state of each object as it progresses through a Finite-State-Machine (FSM) and apply the appropriate visualizations to clients exploring the content.

The way the state transitions occur could be handled by the content owners themselves or eventually by external decentralized mechanisms such as Token Curated Registries (TCRs). The challenge and goal is to enable the reconciliation between content creators and transacted data that has become obsolete or invalid over time.

Providing the proper feedback to users of web3 applications presents some unique challenges, but I’m excited to see innovations in how design systems and frontend interfaces communicate the subtleties that differentiate the next iteration of the web.

These are problems we are continuously thinking about at Ujo where we are designing new applications for music that bring ownership to artists. In a later post, I’ll expand on this and discuss some of the strategies we’ve come up with or considered with the hope that we can discuss pain points and come up with solutions.

Building Ujo

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store