winforms - tipos - usuario final caracteristicas
Edición en cuadrículas vs. formularios de detalles: ¿qué tan inteligentes son los usuarios finales? (6)
Me encantan las redes, especialmente las de terceros como Devex, C1, etc.
Nuestro programador no cree que los usuarios finales puedan manejarlos, por lo que siempre diseña sus formularios con grillas de solo lectura (con clases de solo lectura). La elección de editar un elemento en la cuadrícula abre un formulario de detalle que permite la edición.
Esta aplicación va a ser utilizada por gente de negocios en general, no geeks. Pero todos son muy buenos usuarios de Excel, lo que creo que es un poco ''grid''. ¿Debo confiar en mi desarrollador principal o ir con mis instintos, que dice que a los usuarios les gusta la edición rápida, que la cuadrícula es mucho mejor que las formas de detalle? Quiero tener una sensación constante para la aplicación, así que prefiero no mezclarla demasiado.
¿Por qué no haces algunas pruebas de usuario y encuentras la respuesta de esa manera? Haz una maqueta de prototipos simples o usa ejemplos existentes y haz que lleven a cabo tareas simples. Verá rápidamente qué tan buenos son los usuarios y la elección desde allí debería ser bastante sencilla.
En mi experiencia, las cuadrículas con edición pueden ser difíciles tanto para el programador como para el probador y el usuario, ya que normalmente el desencadenante para la validación es el evento de enfoque de muerte. Es decir, el usuario saca pestañas de una celda y se detiene con un error en esa celda hasta que la corrige.
¿Eso esta bien? Depende
Si los datos en cada celda de la grilla se pueden validar sin hacer referencia a otras celdas y especialmente a otras filas, entonces tal vez eso esté bien. Pero si la validez de una celda depende del valor en otra, entonces una validación desencadenada por el enfoque de matar puede ser complicada. Su usuario puede terminar en una situación en la que tiene que poner ALGO en una celda solo para poder salir de esa celda y navegar hasta la celda real que causa el problema.
Otra ventaja de un diálogo es que hay un montón de espacio en pantalla para textos útiles, etiquetas más largas, múltiples mensajes de error al mismo tiempo, todos al lado de los campos por error. En una grilla, a veces todo lo que puede hacer es cambiar el color de la celda y abrir un cuadro de diálogo modal solo para esa celda.
Trabajo en una aplicación que reemplazó una aplicación que tenía edición en cuadrículas. Cada programador involucrado con la aplicación anterior estuvo de acuerdo en que en la nueva aplicación no habría edición en las grillas, y no es que seamos flojos. Solo queríamos enviar algo que sabíamos que podríamos hacer sólido, que sería más fácil de probar para nuestros probadores.
Estoy de acuerdo en que los usuarios con experiencia en Excel se sienten cómodos editando en cuadrículas, pero es mejor que se aseguren de que sus cuadrículas se comporten tan bien como las grillas de Excel.
Esto es principalmente una cuestión de gusto, pero mi preferencia está en línea con su desarrollador (y la respuesta de Corey, más arriba). Prefiero un modelo de solo lectura / edición sobre una gran grilla editable, para la mayoría de las aplicaciones . Pero trabajo mucho en Excel y me mataría tener que abrir una fila a la vez. ¡Propósitos diferentes! Si vas a hacer una gran cantidad de edición de acceso aleatorio, me quedaré con una grilla. Para todo lo demás (incluida la entrada secuencial) usaría un modelo de solo lectura con un formulario de salida. Varias aplicaciones en las que he trabajado han demostrado que los usuarios pueden tratar en el contexto apropiado.
Los usuarios pueden manejar totalmente las grillas. Es más intuitivo que un botón de edición y una forma de detalle.
Sin embargo, ¿esta aplicación es una aplicación para múltiples usuarios? ¿Podrían los datos subyacentes ser cambiados por más de un usuario a la vez? Si es así, entonces tiene que tomar algunas decisiones de diseño de concurrencia, y en ocasiones, eso puede ser más fácil de resolver cuando los usuarios solo pueden editar una fila a la vez.
Aunque huele un poco a pescado, y sospecho que tu programador está haciendo excusas convenientes porque es más fácil para él diseñar rejillas de solo lectura en un patrón maestro / detalle.
Quédate con tu instinto. :)
Si no confías completamente en tu desarrollador líder, no deberían ser tus desarrolladores principales.
Aparte: si su desarrollador principal tiene un título en Ciencias de la Computación (u otro título similar), no los llame "programadores". Es negativo para un ingeniero profesional.
Si anulas su decisión, no sentirán el amor por decir lo menos. Tenga mucho cuidado con pisar los dedos de sus ingenieros de software. Solo hazlo si estás 100% seguro de que están cometiendo un error. Incluso entonces, puede abordar el problema de una manera que les haga darse cuenta de que es un error sin que usted anule una de sus decisiones. Ayúdelos a tomar la mejor decisión preguntándoles cómo resolverían el caso particular que le preocupa. Si no están preocupados por el mismo caso, déjalo ir. Es por eso que son el desarrollador principal. Siempre que sean inteligentes y entiendan su preocupación, es lo mejor que pueden hacer siempre que contraten a las personas adecuadas. El daño que podría infligir en su relación y su productividad anulando la decisión de su desarrollador principal podría ser mucho peor que la vista de cuadrícula editable frente a no editable.
Edite en el lugar en la cuadrícula siempre que sea posible y nunca tenga un diálogo de edición. No puedo pensar en ninguna ventaja para tener un "modo de edición", y desperdicia el tiempo de los usuarios y agrega complejidad a la aplicación (desde la perspectiva del usuario). Tener un diálogo de edición hace que sea más difícil aprender la aplicación que editar en el lugar porque el usuario tiene que aprender dos ventanas y cómo navegar entre ellas.
Como revela la experiencia con Excel, Access y otras aplicaciones de escritorio, los usuarios no tienen problemas para editar una grilla más que para editar cualquier otra cosa. No debería tener un problema, especialmente si hace que su grilla parezca una hoja de cálculo de Excel o una tabla o formulario de acceso, y no como su típica aplicación web "Haga clic aquí para actualizar".
Creo que la tendencia de algunos desarrolladores a hacer cuadrículas de solo lectura es un remanente de los primeros días de la aplicación web cuando no había cuadrículas editables ni cuadrículas: había tablas html y cualquier edición requería un formulario. No veo excusa para el modo de edición con la tecnología actual.
En cuanto a la validación, informe al usuario de cualquier error de validación cuando el foco abandone la celda, pero no use indicaciones de error modal (marcar el campo con color es una forma de hacerlo, pero no de la única manera). Permita que el usuario lo corrija siempre que lo desee, tal vez mediante la fijación de otros campos. Esto resuelve el problema de validación dependiente.
Si se puede hacer de forma asincrónica o en menos de medio segundo, considere publicar automáticamente cambios en el registro con la pérdida de enfoque en la celda o (alternativamente) la fila. Esto soluciona el problema de simultaneidad para múltiples aplicaciones de usuario, además brinda a los usuarios un ahorro implícito, otra mejora de usabilidad que las aplicaciones web podrían usar.
La manipulación directa ha sido un principio de usabilidad probado desde que se inventaron GUI. Los modos se han reconocido desde hace tiempo para presentar problemas de usabilidad. Ya es hora de que las aplicaciones web alcancen un nivel de usabilidad de los años ochenta.
Por cierto, un montón de texto explicativo en la ventana (por ejemplo, etiquetas largas y mensajes múltiples) es una indicación de un problema de usabilidad, no una solución.