in reply to Re^2: Disabling keyboard input
in thread Disabling keyboard input

While I'm not at all convinced (hey, if he can only fill in the result after getting the result, why do you need to wait?), I'd suggest looking into bindings for curses, at least on Unix-y systems.

Replies are listed 'Best First'.
Re^4: Disabling keyboard input
by hegotf (Novice) on Aug 09, 2011 at 14:51 UTC
    He can omit the task and made up the result as well, but if he will have spare time, it should encourage him to fulfil the task as instructed.

    Perhaps the pause will become a natural pace of his work.

      If the questions are at all predictable, then the operator probably knows some of the answers before the questions are asked, even if it involves doing a task. (Odds are good that there are quite a few questions/tasks that can and have been parallelized.)

      As for unpredictable questions though, I've seen such things in the form of randomly asking "Is {randomThing} {randomState}". That is very annoying, and you spend more time parsing the question and worrying about double negatives than you do actually checking the component.

      If there is a problem with people not doing their jobs, perhaps the question should be directed to your HR department?