0000000000001101 - Steemit Interface PoC - Bug Fixing and Enhancements

in Steemit Dev Group3 years ago (edited)

👇🏼 Source
image.pngSeparator-code.png

A big thank you for all of the comments on my last post. It's nice to hear that you like how it's looking and for highlighting some of the bits that I'd missed.

Sometimes, it takes just as long to iron out the problems as it does to write the initial version and this has certainly been the case with what I've done here. The potentially long delays between rewards being earned, being claimed, converted in the internal market and subsequently powered up means that sometimes things can look wrong even when they're correct so I've had a lot of fun following the money trail to ensure that the data's as accurate as it can be.

👇🏼 Source
image.png
Separator-code.png

So here's a summary of the changes I've made based upon your feedback...

Increased the Data Limits

@moecki pointed out that my data set was limited and highlighted the 250 limit on the transfers_api data set. Over a 3 month period, 250's really not very big so this has been increased to however much data exists for the time period. Obviously, the more data, the longer the page takes to load but in most cases, there isn't a delay. moecki's 517 Transfers In are now all available 😀

Separator-code.png

Transfers Direct To STEEM Power are Now Included

@remlaps highlighted that some Transfers In go straight into STEEM Power and not via the wallet. These Transfers In are now included in the summary pie chart and accompanying table under the title "Transfer In: To STEEM Power" and are also included within the "STEEM Rewards & Transfers In" and the "Transfers In" tab - with a memo saying "To Steem Power".

Separator-code.png

Other Enhancements

I'm not the kind of person who'll sit and bug fix without introducing something new so I've also added in a few more features and some more subtle improvements.

  1. Toggle Between 1 Month and 3 Months Data: I've included a simple link under the "Account Summary" pie chart to toggle between 1 month and 3 months worth of data. 3 months is currently the limit due to the account_history API which I use to analyse trades. Since I only use the trades for point 3 below, I could remove this small piece of information if a longer timeframe's included.
  2. SBD To STEEM conversions highlighted in the Data Table: I found the inclusion of SBD data within a table primarily dedicated to STEEM quite confusing so I've clarified this by highlighting the SBD amount and then its conversion to STEEM. I think that it's clearer now.
  3. NET Value Trades from SBD to STEEM: Underneath the "SBD Rewards & Transfers In" chart, I've included a paragraph to highlight what trades the user has done on the internal market.

Untitled-2.png
Separator-code.png

The site is available here - http://steemit.lovestoblog.com/clubstatus.php?author=the-gorilla

Footer-Top-green.png

As always, please let me know what you think 🙂

Sort:  

Now, it seems very correct :-))

I didn't mention in your last post that I like the link between the statistics and the account name in your frontend. However, at some point later you should also add a link to the author's posts or offer both. But time will tell...

Obviously, the more data, the longer the page takes to load but in most cases, there isn't a delay

If there is a significant delay, you could first use the offset to see if the 250th transfer is still within the 3-month period before querying and processing 500 or 1000 records.

The addition of the "SBD To STEEM conversions" is also very helpful to understand the numbers.

However, at some point later you should also add a link to the author's posts or offer both.

That's my hope too. I think I'll need to separate it out a lot more into sections like "posts", "statistics", "update profile", etc. there's quite a lot that would enhance a user's profile page 🙂

I'd also like to introduce "shared wallets" so that I can quickly spot a scammer 🤣

If there is a significant delay, you could first use the offset to see if the 250th transfer is still within the 3-month period before querying and processing 500 or 1000 records.

At the moment, I retrieve 1,000 and the point at which the date is earlier than the distance in time I want to go back to, I break the loop. If at the end of the 1,000 we're still within the time band, then I load another 1,000 and repeat. I could change this offset to a smaller number but the API return is so quick and the looping would need to happen anyway, I think it makes sense to go big 🙂 I tested it with one of the "trading bots" which meant that I had to process over 10,000 rows of data. Nothing broke and it was a pretty extreme test case so I'm confident that we won't have a problem.

The addition of the "SBD To STEEM conversions" is also very helpful to understand the numbers.

Thanks. I had problems correlating the numbers and found that the more information I added, the clearer things became. So if it's useful for me, it must be useful for everybody 🙂