It’s happened to everyone. You kick off a software installer, answer a few questions about how you’d like things set up, click next and you’re presented with a long progress bar. “No problem,” you think to yourself, “this is a good excuse to grab a cuppa joe.” You leave the computer to its business and hit the kitchen, maybe catching a glance at the paper. After some time has passed, it occurs to you that the installer’s probably been finished for a while, so you head back to your computer to start using your fresh new software. And then BAM! You get slapped in the face with just one last question that the installer needs you to answer. It turns out that it’s only partially complete, and when you click next again, you’re presented with another long progress bar. Now you’re faced with a decision: do you switch tasks again, or do you babysit the installer, in case it has another question?
This behavior drives me absolutely mad. I’m impatient with installers to begin with; they’re a hiccup (albeit a necessary one) between me and the software I want to use. Of course, it’s not just installers that suffer from this problem. Any piece of software that has to perform some kind of long-running task can be subject to this annoyance, simply by requiring user input anywhere except at the very beginning or end of a lengthy task.
The amount of frustration this bug causes is directly proportional to how long the task will take. I recall a recent mishap where I was installing an older Debian distro on an extremely slow ARM machine. I thought I had answered all of its questions, and left my office to do errands for several hours. I was confident that when I returned, the machine would be ready to go. Of course, you know how this story ends: upon my return, I found the installer waiting for input, and it took several more hours for the installation to complete. My work for the day was set back, and my schedule was thrown off.
Thankfully, the solution to this problem is extremely obvious: batch up and prompt for all of the necessary user input before starting a long running task. Never, ever interrupt the task to prompt for more input unless it is 100% unavoidable. If truly unforeseen circumstances do require user action, try to continue any work that can still be performed. If all of the work is dependent on the user feedback, consider continuing the work in the background by guessing the most likely user response. If the user shows up and enters a different response than the one guessed, back out the guess work and do the right thing. If the user is not present to see the prompt, at least there’s a chance that the long-running task will continue down the right path uninterrupted.
Comments are disabled for this post