UI/UX improvements Web application

I am starting this topic here, to have feedback from the community with regards to the usability and functionality of our Web application.

The aim is to gather input, and we can evaluate what can be done now, what can be done later, or not done at all.

I will give my personal view on things and everybody please give yours.

We need to have our identity, so an idea is have our own colour scheme.

One of the questions, that have been asked a lot, are:

  • borrow APR may be with a graph for historical (30 days) values
  • deposit APY may be with a graph for historical (30 days) values
  • utilisation value/ratio
  • collateral factor (or Loan-to-value)
  • liquidation value/threshold
  • liquidation bonus

These risk parameters are crucial to enter the market, and having them just in front of you, on the screen, while depositing or borrowing, is an advantage over others, where one has to dig into the documentation to find it - sometime even google it.

On the transaction screens, supply, withdraw, borrow, and repay, a percentage box 25% / 50% / 75% / 100%, would make the user much more comfortable, and not having to grab the calculator.
A slider to have custom percentages would even be better.

An overview screen would give a user the total picture of the market, on the supply side and on the borrowing side (Aave is having a good dashboard like this).

The staking page could also use a facelift, and make it more user friendly.

A landing page is important, which should tell just enough about percent, with numbers may be. Keep it simple idea, and not clutter with too many scrolls.

These are some ideas, let us know yours.

1 Like

thanks @Bluecrypt!

What we are missing right now is the “Stats” page.

We need to create a “Stats” page that is linked on the header of the percent.finance.

Here we can show:

  • TVL
  • Treasury
  • collateral factors for each token

and the metrics that you mentioned above.

I think we can discuss what sort of metrics would be nice to add here and then we can come up with a plan.

Please weigh in @brisket @Vaspou @CliveSpader @Spartacus @PercentFinance

Hey guys, ya I am absolutely on board with having a stats page! Those metrics sound good to me. Anything to make us as friendly as possible to everyday users.

@Bluecrypt thanks, this is a very important discussion as we head into Phase III, which will be presumably MM-centric.

As a general comment on the UI: I think the way UI currently is with B/W logo and simple interface already makes for a great style. Makes us stand out from likes of Cream and Aave (less Compound, but that as well) - kind of underscores our “no hype” approach. This also builds a foundation for better user adoption with future improvements we’re going to make.

I agree with each, except for utilisation ratio - i believe it’s more intuitive to add a column “total supplied” and “total borrowed” next to “supplied” and “borrowed” columns respectively.

Also i strongly recommend adding small “i” signs near each term and provide a brief explainer pop ups - something that is missing across most DeFi protocols, which is a huge neglect given we are dealing with people’s money.

Agreed as well

I think you guys are talking about the same thing, @cany please correct if wrong. I agree with @bluecrypt in having these relevant metrics like TVL and Treasury on the main page for starters.

Taking all of these proposals together i believe it should be possible to quickly update the website @PercentFinance?

One thing that might take a bit more effort is adding those little information pop-ups with description. i’ll let others weigh in on whether we need them. but if everyone else here agrees we should have them, maybe @CliveSpader can write brief and clear explainer texts for them with the help from the rest of us?

On a longer term note - i support what @cany proposes with having a separate stats page. i’d add to this that considering that we will presumably transition to Treasury management and PCT-pool management, maybe it makes sense to have the relevant metrics on how these things are working out at this dedicated page in addition to stuff like TVL, utilisation ratio etc.

Yup @Vaspou, makes sense to me. Once people decide what metrics we want I can definitely write little descriptions that everyone can collaborate on/ correct me on.

1 Like

Good inputs above. Here are 3 things I mentioned in Discord a while back:

  1. I notice that the front-end’s idea of my balances often gets out of sync with the blockchain. For example, after receiving a USDT transfer, when I try to supply the dialog says my balance is zero. Refreshing the page fixes it. I suggest coding the front-end with an onBlock() trigger to refresh all relevant balances – ETH, ERC20, borrowed, supplied.

  2. The front end is missing information about the markets / pools. Basically a page like:
    https://compound.finance/markets
    https://trade.dydx.exchange/markets/overview (Assets section)

This page should have key information for each market:

  • total supplied in USD
  • total borrowed in USD
  • utilization % (optional, maybe extraneous)
  • supply APY %
  • borrow APY %
  • supply PCT rewards APY %
  • borrow PCT rewards APY %
  1. The front-end uses unnecessary scrollbox frames that prevent me from seeing the entire frame even when my browser window is plenty wide.

