Open koday1 opened 3 months ago
I love the way the timestamps are being used here in gitcoin and think it would be great to do that! We should probably put a little note about the timestamps in all the places the user sees estimated matching (or at least most of them, including):
Also @mosaeedi - keep in mind that we should only show these estimates for current, active QF rounds... not ones that have been completed and have the actual matching shown in qf round tab.
1. Project card For Project card, I suggest we put the timestamp inside the tooltip. Link to Figma .
2. Project single page, matching estimated card Link to Figma .
3. project single page, donations tab, qf round tab, estimated matching section Link to Figma .
4. donation page Link to Figma .
For best optimization, we implemented it in way that the update time is dependent on the last donation on the QF round, so if there's no new donation (like in midnight), we won't refresh the estimated matching, but when a new donation is made, refresh estimated matching is called, and there's a debounce time of one hour, so if there are other donations in the meantime, refresh estimated matching won't be called. After one hour, refresh estimated matching will be called on the next donation. So, if there's no new donation, estimated matching is already updated and we've saved our DB processes.
TL;DR @laurenluz @mosaeedi Is it possible to change the copy to something like "Estimated matching will updated every 60 min"? because we don't know when exactly the estimated matching will be updated. The only thing we know is that the estimated matching is already updated or it will be updated in less than 60 min.
BTW, @laurenluz I believe we can safely set the estimated matching refresh debounce time to 10 min.
I just chatted w/ @RamRamez about this... so if we can update the estimated matching every 10 min, we can reduce the extra dev work by just adding a hard-coded note saying... Next update: <10 min - wherever it is applicable.
@mosaeedi what do you think?
Also, is there some way we can put that on the project card? this round when I was donating and things were not updated right away, I thought there was a bug because all the matching said 0 even on projects I donated to... I wouldn't have thought to check the tool tip.
And for 2. can we decrease the font size on the update text? it's stealing the show a bit from the numbers.
@laurenluz I like that idea, I see no issues with saying "Next update <10 min" and letting the user check back in to see the update.
I also agree w/ adding this directly on the project card instead of the tooltip. I ran into the same issues with my first donations in the GIV-Earth round.
cc @mosaeedi
We need this feature for the next QF round. cc @laurenluz @mosaeedi
Hey @RamRamez @mosaeedi just reviving this issue.
If we will use 10 min as the time for updating estimated matching, can we move forward with creating designs for the notes saying 'Next Update <10 min'? As discussed above, it would be in these 4 places:
@koday1 it's 2min on production now, maybe we can skip this design?
@RamRamez Got it - thanks for letting me know. @laurenluz I'm curious what your thoughts are on this - should we still add a note for the user if we're going with a 2 min update time?
let's skip it for now. this will all probably change anyway with the updated estiamted matching.
Updating estimated matching after every donation in a QF round requires a lot of resources on the backend. To reduce this load we are shifting to updating the matching every 1 hour instead of after every donation. @RamRamez
Per our discussion on the QF call today, we need to add a note in the UI next to the matching estimates that says "Matching estimates updated every hour" OR add the timestamps of the last update, and prediction for the next update.
For reference, here is how Gitcoin handles it, with specific timestamps:
@mosaeedi Are you able to help with a design for this note next to estimated matching?
This is related to matching improvements to better represent COCM: https://github.com/Giveth/giveth-dapps-v2/issues/4251