Added ⚡️ content to to Onboarding > Funding a wallet #2

[Bosch-0]

⚡️Live preview

Added Lightning content to the Funding a wallet page in Onboarding. Big thanks for @pavlenex for the feedback / guidance!

Closed #569 in favor of this. Made a lot of changes based on feedback on that PR as well as going over the request page made me re-think a lot of the content here.

This page focuses on the funding flow of a standard non-custodial mobile Lightning wallet that does not use any Lightning services. I have a sub-page called 'Lightning services' for this page that is almost complete and will be up once this PR is merged (as feedback here will effect that page). That page will cover the same funding flow but using Lightning services.

Lightning services obviously give the superior UX, should that be the primary application we are designing for? Wanted to discuss this further with you all. For now I think it's good to have both wallet types laid out (with and without LN services) until there is easy plug-and-play Lightning services tools around (Dunder / Blocktank are making strides here).

Also moved this page to be after First use in this chapter closing #550

Closes #518

[pavlenex]

Great work. I forwarded a bit of feedback via Slack already, I think this is good foundation that we'll have to clean up an simplify just a little bit, but the meat is there and it looks good, so do illustrations. 🚀

Below are few minor suggestions and a question.

[GBKS]

This has become quite a complex page with the Lightning addition. I think you have all the right pieces here, but I find that the writing could be polished a bit further, and the page could flow better.

I left a good amount of feedback to simplify sentences. While reading, I tried to pay attention to smoothly I could parse the content, and there were various sentences I had to reread. That's where I left the comments.

Note that you used will 14 times and should 17 times. I think you can avoid most of them and be more direct.

I think this page could benefit from a flow chart, or you could consider moving the overview at the bottom to the top of the page. I found it difficult to follow the flow through the written text. Creating that mental map of the user flow at the top could help readers fill in the details as they read.

Another idea, how about using our Fact/Tip/Recommendation box style for pointing out the benefits of Lightning services? That way it's super easy to identify those pointers.

[sbddesign]

Thanks for all the hard work on this page @Bosch-0. I spent a lot of time reading this page. I think the initial opening of channels is turning out to be one of the most challenging topics in Lightning.

• There are a couple of typographic and grammatical suggestions
• I think moving the completed user flow closer to the top will help the reader
• I encourage you to look at the example user flow and consider what can be removed from each frame.
  • Does a new user need a block explorer link?
  • Does a new user need to know what a Lightning node is?
  • Should a user be allowed to send/receive when initial block filter sync is still happening?
  • These are all my opinions; they could be wrong but I raise them for consideration.

Thinking ahead to the future: I think we should try mapping out a similar funding flow with different types of LSP scenarios. Separate PRs, perhaps.

[sbddesign]

Hardline view: users should not be allowed to generate an on-chain address until block filters have synced for the first time.

I have witnessed a problem with wallets where you send money to the wallet, and then don't see it for several hours due to block filter sync issues. That's fine for me personally; I grasp the concept of "still syncing" and "go check a block explorer if in doubt". I just fear that's too much for onboarding a new user.

Thoughts, anyone? Is my viewpoint too radical?

[Bosch-0]

@sbddesign @pavlenex @GBKS

Hey guys, I addressed mostly all your feedback with the latest commit. Let me know what you think of the changes :)

I removed the How it works section as that seemed a common point of confusion. It's probably better to explain these things when the user gets to the stage where they are relevant to understand.

[GBKS]

This screen is very busy and lacks a clear call-to-action for newcomers. I'd put up a big "Send your bitcoin to the address below" title. I'd also remove the completeness indicator, makes me think that I can't send the bitcoin yet. Also think the note about the channel and the "What is a channel?" link should be right next to each other.

[Bosch-0]

Made some changes, what do you think?

I think letting the user know that their funds won't appear until that sync is complete is very important. I re-worded it so it's clear you can still fund while it is in progress.

Having the user think their funds have gone missing is a bigger problem to avoid than thinking they can not fund straight away. Though as mentioned above you can explain that they can still fund while the sync is in progress with some copy.

[GBKS]

Quick mock-up for simplifying this.

[pavlenex]

@GBKS @Bosch-0 Should we update the mock or is this something we can want to do in a follow-up? Would be cool if we can get this baby merged if everything else looks good. I like the simplified version.

[Bosch-0]

I think this misses quite a lot of important things - if a channel is being automatically opened the user will have less funds available once that happens. If it is not explained that a channel will be opened I'd imagine they would be confused as to why they received less. I like the way the network sync is presented though. I'd have to change quite a few things if I used the above image so maybe add these in a follow up? idm

Can you share the Figma file for this @GBKS

[pavlenex]

Yup, just asked @GBKS and we agreed this is better suited for a follow-up and some explorations. We can even invite people to post their own solutions in a workshop kind of. format after providing a case for it. Just an idea, but can be just a simple follow up PR.

Let's merge this baby 🚀

[GBKS]

I think that channel opening info + fee should be explained in a separate page that comes before this invoice screen. It's just too much for a single screen.

[GBKS]

Would be cool to have a custom icon here that reflects what is happening.

[pavlenex]

I really like the flow-distinction and the direction in which this PR is heading. I have a few suggestions bellow 🎸

[pavlenex]

I'm thorn on this. On one hand, we saw on wallet review calls that indicator in the corner is not always obvious to users. Is there a better way we can tell users that they'll need to wait? Because if we show a funding flow without telling them they'd need to wait, I assume then they won't be able to perform a funding action?

[Bosch-0]

Addressed everyone's comments, requesting another overview / ACKs :) @GBKS @sbddesign @pavlenex

[pavlenex]

Good improvements, I re-read the page top to bottom again, and discovered some inconsistencies, and was a bit confused with the Send bitcoin section.

Some of these are simply question and come from my misunderstanding of the desired flow perhaps 😄

[Bosch-0]

Made some more updates based on feedback, requesting (hopefully) a final review

[pavlenex]

@Bosch-0 LGTM, just a ⚡ Pay-to-open info box is duplicated twice in text, not sure if that's intentional or not. Also you should resolve image conflicts so we can merge it in.

I think this page is in a shape where we can get it merge, but it'll likely need some tweaking once all pages from the pending PR's are there. We'll also need to get some hands on feedback from people to see if things are clear enough, since it touches quite a few new(technical) concepts.

[Bosch-0]

Some more changes added, re-worked a few things which I think has made it more clear on the automatic channel open part - still need to discuss this further though we should follow that up in another PR.

Fixed conflict also

[GBKS]

ACK. I'd like to review some of the UX choices in our Payments follow-up task to ensure consistency across the pages, and also update the UI kit to include all the best practices we've outlined.