@pyggie please keep in mind that @percentfinance has already added utilisation rate and collateral factors. But i support all other items you list, also with:

This doesn’t have to be a separate page. we can show it on main page:

@pyggie what browser/device are you using?

This was Chrome on Windows desktop.

1 Like

Check this work, please do comment, so I could finalise it, and this will give us an idea on how we want it, and will give a developer and designer an idea on what is required, so they could put a cost against this.

1 Like

Great stuff @Bluecrypt!

Do you think its better to have a dashboard with multiple tabs rather than a single screen with data, as originally outlined here: https://docs.google.com/document/d/1meS8adyZfLfhifn4kBwYm4hsiLWhyPChR2oyEGaHXPk/edit ?

I do like the dydx version of the dashboard, but we could look into making it more functional by splitting the two

There is another attempt here, with some aid from a designer I know (unfortunately not available :sigh:)

Everybody can add comments in the section ext to the page, so it’ll be easier for me to gather these and amend the pages.

I have an overarching comment, so i’d rather leave it here. The original idea for the protocol stats dashboard (at least the way i saw it) was to make sure that liquidations are easy to do by anyone willing to monitor the dashboard and press a button when needed, rather than create a very sleek protocol metrics portal.

So, i’d rather go with the most informative + functional approach, where its easy to asses utilisation rates across assets and see where most slack is being built up + have a simple list of most risky positions and UI that allows to liquidate them with a press of a button.

Given that we want to go with slightly more competitive mm parameters, risk management is important for us, so if we’re able to create simple yet effective user-friendly liquidation mechanics, i think we kill 2 birds at the same time.

How would you integrate this @Bluecrypt ?

Liquidation is a process on its own, and even if we may go for a portal, we will be beaten by the liquidation bots watching the lending smart contracts.

@Bluecrypt makes sense, my initial idea was to make sure that we are clearly covered on the front whether or not there is interest from professional liquidators (assuming they don’t necessarily follow smaller protocols like ours).

i’m not that well informed about how quickly they switch to new protocols/markets. Maybe you can weigh in this, as my motive was to make sure we’re secured on that front by having a very accessible UI to mitigate any early risks for mms

Sure, I got your point, and I am all for having a dashboard to manually liquidate position as soon as they are underwater, awaiting liquidator bots, to find the protocol, and start the process.
I guess this’ll require some development @PercentFinance could assess this.

@moderators guys anyone with a deeper knowledge on this? I guess we need to first asses whether its needed in the first place if arb bots are quick to spot any inefficiencies and we won’t need to bother building it and just go with the dashboard approach as you @Bluecrypt propose…

If not, than i’m all for considering an all-in-one dashborad/liq portal page, using one main page for all markets (i.e. total utilisation, largest markets within it etc) AND the list of riskiest positions across the protocol + combine it with separate pages for each market (which could be clickable from the main overview page) that contain both the utilisation params and riskiest positions lists, but for a specific market

Bots are trivial these days, and being a fork of compound, people who already have compound bots will not have to do that much work to target our site, so I believe offering liquidation on our website won’t work, as Bluecrypt says. In fact I’ve been considering having our own liquidation bot, but again we would probably get beaten by more experienced botters.

A dashboard on the other hand is crucial, and I am in favour of the proposed design. Tentatively I might be able to get this done myself via my business partner who is a front-end guy.

Having consulted with a couple more ppl involved with on-chain mm in these past days, i agree with you guys. Looks like manual liquidation UI will just turn out almost useless.

So lets go with the dashboard proposal. What i would suggest, since @Bluecrypt’s proposal is well thought-out in terms of data to display is we let the UI person doing it figure out the most user-friendly and informative approach, finalise the mock-ups, which we then can comment or approve.

This is a great option. I’m also talking to one person about this.

What i’m currently working on is a broader functionality roadmap (much more concrete than what was provided here) to propose to the community. Accepting it would mean going with a team that shall be responsible for delivering it milestone after milestone across many months.

So i was thinking that we could combine our current set of immediate UI/UX and smart contract tasks into one big bounty to test the skills on both front and backend of such a team. Dashboard, new oracle adapter and maybe a couple other things would make it there.

What do you think?

from Jacob.

Based on the latest mockup, the estimate would be