Added ⚡️ content to to Onboarding > Funding a wallet

[Bosch-0]

Live preview

Added Lightning content to the funding a wallet page in onboarding.

This is an entirely new page and will likely need some revisions but I think it is pretty solid right now.

Closes #518

[sbddesign]

Awesome @Bosch-0, very extensive work here. I left some nitpicky grammar and style edits as usual.

Beyond that, I have two main topics I would like to discuss for this PR.

Exchanges, Rewards Programs, Etc.

I see you removed a lot of the stuff about receiving Bitcoin from an exchange as well as from gift cards and rewards programs. How does everybody feel about this?

Obviously, we're going down the LN mobile first path, so maybe the exchange topic isn't relevant. Should this type of content go on another page? Or just be deleted altogether?

Describe the use case better

I feel that the extensive technical detail of this page fails to capture the "why" of each funding method. Sure, user has to do steps 1, 2, 3, and 4 to fund a wallet with method X, Y, or Z, but why do they choose to do this? We are talking about "funding a wallet" in this highly abstract sense when we need to consider why the user is funding the wallet to begin with.

• With Lightning Services: to me, the use case for this seems like somebody whose goal is to start receiving bitcoin straightaway.
• Without Lightning services: to me, the use case for this seems like somebody whose goal is to start sending bitcoin straightaway.

I think each funding method should be accompanied by a description of these use-cases or user motivations.

[Bosch-0]

Cheers @sbddesign

I see you removed a lot of the stuff about receiving Bitcoin from an exchange as well as from gift cards and rewards programs. How does everybody feel about this?

I don't think it is that relevant. We should stay focused on the application design content not how it is funded. That UX should be handled well by the exchanges imo.

Could add some details in the areas talking about having on-chain and Lightning funding options and how you should have both as third-parties may not support receiving direct Lightning payments?

Great point about clarifying the use cases, completely agree. Will add something for that :)

[pavlenex]

I've reviewed this PR half-way through. Whoever reviews this needs to review it with #568 in mind, as the terminology used here was better explained on that page. There are some overlaps between the two pages as well.

This is great content, but I'm feeling that Funding a wallet may not be an appropriate page for this. As we discussed on yesterday's call, we need to think of a UX over technology and then suggest technology that makes that optimal UX possible.

The content @Bosch-0 wrote here is great, and spot-on but I think there's a distinction between the initial funding of a wallet and receive. I think a lot of what's being said in this page talks about technology that allows users to smoothly receive funds.

I think that a flow for initial funding vs receiving is different. That first initial funding is usually a person transferring Bitcoin from an exchange, redeeming a gift card, or simply having a friend who onboards them.

One thing that most of the wallets miss is how does a user obtain Bitcoin and I think that can be the goal of this page. Initial content talks about it, but doesn't mention the ideal flow.

For example, I've never seen a wallet that doesn't show Send until user received funds first. I've never seen a wallet that educates users on how to :buy or earn bitcoin. There are wallets focused on gaming to earn (Zebedee) and I think that's an awesome example.

I think there's a lot of space there for us to cover those flows on this page and tackle the problem on how does a user obtain bitcoin in the first place as I think many wallets in this space miss out on that.

@Bosch-0 what are your thoughts on this? I'm happy to team up on this one and help. As I think for this PR to happen we need to think of it in context of LSP PR #532 and Receive PR #574

[pavlenex]

I think zero confirmation is clearer here? And it's already used term in wallets like Breez.

Suggested change

	* Spend-unconfirmed so users can send and receive as soon as their wallet is funded without having to wait for the on-chain transaction to confirm.
	* Zero-confirmation so users can send and receive as soon as their wallet is funded without having to wait for the on-chain transaction to confirm.

[Bosch-0]

They call them turbo channels in Breeze, which I'm not a fan. Zero-confirmation doesn't really give much of a description to what that service is offering. Spend-unconfirmed is used by Phoenix and I think is a bit more descriptive to what the service is actually enabling.

[Bosch-0]

@pavlenex thanks for the thorough feedback! I agree that a distinction between funding a wallet and receiving bitcoin needs to be more clear.

I think that a flow for initial funding vs receiving is different. That first initial funding is usually a person transferring Bitcoin from an exchange, redeeming a gift card, or simply having a friend who onboards them.

I think there's a lot of space there for us to cover those flows on this page and tackle the problem on how does a user obtain bitcoin in the first place as I think many wallets in this space miss out on that.

I agree with adding some content around obtaining bitcoin but still think we should cover some of the more technical aspects of the bitcoin hitting the wallet. Lightning services are actually the most valuable when funding a wallet then when doing generic requests. The flows will be slightly different from the ones that will be in the requesting bitcoin page in payments and won't focus on Lightning services as much as this page.

One thing that most of the wallets miss is how does a user obtain Bitcoin and I think that can be the goal of this page.

That is only part of the funding flow though, if that is the goal I would call a page like that "Obtaining Bitcoin." Rather than "Funding a wallet."

I've got some ideas how to find a good middle ground, will push some updates today :)