¿Cómo se valida la entrada crítica que no puede ser examinada?

¿Cómo se evita que los usuarios creen conjuntos de entrada erróneos, cuando no hay una forma práctica de examinar la entrada?

La escena

Modifico un pequeño paquete ERP escrito en Visual FoxPro. Una parte del paquete se refiere a la impresión de manifiestos de camiones y facturas que se enviarán con los conductores en sus rutas de entrega. La rutina de impresión, cuando no se alimenta como entrada, intentará imprimir todo, lo que provocará que se desperdicien resmas y resmas de papel de impresora en una impresora de alta velocidad.

No estoy en condiciones de volver a escribir ninguno de los elementos de la interfaz GUI, ni puedo adaptar ningún marco, kit de herramientas u otro código externo para usar en esta situación. Las razones están relacionadas con la política de la oficina, no sugiera que pueda anular el marco ERP existente, ya que no es una opción para mí.

La cuestión

Los usuarios se encuentran en un entorno de alta presión y tiempo crítico. Cada proceso se mide en minutos o incluso segundos, lo que significa que tengo que minimizar el tiempo de procesamiento tanto como sea posible. Debido a este entorno y las posibles distracciones, los usuarios frecuentemente ignoran los cuadros de diálogo, presionando la tecla [Enter] que hace que el foco se mueva rápidamente a través del formulario y eventualmente aterriza en el botón de acción para el diálogo de entrada, lo que provoca que activen una impresión automática .

La entrada consta de un rango de fechas, un rango de ruta y un rango de orden de venta.

La entrada para el rango de fechas no se puede configurar automáticamente en "fecha de hoy", ya que se requiere una impresión posterior frecuente. Además, los usuarios finales trabajan durante la medianoche, es decir, el cambio de fecha hace que esto sea poco práctico sin manipular una rutina que detecte automáticamente el cambio, etc.

La entrada para las rutas no se puede codificar, ni se puede deducir de las rutas que ya se han enviado, ya que se requieren reimpresiones (ver arriba).

La entrada para pedidos de ventas solo tiene significado al imprimir pedidos individuales o rangos específicos.

Entonces, francamente, no hay una forma práctica de validar la entrada .

El botón de acción que activa la impresión no se puede bloquear. Cualquier sugerencia de que se coloque un cuadro de diálogo de bloqueo delante del usuario será ignorada. No tengo libertad para discutir por qué esto no es una opción, aparte del concepto que ya se ha discutido en otra parte del sitio (desde un punto de vista diferente) y fue rechazado.

El bloqueo de impresiones cuando todas las entradas están vacías se rechazó como una decisión de diseño ya que el software debe acomodar esto como una característica.

Los usuarios

Se ha pedido repetidamente a los usuarios que no hagan esto. Frecuentemente ignoran este consejo. Activar este desafortunado evento no es algo que sus capataces / gerentes abordarán, por lo que no hay presión para terminar con el comportamiento.

La organización

No tengo nada que decir sobre el flujo de trabajo involucrado, solo la modificación de los componentes de software existentes afectados por ese flujo de trabajo.

El vendedor

El proveedor obtiene el paquete en segundo lugar como una instalación personalizada del proveedor de software original. El proveedor requiere que se les envíen todos los cambios de código para su integración en su base de código. Los cambios significativos en la arquitectura darán lugar a mayores costos futuros durante las migraciones de versiones debido a la extensa personalización involucrada; en algunos casos, los programadores incluso me han dicho que ignorarán por completo los cambios tan grandes y que harán lo que quieran.

El software

No tengo nada que decir en la selección o instalación del software, por lo que cambiar la plataforma está fuera de discusión.

En cuanto al entorno del software, cada factura impresa es una sola llamada. No hay una instalación de impresión por lotes, y debido a cómo la instalación de impresión está integrada en el sistema (y también algunas peculiaridades del lenguaje) no es factible hacer un envoltorio de lote alrededor de esa API. Para colmo, esta parte del programa llama a otro programa que imprime la factura, que a su vez llama a la API de imprimir un informe, que imprime una sola factura. Diseño horrible, lo sé.

