[Design] Onboarding Wizard 1.0

[Bosch-0]

Overview of current on boarding process (old top, new bottom).

1.0 Problems

In general, the on-boarding is very limited / almost non-existent. Having an on-boarding process is one of the best ways to educate users about features (wallet / node) and other more general info (privacy / security practices). Currently the user is thrown into the deep end with the GUI without a clear explanation as to what is going on or what steps to take next.

No option to select the users language exists in the current on-boarding. Having this as the first option will significantly improve the UX for non-English users (the current default language). Currently, the only way to set language is within the GUI itself which means non-English users will likely miss the current node info welcome screen.

Details such as what is the Bitcoin core GUI, what is a node, why should you run a node, and what is a pruned node are not clearly articulated / given the importance they deserve in the current welcome screen. This is mostly due to a cluttered UI and unclear explanations. #26

2.0 Solutions

This on-boarding process is only gone through when the user launches the GUI for the first time after installation. Each design has had a cleaning up of its UI. Design specifics (padding, margins, fonts etc.) can be found in my figma design source files - feel free to leave comments on figma directly by clicking the speech bubble in the top left and clicking the part of the design you wish to comment on.

2.1 New Welcome Screen

This new welcome screen gives a simple explanation to the user what the GUI is. Although this might seem trivial I've seen some users who have downloaded the GUI still unclear on this point. The download page on bitcoincore.org/en/download does not explain the features of the GUI so I understand the confusion some may have.

2.2 Your Full Node Screen

3.0 Extra

Why am I doing this in versions?
Breaking up designs into more manageable steps, much like using atomic commits, make things easier from an implementation perspective. V1 is primarily a content re-work and does not involve any major technical changes.

V2 (WIP) will have basic wallet creation embedded. Currently the GUI automatically creates a default wallet on launching without prompting the user it was created or giving them any details about wallets which can lead to a lot of confusion bitcoin/bitcoin#15454. The create wallet flow for the on-boarding will be similar to what I have done here #77

V3 I'd like to explore having HWI and other more complex ways to load and create wallets.

Design constraints
The Bitcoin Core GUI uses Qt Widgets which inherits most of its design components from the host OS, this design was done for WindowsOS but should translate nicely to MacOS and Linux. If people would prefer me to do these designs in Linux or MacOS instead please let me know.

Figma source file

[jonatack]

Concept ACK!

• I think you are right to break these changes down to manageable steps
• Maybe define GUI on first use (Graphical User Interface)
• I suggest referring to this style guide for Bitcoin-related writing: https://github.com/bitcoinops/bitcoinops.github.io/blob/master/STYLE.md

[promag]

Concept ACK, to improve the current GUI.

[Bosch-0]

@jonatack Made that small change regarding the GUI - complete beginners are unlikely to know what that means.

Thanks for that resource also, have not come accross that before!

[jb55]

Concept ACK, looks great!

[michaelfolkson]

Concept ACK, visually looks great.

What sort of feedback are you looking for @Bosch-0? I'm assuming wording can be edited at a later stage so you aren't looking for wording feedback. I'd have a couple of suggested edits on wording.

Ideally you'd condense the two screens into one but with all the information you're presenting and in the interests of keeping the first screen relatively clean two screens definitely makes sense.

[Bosch-0]

Wording feedback is more than welcome, especially so considering this is majority a content re-work rather than an addition of features.

As this is one of my first design contributions I'd like some feedback on how I have presented this, is it clear to everyone the problem I am addressing and the solutions offered? What could I do better? What is unclear? Do you want more visual representations, more words or all of the above? For example I could include gifs to show how the flow works more clearly (I will update OP with one for this flow soon) - is this useful?

