Slow and confusing initial wallet loading

[thibistaken]

Initial wallet loading is taking a long time (over 60 seconds!) before showing any time estimate for completion. No details are provided to educate the user in terms of what is happening in the background.

As a user who may not be knowledgeable about bitcoin and Wasabi, I worry that block chain data is being downloaded. I don’t know how much bandwidth or disk space is required in that case. How much longer will it take? Is the wallet bugging right now? What is going on in the background? Am I even doing this right? What if I shutdown the wallet during the sync, am I going to be losing any data? After 2 minutes, a time completion estimate is shown on the screen with a progress percentage score, which feels better than before. Why not show it right away on start up?

These questions are opportunities for Wasabi to inform the user on loading with perhaps clickable links to the documentation about this particular step, or by providing bite-sized content for the user to learn. In WW1, I remember we could see that block filters were being downloaded, Tor initialized, and so on. Why not show that and add links to explain what Tor or bloom filters are? The map with bitcoin icon animations is great but perhaps occupying too much real estate compared to the value it brings to the user? If we know that an average a user has to wait for 60-90 seconds on that screen, this is a great time to educate them on coinjoin, Wasabi, etc.

How To Reproduce?

1. Just open an already created wallet and wait

Screenshots

[MaxHillebrand]

@turbolay is on it with #9063 #9071 #9079 #9080 #9082

Search for "BLOCKS DL" https://github.com/zkSNACKs/WalletWasabi/pulls?q=is%3Apr+blocks+dl

[turbolay]

@turbolay is on it with #9063 #9071 #9079 #9080 #9082

Search for "BLOCKS DL" https://github.com/zkSNACKs/WalletWasabi/pulls?q=is%3Apr+blocks+dl

Please note that my PR are not related to this:

Initial wallet loading is taking a long time (over 60 seconds!) before showing any time estimate for completion.

This because of Tor/Backend/P2P Nodes initialisation/BlockchainAnalyzer takes an extansive amount of time, and especially if you're on an HDD.
It's indeed more an UI issue or the Analyzer

It's a separate issue, but imho the time estimate is also not really good. We cant have a precision to the second, so why try to give one? The time jumps, go up etc its not a good UX. It would be better to just display: Estimated time to completion: ~35 minutes, Estimated time to completion: <1 minute

[soosr]

It's a separate issue, but imho the time estimate is also not really good. We cant have a precision to the second, so why try to give one? The time jumps, go up etc its not a good UX. It would be better to just display: Estimated time to completion: ~35 minutes, Estimated time to completion: <1 minute

Even the minutes, moreover in some cases the hours can also jump, All depends on the download speed of a block. So hiding the seconds won't fix it.

Initial wallet loading is taking a long time (over 60 seconds!) before showing any time estimate for completion.

It is because it is only displayed when the percentage > 1%, it could be easily changed in the UI code so the time estimation would be visible instantly.

[thibistaken]

Three solutions were previously discussed:

1. Get rid of the loading page entirely and bring the user into the main wallet page. This would require too much refactoring of the code to ensure nothing breaks. Not being considered at the moment.
2. Improve loading speed as much as possible. This is what @turbolay is working on in other issues referred to previously in this thread.
3. Leverage the wait time on the loading page to educate the user. Something that could be done would be to include educational content with bite-sized information about coinjoins, bitcoin privacy, fungibility, history about chaumian blinded signature, etc.

Options (2) and (3) are not mutually exclusive, could be quite valuable as UX improvements, and seem to require the least amount of dev work. I could perhaps share some ideas for (3) to explain better what I mean.

[stale]

This has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[MaxHillebrand]

closing in favor of other standalone issues.