UI Refactoring Goals

Goals

Refactor the styling in the UI to be more common and add the concept of Themes to set variables

Refactor the common Components to be more reusable and less coupled to the current design

Use containers more than we currently do, but with an eye toward isolating elements to be easily moveable to other areas.

General improvements to load times and determine the minimum required data for a component, which can be used to improve getters

Create a Visual Guide page to show all the various common elements and allow theme switching on one page.

These should provide 5 wins:

• easier reskinning - a/b testing of new designs
• isolation of components to allow for easier exporting of augur widgets (embedded order form for example)
• easier development through use of a lego-like component library to be able to quickly build out new features or construct new pages
• increase the speed of loading data by auditing the minimum required data for components and finding efficency improvements
• Visual Guide is a great way for devs to easily look through all the components rendered out to make sure they are using the right components to achieve the visual look we are driving toward.

Overall the goal is to decouple as much of the UI as possible from the current design pattern, while also DRYing up the styling and repeatedly used elements in a way that makes composing new designs as simple as placing some components into a react file and having it “magically” work the first time with very little additional edits required, ideally none. Need a Order Form on the account page for some reason? just import <OrderForm> and feed it a marketId. Need to change the entire style of the UI to use Yellow, Blue, and Red as the main color scheme? simply create a theme file and change the theme passed to the top level App.jsx component.

Ultimately we should create a foundation for future development that is easier to reason about, provides a faster velocity of development, decreases the time it takes to onboard new employees, helps open source developers contribute smoothly, and allows for easier A/B testing around a top level Theme defined in one file for easy manipulation and edits that naturally flow through to the entire App in a coherent way.

Refactoring Styles

Themes will allow us to set a top level theme to the app, something like default-ui or betting-ui or reporting-ui. These top level themes would allow us to change all the colors/text on the entire site based on the theme. The idea is to standardize the color variables for example, so instead of color-purple we would instead use something like color-primary. If we wanted to use another color besides purple for our primary theme color, it would be as simple as changing the variable under the theme from purple to yellow for example. Instead of needing to go to each component and dictating in the UI that if it’s default-ui theme we use color-purple but for betting-ui we use color-yellow instead we simply change the top level color-primary to yellow if we are in betting-ui or purple if default-ui. This change would then flow down to the rest of the design and all the primary colored objects would now be yellow or purple.

Benefits:

• Easier creation of multiple styles/themes for the entire app without needing to think about where each new color goes
• Easier A/B testing of new themes using the development or even live version of the app
• Faster creation of new specialized UI such as the betting or market marker ui’s we have planned

Refactoring Common Components

There are common elements in this UI that are used on multiple pages. Some of these common things are already standardizing like the icons for example. I would like to take this approach with basically everything that’s used more than one time. A simple example in the new design is the market state labels. They all look the same on multiple pages and generally say things like Open, In Reporting, Closed with a colored line underneth the text, green, yellow, and red respectively. Instead of defining these in each component used and adding the CSS specfically for that one component, it would be better to standardize it so that we could have a <MarketStatus marketId={marketId}> that would automatically color/label the market state and wouldn’t require any extra css work in that particular component.

Benefits:

• Faster composition of new pages/features/elements in terms of actual development time
• Easier to reuse or modify existing component layout easier since everything is decoupled from their original location
• Easier onboarding of new employees or open source developers given the readable/lego style component composition

Increased Use of Containers

Currently we use container elements as top level type components, such as Market-View for the trading page. If we increased the granularity of these containers to instead have containers for things like OrderForm, Depth Chart, Candlestick Chart, OrderBook, etc we would be able to decouple these components in a way that allows for easier composition of new pages or mixing and matching of elements we currently can’t do easily. An example of our current issues around this is the Order Form. We have two places that the Order Form is currently shown: The Trading Page and Market Creation Liquidity section. Unfortunatly they are currently two completely different components that are both styled seperately and it’s not very DRY. If we instead used a container at the Order Form level, instead of market-view (trading page) or create-market we could then re-use the same order form component since the container would ensure that the proper state/actions are available to the Order Form instead of relying on them to be passed in from the top level market-view or create-market components.

This would allow us to throw the Order Form into the portfolio positions page for example, giving users a quick way to place a trade without having to click through to the trading page. Further, we could then export the Order Form as a widget to be used by third parties in a much simplier package that would simply require some data from the Augur-Node, things like Market Id, min/max price, etc.

Benefits:

• Easier re-use/composition of components of the augur ui
• Easier to export individual actionable components out to third party sites as embedded components
• Faster development with less concerns about passing the needed functions to OrderForm

General Data Improvements

Currently we tend to pull in large amounts of data without needing to actually display all that information in the UI at that time. During this refactor we should look for areas to improve the data fetching and lazy loading of information that needs to be displayed in the UI. This process should allow us to not only decrease load times but also optimizing the data retured to be only what is needed in an effort to reduce over fetching.

Benefits:

• faster load times
• more efficient API

Visual Guide

The Visual Guide will be made after the previously discussed changes are made, the idea being a central location to be able to visually see all the various permutations of the components rendered out on one page in a searchable maner. We would also allow the changing of themes to see what colors change and how it will look. Justin provided an example link of something similar to what this Visual Guide might look like Example Visual Guide.

Benefits:

• Easier recognition of what element is appropriate to match the mock we are trying to build
• Easier on boarding of new employees who would be able to visually confirm what they need to import/add to their component
• Easier for open source contributors to be able to build new components for us without having to get into the details

Opening this up for public discussion/contributions before we get to work. I’ll keep editing this top level post with new ideas/corrections or expand it if we need more details. For now this is just a general overarching view of things we would like to change and the benefits we expect to get out of these changes.

[justinbarry]

typescript?

[pgebheim]

I’m really interested in how the component model can be used to help us keep your data model under control as well. Specifically, if we are looking at what minimal data is needed within a Container, can we make the getters operate on that level, as well as the aggregate level (e.g. select data for all markets such that each component can be rendered quickly).