Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Gov 1.5 - Holographic consensus interface #16

Open
rossneilson opened this issue Nov 10, 2022 · 9 comments · May be fixed by #339
Open

Gov 1.5 - Holographic consensus interface #16

rossneilson opened this issue Nov 10, 2022 · 9 comments · May be fixed by #339
Assignees
@dcrescimbeni
Labels
1.5 app:Frontend
Milestone
2023 - Sprint 7

Comments

@rossneilson
Copy link
Contributor

rossneilson commented Nov 10, 2022 •
edited
Loading

With DXdao contracts, nicknamed "Gov 1.5" due to it being only one large change away from "Gov 2.0" we have a more complex system.
The same as in DXdao currently this architecture has holographic consensus. This is what allows proposals to boost and execute faster and without 50% votes.

The logic of this system is that it incentivises attention to proposals with a high monetary value assigned to them. Essentially people staking on a proposal are making a bet that the proposal will either pass or fail.

We have designs in the figma for a first iteration of this interface. Since this is an entirely new feature for Gov 1.5 and not in guilds we need to add it as a feature to the store module for 1.5 and handle that logic when choosing what to render.
This also means we need new optional hooks in our interface which need implemented for this issue (names just from top of head, rename them):

  • useHolographicState
  • useHolographicVotesOfProposal
  • useHolographicStake

https://www.figma.com/file/Z2yCtX1NLhdJYYoBiXkdMg/DAVI-v1?node-id=39%3A9061&t=u57B1yj9ksOl2R8g-1

Most of this logic will be in relation to the voting machine for each scheme as that is where holographic consensus logic lives (I think)

We can handle the more complex state of holographic consensus separately and show it as an additional pill for now.

In the confirm prediction modal we should see the speedometer change dynamically depending on what .
When the user first chooses for or against we should set the amount to stake to the total needed to change the current state (e.g staking on For would suggest the min amount of DXD to change to pending boost state).
The logic for working out pending boost state as well as the stake required to change states is very important and a little complex (dependant on amount of currently boosted proposals and more) refer to the contracts closely and we should test it well.

There is a library linked below we could use for the speedometer, take a look and we can use it if it seems good. If not we can always make our own, just that the animations would be nice to have with the package.
@rossneilson rossneilson changed the title Holographic consensus interface design Design - Holographic consensus interface Nov 10, 2022
@rossneilson rossneilson transferred this issue from DXgovernance/DAVI Dec 28, 2022
@rossneilson rossneilson added this to the 2023 - Sprint 1 milestone Jan 9, 2023
@rossneilson
Copy link
Contributor Author

https://www.npmjs.com/package/react-d3-speedometer

@borisblock3007
Copy link
Collaborator

This is the latest draft of Holographic consensus interface

Image

Image

@rossneilson rossneilson removed the Design A design task label Mar 7, 2023
@rossneilson rossneilson changed the title Design - Holographic consensus interface Gov 1.5 - Holographic consensus interface Mar 10, 2023
@dcrescimbeni dcrescimbeni self-assigned this Mar 14, 2023
@dcrescimbeni
Copy link
Contributor

annotely_image

About the elements, to me, it seems the position should be switched to align with the speedometer.

The thumbs-up and thumbs-down buttons will just open the modal, right? With the option pre-selected (if the user clicked on the thumbs up, the "for" option will be selected).

Maybe we can replicate the same UI elements in the modal and highlight the current option like this:
image

@dcrescimbeni
Copy link
Contributor

dcrescimbeni commented Mar 14, 2023 •
edited
Loading

A thing with the current speedometer library is that we can't configure the needle shape, just the color:

image

Is this OK or should I look for an alternative?

@borisblock3007
Copy link
Collaborator

i think it looks even better with this needle shape. i also moved status text a bit lower and removed the background for a more minimalistic look :)
holographic 3

@borisblock3007
Copy link
Collaborator

switched the buttons positions and removed a speedometer title in the modal
holographic 5

@dcrescimbeni
Copy link
Contributor

I'm having an interesting problem: the slider functionality don't play well with big numbers.

My first approach was that the slider sets a percentage, so all the way to the bottom you stake 0%, on the middle you stake 50% and so on.

The problem with this approach is that it could (and most certainly will) lead to cases where a percentage of a number ends up containing decimals, and staking numbers are integers, and there doesn't seem to be a way (that I know of) to get just the integer part, or calculate it in a way that avoids decimals.

The other approach is to set the slider range the same as the user balance: for example, a user with 700 tokens would stake 0 if the slider is all the way to the left, and 350 if it's in the middle. The problem with this is that values end up in scientific notation, like "8.27361111111110994e+19".

Another thing, not related to this, is the ability for the user to set exact or small amounts. It'll be hard to set a precise amount in a slider, and if the user has a big balance, staking a few tokens could be super hard.

@rossneilson
Copy link
Contributor Author

I'm having an interesting problem: the slider functionality don't play well with big numbers.

My first approach was that the slider sets a percentage, so all the way to the bottom you stake 0%, on the middle you stake 50% and so on.

The problem with this approach is that it could (and most certainly will) lead to cases where a percentage of a number ends up containing decimals, and staking numbers are integers, and there doesn't seem to be a way (that I know of) to get just the integer part, or calculate it in a way that avoids decimals.

The other approach is to set the slider range the same as the user balance: for example, a user with 700 tokens would stake 0 if the slider is all the way to the left, and 350 if it's in the middle. The problem with this is that values end up in scientific notation, like "8.27361111111110994e+19".

Another thing, not related to this, is the ability for the user to set exact or small amounts. It'll be hard to set a precise amount in a slider, and if the user has a big balance, staking a few tokens could be super hard.

Ok, lets not spend too much time on this then if its overly complex.

@borisblock3007 could we get a design for just a token input field instead?

and then we can set the suggested amount to boost or unboost to the default amount in that field each time the user changes their option (upstake or downstake)

@dcrescimbeni
Copy link
Contributor

Hey, I got a suggestion from Madusha that might work, so I'll try that next.

@dcrescimbeni dcrescimbeni linked a pull request Mar 27, 2023 that will close this issue
Open
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dcrescimbeni dcrescimbeni

Labels
1.5 app:Frontend
Projects
Sprints
Status: Review
Milestone
2023 - Sprint 7
Development

Successfully merging a pull request may close this issue.

Feat/holographic consensus dcrescimbeni/davi-monorepo
3 participants
@borisblock3007 @rossneilson @dcrescimbeni