13 standards
The part a reader of the specification never sees: the first run, the sign-in surface, how long a prompt may sit waiting, and the things a user should never be shown at all. Mostly written as guidance rather than as a wire format.
Also searched as UX, onboarding, sign-in, login, friction, prompt, address, usability.
13 standards, spread across 4 of the 12 topics.
A new arrival meeting a sign-in screen that assumes they already have a wallet simply leaves. This organises the options so the familiar route is offered first and the wallet route is there for those who have one.
Filed under Opinions
User experience is the main subject of these 8.
Bitcoin addresses were meant to be temporary scaffolding and instead became the thing users are asked to handle. This argues that showing an address to a person is a failure of design, and looks at what ought to replace it.
Developers building on Bitcoin keep designing the same flows from scratch. This collects the user experiences worth getting right, as a reference to work from rather than a specification to implement.
Asking someone to create an account and back up a key before they have seen what an application does loses most of them. This starts them with a temporary key straight away and offers a proper one later, once they care.
A new arrival meeting a sign-in screen that assumes they already have a wallet simply leaves. This organises the options so the familiar route is offered first and the wallet route is there for those who have one.
Every chat-style client invents its own commands, so what you learn in one is useless in the next. This fixes a common set of verbs that behave the same way everywhere.
A visitor with no wallet lands on an app and has nowhere to go: pick the one wallet the app happens to recommend, or leave. Nobody is paying to get that person set up, so sites either force a single choice that quietly favors one vendor or lose the visitor at the install step. This describes how an app can offer a real choice of wallets and let vendors compete to fund the newcomer's first wallet, without the amount being readable or harvestable by bots.
A web app can only find the Bitcoin wallet running on a user's own computer by poking a handful of local addresses, and newer browsers treat that poke as suspicious and interrupt the user with a security dialog that never mentions the word "wallet". If the user clicks the wrong button, nothing explains what just happened, and the browser locks out that discovery permanently for that site. This leaves developers needing a way to prepare the user before that dialog appears, so a refusal is recoverable instead of final.
When a wallet request fails, today's wallets each write their own error sentence and hand it straight to the app, which has no choice but to show it to the user unchanged. That sentence rarely says whose fault the failure was, whether trying again is safe, or whether the payment might actually have gone through anyway. The result is users double-spending after a timeout, support tickets full of mismatched wording, and apps that cannot translate or shorten a message they did not write.
These are about something else, and deal with user experience on the way.
Sharing where to send a payment usually means copying a long key and hoping it survived the paste. This packs the recipient and an optional amount into a single link that can be sent, tapped or turned into a QR code.
Right now if you run two wallet-enabled apps on the same computer, or try to use your phone's wallet from a desktop browser, things break: one app grabs the only expected port, or whichever wallet loads last wins and silently takes over. There was no agreed way for an app to see what wallets are available, let the user pick one, and keep that choice stable without accidentally scrambling which wallet handles which connection.
An app that wants to greet a returning user by the name of their wallet account has no way to ask the wallet what that account is currently called, so it either guesses, hardcodes a vendor name, or stays silent. This leaves users confused when the same account shows up under different branding across apps or over time. A small, optional way to carry that label alongside the version string the wallet already returns solves this without adding new wallet methods."
An application asking a wallet for permission gets an error if the person does not answer straight away, which is unfair to anyone who stepped away. This says the request waits for them rather than timing out.
Giving someone their first on-chain item requires them to have a wallet and coins, which they do not yet have. This lets a publisher fund it in advance so the recipient becomes the owner by clicking a link.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic