web-development-kb-es.site

Botón desplegable y opciones de disyunción

En la parte superior de la aplicación, tenemos una barra de funciones que (casi) contiene todas las funciones que se pueden realizar en las entradas de la tabla a continuación, bastante similar a la interfaz de usuario fluida de Office. Intentamos minimizar la cantidad de funciones, pero tenemos varias pantallas en la aplicación que excederán el espacio que hay en la barra. Ahora queremos incluir un botón desplegable/botón de división/botón de menú/....

Sin embargo, tenemos un grupo de funciones donde las opciones son disjuntas y nunca están activas al mismo tiempo, sin embargo, sería sensato agruparlas. Nunca ocultamos botones en la aplicación, sino que los atenuamos.

¿Cómo procedería si la función superior está desactivada (pero es la función más utilizada) y la segunda función está activa?.
¿Debería la segunda función "saltar" a la cima?
¿Debería quedarse allí? Si debe permanecer allí, ¿cómo indico que el botón está inactivo pero que el menú desplegable está activo?.
¿No debería usar un botón de menú?

5
marten

Los botones divididos son excelentes cuando hay un comando que los usuarios usan la mayor parte del tiempo y luego otros que usan la mayor parte del tiempo. Los usuarios tienen acceso rápido con un solo clic a lo que necesitan la mayor parte del tiempo, mientras que los comandos que se necesitan con menos frecuencia todavía están disponibles pero fuera del camino. Así es como contribuye a una interfaz de usuario "fluida" (rápida y sin sentido): al promover la velocidad de los comandos comunes mientras se oculta el desorden de comandos raros.

Aquí las opciones con las que te veo enfrentado en tu situación:

Deshabilitar el botón. Al usar un botón dividido, si mantiene el comando para el botón igual y lo deshabilita cuando sea necesario, los usuarios pueden pensar en todo el menú está deshabilitado (si no se dan cuenta, la pequeña flecha está habilitada). También socava la "fluidez" del botón de división, ya que la mayoría de los usuarios no siempre pueden acceder al comando al que probablemente necesiten acceder.

Intercambiar comando de botón. La segunda peor opción es intercambiar comandos por el botón. Aquí la preocupación es que los usuarios no podrán desarrollar hábitos útiles para cada comando, ya que a veces un comando está en el botón y otras veces está en la división. Tendrán que detenerse, leer el botón y pensar antes de actuar ("está bien, el comando que quiero no está aquí, por lo que debe estar dividido esta vez"). De nuevo, no demasiado bueno para la fluidez. Las pautas de Windows UX permiten hacer que el botón sea el último comando utilizado, bajo el supuesto de que es probable que se vuelva a usar. Si eso se ajusta a su caso, entonces es una buena solución. Sin embargo, tendría cuidado al cambiar un comando ¡diferente del último utilizado (p. Ej., Porque el último comando ahora está deshabilitado) a menos que el nuevo comando sea altamente predecible y "tenga sentido" para sus usuarios No intentaría esto sin una buena cantidad de investigación de usuarios primero.

Botón de menú. Parece que tiene un caso en el que el uso del comando se distribuye de manera más uniforme entre los comandos, de hecho, cada comando no está disponible por una buena parte de el tiempo. Quizás necesite un ¡botón de menú, que es diferente a un botón de división en el sentido de que un botón de menú ¡siempre abre un menú desplegable de comandos, esencialmente lo mismo que un Presiona el menú. Etiquete el botón de menú con la categoría de comandos. Al hacer clic, se despliega una lista estable de comandos, con algunos deshabilitados según sea necesario. Esto significa que sus comandos siempre necesitan dos clics para seleccionar, lo que le cuesta al usuario cierta eficiencia, pero al menos los usuarios no tendrán que detenerse y pensar antes de usarlo.

Botón de alternancia. Por casualidad, ¿son los dos opuestos de comando más comunes mutuamente excluyentes del otro de modo que uno siempre está habilitado y cuando el otro está deshabilitado? ¿y viceversa? Por ejemplo, ¿un comando expande la vista y otro la reduce? Si es así, tal vez pueda combinar los dos en un atributo _ alternar _. Aquí tiene un botón de alternancia (o incluso una casilla de verificación) etiquetado como uno de los estados del atributo (por ejemplo, "Expandir") que el usuario puede establecer (marcar) o no. Todavía tiene una flecha desplegable para otros comandos para ajustar el estado actual. De esta manera, siempre tiene la "misma" función (como la perciben sus usuarios) habilitada como su botón.

Menú de banco. Si hay muchos comandos en el lado dividido, la última opción que se me ocurre es construir un " banco de menú ", esencialmente un botón dividido con más de un botón. Seleccione de dos a cuatro de los comandos más utilizados, donde al menos uno de ellos siempre está habilitado. Dele a cada uno de estos comandos su propio botón de comando que siempre está visible, agrúpelos y agregue una flecha desplegable para los comandos restantes. La desventaja de esto es que ocupa más espacio que un solo botón, y siempre tendrá botones deshabilitados que ocupan un espacio valioso, pero al menos garantiza que el comando más comúnmente necesario esté siempre a un clic de distancia.

9
Michael Zuschlag

Si te entiendo correctamente, es así, tienes un menú, digamos

Save | Edit | Undo

Deshacer como punto principal tiene una opción desplegable para Rehacer, pero puede ser que uno no pueda deshacer nada, solo rehacer.

En este caso, me gustaría que saltara a la cima para ser visto, aunque normalmente es mejor tener un menú consistente. Sin embargo, la gente está acostumbrada a esto, porque es un poco como ocultar botones que no se pueden usar y mostrar botones que se pueden usar.

1
Lukas Oppermann