Los formularios de entrada son una combinación extraña de un encabezado de formulario que carece de cuadros de entrada, pero puede contener otros elementos de la GUI. Los cuadros de entrada se definen en tiempo de ejecución.

El objetivo

El software evitará que los usuarios impriman erróneamente toda la documentación.

¿Cómo resolverías este problema?

Esto es fácil, si dejan todo en blanco, le indicará que imprimirá todo, sin embargo, la selección POR DEFECTO en ese aviso DEBE ser cancelar.

Si ingresan valores, imprima lo que pidieron.

De esta manera, no abrirán accidentalmente el formulario e imprimirán todo. Se abrirán paso y no imprimirán nada. Tendrían que pausar e imprimir, cambiar la selección en el indicador a Aceptar, desde Cancelar, para imprimir todo.

Me parece que tiene el requisito de arreglar algo, pero cada vez que propone una solución (y hay muchas buenas ideas en su lista) se la derriba.

Este es el punto donde necesita retroceder. No necesitas una idea vaga de que "esto está mal; arréglalo". Lo que necesitas es una especificación. Pregunte a las personas que lo deseen fija exactamente lo que no quiere que se haga, ya que hasta ahora todo lo que tienes es lo que ellos no quieren. Eso es fácil: simplemente no hagas nada y luego no harás ninguna de las cosas que no quieren. Dígales que si quieren que se realicen cambios, deben elaborar reglas positivas y concretas, y usted las implementará.

Trataré de responder a una pregunta más genérica: cómo evitar que un usuario cometa un error que provoque un desastre o algo que no se pueda cancelar o deshacer (como desperdiciar papel al imprimir varias páginas que el usuario no esperaba impreso).

Como se dijo en la pregunta original:

Los usuarios se encuentran en un entorno de alta presión y tiempo crítico. Cada proceso se mide en minutos o incluso segundos, lo que significa que tengo que minimizar el tiempo de procesamiento tanto como sea posible.

Esto significa que:

• El producto de software debe hacer todo lo posible para aumentar la productividad de los empleados. Cuando cada segundo cuenta, la experiencia del usuario y la productividad son aún más importantes que para los productos generales, donde una pérdida de unos segundos en alguna característica que la persona ni siquiera usa con demasiada frecuencia es aceptable.

• Los usuarios están demasiado ocupados para prestar atención al producto de software. Cuando, en un ambiente tranquilo, utilizo alguna función de Microsoft Word que utilicé la última vez hace un año, si Microsoft Word me hace una pregunta, explicando cuáles serían las consecuencias de mi elección, puedo permitirme pasar un minuto o dos leyendo la pregunta, y tal vez incluso voy a leer la documentación. En su caso, no puede permitirse eso. Sus usuarios no tienen tiempo para leer.

Cuadros de mensaje: no, no y ... no!

Como ya se explicó en mi otra respuesta , los cuadros de mensaje son malos en la mayoría de los casos, por dos razones (vea Acerca de la Cara 3 de Alan Cooper para más detalles):

• El diálogo que gritó "¡Lobo!" El principio incita al usuario a descartar repetidamente un diálogo sin prestar atención si la aplicación muestra el mismo diálogo con demasiada frecuencia.

• El cuadro de diálogo perturba el flujo de trabajo: el usuario no puede concentrarse en la aplicación, porque el cuadro de diálogo quita este foco y la interacción con la aplicación se suspende hasta que se cierra el cuadro de diálogo¹.

Esto significa que los cuadros de diálogo son un mal absoluto en su caso desde el punto de vista de UX: se descartarán y disminuirán la productividad en un entorno donde cada segundo cuenta.

Otros medios

De acuerdo con la pregunta:

• "La entrada consiste en un rango de fechas, rango de ruta y rango de orden de venta".

