design - form - ¿Las acciones no autorizadas en la interfaz de usuario deben ocultarse, deshabilitarse o dar como resultado un error?
user input ux (13)
Como con casi todas las preguntas de UI, la respuesta es "depende".
Debe ponderar la visibilidad con la satisfacción del usuario, entre otras cosas. Por ejemplo, permitir una acción no válida le da la oportunidad de explicar por qué algo no es válido. Esto es particularmente útil si la respuesta a "por qué está desactivado" no es obvia. Para una aplicación donde la mayoría de los usuarios son principiantes, eso es importante.
Por otro lado, puede ser muy frustrante ver un control, hacer clic en él, solo para ser recompensado con el mensaje "lo siento, no puedes hacer eso ahora". Una aplicación que heredé hace un par de años estaba plagada de ese tipo de cosas y hacía que el uso de la interfaz de usuario fuera un ejercicio de frustración.
Completamente ocultando la funcionalidad probablemente sea una rara idea. Imagina saber alguna característica "estuvo allí hace un minuto" pero ahora se ha ido. Ya sea un elemento del menú o un botón de la barra de herramientas o algo completamente distinto, ocultarlo puede ser un ejercicio de frustración para el usuario final.
Intenta hacer algunas pruebas de usabilidad, solo preguntando a la siguiente persona que veas "hey, ¿tiene sentido desactivar esto o mostrarte un diálogo informativo?". Solo una otra opinión suele ser suficiente para que veas el problema desde otra dirección.
En pocas palabras: haz lo mejor para el usuario. Todos los escenarios que menciona son válidos bajo ciertas circunstancias. Al igual que con todas las preguntas de la interfaz de usuario, pregúntese (o mejor, a sus usuarios) qué es lo mejor para sus necesidades.
Esta es una pregunta perenne para mí que nunca he resuelto, así que me gustaría su opinión. Si tengo acciones que sé que un usuario no podrá realizar debido a privilegios insuficientes o estado del objeto, ¿los elementos de la interfaz de usuario para esas acciones deben ocultarse al usuario, visibles pero inhabilitadas o visibles, y producir un error si se intenta? ¿Cuál sería la razón de su respuesta? Si está deshabilitado, ¿le comunicaría el motivo y, en caso afirmativo, cómo?
Esta es una interfaz web, así que ya sé que necesito verificar la entrada entrante / obtener permisos y manejar los errores allí de todos modos. Principalmente estoy hablando de cómo manejar la interfaz de usuario.
Esto es similar a las Reglas sobre deshabilitar u ocultar elementos del menú , aunque estoy interesado en todos los tipos de elementos de la interfaz de usuario, no solo en los menús.
Ejemplos:
Tengo una nueva página que permite a un usuario crear un nuevo evento. Los eventos pueden ser eventos maestros o subeventos. La creación de un evento maestro requiere el privilegio "EditMasterEvent", mientras que la creación de un subevent requiere solo el privilegio "EditEvent". Tengo un menú desplegable que permite elegir un evento existente como padre (evento maestro) o sin padre (este es un evento maestro). Si la opción "Crear evento principal" se muestra en el menú desplegable u omitida si el usuario solo tiene privilegios de "Editar evento".
La eliminación de eventos requiere que seas un administrador de la aplicación o tengas los permisos de edición apropiados para el tipo de evento. En este último caso, el evento también debe tener más de 5 años. La eliminación de un evento provoca importantes eliminaciones en cascada de datos relacionados en el sistema y, por razones legales, estos datos deben conservarse durante al menos 5 años después del evento. Como esta operación es rara para el usuario normal, el caso típico es que la acción no está disponible. ¿Debería mostrarse siempre o solo cuando sea posible?
Depende. ¿Desea que el usuario sepa que la acción es posible, pero no para ellos? En ese caso, muéstreles el botón, pero deshabilítelo. Un ejemplo podría ser si un usuario no tiene autorización para eliminar, pero otros usuarios sí, deben saber que las entradas se pueden eliminar, de modo que pueden pedirle a alguien que lo haga por ellos si necesitan la acción.
Por otro lado, si se supone que el usuario ni siquiera debe saber sobre la acción (por ejemplo, un usuario que no tiene acceso de lectura a los registros de auditoría probablemente no debería saber que estos registros existen) no debería poder ver el botón , así que ocúltalo por completo
Desactivo los elementos en lugar de ocultarlos. De esa forma, el usuario sabe que la opción normalmente estaría disponible y proporciono una información sobre herramientas para explicar por qué el elemento no está disponible actualmente.
Gran pregunta!
Un par de consideraciones:
Si coloca los elementos en la página pero los desactiva, aún hay una posibilidad remota de que el usuario pueda revisar el sistema y habilitarlos mediante javascriptlet.
Si no los muestra, la funcionalidad general puede ser un poco confusa para el usuario general. "¿No debería haber un botón de edición aquí?"
Si vas a mostrar, deshabilitar o mostrar y verificar los elementos, definitivamente haré la validación del lado del servidor. No deje la validación en manos de JavaScript; Creo que las razones para esto son obvias.
La regla general es desactivar el uso si el usuario puede hacer algo en la interfaz de usuario para obtener el privilegio. Deshabilitado significa "usted puede hacer este comando, pero ahora no como están las cosas". La "forma en que son las cosas" incluye la selección actual, así que use la habilitación / deshabilitación si el usuario tiene el privilegio EditEvent para objetos viejos pero no para nuevos objetos. Debería haber una indicación clara de qué objetos son eliminables para que los usuarios entiendan por qué los comandos asociados están deshabilitados para algunos objetos (por ejemplo, si los usuarios generalmente saben que los registros deben conservarse durante 5 años, un campo Age simple puede ser suficiente, tal vez reforzado con una diferencia gráfica para registros mayores de 5 años).
Use los cuadros de mensaje en lugar de deshabilitar si no hay forma de que el usuario tenga claro el motivo de la desactivación suponiendo que tiene un conocimiento promedio del dominio. La información sobre herramientas para controles desactivados, por cierto, es una gran idea, pero puede no ser suficiente por sí misma.
Utilice el ocultamiento si el usuario nunca tiene el privilegio, sin importar lo que haga en la interfaz de usuario dada su posición actual en la organización (p. Ej., No es un administrador de la aplicación). Es abrumador y frustrante usar cuadros de inhabilitación o mensajes para este caso. En lo que respecta a los usuarios, las acciones para las que no tienen el privilegio no son su trabajo (de lo contrario tendrían el privilegio), por lo que los controles asociados simplemente no deberían existir en su UI. La documentación o los manuales de procedimiento de la organización pueden indicar a los usuarios cómo se llevan a cabo tales acciones (por ejemplo, "Su supervisor crea nuevos eventos para usted").
Tengo más detalles en http://www.zuschlogin.com/?p=40 .
Mi sensación personal es que los elementos siempre deben estar presentes. Si el usuario no tiene suficientes permisos para hacerlas, deberían generar un error al hacer clic en ellas.
Sé que los traductores realmente no disfrutan creando un trillón de mensajes de error de "permiso denegado" diferentes, por lo que a menudo esto no se hace en aplicaciones localizadas, que tienden a ocultar los elementos en su lugar.
En la práctica, mucha gente tiende a ocultar las opciones, incluso en aplicaciones no localizadas.
Oculto: este es el mejor enfoque para acciones que nunca están disponibles para el usuario actual. No tiene sentido que el usuario pierda el esfuerzo mental averiguando por qué algo está deshabilitado si no hay ninguna acción que puedan tomar para cambiar esto.
Deshabilitado: este es el mejor enfoque para las acciones que a veces están disponibles, pero no en el momento o en el contexto actual. Una opción deshabilitada debe transmitir dos cosas: primero, la acción no está disponible en este momento, y segundo, hay algo que el usuario podría hacer para que la acción esté disponible (cambie alguna configuración o permiso, seleccione un elemento, ingrese datos de requisitos previos, etc. ) Si puede indicar lo que se debe hacer para habilitar la acción en una información sobre herramientas, mucho mejor. La activación / desactivación de acciones a medida que el usuario ingresa datos o cambia el contexto proporciona excelentes comentarios sobre lo que el programa requiere.
Error con un error: esta es la peor opción. Solo debe recurrir a un informe de error para las operaciones que podrían funcionar: no puede decir que fallará, excepto al intentarlo.
Otras personas han proporcionado buenas respuestas con sugerencias válidas para evitar ocultar elementos y, en su lugar, deshabilitarlos y proporcionar algunas pistas por los motivos.
Entonces, me gustaría verlo desde una perspectiva diferente, pero ¿cómo ocultar algunos elementos de la interfaz de usuario en los casos en que el usuario no necesita verlos, sin importar si tiene o no tiene permisos para acciones particulares relacionadas con los elementos?
Por ejemplo, digamos que los usuarios de alguna función tienen acceso a los registros de vendedores en el sistema.
Pero entonces el analista de negocios dice: "Mira, hay un menú desplegable con la lista de vendedores en esta forma y no debemos permitir que algunos roles específicos lo vean".
El desarrollador pregunta: "Entonces, simplemente eliminamos el permiso de" Leer vendedores "de este rol, ¿verdad? Pero el analista responde: "No, este rol aún debería poder ver a los vendedores en la página de Vendedores. Es solo esta forma en la que deberíamos ocultar la lista de algunos roles y mostrarla a algunos otros roles".
Entonces, el desarrollador agrega un permiso llamado "Mostrar lista desplegable de vendedores en el formulario X".
Ooops, ahora tenemos un problema. El acceso a los mismos datos está siendo controlado por dos permisos separados. Ahora tenemos que descubrir cómo combinar ambos. ¿Y qué pasa si hay más de un formulario en el que la lista del vendedor debe ocultarse para algunos roles? ¿Cómo lo combinamos con "Leer la lista del vendedor"? Para nosotros, los desarrolladores, es algo claro que el permiso "Leer" debería tener una prioridad más alta que "Ver", por lo que incluso si un usuario puede "Ver" una lista, todavía no debería verla (o ver vacía o deshabilitada con un útil sugerencia) si no tiene el permiso "Leer". Nosotros, desarrolladores y analistas del sistema lo sabemos. Pero, ¿cómo debería saberlo el administrador del sistema? ¿Deberíamos enseñarle esto? ¿Cómo podemos garantizar que el administrador no confunda todos esos "Ver" y "Leer" para la lista de datos única?
Como puede ver, todo se complica por una razón: estamos mezclando los permisos de procesamiento de datos con las ventajas de la IU en la lista de permisos de función.
He visto muchos proyectos en los que se complica debido a que los permisos en el servidor se acoplan demasiado a la IU, lo que requiere problemas y posibles agujeros de seguridad (porque tienes varios elementos en el editor de permisos de función para las mismas acciones en los mismos datos) .
Los permisos son sobre el acceso y las operaciones en algunos datos específicos. La IU solo puede reaccionar a los permisos de forma consistente en todo el sistema (deshabilitar con pistas, ocultar, etc.). Nunca debemos inventar nuevas entradas de permisos solo para fines de UI.
Ahora queda la pregunta, pero ¿cómo ocultamos realmente los elementos de la interfaz de usuario para algunos usuarios del sistema para evitar abrumarlos con una gran cantidad de elementos siempre desactivados? Una solución podría ser espacios de trabajo de roles. Si sabemos claramente que los usuarios de alguna función nunca necesitarán acceder a algunos datos específicos, creamos un conjunto de entradas de control de la interfaz de usuario, similar a los permisos, pero esta vez no los llamamos permisos. Y podemos ser realmente sofisticados aquí, incluso permitiendo a los usuarios personalizar libremente su espacio de trabajo y elegir lo que pueden o no pueden ver. Por supuesto, los permisos siempre tendrán la mayor prioridad, pero solo afectarán los datos y el estado de los elementos de la interfaz de usuario y no la visibilidad.
Esos son mis dos centavos. Desafortunadamente, yo mismo no he trabajado en un sistema en el que los permisos y las opciones del espacio de trabajo de la interfaz de usuario estén perfectamente separados porque siempre de alguna manera llego demasiado tarde a un proyecto, cuando el "daño ya está hecho". Pero espero que algún día tenga una oportunidad. Solo espero encontrar un buen ejemplo de cómo hacerlo bien, pero de alguna manera las búsquedas en Internet no me dan nada útil. ¿Significa realmente que nadie más ha llegado a las mismas conclusiones que yo? No lo creo, alguien en el mundo del patrón de diseño de la empresa debería haberse dado cuenta de que esta IU <-> impedancia de la impedancia del permiso hace mucho tiempo.
Según el artículo, los ocultaremos o los desactivaremos. Si el usuario tiene acceso a una característica grande, pero no a una pieza más pequeña dentro de ella, entonces ocultaremos la pieza más pequeña. Sin embargo, si el usuario tiene acceso a varias funciones grandes, pero no a otras, las dejaremos visibles pero desactivadas como una estratagema de marketing para recordarles que las funciones están disponibles para comprar si deciden que las quieren.
También he visto algunos programas que desactivan el elemento del menú y cambian su texto a "Iniciar sesión para hacer blah ..."
Me gusta esto porque no me deja con el "¿por qué no funciona?" sentimiento y me dice inmediatamente qué hacer para que funcione. No es aplicable en todos los casos, pero este es un buen enfoque si puede implementarlo.
Tengo un odio particular hacia las aplicaciones que desactivan los botones. Si es un usuario final, quiere saber por qué no puede usar ese botón. Tenerlo en gris no te dice nada. ¿Cómo se llega al estado para habilitarlo? Los consejos sobre herramientas son una solución, pero no son los mejores, muchos usuarios tendrán problemas con la información sobre herramientas (a menos que trabaje con usuarios experimentados).
Tiendo a manejar los dos tipos diferentes de situaciones de manera diferente. ¿Es esta una acción gobernada por privilegios y por estado del objeto?
Si la persona no tiene suficientes privilegios para realizar una acción, oculto la opción, ellos no saben que pueden realizar la acción.
Si la opción no está disponible porque el objeto no está en un estado que pueda usar esa opción, lo desactivo, permitiendo que la opción sea visible para el usuario, pero no se puede hacer ninguna acción.
De tus ejemplos:
No tendría "Crear evento principal" como una opción. El usuario no tiene privilegios suficientes para verlo.
Tendría el botón Eliminar visible para los administradores. Luego, dependiendo de cómo se haga el resto del sitio (un montón de texto visible, información sobre herramientas, ícono de ayuda, etc.), seguiría esa convención sobre informar al usuario por qué el botón no se puede usar en este momento. Y, posiblemente, poner un temporizador, arriba, cerca del botón con la edad de la publicación o cuánto tiempo hasta que se puede eliminar.
Yo diría deshabilitar con un vuelo estacionario que contiene el motivo.
Evita que el usuario se pregunte qué diablos está pasando y, al mismo tiempo, les hace saber que ciertas acciones son posibles en las condiciones adecuadas.