¿Es mejor evitar una acción prohibida o mostrar un mensaje de error / explicación?

Antes de ocultar completamente una parte de la interfaz de usuario para una función a la que el usuario no tiene acceso, considere:

1. ¿El usuario sabrá sobre esa característica?
2. ¿Pasarán mucho tiempo buscándolo?
3. ¿Sería mejor mantenerlo en algún tipo de estado "deshabilitado" junto con información sobre herramientas u otro indicador para que puedan saber por qué no está disponible?

Aquí hay un ejemplo simple. Suponga que su aplicación incluye la opción de imprimir. Cuando no hay una impresora disponible, ¿debería ocultar completamente el comando del menú de impresión? ¿Causará esto confusión y pérdida de tiempo cuando el usuario busque en todos los menús y finalmente contacte a su equipo de soporte técnico tratando de encontrar el comando "imprimir"? ¿Su equipo de soporte técnico comprenderá incluso que este usuario no está viendo el comando "imprimir"? ¿Habrá efectos secundarios no deseados si, por ejemplo, la impresora está conectada pero se ha apagado para ahorrar energía?

Como regla general, creo que en muchos casos, especialmente en los casos en que una opción a veces está disponible, los usuarios son mejor atendidos por una opción deshabilitada o incluso una opción habilitada que muestra un mensaje de error que explica POR QUÉ la opción no es actualmente disponible.

Veo dos enfoques diferentes.

Si las acciones están deshabilitadas debido a seguridad, realmente trataría de eliminarlas si es posible. Fácil con elementos de menú o la mayoría de los botones de la barra de herramientas.

Si las acciones están deshabilitadas porque tienes una versión más barata del software, las mantendré presentes pero deshabilitadas. Esto le permite al usuario saber "podría tener esto si pagara más", mientras que si se eliminara no sabría lo que le faltaba. Veo que la ventana emergente "no puede hacer esto debido a la licencia" es una interfaz de usuario incorrecta, ya que el usuario no puede saber si puede hacer una acción sin realmente intentar hacerlo.

Otro enfoque es no mostrar la acción en absoluto.

Stack Exchange es un buen ejemplo de esto. Si no tengo derechos de "edición" para las publicaciones de otras personas, no veo un enlace "editar" en absoluto. Esto significa que no trato de hacer clic y me pregunto por qué no funciona.

Es posible que esto no funcione en todas las circunstancias, pero en su ejemplo las opciones/enlaces "admin" y "financiero" simplemente no aparecerían para usuarios limitados, incluso en las pantallas de administración para esos usuarios. Si el usuario fue cambiado a un usuario "Regular" o "Premium", aparecerían esas opciones/enlaces.

¡Entonces podría considerar mostrar el tipo de usuario en algún lugar semi prominente para que el administrador pueda recordar por qué ciertas opciones/enlaces no son visibles!

Como han dicho otras respuestas, si el usuario no tiene permiso para realizar una acción dentro del sistema (como en, sin privilegios de edición/administrador), entonces la acción no debería mostrarse en absoluto.

En los casos en que las acciones están deshabilitadas debido al estado de la aplicación (no se puede editar un archivo de solo lectura, no se puede copiar/pegar si no se selecciona texto, el usuario tiene una versión de prueba del software que carece de algunas características, etc.) piensa que la acción debería ser mostrada, con una indicación visual de que la acción no se puede realizar actualmente. Tenga en cuenta que no digo "deshabilitado", porque si el usuario intenta esa acción, debería poder averiguar por qué no es factible. De esta forma, un usuario puede ver que la acción está deshabilitada, pero también puede recibir un mensaje explicando por qué.

Tendría cuidado con el caso en que un usuario tiene una versión de prueba/con licencia de una aplicación que carece de funciones. Por ejemplo, si tuviera una aplicación de lectura/escritura ISO que no ripearía CDs a menos que pagara por ella, entonces podría mostrar la opción "copiar CD" pero no dejar que el usuario la ejecute. Pero si su aplicación tiene características completas de suites en las versiones de gama alta (visual studio, por ejemplo), mostrar todas esas cosas pero no permitirlas podría ser frustrante para el usuario. No quiero abrir mi IDE y ver bases de datos, redes, UML integrado, pruebas, perfiles, etc. suites cuando sé que todo lo que tengo licencia para hacer es escribir y construir proyectos .