• No hay valores incorrectos (por ejemplo, el usuario puede ingresar una fecha anterior, una fecha futura o hoy en el primer campo), por lo que la validación no es posible.

• "La rutina de impresión, cuando no se introduce nada como entrada, intentará imprimir todo, lo que provocará que se desperdicien resmas y resmas de papel de impresora en una impresora de alta velocidad".

• Es totalmente posible solicitar imprimir con los datos predeterminados utilizados.

En términos más genéricos, significa que:

• Tiene un valor predeterminado, que en realidad puede ser válido,

• No desea que los usuarios presionen el botón "Imprimir" con los valores predeterminados guardados por error, mientras tenían la intención de cambiarlos.

Aquí hay algunas técnicas que puedes probar:

1. La magia deshacer

Sí, los usuarios se encuentran en un entorno de tiempo crítico. Sí, una vez que la impresora comienza a imprimir, no se puede detener. Pero todavía hay algo que puedes hacer.

Incluso en un entorno de tiempo crítico, es probable que imprimir en este momento e imprimir en cinco segundos no cambie nada.

Cuando el usuario hace clic en "Imprimir", muestra un pequeño botón "Deshacer" , tal como lo hace GMail cuando solicita eliminar, por error, todo su correo. Espere cinco segundos ². Ocultar el "Deshacer" y solo después de eso, imprimir.

Ahora, el usuario tiene la oportunidad de notar el error y cancelarlo antes de que el daño esté hecho, mientras que el material se imprime solo con un pequeño retraso de cinco segundos.

2. El fondo discreto de "valor predeterminado"

¿Es sospechoso tener valores predeterminados? ³ Con un valor, rara vez es sospechoso. Con tres, hay posibilidades de que los casos en que el usuario tenga que mantener los tres valores por defecto sean bastante raros.

En este caso, puedes:

• Resalte el valor cuando tenga su valor predeterminado. No en rojo: el rojo es para valores no válidos. Configúrelo en amarillo-naranja y vuelva a blanco cuando el usuario modifique el valor predeterminado.

• O deshabilite el botón "Imprimir" hasta que se cambie un valor. Agregue una casilla de verificación cercana, que el usuario puede verificar para confirmar que su intención es imprimir con los valores predeterminados.

3. Mejora la interfaz de usuario de tus controles

Estamos viernes 6 ^º enero de 2012 hoy. ¿Cuál será la fecha del próximo jueves? Rápido, rápido, estás bajo presión, solo tienes un segundo para tu respuesta. Además, estás cansado y hay mucho ruido por todas partes. No es fácil de responder, ¿no?

La gente no puede manipular fechas fácilmente cuando está escrito como 1/8/1012. Saturday, 7th of January (tomorrow)Es un poco más fácil. Una vista gráfica que destaca los sábados y domingos, muestra hoy y el desplazamiento es aún mejor.

Nada es tan feo como "Ubicación: Nueva York". Esas tres letras no tienen sentido cuando estás cansado y trabajas en un ambiente estresante; Los errores son fáciles. En cambio, un mapa gráfico de Estados Unidos que muestra un punto rojo para la ciudad de Nueva York es mucho más atractivo, y el usuario tiene muchas más posibilidades de notar que, aunque quería seleccionar San Francisco, el punto rojo parece aparecer en un lugar incorrecto .

¿Te gustaría que tu GPS te dijera que tienes que moverte de 38.90403, -77.04878 a 38.90568, -77.04665, luego girar a la derecha y moverte a 38.90565, -77.04345, luego girar 90 ° a la izquierda y moverte a 38.90660, -77.04345? ¿Serías capaz de concentrarte en tu trabajo (el camino)? Mostrar el 1/8/2012 y NYC a usuarios ocupados es tan amigable como un GPS que arroja coordenadas en bruto en lugar de una vista 3D de un mapa lleno de color.

Al proporcionar controles más ricos y una visualización más rica de los datos , puede disminuir el nivel de errores de sus usuarios en un entorno estresante.

