Type This Way

It’s time to go log in to the system and do the thing. You try using your password manager to fill in the form, but unlike with No Autofill For You the form is now filled out — but the button to submit the form is still disabled for some reason. You focus the username field, hit the backspace key to remove the last character, and the field immediately becomes enabled.

Next you are presented with a prompt to enter a code for multi-factor authentication. For some reason, it’s not letting you paste the code from your clipboard into the field, so you have to type it. Since it’s numeric, and because you’re using a 101-Key Keyboard and like practicing your 10-key typing, you set about entering the code on your keypad, but no characters appear on the form. Stymied, you try entering it with the number keys above the letter keys, and those work just fine. Weird.

Whatever the excuse, reimplementing or overriding the behavior of standard form controls in either a web browser of native GUI is a difficult thing to do comprehensively. These affordances need to respond to a wide variety of input devices and methods of using them, and it’s entirely too easy for someone trying to reimplement these controls to either miss a particular case or decide that a particular method of use isn’t “safe” and therefore should be prevented.

Among the many conceits of programmers who believe they can do no wrong is the idea that there is one and only one correct and valid way to input information, and that is what the programmer believes is true and correct.

This often results in things I’ve discussed here previously such as Segmenting Fields and Choosing Counties, but it also results in wrongheaded ideas such as “it’s not safe to paste into an input”, or “we should validate there was keyboard activity to make sure it’s a person doing the typing”.

It can also result in incomplete implementations: instead of using <input type="number"> because the up/down spinner buttons don’t make sense for this control; disabling them is laborious and rather than doing client-side validation as intended (which often doesn’t yield the desired interaction patterns), one could instead decide to monitor the keycodes entered into the field to ensure they’re numbers. This can lead to only accepting the regular numbers typically found atop the keyboard (0x30 – 0x39) and rejecting Keypad Numbers (0x60 – 0x69). I have seen this in the wild, and I was at the time using a keyboard for which I had programmed to have only keypad numbers.

I’ve also seen – once, on a system meant for public use – an input that disabled typing into the field and forced people into using an on-screen keyboard, with the justification that “they might have a keylogger installed”. If you think your threat model justifies extremes like this, maybe your system shouldn’t be open to the public. I mean, keyloggers have been made into games and people will run just about any and all code. Why let anyone use the system at all?

Look, I get it – having the ability to control how an input affordance works makes it very tempting to prescribe how it should be used. In doing so you will invariably break something, even if it’s only the expectation that your affordance works the same as it does everywhere else.