📱 Revise `Daily spending wallet` -> `Funding` page

[Bosch-0]

This issue will be part of a bigger milestone that focuses on revising the newly formed Daily spending wallet reference design we now have in the guide.

As discussed in the re-org discussions we wanted to do the below:

• Rename Funding a wallet (now just Funding) to Assisted funding refocused on spending wallet that use LSPs
• Make a new page called Manual funding which focuses on funding a wallet without an LSP.

I am going to attempt to have this as just one page called Funding as having two will likely lead to some overlap in content. But if the content gets too long it will be split into separate pages like mentioned above.

Will be doing https://github.com/BitcoinDesign/Guide/issues/744 before tackling this as it will be referenced quite a bit.

[Bosch-0]

For these revision pages the images should also be generally updated:

• Ensure they reflect what is shown in the UI kit
• Apply new modal formatting to images
• Remove grey area on the iPhone 'dip' at the top of the phone (see below).

[Bosch-0]

My review of this page

We should just call this page Receiving bitcoin and address https://github.com/BitcoinDesign/Guide/issues/691 as part of this issue. Having a funding, requesting and receiving page is inevitably going to include a lot of overlap. There are some slight nuances to consider compared to funding (e.g. a channel is opened by a LSP) and a general receive but they are small and could be addressed in one page.

This page should be moved to after Requesting bitcoin and both be before Backup & recovery. This is a more linear order of what operations a user is likely to take. They make a request (Requesting bitcoin - this page covers different ways this can be done), they receive some bitcoin (Receiving bitcoin - this page), now that they have bitcoin they should back it up (Backup & recovery).

• Remove the content around the user opening channels and focus LSPs conducting this operation. We can link off to the LSP section for the deeper dives on the topics to keep this page short.
• Remove content around on-chain expect in the context of swaps / channel closures (move this content towards the bottom of the page).

[GBKS]

Still think that funding and receiving are different enough. One is part of onboarding, about getting the user in a place where they can use the wallet at all and may require a more elaborate UX (and content like allowing users to buy bitcoin). The other is about more regular use and can discuss stuff like automated channel rebalancing. Definitely some overlap, but I think it still works if we remove some duplication, cross-link more, and are OK with shorter, more focused pages.

[sbddesign]

It seems like there is a lot of content on this page specific to onboarding and the first-use of the wallet.

[Bosch-0]

Still think that funding and receiving are different enough.

I don't think they are different enough to warrant separate pages. I was thinking of removing the buying bitcoin within the app. That seems out of the scope of this reference design and although good UX, is more of a biz dev thing imo.

automated channel rebalancing

We don't currently cover this, but auto re-balancing a leaf node (essentially a DSW that only has channels with one peer) isn't possible. You need a circular connection in order to shift balances dynamically, which these do not. Need to research this some more / think about how balancing would work in a DSW if at all. You could do a manual re-balance though using something like loop, but this would then require users to understand channel / have on-chain bitcoin which users of this type of wallets should not be concerned with.

It seems like there is a lot of content on this page specific to onboarding and the first-use of the wallet.

Yeah I think some of it could be moved to First use (which I suggested we rename to Onboarding)

[GBKS]

Yeah I think some of it could be moved to First use (which I suggested we rename to Onboarding)

Let's clarify the terms First use and Onboarding for ourselves. First use is pretty clear, it's the first time a person opens the app and starts messing with it. At the end, the wallet should be set up for consecutive use, so at minimum they should be able to receive bitcoin and ideally they also have funds they can send. I see onboarding as the larger process of making someone comfortable with a service, which considers earlier points in the usage life cycle, like learning about the product benefits on the website. It can also include later points, like ensuring users can easily navigate more complex features after repeat use (like getting people to use multi-sig when their funds grow).

Basically, I see onboarding is the overall process of getting people from zero to regular users, and first use is one (crucial) part of that. Would you agree or not? This would help us structure the content.

I was thinking of removing the buying bitcoin within the app. That seems out of the scope of this reference design and although good UX, is more of a biz dev thing imo.

I'd keep it, even if it's just a small note, as projects will very likely deal with this.

[sbddesign]

You need a circular connection in order to shift balances dynamically, which these do not. Need to research this some more / think about how balancing would work in a DSW if at all.

I think it's possible. Solution: the LSP opens two unannounced channels with the DSW so that it has a second channel to work with for channel balancing purposes. I know somebody is working on this very thing, but would have to check up on who it was.

The above may become unneeded if channel splicing becomes a thing.

[Bosch-0]

Basically, I see onboarding is the overall process of getting people from zero to regular users, and first use is one (crucial) part of that. Would you agree or not? This would help us structure the content.

I agree that first use is one crucial part of that. What is getting people from zero to regular users? This isn't clear to me. Do you mean regularly using the app, or educated enough to use it as intended? Or both?

I like how nn group defines onboarding which focuses on feature promotion (you can request and pay people with this DSW), customization (probably not relevant for DSW), and instructions (A small wizard when the user first requests or something). I don't think it has to encompass executing on a feature (e.g. requesting + funding the wallet), but leave users comfortable to take that action when they are ready.

I'd keep it, even if it's just a small note, as projects will very likely deal with this.

Yeah I was thinking of just having it as a tip box rather than frames showing it.

the LSP opens two unannounced channels

You could do this but it just makes scaling that much more complicated if everyone needs two channels to onboard. You can batch, or in the future do this as a small channel factory, and yeah splicing would solve this issue.

[GBKS]

What is getting people from zero to regular users?

Basically "Aware" and "Interested" in the Usage life cycle. Consider the new Bitcoin Core App. Even if we create the best app, if bitcoincore.org remains as is, people will still not know what it does, what benefits it provides, included features, etc.

[Bosch-0]

if bitcoincore.org remains as is,

Agree that the website / way the user gets to downloading the app are also part of onboarding. I think onboarding can be fine applied in the way I mentioned in my OP without having to encompass every aspect of it.