Validación progresiva y divulgación
Estoy tratando de encontrar un ejemplo de validación progresiva. Tenemos una interfaz de usuario para un editor visual donde un usuario hace cosas como indicar dimensiones en píxeles o porcentajes.
Las propiedades del editor están en conjuntos de pestañas, por lo que no todos los campos son visibles al mismo tiempo. Hemos estado discutiendo cómo y si hacemos validación en esta interfaz de usuario.
Vengo desde la perspectiva de que: a) La validación es útil porque creará un canal de comunicación donde el usuario puede aprender las expectativas del software y "mejorar" en lo que se requiere. b) Siempre es mejor indicar los errores de validación en los campos de entrada directamente (se use o no un resumen en otro lugar) para que los usuarios tengan una señal visual de lo que debe cambiarse.
Mi colega, por quien no tengo nada más que el máximo respeto, no está de acuerdo. Su lógica es la siguiente: a) Será más conveniente prevenir ciertos tipos de entrada o, en el caso de alguna entrada, cambiarlo a un valor más apropiado si no es válido. Por ejemplo, si alguien usa un valor de porcentaje mayor que 100, la IU restablecería el valor a 100 en un evento de foco perdido. b) Debido a que estamos en un entorno de pestañas, algunos de los errores no serán visibles para el usuario. Usar un resumen es inútil, ya que puede haber "muchos" errores de validación.
Pensé que una solución para esto podría ser una divulgación progresiva de valores no válidos. Cuando un usuario ingresa valores que pueden ser incorrectos, se marcan en algún tipo de resumen. El resumen permite a los usuarios navegar a los campos en cuestión también sin que sean visibles.
Desearía ser una persona original, pero estoy seguro de que hay precedentes aquí. Mis preguntas son las siguientes:
¿Algo que agregar a las perspectivas de mí o de mi colega?
¿Algún ejemplo de una interfaz de usuario como esta con entrada compleja que haga validación progresiva?
Actualmente estamos lidiando con el mismo problema para una aplicación de escritorio, aunque no basado en pestañas. Puedes probar un enfoque como este:
donde aparece un pequeño icono si algo requiere la atención del usuario. Tal vez incluso use dos colores: amarillo para advertencias y rojo para cosas que debe se arreglen antes de que el usuario pueda ir más allá.
Lo mejor que puede hacer en esta situación compleja es crear un prototipo de la mayor cantidad de IU que pueda y pruébelo en su base de usuarios para ver qué sucede. Puede usar HTML en combinación con algo como jQuery UI para obtener rápidamente una gran cantidad de controles interactivos disponibles y listos para probar rápidamente.
Su sistema de pestañas suena complicado, así que tengo que sugerir un par de cosas para simplificar:
- Cree botones "aplicar" dentro de cada pestaña para que el estado se pueda guardar solo para las propiedades que el usuario puede ver en este momento. Si eso resultara en un estado de aplicación no válido, rediseñe sus pestañas para que los usuarios tengan propiedades agrupadas que can se guarden independientemente una de la otra.
- Si no puede hacerlo, puede resaltar las pestañas con un icono "no válido" y un color para indicar que las propiedades en esa pestaña necesitan atención. Si bien las pestañas no son válidas, el botón "aplicar" está deshabilitado. Podría considerar agregar una notificación al botón si se hace clic para mostrar un mensaje que indica que todavía hay errores. Los resúmenes de lo que está mal se mostrarían dentro de cada pestaña en lugar de tener un resumen general.
- Un resumen global podría funcionar, pero dudo en sugerirlo, ya que parece que no habría una ubicación inmediatamente obvia para ponerlo, y a menos que ese sea el caso, ¿los usuarios lo notarán?
- ¿Cómo se agrupan las propiedades? Probablemente funcionalmente? Intente mirarlos desde un ángulo diferente, por ejemplo, por la probabilidad de uso. Esto es parte de cómo Microsoft se acercó al diseño de la cinta para sus productos de Office 2007. Tal vez podría diseñar sus pestañas de tal manera que la mayoría de los usuarios solo necesiten meterse con las propiedades en la primera pestaña, o inmediatamente visible, y las otras pestañas podrían considerarse "avanzadas" o contextuales.
Finalmente, y ya dije esto, ¡prueba tu diseño! :-)
En cuanto a los errores de manejo, mi experiencia ha sido que si evita ciertas entradas, los usuarios se confundirán. Por ejemplo, si no está claro en un campo de entrada que solo se permiten números, pero de todos modos no se permiten otros caracteres, eso será frustrante para el usuario; no lo experimentarán como una forma inteligente que está tratando de ayudarlos. . Por lo tanto, le sugiero que use una microscopía clara en todo momento si decide seguir el camino del uso de eventos y detección de entrada para corregir automáticamente las cosas.
Pero todo esto es anecdótico: no he realizado ninguna investigación en esta área. En lugar de aceptar mi palabra, consulte el libro de Luke Wroblewski, Diseño de formulario web: Rellenar los espacios en blanco , y su investigación sobre el manejo de errores para obtener algunas ideas útiles sobre cómo lidiar con situaciones como esta (para ejemplo, esto publicar en el rediseño del formulario de pago de Apple discute cómo manejan los errores en detalle).
Recientemente trabajé en un proyecto que encontró un problema similar. Puede ver una captura de pantalla de cómo lo resolvimos en mi artículo " Minimizing Complexity " del año pasado.
Pensé en un caso en el que se usa un resumen de muchos errores y tal vez funciona.
En cualquier IDE como, por ejemplo, Visual Studio, existe la posibilidad de un sinfín de errores, ya sea al crear o utilizar herramientas de análisis estático al escribir código. En general, hay docenas o cientos de archivos y muchos de ellos se abren en pestañas, con una o dos visibles a la vez,
Los errores se enumeran en una lista redimensionable desplazable que se desliza (por defecto) debajo de la IU principal. Esto podría hacerse tan pronto como quede atrapado un error. Cuando se hace clic o se hace doble clic en un error, lo lleva al lugar correcto y al foco para corregirlo, y el error desaparece de la lista cuando ya no es válido.
(En realidad, muchos de estos errores necesitan una acción iniciada por el usuario para ser reevaluada, pero hay muchos complementos de análisis estático que lo hacen en segundo plano y actualizan la lista de errores dinámicamente mientras se edita el código) .
a) Por ejemplo, si alguien usa un valor de porcentaje mayor que 100, la IU restablecería el valor a 100 en un evento de foco perdido.
Buen punto, pero luego debes asegurarte:
- El usuario se da cuenta de que su entrada ha sido reparada.
Quizás, por ejemplo, haga que el campo parpadee por un segundo si fija el valor. - Puede adivinar razonablemente lo que realmente quiso decir el usuario.
Por ejemplo, tome un selector de color con el que luché ayer. Quería que algunos elementos coincidieran con los de otro sitio, así que obtuve los valores hexadecimales y los copié y los pegué en los pequeños cuadros de texto ad-hoc. El primer valor fue#202040, pero por alguna razón solo pegué#20204, que rápidamente se "arregló" en#020204. El segundo valor que pegué fue#BCD(abreviatura de#BBCCDD), que también fue "arreglado" a ...#000BCD. Suspiro.