Discovery needs visible progress and failure reasons
Aliases: device discovery · scanning for devices · discovery timeout
What it is
“Find nearby devices” spins for a minute, the list stays empty, and there is no timeout or why. Waiting, stepping closer, or giving up are all plausible. Discovery needs progress and a failure reason: a scan is a process with a start, work in progress, and an end, and the end must split “nothing nearby to join” from “this side cannot scan.” An endless spinner turns discovery into unbounded waiting. This is after the pairing wizard is already open. It is how the scan stretch accounts for itself, not how expensive first-time pairing is, and not the system copy inside a permission dialog.
Why it happens
Discovery is a sample of radio or LAN, with physical duration and range. People cannot see the radio; they infer from the UI whether the system is looking. An infinite spinner means “perhaps the next second,” so waiting outruns the real scan cycle. Progress that can end turns sampling into a closed action: first “listening for Bluetooth advertisements / scanning TVs on this network,” then, if empty after a few seconds, “no devices found,” plus the most likely next step (move closer, wake the other side, retry). “Not found” alone still sounds like a broken device; “scan finished; no receiver is advertising in range” lets waiting stop. When a device appears mid-list, mark “still looking,” or people treat the list as complete and tap the wrong box.
Studying it
Give the same discovery task to people who have paired this set and people who have not. Manipulate scan feedback: endless spinner, bounded progress, whether the empty state names a reason.
Independent variables: timeout or not, indeterminate spinner versus staged progress, whether empty results split “no device” from “cannot scan,” a powered-off target and a powered-on target placed nearby on purpose. Dependent variables: excess wait, early abandon, rate of taking the right next step on empty (power the other device / move closer), taps on the wrong nearby device.
A lab with the target on the table and awake undercounts “not found.” A harder probe puts the target in another room or off, and checks whether the UI still looks like “still searching.” Do not put pairing completion rate and discovery wait on one table—the first is the barrier, the second is process visibility.
Where it stops holding
Devices that advertise themselves in a factory window (lid-open headphones, a dongle just powered) appear almost instantly; a progress bar is surplus, a brief “found” is enough. Security-sensitive discovery (do not list the neighbour’s computer name) may give few details, but timeout and “not found” still have to exist. A continuously listening surface (a sidebar of “nearby devices”) is not a one-shot scan and should not wear a start–end progress model; show when the last successful sighting happened instead.
Applying it
- Give every lookup start, in-progress, and end. In progress, name the channel (Bluetooth, same Wi-Fi, account-online devices). Never end on a spinner.
- Split empty copy: “no connectable device nearby” versus “this device cannot scan right now.” The latter points at a changeable condition; the former at retry and checking that the other side is on.
- Bound the scan; when the bound hits, end and allow one-tap rescan rather than spinning forever.
- Verify by starting a lookup with the target off: the UI must end in bounded time and say not found. Power the target and look it up again; it should appear during progress or at the end. An unexplained infinite spinner anywhere in the path is a fail.