Mi regla de oro es: si una acción no está disponible para un usuario debido a permisos, no es visible. Si una acción no está disponible debido al contexto temporal (este botón 'Guardar' no tiene sentido hasta que el usuario haya ingresado algo para guardar), entonces está deshabilitado.

"Permisos" cubre tanto "usuario administrador frente a usuario normal" como "licencia premium frente a licencia de cheapo". Los elementos de IU inutilizables son desorden, no es la forma de anunciar sus características adicionales.

Muchas respuestas parecen acertar, solo quería resumirlo todo con una de las heurísticas de Nielsen, que apunta exactamente a esto. Afirma:

Prevención de errores Incluso mejor que los buenos mensajes de error es un diseño cuidadoso que evita que ocurra un problema en primer lugar. Elimine las condiciones propensas a errores o verifíquelas y presente a los usuarios una opción de confirmación antes de comprometerse con la acción.

Fuente: http://www.useit.com/papers/heuristic/heuristic_list.html

Realmente me gusta shemnon's respuesta. Extendería su segundo caso y aplicaría el mandamiento de Nielsen mencionado por ign; si el usuario tiene una licencia más barata, deshabilitaría la opción y reemplazaría el objeto de selección con un icono que aclare aún más el estado deshabilitado de la opción.

Algo como

• O Opción 1
• O Opción 2
•  Opción 3
• O Opción 4

Como este producto de suposición todavía está en desarrollo, también incluiría al menos una declaración del nivel de licencia del usuario en la misma página. De esa manera, el administrador ve que el nivel de licencia del usuario al mismo tiempo que el administrador observa las variables del sistema directamente afectadas por esa licencia.

Una belleza del software es que todo lo que tiene que hacer es llamar a la información.

Editar: Además, podría emplear un esquema de permisos centrado en roles, donde los permisos se pueden asignar a roles y no a usuarios individuales. A menudo, esto mitiga una tonelada de sobrecarga de la necesidad de administrar de manera individual los permisos de los usuarios.

1. El administrador abre la pantalla de edición de roles.
2. El administrador puede seleccionar un botón de opción para la licencia más baja a la que se aplicará el rol.
3. Los permisos que no están disponibles para el rol seleccionado están deshabilitados y editados con "x".
4. El administrador selecciona los permisos de las opciones activas restantes.
5. Más tarde, en la pantalla de administración de usuarios o el perfil de usuario, el administrador ve una lista de roles que el usuario puede tener según la licencia, y el administrador selecciona uno o varios.

En general, mi regla de oro es la siguiente (y necesito tener una buena razón para romperlo): si el razonamiento detrás del componente deshabilitado fluye del contexto o esa comprensión debería ser fácil para el usuario debido a otra razón, entonces el bloqueo es la solución preferida. De lo contrario, el usuario podría sentirse frustrado al tratar de descubrir por qué es así, y lo que es peor, probablemente no recordará la razón (caso lo descubrió) la próxima vez que lo encuentre.

Para responder a su pregunta específica, desea mostrar información suficiente para que los usuarios puedan comprender las limitaciones antes de hacer clic. En su ejemplo, usted debería enumerar a cada usuario con su licencia como un campo de solo lectura conectado visualmente (por ejemplo, por proximidad) con los controles para configurar su permisos O puede combinar el campo de licencia dinámicamente con la etiqueta de los permisos (por ejemplo, "Permisos (con licencia limitada):").

Los permisos no aplicables probablemente deberían estar deshabilitados, no habilitados y no ocultos. Si vale la pena el desorden, incluya texto en línea, texto emergente/información sobre herramientas o un enlace para explicar por qué los permisos no están permitidos por la licencia (el texto en línea puede reemplazar los controles deshabilitados si enumera los permisos; por ejemplo, "Admin , Financiero no permitido para usuarios limitados ").

La regla general es deshabilitar el uso si el usuario puede hacer algo en la interfaz de usuario para habilitar el comando. Desactivado significa "puedes hacer este comando, pero ahora no como están las cosas". La "forma en que están las cosas" incluye la selección actual. Siempre que use la desactivación, debe haber una indicación clara para que los usuarios entiendan por qué los comandos asociados están desactivados para algunos objetos.