^{¹ Esto, por cierto, se aplica a otras variantes de cuadros de diálogo. Anteriormente hizo una pregunta sobre los cuadros de diálogo en los que los botones serán aleatorios y será difícil descartarlos. Lamentablemente, este enfoque no ayudará, pero solo perjudicará: los usuarios seguirán descartando lo que dice el diálogo, pero perderán más tiempo tratando de cerrarlo para volver a trabajar.}

^{² Digo cinco segundos como ejemplo. Debe controlar la actividad de los usuarios durante unos meses para ver qué tan rápido hacen clic en "Deshacer". Lo más probable es que sea inferior a un segundo. Si ve que el retraso es de 0.6 a 1.8 s. con un promedio de 1.1 s., puede mostrar "Deshacer" durante dos segundos y luego imprimir.}

^{³ ¡Por favor, por favor, por favor, di que no! Porque si es así, significa que hay algo mal con sus valores predeterminados. Por ejemplo, si el valor predeterminado para la fecha es hoy, mientras que en el 75% de los casos, los usuarios tienen que configurarlo para mañana, en el 10% para ayer y en el 10% para el día después de mañana, debería establecer el valor predeterminado valor para mañana.}

¿Puede determinar antes de imprimir cuántas páginas se imprimirán o, de alguna otra manera, medir el tamaño de la salida? Si es así, determine un tamaño máximo para el uso normal, y si es más grande, use un cuadro de diálogo de confirmación que indique el tamaño de salida y, para que no se pueda descartar sin leerlo, requiere que el usuario vuelva a escribir el tamaño de salida para confirmar.

¿Cómo resolverías este problema?

Separe claramente los casos de uso. Hay un caso de "imprimir algo ahora" que puede conducir a una salida sin fin. Solucione esto para proporcionar todos los valores predeterminados correctos.

Hay un caso de "reimpresión de algo anterior" que es una solicitud especial (no estándar) donde las entradas se pueden verificar cuidadosamente.

La entrada para el rango de fechas no se puede configurar automáticamente en "fecha de hoy", ya que se requiere una impresión posterior frecuente.

Falso.

La entrada se puede configurar automáticamente hoy sin ningún efecto en las solicitudes frecuentes de impresión de respaldo.

¿Qué posible impacto tendría un ajuste automático a la "fecha de hoy" en las solicitudes de impresión inversa? Enumerarlos en la pregunta.

La entrada para las rutas no se puede codificar, ni se puede deducir de las rutas que ya se han enviado, ya que se requieren reimpresiones (ver arriba).

Falso.

Las reimpresiones y las impresiones posteriores son un caso especial. Ellos no tienen campos predeterminados y son la excepción y no la regla.

Permítame volver a plantear el problema.

Estado actual: presionar a ciegas Enterhace que se impriman resmas de papel.

Estado deseado: al presionar a ciegas Enterno se imprimen resmas de papel.

Solución: cambie el software para que presionar a ciegas Enterhaga algo, cualquier cosa , que no sea la impresión de resmas de papel.

Eso te deja con el problema de lo que debería hacer en su lugar. Personalmente, les preguntaría a los operadores qué quieren. Mi conjetura es algo así como imprimir las facturas más urgentes que aún no se han impreso. Deje la capacidad de imprimir todo, pero requiera una decisión consciente para hacerlo.

Tiene una situación en la que el proceso predeterminado actual está generando desperdicio y costos de tiempo para sus usuarios.

Sin embargo, deshabilite la capacidad de presionar enter por completo al enfocarse en el botón "restablecer parámetros" (cree uno si es necesario) para que si presionan enter permanezca en esa pantalla, pero no hace nada. Crearía algún tipo de botones de acceso rápido para las selecciones más comunes para completar automáticamente el formulario con esos parámetros para ayudar a los usuarios. Pero esto debería resolver su problema incluso sin los botones de acceso rápido.