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

Yes, there is a reason.

Operator needs to do a specific task during that pause so only after finishing the task he can acullay fill in the result. So sleep function is required to encourage him to do his job properly.

Replies are listed 'Best First'.
Re^3: Disabling keyboard input
by Tanktalus (Canon) on Aug 09, 2011 at 15:05 UTC

    I obviously don't have enough information to be sure, as you're being quite vague (probably for good reason). But a lack of information rarely prevents me from chiming in :-)

    I have done the install software for more than one application over my career so far (I'm not saying that's what you're doing). While many in upper levels of management think "install" == "copy files, how hard can that be?", we took it as much more than that. Initial configuration has always been part of it. That is, we ask a bunch of questions which then tell us how to deploy. And here is where we get to what is likely relevant to you: we ask all questions up front only, and perform all actions after that completely automated. Don't make the user come back from a coffee break only to find that the activity is incomplete, waiting for their input. Allow them to go on their coffee break and come back to a completed activity.

    This often means that you need to automate more stuff. That's always a good thing, in my mind. It is more work up front, but generally pays for itself quickly. Sometimes in a year, sometimes in a week. And it generally improves quality: once you get the automation tweaked properly, it won't make typos or forget steps, like a human is apt to do (especially this human who is far too lazy and egocentric to do mindless stuff repeatedly).

    Maybe this isn't something that you know how to automate yet. And so, for now, you continue to harass the operator for information. In that case, I'd make a couple of suggestions. First off, don't annoy the operator any more than you already have to. Don't sleep. Don't ignore stuff she has already typed. Because the operator may already know what is next, and is likely smarter than your program.

    Second, your goal should not be further harassment, but further automation. Design decisions should be based on making things as painless for humans as reasonably possible, and eliminating error. Free the operator from the mundane things that computers can do so they can do higher-value things for the company, such as analysis or Sarbanes-Oxley compliance. (Sorry - that last one isn't high value for the company as much as for the public and/or politicians.)

      I'm a supporter of automation as well, but in my case there's rather some standarization issue to be done. You see, I work in a factory which produce electronic equipment and unfortunately this industy requires a lot of manual work.

      My current goal is to standarize Inspecion Point. Operator's job at that station is pretty hard becouse he needs to check a lot of details on a product and it is quite impossible to do it in less than a single minute time.

      Problem is: they finish inspection too fast anyway. I understand that new software isn't a whole solution to the problem and might not force some standarization of work, as planned but I believe that it will be a useful tool. For diagnostic purpose as well.

      And even if it won't work in a long run (and I'm aware that it's quite possible) I still consider it as worth of trying.

Re^3: Disabling keyboard input
by happy.barney (Friar) on Aug 09, 2011 at 14:33 UTC
    maybe it will be better to log time between responses and analyze them later
Re^3: Disabling keyboard input
by moritz (Cardinal) on Aug 09, 2011 at 14:39 UTC

    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.

      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?