versiones guia español descargar actualizar validation gridview user-interface input data-entry

validation - guia - qgis manual



Ingresando datos en una grilla (6)

Una pregunta de UI: ¿hay algún consenso sobre cuál es la mejor (definida como "la que los usuarios finales prefieren") o la forma menos conveniente de implementar la entrada de datos en una grilla?

Tengo una grilla, con muchas filas. Las columnas de la cuadrícula contienen varios tipos de propiedades, que el usuario puede ingresar / editar. Los "tipos" de propiedades incluyen:

  • Texto libre
  • Números (dígitos numéricos)
  • Valor de Enum (p. Ej., Uno de "Alto", "Medio" y "Bajo")
  • Otros (por ejemplo, fecha, duración)

El tipo de "texto libre" no es difícil de diseñar (así que no preguntaré sobre eso), pero ¿qué pasa con los siguientes dos tipos?

Dígitos numéricos

  • Al usar un teclado para ingresar un número, ¿permitiría la entrada de texto libre y luego ejecutaría un método de validación en desenfoque? ¿O puede controlar cada pulsación de tecla para restringir la entrada de datos a dígitos solamente?
  • ¿Cómo le dice al usuario (en una grilla, no en un formulario) que la sintaxis de los datos en alguna columna está restringida a solo numérica? ¿Qué haces si el usuario presiona una tecla incorrecta (no numérica)?
  • Un control ''spin'' o ''spinner'' es un control estándar de Windows; ¿es apropiado intentar usar uno en una grilla basada en HTML también?

Valores Enum

Para ingresar o editar un valor enum usando el mouse, supongo que hacer un pequeño menú contextual con un clic del mouse es lo que hay que hacer.

  • Una alternativa es usar el control de entrada <select> (es decir, un cuadro combinado). Aunque creo que tener una columna llena de cuadros combinados no es tan fácil de leer como tener una columna de valor de texto (porque los cuadros combinados agregan tinta adicional que no es de texto)? ¿Qué piensas que normalmente muestra texto sin formato, pero reemplaza ese texto con un cuadro combinado cuando el campo recibe el foco de entrada (y luego elimina el cuadro combinado en desenfoque)?
  • ¿También mostraría ese mismo menú en el enfoque, cuando el enfoque cambia como resultado del teclado (es decir, la tecla [Tab]) en lugar de un resultado del mouse (es decir, un clic)? En otras palabras, ¿debería tabular a un resultado de campo en un menú emergente? A propósito, los menús emergentes basados ​​en CSS que he visto responden al mouse pero no al teclado (por ejemplo, a las teclas de flecha [Arriba] y [Abajo]). ¿Conoces alguna implementación de entrada de datos tipo Intellisense que pueda ejecutarse en un navegador?

¿Por ejemplo?

También me interesaría ver cualquier cosa que creas que sea un ejemplo ejemplar. Estoy interesado en la interfaz de usuario del escritorio y / o en las respuestas del navegador.

Editar: después de otra pregunta con la etiqueta [entrada de datos] (" ¿Alguien ha utilizado Sigma Grid (cuadrícula de datos editables basada en JavaScript)? "), Estoy viendo el ejemplo de Sigma Grid. Hace muchas cosas bien IMO (buen soporte para el teclado y cuadros de selección just-in-time); pero su soporte para campos numéricos puede ser imperfecto, por ejemplo, si presiono ''a'' en una celda numérica, a veces aparece un cuadro de alerta para decirme que estoy equivocado (donde tal vez una información sobre herramientas sería menos intrusiva), y / o a veces deja la celda vacía (en blanco), borrando la ''a'' y no dejando nada en su lugar.

Edite en respuesta a una de las siguientes respuestas.

De nuevo, sin embargo, determine QUÉ será el uso principal de su formulario y optimícelo para eso. La visualización o el análisis de los datos tiene diferentes necesidades que la entrada masiva, y satisfacer a los usuarios del teclado es completamente diferente a los usuarios de teclado + mouse.

