Defining the Polkadot Staking Experience: Phase 0

This product is a work in progress, designed to communicate ideas, generate feedback, and define a solid foundation for application-side Polkadot.

Introduction

This project lays down foundations and initial direction for a Polkadot front end application pathway, focusing on the Staking use case.

Interface design has been considered in detail alongside the critical functions of staking in Polkadot, with the aim of creating a next-generation Dapp experience.

What this means in practicality includes, but is not limited to:

• A modern Dapp utilising the latest UX technologies
• Easy access to major staking functions
• Ability to browse the app without having to connect wallets / accounts
• The ability to handle independent APIs concurrently
• Interactive, real-time graphs and metrics where applicable
• Unbiased validator selection
• Intuitive help content guiding the user through the experience.

High Level Characteristics and Direction

A React and (eventually, comprehensively typed) TypeScript based project, the app adopts the following characteristics:

• React 18 (beta) from the off, aiming to leverage concurrent UI patterns that should start rolling out in major packages in the near future
• Fully flexbox-based interface alongside Framer Motion animation and gesture library, where transitions have been considered and baked into the fundamental navigation of the app
• An event-driven and context-aware interface designed to react to real-time events from blockchain nodes alongside other external APIs concurrently.
• Leveraging latest CSS standards to deliver a professional and uncompromising Polkadot style guide
• Designed to be easily migrated to native platforms, such as React Native Desktop — an initiative that is being rapidly accelerated by Microsoft to replace Electron-based apps. Note that the focus now is primarily for the web, albeit with the high level interface elements being made suitable for desktop too— expansions to native platforms will be considered only after a web-based MVP is established.

Interface

Already-established interface elements include:

• Modular components that display critical statistics and account activity
• A context-aware assistant modal that updates with definitions, external articles and critical to-do’s that depend on the app state
• A network bar designed to abstract network-centric information from the main interface. Expand to see additional network information
• Event driven announcements pertaining to states that prevent the user from carrying out critical tasks, such as the nominator cap being reached.

Framer Motion is being heavily leveraged to maximise interactivity, including:

• Hovering and tapping gestures on components of interest
• Stagger children for list transitions
• Entry and exit transitions of major components (modals) and footer content (network bar).

Charts.js is being used for graph components, and has been determined to be the best package for the app’s requirements.

Number easing is present on numerical data.

All un-synced graphs and statistics assume a value of zero until the required data has been fetched from the required API.

Network Layers

Network Bar provides technical info and meta data related to the chain and prices.

The app balances user experience with ideals of decentralised data fetching:

• Relying on a node connection for critical data that the app considers primary
• Relying on external APIs where necessary. Such APIs are siloed into components where it is made obvious they’re not sourced from a node connection. An example of this is the price ticker, or the upcoming validator selection algorithm integration, or Subscan API to provide validator metrics
• To coincide with open source distribution, API quotas need to be based on IP address, not on an API key.

The app considers multiple API connections. A direct connection to a Polkadot node is established first and foremost and collates data in the following manner:

1. A Polakdot JS API websocket connection is established
2. Initial subscriptions are made, and chain storage values are fetched
3. Staking metrics that rely on the previous metrics (such as the current era) are then fetched.

This multi-stage fetching approach has identified limitations of the Polkadot JS API, such as relying on multiple contexts and embedded component hierarchies when working with React contexts. This app is in a great position to leverage API redesigns and test their usabilities as and when they become available.

A price ticker relies on Binance’s public spot API.

The Subscan API will be used in the near future, primarily for data-heavy validator statistics.

To reiterate, these APIs are essential for the user experience and viability of this app, and are used to complement underlying node data.

Assistant

The Assistant overlays the page and displays context-aware resources

Help documentation is often a secondary thought for Dapps, resorting to external links to often-technical documentation.

The aim of this project is to educate users within the app, integrating a modal that provides useful information that depends on the state of the app. This has been called the Assistant.

The Assistant currently has been designed to:

• Display Polkadot-specific terminology and definitions
• Link to external articles and tutorials
• Highlight vital next steps.

There are opportunities to expand the Assistant we can foresee now, including:

• Integrating web3 authentication and “liking” articles that will rank further up the list
• The ability to manage the resource lists in a more decentralised manner on Github
• Opportunities in ML, such as training a network to understand various voice commands that would invoke the Assistant or other app functions.

Staking

The staking interface is designed to house all call-to-actions for the major staking interactions.

The Staking page will simply be where staking actions happen, including bonding and choosing how to select validators.

• Stake is the primary interface for managing staking activity, including bonding funds and nominating validators
• Manual selection or Smart Nominations (validator selection algorithm) will be supported
• Nominator pools will eventually be supported as they are rolled out.

The staking section along with Validators and Payout sections will evolve as the limitations or bottlenecks of the APIs available to us become more apparent, but the intention is to provide full staking support in addition to critical validator metrics.

Community Opportunities

Community project placeholders.

Embedding community projects around staking and the Polkadot ecosystem will promote the entire space, and further educate end users of the work happening with parachains, programs to promote staking, etc.

Next Steps

Upon positive feedback from the existing effort, a next iteration would pertain to:

• Theming for dark mode and additional network support
• Network switching (Kusama)
• Validator lists with Subscan API experimentation
• Validator Selection Algorithm interface embedding.
• Live dashboard statistics
• Transaction interface and monitoring (pending, completed)
• The project being made available on GitHub.

For interested non-Parity parties: Please contact me for any constructive feedback or ideas to improve the ideas discussed in this piece. @rossbulat on Twitter is my preferred public communication channel.