Type Through a Straw
It’s time to log in to the system to do the thing. You’re doing this on an input-constrained device: a TV streaming box, video game system, a printer, or something else that can’t offer a regular typing experience. Maybe you’re trying to watch a show, maybe you’re trying to get your washing machine to send you a push notification when it’s done. But it wants you to enter your full login credentials on the potato quality built-in input: the remote control, the up/down buttons, the rotary dial.
After a few minutes, you manage to enter the password, with all its variety of capital letters, numbers, and punctuation, but the system rejects your login attempt. Maybe you made a typo somewhere.
You resolve to one day live in a cabin on a mountain, far away from anything involving computers or the internet.
Whatever the excuse, trying to input login credentials on a device not meant for textual input is among the most frustrating login experiences possible, especially as it’s often paired with Context-Ignorant Visibility.
If you’re trying to log into an app on a device already connected to the internet, there is device code flow. The idea is, you launch the app on the device, it obtains a code from the server, you visit the shown URL on a device you can actually type on, enter the code, then authenticate as normal, authorizing this device. It’s part of OAuth 2.0 and fairly well-trod territory.
Device code flow is unfortunately a popular target for phishing, at least for Microsoft 365 accounts, which for some reason allow this authentication method to ask for broad permissions. I am not going to propose ways to defend against this, but it strikes me that at the very least the code flow link should provide some geo ip location about where the request originated from.
On the Apple TV hardware at least, there is the possibility of delegating complex input to a nearby iPhone signed into the same AppleID account. This is still modestly frustrating as in my experience it doesn’t seem to be compatible with paste or autofill; in this case I’ve had to lookup the credentials that need entering on another device and enter them on the iPhone, all while a) not letting my iPhone go to sleep, and b) not letting it get too far away from the Apple TV hardware. Compared to using an on-screen keyboard with the much-maligned remote, it’s not much better.
Non-computer hardware is a bit trickier — we have a modestly old laser printer, and connecting it to the wireless network involves typing in a password by pressing up/down buttons to choose a character, and forward/backward buttons to advance or backspace the cursor. The last time I changed our wireless network credentials, I gave up and moved the printer to a location where it was more convenient to connect to the network via cable, only to find out the printer only works with Airprint when connected via wireless. This is a terrible inputting experience, but it’s a printer, what did we expect.
We have a robot vacuum that connects to the wireless network through a special mode that provides its own wireless network that exposes through the network login portal an interface to choose and log in to other wireless networks. While this is much better, it’s still somewhat fiddly, because we have to juggle network connections on another device.
Maybe the best experience we’ve had for connecting devices to our network is for the device to have a mode which makes itself available over bluetooth, which an app then uses to input credentials for the wireless network. While this could get into Use the App territory, the home devices we have which are not printers are ones where network interaction primarily happens through our phones anyway.
If people need to authenticate something with your system on an input-constrained device, or you are creating an input-constrained device, please invest some effort into providing a less-frustrating experience of authenticating.