I'm following up with some thoughts on the dashboard view. This got addressed to some degree in the last push, but seemed to get stuck at a point. Hopefully should provide some food for though to discuss and continue off.
For background, some questions I've thought about:
What information does it make sense to include there, ie. various interpretation needs: traders, contractors, investors/prospects, miners, stakers; insight of the entire block explorer structure)?
How is it composed (ie. structure/layout/components – as a whole and optimizing it)?
How is it curated (ie. groupings, details – to benefit better interpretation of the data)?
On higher level we got two larger groups of information to work with.
1) Blocks+Mempool data
Next Block breakdown, Recent entries log, Mempool breakdown, Recents entries log
2) Statistics
PoW, PoS, Distribution
Layout/Structure
The way the containers are positioned against one another doesn't make it overly easy to scan them atm. Also, the containers aren't always ideal in size or proportion for the content .ie mempool and latest blocks being placed in similar width – where-as mempool would be more optimal in a smaller container.
I created two quick higher level layout examples to address this:
1) A 50/50 proportional breakdown (slide 2) for stats and last blocks/mempool as well having the two reversed for better optical scanning (condensed stuff on left, larger chunks on right). But needs the latest block and mempool to be solved still.
2) 1/3 horizontal and vertical breakdowns (slide 3). Off the bat, this could work quite well. The stats can be populated in 4 almost squares, which can scale and left-right-top-down stack for mobile logically. Last Blocks gets slightly more spacier and allows for the tables to be symmetrically placed against Mempool. This can easily be taken further, maybe the split isn't exactly 1/3 but in the middle of PoW card or some other rule etc.
Last Blocks/Mempool Breakdown
For both Latest Blocks and Mempool, there's a log of recent entries and a section for "live data" (by live data – I mean the idea that the user would understand that these changes in the data are occurring right now, so being able to tell what is doing what etc).
The difference I noticed is that the notion of a live data bit is clear with the mempool (due to high activity, rows being added, nr's, bars changing) where-as for Latest Blocks there's little indication of it. Having it helps to give a robust insight into how the blockchain functions, so bit more additional value. A more visual representation would be ideal as touched point on earlier, but here I'm looking at some smaller details and methods which might help to better communicate these things.
Potentially the lowest hanging fruits would be working in some use of timers and slightly emphasizing the transitions on row + number changes. Also the "Next Block" addition could take use of an indicator that is triggered by some actual values changing.
Ie (o) block created ---> (o) approved by votes ------> (o) pending/added -> Plays simple change transition to next one.
Statistics breakdown
These are currently broken down in three groups: PoS, PoW and Distribution and placed in near-symmetrical containers. There are several issues here that can be broken down further, but i'll just touch point on the hierarchy and standardization of the groups. Being in the top-down listing, PoS is on the top on the hierarchy and the heaviest of the three with 6 value sets vs 4 for others. This creates a lot of imbalance. PoW makes sense. Distribution, on the other hand, is a bit weird umbrella as both Treasury and Market/Price related stats are strong groups on their own. E.g. the price conversion to USD is in the very bottom of all this – which is undoubtedly a useful metric and should be further up in the hierarchy.
I had a go at iterating these groups to provide a better interpretation of this information. Instead of the 3 groups, tried working with 4 groups each with a limitation of 4 data sets. Distribution is broken up to Treasury and Market/Distribution (something in lines of that). These are both more logical groupings, as well can be leveraged to refer to the relevant subpages.
https://alpha.dcrdata.org/market and https://alpha.dcrdata.org/address/Dcur2mcGjmENx4DhNqDctW5wJCVyT3Qeqkx?txntype=merged_debit
Groups details for discussion (slide 4):
Market (Or Price and Distribution)
1. Current Price in USD. Subtitle: % change in 24/h
Same as before, ideally there should also be an easy way to switch between the currencies, whether it's USD, EUR, BTC, etc.
2. 30 day average. Subtitle: High and Low.
Useful longer term metric, both traders and contractors perspective.
3. Total supply mined. Subtitle: % of 21 mil.4. Locked in PoS (Staked). Subtitle: % of total supply.
May argue to have this under PoS. From market perspective it's essentially an available supply. Obvious replacements would be either Volume or Market Cap.
Proof of Stake
1. Ticket Price. Subtitle: Value in USD
Could save up 1 spot by including the PoS reward as part of ticket price. Since the DCR/USD value is already visible in the previous card. Big tradeoff is that this would mean ROI would be left out, which likely outweighs it.
2. PoS reward. Subtitle: ROI/Ticket
ROI/Ticket is probably the least confusing. ROI/~Votetime is a clever way to bring in the avg vote time on the return, so that's certainly a contender.
3. Estimated Next Ticket Price + time remaining. Subtitle: min-max price
The time remaining is arguably an important metric, as some stakers may rather wait for the price to drop before buying new tickets. I grouped here with the price estimate, though this makes for a rather long data set that stands out a bit too much. It probably makes more sense to have the time remaining instead of Ticket Pool Size as 4th item.
4. Ticket Pool Size. Subtitle % over target.
If i'm not mistaken then this should concern a very small group of users. Being significantly more technical piece of data, this is probably better replaced by % Locked in PoS (staked) or time till next ticket price.
Proof of Work
1. Hashrate. Subtitle: % change in 30 days.2. PoW Reward. Subtitle: USD value.3. Difficulty.4. Reward Reduction in. Subtitle: block nr of target block nr.
Treasury
1. Grand Total. Subtitle: Value in USD.2. Growth DCR/block. Subtitle: USD/24hr3. Received Last 30 days. Subtitle: +/- Net spent/received.4. Spent Last 30 days. Subtitle: %Change to previous month.
To provide a quick perspective on the treasury's current performance.
Hi,
A follow-up to: https://github.com/decred/dcrdesign/issues/139 Ref: @harlovski @buck54321 @raedah @chappjc
I'm following up with some thoughts on the dashboard view. This got addressed to some degree in the last push, but seemed to get stuck at a point. Hopefully should provide some food for though to discuss and continue off.
Wireframes: https://xd.adobe.com/view/18ffd9fa-4486-45b8-5598-acacf4f4023c-6ece/
For background, some questions I've thought about:
On higher level we got two larger groups of information to work with. 1) Blocks+Mempool data
Next Block breakdown, Recent entries log, Mempool breakdown, Recents entries log2) Statistics
PoW, PoS, DistributionLayout/Structure The way the containers are positioned against one another doesn't make it overly easy to scan them atm. Also, the containers aren't always ideal in size or proportion for the content .ie mempool and latest blocks being placed in similar width – where-as mempool would be more optimal in a smaller container.
I created two quick higher level layout examples to address this: 1) A 50/50 proportional breakdown (slide 2) for stats and last blocks/mempool as well having the two reversed for better optical scanning (condensed stuff on left, larger chunks on right). But needs the latest block and mempool to be solved still. 2) 1/3 horizontal and vertical breakdowns (slide 3). Off the bat, this could work quite well. The stats can be populated in 4 almost squares, which can scale and left-right-top-down stack for mobile logically. Last Blocks gets slightly more spacier and allows for the tables to be symmetrically placed against Mempool. This can easily be taken further, maybe the split isn't exactly 1/3 but in the middle of PoW card or some other rule etc.
Last Blocks/Mempool Breakdown For both Latest Blocks and Mempool, there's a log of recent entries and a section for "live data" (by live data – I mean the idea that the user would understand that these changes in the data are occurring right now, so being able to tell what is doing what etc).
The difference I noticed is that the notion of a live data bit is clear with the mempool (due to high activity, rows being added, nr's, bars changing) where-as for Latest Blocks there's little indication of it. Having it helps to give a robust insight into how the blockchain functions, so bit more additional value. A more visual representation would be ideal as touched point on earlier, but here I'm looking at some smaller details and methods which might help to better communicate these things.
Examples on other block explorers for illustrating: https://explorer.rsk.co/ - use of timer counting down, use of transitions and some motion design on the charts updating https://blocks.fusionnetwork.io/#!/dashboard - emphasized transitions https://explorer.ont.io/ - block interval visualization, transitions when loading and viewing, use of timer, transitions on numbers changing https://etherscan.io/ use of timers, basic transitions https://mainnet.theoan.com/#/dashboard - this is bit of a gimmick, though loading icon animation combined with timer and text change does communicate addition of new blocks rather clearly https://blockscout.com/poa/core - emphasis on transitions when loading https://explorer.nexty.io/ - emphasis on transitions, transitions when loading
Potentially the lowest hanging fruits would be working in some use of timers and slightly emphasizing the transitions on row + number changes. Also the "Next Block" addition could take use of an indicator that is triggered by some actual values changing.
Ie (o) block created ---> (o) approved by votes ------> (o) pending/added -> Plays simple change transition to next one.Statistics breakdown These are currently broken down in three groups: PoS, PoW and Distribution and placed in near-symmetrical containers. There are several issues here that can be broken down further, but i'll just touch point on the hierarchy and standardization of the groups. Being in the top-down listing, PoS is on the top on the hierarchy and the heaviest of the three with 6 value sets vs 4 for others. This creates a lot of imbalance. PoW makes sense. Distribution, on the other hand, is a bit weird umbrella as both Treasury and Market/Price related stats are strong groups on their own. E.g. the price conversion to USD is in the very bottom of all this – which is undoubtedly a useful metric and should be further up in the hierarchy.
I had a go at iterating these groups to provide a better interpretation of this information. Instead of the 3 groups, tried working with 4 groups each with a limitation of 4 data sets. Distribution is broken up to Treasury and Market/Distribution (something in lines of that). These are both more logical groupings, as well can be leveraged to refer to the relevant subpages. https://alpha.dcrdata.org/market and https://alpha.dcrdata.org/address/Dcur2mcGjmENx4DhNqDctW5wJCVyT3Qeqkx?txntype=merged_debit
Groups details for discussion (slide 4): Market (Or Price and Distribution)
1. Current Price in USD. Subtitle: % change in 24/hSame as before, ideally there should also be an easy way to switch between the currencies, whether it's USD, EUR, BTC, etc.2. 30 day average. Subtitle: High and Low.Useful longer term metric, both traders and contractors perspective.3. Total supply mined. Subtitle: % of 21 mil.4. Locked in PoS (Staked). Subtitle: % of total supply.May argue to have this under PoS. From market perspective it's essentially an available supply. Obvious replacements would be either Volume or Market Cap.Proof of Stake
1. Ticket Price. Subtitle: Value in USDCould save up 1 spot by including the PoS reward as part of ticket price. Since the DCR/USD value is already visible in the previous card. Big tradeoff is that this would mean ROI would be left out, which likely outweighs it.2. PoS reward. Subtitle: ROI/TicketROI/Ticket is probably the least confusing. ROI/~Votetime is a clever way to bring in the avg vote time on the return, so that's certainly a contender.3. Estimated Next Ticket Price + time remaining. Subtitle: min-max priceThe time remaining is arguably an important metric, as some stakers may rather wait for the price to drop before buying new tickets. I grouped here with the price estimate, though this makes for a rather long data set that stands out a bit too much. It probably makes more sense to have the time remaining instead of Ticket Pool Size as 4th item.4. Ticket Pool Size. Subtitle % over target.If i'm not mistaken then this should concern a very small group of users. Being significantly more technical piece of data, this is probably better replaced by % Locked in PoS (staked) or time till next ticket price.Proof of Work
1. Hashrate. Subtitle: % change in 30 days.2. PoW Reward. Subtitle: USD value.3. Difficulty.4. Reward Reduction in. Subtitle: block nr of target block nr.Treasury
1. Grand Total. Subtitle: Value in USD.2. Growth DCR/block. Subtitle: USD/24hr3. Received Last 30 days. Subtitle: +/- Net spent/received.4. Spent Last 30 days. Subtitle: %Change to previous month.To provide a quick perspective on the treasury's current performance.