Quiero que la misma pantalla (es decir, una tabla / cuadrícula) funcione bien para mostrar propiedades existentes, crear nuevas propiedades y editar propiedades existentes. Espero docenas de elementos (es decir, docenas de filas de datos), cada uno con solo unas pocas columnas (por ejemplo, una columna de texto / descripción del artículo, más 1 o más columnas para 1 o más propiedades de elementos asociados).

Algunos de los datos / propiedades pueden ser subjetivos y relativos (por ejemplo, dos propiedades para cada elemento son la "prioridad" o la "dificultad" de cada elemento, lo que es especialmente significativo solo cuando se compara con otros elementos), que es una razón por la que deseo para mostrar todos los datos juntos en una pantalla: para que el usuario final pueda compararlos.

Mi aplicación es para usuarios de computadoras relativamente expertos (no principiantes), pero no especialistas en la entrada de datos: por ejemplo, los usuarios son desarrolladores de software, gerentes de proyectos, gerentes de productos, personal de control de calidad, etc., pero también hasta cierto punto sus clientes; se está ejecutando en una intranet (no en internet pública), sin embargo, fácil de usar y fácil de entender es muy importante.

Además, no veo por qué satisfacer a los usuarios de teclado es completamente diferente a los usuarios de teclado + mouse: pensé que una sola solución podría / debería soportar una y / o ambas.

En el caso de los valores numéricos, generalmente solo uso JavaScript para restringir la entrada de cualquier valor que no sea el que desea que ingrese. En este caso, números. No es necesario darles alertas o cualquier otra cosa, simplemente no lo permitan.

Para los valores enum, realmente iría con algún tipo de cuadro de selección o desplegable. Eso es lo que las personas están acostumbradas a usar en los sitios web. Puede hacerse elegante con él y esconderlo hasta que el mouse pase, o haga clic en el cuadro.

Para tabular, les permitiría tabular en otro cuadro de selección. Esto será más rápido para que algunas personas ingresen una gran cantidad de datos.

En mi humilde opinión, la gran pregunta que debe hacer es el propósito principal de su página y la relativa sofisticación de sus usuarios. ¿Estás lidiando con los profesionales clave de Tab + 10, los mecanógrafos de mouse + clic + hunt-peck, un poco de ambos?

Las elecciones que haga deben tomar esto en cuenta. Supongo que, en virtud de la elección de una grilla, los usuarios son un paso hacia arriba desde la parte inferior, y usan la navegación con tabulación como medio principal para navegar su formulario, y el uso principal es la entrada masiva de datos.

En cuanto a la entrada numérica:

  • Si planea proporcionar una rutina de conversión, no es necesario restringir los dígitos.
  • En el caso en que un usuario ingrese una entrada no válida (tenga en cuenta que algunos números, no solo el texto pueden ser inválidos ... por ejemplo, edad negativa) es mejor que muestre el error en línea e inmediatamente.
  • Evite los rotuladores, especialmente si se trata de números con decimales. Los Spinners alejan el foco de la entrada de datos y proporcionan un valor mínimo a menos que se trate de un conjunto finito de números discretos. Si este es el caso, un Combo / Select puede ser mejor (detallaré por qué en la próxima publicación).

En cuanto a los valores enum:

  • Evite las ventanas emergentes / menús de contexto como la plaga. Requieren que el usuario use el mouse y quite el enfoque de la tarea actual, literalmente cuando genera una nueva ventana. Un Combo / Select permite a los usuarios cierto grado de escritura anticipada, y permite la selección del teclado mediante flechas.
  • El problema del cuadro combinado que aparece (la flecha que hace que el texto sea más difícil de leer) es algo que puede aliviar con la solución de enfoque que proporciona; sin embargo, generalmente puede hacer que su cuadrícula sea más legible en general con más espacio entre las filas y columnas .

Comentarios adicionales:

  • Texto libre las fechas con conversiones si es posible. A menos que planee capacitar a sus usuarios, u opte por adoptar algún sistema de enmascaramiento draconiano (e igualmente fastidioso golpe de muñeca en la falla de validación), se les debe permitir ingresar fechas como lo deseen. Advertencia si se trata de gente internacional, ingresan meses y días de manera diferente. SOP en los EE. UU. En mm / dd / aaaa, mientras que muchos países prefieren dd / mm / aaaa.
  • Si tiene una cantidad considerable de campos, puede considerar dividir la entrada de datos en varias líneas. Una cuadrícula plana de> 10 columnas es bastante difícil de comprender en una sola vista. El inconveniente de esto es el desplazamiento vertical incrementado, por lo que tendrá que equilibrar la importancia de usar el contexto de datos (por ejemplo, las filas anteriores y las siguientes) para interpretar la fila actual de datos de edición por un lado y obtener todos los información de una fila (multi-línea o H-scrolling) en el otro.

