WebLN
v0.3.2
WebLN
v0.3.2
Overview
IntroductionGetting StartedUX Best Practices
GitHub
Edit this page on GitHub
Edit

UX Best Practices

What follows are suggestions on how best to integrate WebLN into your Lightning app. These aren't strict & hard rules, just ideas on how to prevent your user from being frustrated or overwhelmed.

Inform & Ask Before You Prompt

Most of WebLN's methods will prompt the user in some way, often times to make payments or have them provide information they may feel is quite private. Before running requestProvider or other methods, make sure the user knows what your app does, and why they should allow your calls to run. Popping up as soon as they load a page will cause users to reject WebLN requests, or worse yet, bounce from your page.

Explicit buttons are ideal, but alternatives could be hiding pages behind loaders while requesting the user's provider, or keeping it to sub-pages and not having your homepage / splash-screen not require WebLN.

Don't Assume WebLN

WebLN is still a new spec, and a large portion of your users may not have a client that's compatible. Handle cases where they don't have a provider (See Errors for more info on error handling) and let them know how to get started with a WebLN client. This is also a good time to promote your favorite WebLN projects!

For simple use cases such as making payments, you can always just use BOLT-11 links instead of webln.sendPayment to have maximum compatibility with all types of Lightning clients.

Don't Assume a Particular Client

Anyone can make a WebLN provider, so don't assume the user is using a particular one, such as Joule or BlueWallet. Try to stay agnostic in your language about the user's client, e.g. instead of saying "Confirm the payment in Joule", just say "Confirm the payment".