Software Needs to Focus

When you use a mouse or touch as input you automatically bring focus to everything you do. You’re literally pointing at what you want to do. And if the cursor is somewhere else it jumps to where you point, bringing the focus there.

In contrast, speech input users and keyboard-only users control the computer without explicitly pointing to where they expect those instructions to be carried out.

This often works well, because you generally know where the focus is – you can see the cursor blinking, see that something is selected, or, if there are multiple windows, see that one of the windows is active because it has a darker border. But the focus can change unexpectedly. And speech input and keyboard-only users can very easily make mistakes when the focus isn’t where the user expects it to be.

This happens alarmingly often, probably because a lot of software testing happens using the mouse, which doesn’t pick up focus problems.

If you select the link in the address bar of your browser, for instance, and the browser loses focus just before you copy it, you might not realize what’s happened until you’ve pasted the wrong thing.

Focus can change when a program does something in the background. Unexpected focus changes happen more often when users are frequently switching among programs. Using Dragon for speech input into another program immediately after you’ve changed the focus to that program, for instance, sometimes briefly takes the focus off that program so that the Dragon command doesn’t work.

So here’s a Dear Software Maker message: please think of speech input and keyboard-only testing as a sorely needed way to catch focus errors. And think of focus errors as an unwanted way to greatly annoy speech input and keyboard-only users.