De nuevo, sin embargo, determine cuál será el uso principal de su formulario y optimícelo para eso. La visualización o el análisis de los datos tiene diferentes necesidades que la entrada masiva, y satisfacer a los usuarios del teclado es completamente diferente a los usuarios de teclado + mouse.

EDITAR: responde a los comentarios

Además, no veo por qué satisfacer a los usuarios de teclado es completamente diferente a los usuarios de teclado + mouse: pensé que una sola solución podría / debería soportar una y / o ambas.

No es completamente diferente. Piense en ello como la diferencia entre "optimizar para" y "apoyar" al grueso de sus usuarios. Algunos ejemplos: los editores de código están optimizados para usuarios de teclado. Entre las teclas rápidas, los accesos directos y la navegación por el teclado, el usuario rara vez necesita usar el mouse. La mayoría de los juegos de RTS funcionan usando el teclado de una mano sobre el otro. En general, admiten el uso exclusivo del mouse, pero no está optimizado para esto. ITunes está en el otro extremo: depende del ratón casi exclusivamente (como lo hacen la mayoría de las IU dominadas por la caída de drag) y usar el teclado solo es casi imposible.

¿Permite la entrada y muestra un error; o prevenir la entrada y mostrar un error? ¿A qué te refieres con mostrarlo "en línea" cuando se trata de una cuadrícula (una celda, en algún lugar dentro de una mesa)?

No estoy seguro de qué plataforma está desarrollando, pero sí, me refiero a algún lugar dentro de la mesa, preferiblemente en la fila de datos de la que está hablando. En ASP.NET, GridView permite TemplateFields, que le permite insertar múltiples controles en la misma "celda". En el mundo de los clientes ricos, la mayoría de los componentes de terceros brindan soporte para cosas similares OOTB (por ejemplo, IDataErrorInfo) que le dan errores en contexto.

Si la alternativa es poner todos los errores por encima o por debajo de su grilla, será difícil para sus usuarios determinar cuál de las docenas de filas de datos tiene el error. Para un ejemplo de manejo subóptimo de esto, intente agregar 10 elementos a un carro de Amazon, luego cambie todos los montos a 2, excepto 1 artículo, que cambie a -1. Pulse actualizar y vea si puede navegar fácilmente a la fila con errores.

Además, el estilo "en" del estilo de validación es permitir a los usuarios ingresar datos y darles mensajes si es incorrecto, sin impedir la entrada y / o eliminar su entrada. lo hace en numerosos lugares, lo que se evidencia más fácilmente al agregar un comentario. La validación le notifica que necesita al menos 15 caracteres, pero no elimina su comentario cuando lo notifica. Un segundo cercano sería dejar que el usuario sepa explícitamente, y de inmediato que su entrada es incorrecta. Un ejemplo de esto sería intentar cambiar el nombre de un archivo con una barra invertida en Windows. Verás un globo con instrucciones precisas de inmediato.

Bueno, Intellisense o autocompletar es una especie de ventana emergente, pero puede ser operado usando (no aleja el foco) del teclado.

Si puede soportar ventanas emergentes tan limpiamente como Intellisense en Visual Studio, yo diría que lo haga. Mi experiencia sin VS con ventanas emergentes es la que más intento y fracaso (algunas, bastante horribles al requerir que levante el mouse y vuelva a enfocarme en el lugar correcto). Otra cosa a tener en cuenta con Intellisense es que tiene un excelente manejo de final de frase (me refiero a la interacción con las palabras escritas + anticipación + ortografía / perdón de mayúscula + tabulación / manejo de entrada). Como supongo que está utilizando la pestaña para navegar entre los campos (tenga en cuenta que VS no tiene campos), tendrá que encontrar otra forma de que su aplicación sepa que "He terminado, vaya automático -completo / Intellisense lo que acabo de escribir "

