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

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.)

Replies are listed 'Best First'.
Re^4: Disabling keyboard input
by hegotf (Novice) on Aug 09, 2011 at 16:34 UTC

    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.