Feedback on features I may have missed / you think should be apart of this flow is also very helpful (see my discussion with achow at #77). Descriptor wallets was something I was not too familiar with and did not include in my original design but should have. Some technical changes are over my head and I don't grasp right away how they would be implemented in a UI.

[jonasschnelli]

Looks nice. Concept ACK.
Always be careful with the maximal height. Other languages often need more space than English. Make sure it won't break small monitors (1024x768; max height should be below 768). Ideally make the window resizable and have options to scroll or show/hide layers or additional info windows.

[ncoelho]

Concept ACK.

Does the user need to choose the language or can the system language just be used by default?

[Bosch-0]

Some updated designs based on feedback [WIP]:

Global changes

Did some branding updates based on discussions on issue #89. Changed link colors, launch screen logo, top menu icon and logo displayed on welcome window.

Cleaned up the UI slightly, re-worded most of the content only detailing what is relevant to end users with links to deeper dives for those interested.

Your bitcoin full node window

Standard mode
This is just the standard mode currently used in the GUI.

Quickstart mode
@jonasschnelli mentioned here about having a block-filters/SPV mode enabled whilst the IBD happens in the background - is this technically feasibly? This would be a major UX improvement but doesn't come without downfalls which I've communicated in the modes description. If the user selects this option maybe connecting via Tor should be on by default to prevent IP leaks until the IBD is complete (which the user would then switch to normal peers through their own node).

Node settings window

Listed 4 config options most relevant to end users / should be considered prior to beginning IBD. Bear in mind this is targeted at more beginner users, advanced users will likely edit .config file themselves (which I have included a link to more advanced config options at the top).

Bitcoin blockchain directory
Included in previous design, many end users may not have the 500GB free on their main drive (likely an SSD these days) and may want to move it onto another drive. Also included a small tool tip to the right of the change button indicating the available storage in selected drive. User should be prompted if not enough storage is available in the default directory and be unable to click 'launch,' see below:

When enabling pruned node the full IBD still occurs before old blocks are discarded correct? I initially thought instead of not letting the user go forward if they do not have enough storage it could auto-select prune node but this would not work based on my understanding.

Limit node storage
Renamed 'Prune node' to 'Limit node storage'. To an end user limit node storage communicates more clearly what it is they are doing when taking this action. Pruning sounds ambiguous to those not familiar with the term in the context of a blockchain. I also clarified that when you limit storage (prune) you are limiting to a set amount of history (a year in my design, see below).

There is also a UX issue with importing old wallets with a pruned node - is there an ideal pruned size that caters to majority of users? I put a years worth of transaction history (~50GB) as a placeholder for now based on this thread - reference. This is something I'll do some more research on.

It may be worth changing how pruned nodes are communicated in the internal settings as well - e.g. instead of 'prune block storage to xGB' it could say something like 'Only store blocks in from the past x days (or years).' I'd assume users are more likely to know that they had transactions from a year ago than ~50GB of blocks ago. I've heard some issues raised that prune nodes only store tx's relevant to the user (disregarding history) which is not the case - this should communicate how it works more clearly. Though this is an issue for another time.

Launch on startup
A common UX headache myself and many others seem to have is that if they do not have core running all the time so when they go to send or check a received tx they have to wait to sync with most recent blocks first. This can be especially painful if you use bitcoin as a SoV and rarely transact. Having this selected by default will likely alleviate this issue without too much issues for the user - I'd imagine hardware constraints aren't a huge issue for people running core on a desktop or laptop. You could even take this a step further and have it now shown and on by default.

Connect via Tor
As mentioned above, should this be enabled by default if the user clicks quickstart mode? Having to download Tor separately is likely going to be an issue for many users (they will just skip over it and get a false sense of privacy if clicking connect). Still unsure if this should be an option presented to end users for these reasons but privacy should be paramount.

I'd imagine this may be out of the question but could the GUI be shipped with a tor executable similar to wasabi's setup? Maybe even take things a step further and have separate binaries fom the CLI and GUI (GUI ships with Tor for default, no config privacy)? An example of a project that separates the two is Monero - https://www.getmonero.org/downloads/

There is a lot of UX decisions to digest here, looking forward to everyone's feedback!

Figma source file

[Rspigler]

As I've told you previously, love the design!

Some comments:

The About Bitcoin on 'Page 1'? (not the correct terminology) links to Bitcoin Wiki; the Learn More/click here buttons on 'Page 2' and 'Page 3' link to Bitcoin.org. Is there a page on the Bitcoin Wiki we could link to instead?

On Page 3, Under Limit node storage: "...Importing wallets older than a year may not show correct transaction information, increasing node storage may fix this." Perhaps: "...increasing node storage or reindexing the chain should fix this.

There is no info about the option to prune a node until Page 3 (and on Page 2, it currently says "A full copy of the Bitcoin blockchain (~350GB) will be downloaded). I am concerned that this will have users cancel the install before realizing that there is an option for people with limited capacity.

When enabling pruned node the full IBD still occurs before old blocks are discarded correct?

Pruning actually works by deleting bock files 'as you go'. For more in depth info, see the release notes from the initial version (v0.11.0).

I agree that the 'Connect via Tor' is tricky. I too imagine that shipping with Tor is not going to be accepted (and for good reason). It is being worked on with PR's like #86 . That currently helps users identify when their connections are behind Tor, but hopefully a PR can be built on top of that to help more easily set such a connection.

[Bosch-0]

Thanks!

The About Bitcoin on 'Page 1'? (not the correct terminology) links to Bitcoin Wiki; the Learn More/click here buttons on 'Page 2' and 'Page 3' link to Bitcoin.org. Is there a page on the Bitcoin Wiki we could link to instead?

They're called frame's on Figma but page is also acceptable. The guides laid out on bitcoin.org for running your node and changing its config are much better than on the Wiki. The wiki mostly just gives info about the not not instructions on setting one up. I guess the 2nd frame could link to https://en.bitcoin.it/wiki/Full_node but for the config (frame 3) bitcoin.org does a much better job. I'm planning on doing some content rework on bitcoincore.org so eventually links will all go there.

There is no info about the option to prune a node until Page 3 (and on Page 2, it currently says "A full copy of the Bitcoin blockchain (~350GB) will be downloaded). I am concerned that this will have users cancel the install before realizing that there is an option for people with limited capacity.

That is a good point, I'll make this more clear thanks! My thinking has evolved quite a bit since starting this design and will likely be changing it quite a bit (often the case with design work!).

I agree that the 'Connect via Tor' is tricky. I too imagine that shipping with Tor is not going to be accepted (and for good reason). It is being worked on with PR's like #86 . That currently helps users identify when their connections are behind Tor, but hopefully a PR can be built on top of that to help more easily set such a connection.

I'll likely leave this out of the on-boarding in future designs. Having some sort of 'privacy checklist' internal to the GUI would be a better way to communicate this to end users. Also just making it more clear in the settings.

Also updated the link to my Figma file in the OP.

[Rspigler]

I'm planning on doing some content rework on bitcoincore.org so eventually links will all go there.

Sounds great!

That is a good point, I'll make this more clear thanks!

Awesome!

Having some sort of 'privacy checklist' internal to the GUI would be a better way to communicate this to end users

Yes, I started trying to talk through this in #110 , and it definitely gets complicated with all the network options. That is one good way to do it.

[gwillen]

Coming fairly late to this (I saw it linked from another issue), but one driveby comment: I think "IBD" may be too jargony for the GUI, honestly. Omitting it might make the text easier to read, without really making it much longer or any less precise:

"begin your IBD" -> "begin downloading the blockchain"
"conduct a[n] initial block download (IBD) and verify all blocks in the Bitcoin network" -> "download and verify all blocks in the Bitcoin blockchain" [noting that this wording was also discussed above, since it is unnecessarily discouraging in light of the pruning option revealed on the next page.]
"The IBD can take several days" -> "downloading the blockchain can take several days"
"waiting for your IBD to finish" -> "waiting for the entire blockchain to download"

I guess a lot of the text does get a bit longer. But I think it's probably more user-friendly.

(Even as a very technical user/developer, I initially found the profusion of jargon quite challenging at times, when I first started working with Bitcoin. I expect this is even more true for less-technical users than I.)

[Bosch-0]

Good suggestion, will make that change once this is eventually returned too

[hebasto]

@Bosch-0
Could we move this discussion into https://github.com/bitcoin-core/gui-qml/issues?

[Bosch-0]

Yep, good idea! Any major design changes like this should be focused on QML.