Estaba pensando que el marco del cuadro combinado alrededor del texto hace que el texto sea más difícil de leer con rapidez; tal vez un cuadro combinado mínimo, con una flecha hacia abajo pero sin marco alrededor del cuadro combinado (solo los bordes de las celdas de la tabla) sería mejor para las celdas que no tienen el foco: aunque me pregunto por qué incluso la flecha descendente podría ser útil en las células que no tienen el foco.

Si está preocupado por el cuadro de ComboBox, estoy totalmente de acuerdo: cambie el color del marco a algo con menor contraste. Cualquier solución que tomes para minimizar el control "cromo" cuando no está enfocado obviamente hará que sea más parecido al texto, y (¿posiblemente?) Más legible.

En cualquier caso, buena suerte con tu diseño.

Aquí hay una lista confusa de observaciones del trabajo con formularios de entrada durante años.

Dígitos numéricos:

  • No limite la longitud del campo: es realmente molesto si ha agregado un carácter de separación (o uno demasiado) solo para descubrir que ahora no puede completar el campo. Luego debe regresar, eliminar el carácter "ofensivo", ir al final y continuar llenando. Un buen sistema debería recortar y eliminar cualquier carácter que no sea de datos al salir del campo. Si el valor aún no encaja, informe al usuario de inmediato.
  • Para evitar números que no sean números, simplemente ignore las teclas que llenarían una cadena sin número. Tenga cuidado con los separadores de miles / decimales, espacios en blanco y caracteres de control (CTRL-x). Debería poder pegar valores de prácticamente cualquier formato disponible, incluidos los símbolos de moneda (que se eliminarán).
  • Los controles de giro aún no son ubicuos, por lo que solo deben usarse para interfaces expertas. También comparten muchas de las trampas de las barras de desplazamiento: ¿hay espacio suficiente para tener flechas de punto final, si la barra se escala con la escala um, si la escala es lineal, cuál es la longitud de barra mínima / máxima que es fácil? hacer clic y proporciona la precisión adecuada, ¿se puede aumentar de forma precisa y rápida incluso con un teclado?
  • Después de que el usuario sale del campo, el valor debe redondearse a los dígitos permitidos máximos, y preferiblemente formateado de acuerdo con la configuración del sistema operativo para su legibilidad.

Valores de Enum:

  • Cambiar el widget de campo en la entrada sería confuso para los nuevos usuarios, por lo que debería usarse solo para interfaces expertas.
  • Las interfaces similares a Google Suggest son útiles cuando la lista es grande pero familiar para el usuario, ya que la navegación de una lista larga se puede reducir a una porción más manejable con unos pocos clics. Tal vez un selector desplegable debería estar disponible en caso de que el usuario realmente quiera ver todas las opciones existentes. Si el campo no permite nuevas entradas y el contenido del campo no coincide con ninguna de las opciones, debe intentar encontrar la coincidencia más cercana cuando el usuario navega fuera de ella. Por ejemplo, es útil ingresar solo el primer carácter si sabe que las opciones son "Alto", "Medio" y "Bajo", y que el sistema haga el resto.
  • Cuando el campo adquiere foco, mediante el mouse o el teclado, debe mostrar inmediatamente las opciones disponibles si no son muy numerosas. Es una buena pista para los usuarios. Una de las dificultades es si es demasiado insistente, oscureciendo otras partes de la pantalla cuando el usuario está tratando de alejarse.

jQuery tiene algunos complementos geniales que ayudan en los modismos de entrada de datos comunes.

El alto uso de jQuery, y algunos de estos complementos, junto con el factor de estética, me indican que estos complementos representan algunas de las mejores maneras de manejar la entrada del usuario ...

Isaac over at evolt también tiene un buen artículo sobre formularios utilizables

Eche un vistazo a http://www.peterblum.com

Utilizamos este producto en muchas de nuestras aplicaciones durante los últimos 4 años. Definitivamente mejora la interfaz de usuario de formularios web y resuelve muchos problemas de validación. En particular, funciona bien con control de cuadrícula.

La mejor de las suertes