Use cuadros de mensaje en lugar de deshabilitar si no hay de ninguna manera para aclarar el motivo de la deshabilitación al usuario de antemano, suponiendo que tenga un conocimiento promedio del dominio. La información sobre herramientas para los controles deshabilitados es una gran idea, pero puede no ser suficiente por sí sola en todos los casos.

Use ocultar si el usuario nunca tiene acceso al comando sin importar lo que haga en la interfaz de usuario dada su posición actual en la organización. Por ejemplo, las acciones no autorizadas por el usuario con sus permisos simplemente no aparecen. Es abrumador y frustrante utilizar cuadros de mensaje o de desactivación para este caso. En lo que respecta a los usuarios, las acciones para las que no tienen los derechos no son su trabajo (de lo contrario tendrían acceso), por lo que los controles asociados simplemente no deberían existir en su interfaz de usuario. La documentación o los manuales de procedimientos de la organización pueden indicar a los usuarios cómo se llevan a cabo tales acciones (por ejemplo, "Su supervisor crea nuevas cuentas de clientes para usted" o "Necesita permisos financieros para editar cuentas; consulte a su administrador para obtener el procedimiento para obtener la aprobación para actualizar sus permisos. ").

Tengo detalles sangrientos en Control de sus controles .

Algunos de los puntos anteriores son geniales, y no quiero repetirlos, pero ...

En este caso, tendría todas las opciones disponibles visibles. Las opciones que no eran aplicables en sus reglas deberían deshabilitarse (atenuarse). Es de conocimiento común para un usuario de cualquier interfaz reconocer que si algo está atenuado, generalmente significa que no es aplicable para algún tipo de conjunto de reglas.

La información sobre herramientas coincide perfectamente con un botón desactivado. En algunos casos especiales más avanzados, como el anterior con licencias, si el usuario sin la licencia adecuada estaba viendo un área que requería una licencia más alta, cambiando completamente el arte del botón a algo como "¡Actualizar ahora!" en lugar de atenuarlo, sería mejor publicitar el producto y transmitir el mensaje.

Si el usuario administrador lo estuviera viendo, obviamente verían que la opción financiera está atenuada, con una sugerencia de herramienta que explica por qué.

No conozco completamente el contexto de su problema, puede que ni siquiera haya un producto involucrado. Pero según lo que entendí, esa es mi reacción.

Windows UXGuide tiene bastantes recursos que pueden ayudarlo a decidir si mostrar errores o evitar entradas no válidas. Específicamente hay na sección que hace la siguiente declaración sobre ui.

No envíe mensajes de error cuando los usuarios no puedan realizar una acción o cambiar su comportamiento como resultado del mensaje. Si no hay ninguna acción que los usuarios puedan tomar, o si el problema no es significativo, suprima el mensaje de error.

Además, esta discusión me recuerda un poco a lo que Karl Shifflett en su publicación de blog titulado "Fort Knox Business Objects (yes/no)", donde evalúa los pros y los contras de permitir que los objetos comerciales entren en un estado no válido o no y cómo esta decisión afecta la interacción del usuario.

Personalmente, tiendo a evitar que un usuario realice entradas no válidas o deshabilite controles que realizan acciones como botones la mayor parte del tiempo, pero para algunos controles que involucran entradas de texto complejas, tiendo a mostrar advertencias en línea que son menos molestas que los cuadros de mensaje pero aún así El punto al otro lado.

Hacer ambas cosas: backend y UI

Esto realmente no debería ser una o una situación. Las otras respuestas enumeran buenas razones para mostrar opciones no disponibles, y buenas razones para no mostrarlas. Pero la cuestión es que, de cualquier manera, debe manejarlo correctamente en el backend. Aún debe verificar adecuadamente las entradas y permisos de los usuarios, incluso si cree que la única entrada que pueden dar es la correcta.

Esto es doblemente cierto con cualquier aplicación basada en la web, donde el usuario podría habilitar artificialmente un control/opción/entrada deshabilitado. No dejes que el uso de Firebug supere la capacidad de tu aplicación para controlar lo que puedo hacer. Y en los casos en que intenten utilizar una opción que no debería estar disponible, asegúrese de registrar el evento.