Please Don’t Request User Input in the Middle of a Lengthy Task

Just Say No

It’s hap­pened to every­one. You kick off a soft­ware installer, answer a few ques­tions about how you’d like things set up, click next and you’re pre­sent­ed with a long progress bar. “No prob­lem,” you think to your­self, “this is a good excuse to grab a cup­pa joe.” You leave the com­put­er to its busi­ness and hit the kitchen, maybe catch­ing a glance at the paper. After some time has passed, it occurs to you that the installer’s prob­a­bly been fin­ished for a while, so you head back to your com­put­er to start using your fresh new soft­ware. And then BAM! You get slapped in the face with just one last ques­tion that the installer needs you to answer. It turns out that it’s only par­tial­ly com­plete, and when you click next again, you’re pre­sent­ed with anoth­er long progress bar. Now you’re faced with a deci­sion: do you switch tasks again, or do you babysit the installer, in case it has anoth­er question?

This behav­ior dri­ves me absolute­ly mad. I’m impa­tient with installers to begin with; they’re a hic­cup (albeit a nec­es­sary one) between me and the soft­ware I want to use. Of course, it’s not just installers that suf­fer from this prob­lem. Any piece of soft­ware that has to per­form some kind of long-run­ning task can be sub­ject to this annoy­ance, sim­ply by requir­ing user input any­where except at the very begin­ning or end of a lengthy task.

The amount of frus­tra­tion this bug caus­es is direct­ly pro­por­tion­al to how long the task will take. I recall a recent mishap where I was installing an old­er Debian dis­tro on an extreme­ly slow ARM machine. I thought I had answered all of its ques­tions, and left my office to do errands for sev­er­al hours. I was con­fi­dent that when I returned, the machine would be ready to go. Of course, you know how this sto­ry ends: upon my return, I found the installer wait­ing for input, and it took sev­er­al more hours for the instal­la­tion to com­plete. My work for the day was set back, and my sched­ule was thrown off.

Thankfully, the solu­tion to this prob­lem is extreme­ly obvi­ous: batch up and prompt for all of the nec­es­sary user input before start­ing a long run­ning task. Never, ever inter­rupt the task to prompt for more input unless it is 100% unavoid­able. If tru­ly unfore­seen cir­cum­stances do require user action, try to con­tin­ue any work that can still be per­formed. If all of the work is depen­dent on the user feed­back, con­sid­er con­tin­u­ing the work in the back­ground by guess­ing the most like­ly user response. If the user shows up and enters a dif­fer­ent 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-run­ning task will con­tin­ue down the right path uninterrupted.

Comments are disabled for this post