- Si se maneja con el mismo toggle una acción inmediata como Play/Pause y una configuración persistente como Shuffle, el usuario puede confundir el estado actual con la siguiente acción
- About Face 2.0 recomienda evitar el flip-flop button, que pone dos opciones en un solo control, y considera más importante comunicar el estado actual que ahorrar espacio
- La solución se acerca más a expresar la acción como una frase verbal, como
Switch to portrait mode, o a separar estado y cambio con botones de opción, casillas de verificación o una etiqueta de estado + botón de acción - Si el texto está dentro del botón, como en los switches estilo iOS,
ONpuede resultar ambiguo: no queda claro si es el estado actual o el siguiente; en estilos como OS X o Windows Metro, poner el texto de estado fuera del botón reduce esa ambigüedad - La convención de Play/Pause puede mostrar excepcionalmente la siguiente acción, pero para opciones como Shuffle, Like o Auto save es más seguro enfatizar el estado actual y reforzarlo con tooltips, color, estado presionado o una etiqueta aparte
Conflicto entre mostrar estado y mostrar acción
- En botones que alternan entre dos estados, como Play/Pause o Shuffle/Regular Play, la cuestión central es si deben mostrar el estado actual o el estado al que cambiarán después del clic
- Play/Pause suele percibirse fácilmente como una acción de “iniciar reproducción” o “pausar”, por lo que la convención de mostrar Play cuando está detenido y Pause cuando está reproduciendo resulta familiar
- Shuffle/Regular Play se parece más a un estado de opción del modo de reproducción, así que mostrar el estado al que cambiará puede hacer confuso si actualmente está en shuffle o en reproducción secuencial
- El reproductor de música integrado de Xbox 360 se menciona como un caso confuso: mostraba directamente el ícono de reproducción secuencial cuando estaba en modo shuffle, y viceversa en la situación opuesta
Recomendación de About Face: evitar el flip-flop button
- About Face 2.0 clasifica este tipo de control como un flip-flop button, un patrón de elección que conviene evitar
- Cuando un solo botón controla dos opciones mutuamente excluyentes, se ahorra espacio, pero se vuelve difícil cumplir con la segunda obligación del control: comunicar el estado actual
- Si el botón muestra
ONcuando en realidad el estado actual es apagado, la configuración queda poco clara; y si muestraOFFestando apagado, puede surgir la duda de dónde está el botónON - Se recomiendan dos soluciones
- Escribir la acción del botón como una frase verbal, por ejemplo
Switch to portrait mode - Usar otra técnica de UI donde la selección de estado sea explícita, como dos botones de opción
- Escribir la acción del botón como una frase verbal, por ejemplo
Distinguir entre botones de acción y botones de estado
- Un action button y un state button deben diseñarse de forma diferente
- Si es una acción, como Play/Pause, debe mostrar lo que ocurrirá al hacer clic
- Si es una opción, como Shuffle/Linear, debe mostrar el estado actual
- Si el botón de Shuffle usa solo ícono, conviene mantener un único ícono de shuffle y hacer que, según el estado, se vea activo/inactivo
- Cuando está encendido, puede verse más brillante o como un botón presionado
- Cuando está apagado, debe seguir quedando claro que el modo es reproducción secuencial
- En entornos con hover, se puede añadir un tooltip para hacerlo aún más claro
- También existe la opinión de que incluso Play/Pause podría generar menos confusión si no cambiara la etiqueta y, en cambio, el botón
Playse mostrara como presionado
La ambigüedad creada por el texto dentro del botón
ONyOFFen inglés pueden leerse tanto como estados como acciones de cambio, así que ponerlos dentro del botón puede volver difuso si se trata de un estado o un comando- Se proponen pares de palabras más explícitos, como
Enable / DisableEnabled / DisabledStart / StopRunning / Stopped
- Aun así, el problema no desaparece por completo solo con elegir otras palabras
- El usuario puede seguir teniendo que interpretar si el texto del botón expresa un estado o una orden
- La diferencia entre
EnableyEnabledpuede no ser lo bastante clara dentro de una UI
Etiquetas fuera del botón y separación entre estado y acción
- Si no se pone texto dentro del botón y, en cambio, se coloca texto fuera del botón, es posible mostrar a la vez el estado actual y el estado al que puede cambiar
- El switch estilo OS X no dice
ONniOFFdentro del botón; el texto alrededor del switch indica el estado, reduciendo así la pregunta de si el botón representa el estado actual o la siguiente acción - En el enfoque de Windows Metro UI, el color del botón indica el estado actual y el texto
On/Offdebajo de la opción vuelve a confirmar ese estado - También es posible separar etiqueta de estado + botón de acción, por ejemplo
Online [Go offline]Onlinees una etiqueta no clicable del estado actualGo offlinees la acción clicable de cambio- Después del clic, cambia a
Offline [Go online]
- Este enfoque puede ser más compacto que los botones de opción y, al mismo tiempo, separar visualmente el rol del estado y el de la acción
Casillas de verificación, botones de opción y estado presionado
- Opciones como Shuffle generan menos confusión si se representan con una casilla de verificación etiquetada como
Shuffle - Si se usa una sola palabra y el estado marcado indica si está activo, disminuye la carga de tener que interpretar el significado entre varias palabras
- Conviene evitar expresiones con prefijos negativos
- Prefijos como
Not,Non-,Un-,Dis-,Im-,Mis-,In-,Il-,Ir-pueden leerse como una doble negación cuando se combinan con un estado desmarcado
- Prefijos como
- El botón Like de la app de Facebook para Android se menciona como ejemplo: gris cuando está apagado y resaltado en azul cuando está encendido
- Aun así, depender solo del color puede no ser suficiente para personas con deficiencias en la visión del color
Casos reales de UI y precauciones
- Existe una solución intermedia como el botón Shuffle de la web app de Spotify, que usa un color neutro cuando está apagado y un color destacado cuando está encendido
- El cambio estilo Twitter al pasar el mouse muestra el estado actual y, al hacer hover, muestra la acción
- Puede funcionar en entornos con hover, pero no necesariamente en pantallas táctiles
- El switch estilo iOS muestra ambos estados dentro de un solo control, pero también ha recibido críticas porque
ONpuede ser ambiguo: no se sabe bien si es el estado actual o el que se activará al pulsar - La UI de configuración de Discord es un ejemplo de toggle tipo checkbox que hace más claro el estado actual y el futuro
- También se mencionan ejemplos como el toggle con mouseover de Evernote o el interruptor tipo manija de los baños de avión, donde estado y posibilidad de acción se perciben al mismo tiempo
Principios de diseño
- Cuando un solo control asume a la vez la tarea de comunicar estado y comunicar acción, aparece la ambigüedad
- El estado actual debe comunicarse de alguna manera sin falta
- En Play/Pause, retroalimentación externa como escuchar la música o ver correr el tiempo puede complementar el estado actual
- En Shuffle, el estado es más difícil de inferir hasta ver cómo se elige realmente la siguiente canción, por lo que la indicación del propio botón se vuelve más importante
- Un solo botón que hace circular varios estados puede compactar la UI y agrupar configuraciones mutuamente excluyentes, pero el usuario debe poder entender rápidamente cuál es el estado actual
- Play/Pause puede ser una excepción por la fuerza de su convención, mostrando la siguiente acción, mientras que en toggles de opciones generales es más consistente enfatizar el estado actual
1 comentarios
Opiniones de Hacker News
Últimamente Microsoft Teams me tiene realmente frustrado. En la app de escritorio, cuando estás silenciado se ve un ícono de micrófono con una línea atravesada, y cuando se quita el silencio cambia a un micrófono sin línea, así que es fácil de entender.
Pero si entras desde la app del celular, ese mismo ícono de micrófono tachado significa “actualmente no estás silenciado; si presionas este botón, te silenciarás”. Incluso después de presionarlo, el ícono sigue siendo el micrófono tachado, solo se invierte el fondo.
Me pregunto si en un lado es un botón de “activar micrófono” y en el otro un botón de “activar silencio”, y por eso usan el mismo ícono. Al final, para juzgar el estado actual tienes que saber cómo se ve el botón en el estado opuesto, así que siempre termino presionándolo varias veces para comprobar qué enfoque usa esta app.
Me pregunto si este es el precio de la flat UI que perdió sus referentes del mundo real.
Las mezcladoras de audio para música en vivo o grabación también suelen usar el mismo patrón. Cuando un canal está apagado, se enciende una luz roja en un botón “Mute”, y solo algunos equipos muestran que el canal está activo con un botón “ON” encendido encima del fader.
Creo que ya es hora de que las apps de reuniones pasen a un enfoque en el que el audio está apagado por defecto. Ya se ve un poco en la forma en que los elementos de la UI se encienden cuando habla quien tiene la palabra.
Cada vez que cambio de dispositivo, mi cerebro se queda trabado un instante.
Incluso cuando está encendido, es una herramienta con mucho retraso en el feedback. La otra persona puede haberse detenido, o quizá está pensando antes de responder, así que muchas veces hay que probar dos o tres veces para estar seguro.
No es como el modo oscuro, que se ve de inmediato al activarlo o desactivarlo. Por eso, sin importar qué haga el botón, ayuda mucho tener una indicación visual del estado actual, y no sorprende que en los micrófonos haya tantos intentos de mezclar “estado” y “control”.
Si eres dueño de un Tesla, no queda más que estar de acuerdo. Los botones de alternancia de la UI del auto son tan variados que no hay consistencia ni estándar.
Por ejemplo, el botón del climatizador es un solo botón que muestra la temperatura, pero reacciona de manera distinta según cómo lo presiones y por cuánto tiempo. Si lo tocas brevemente, aparece un pequeño popup; si lo mantienes un poco más, aparece todo el panel de control del climatizador; y si lo mantienes presionado unos segundos, puede apagar el climatizador que estaba encendido. El problema es que todo esto hay que hacerlo mientras manejas y tienes que mirar la carretera.
Si la coordinación mano-ojo falla apenas un poco —algo muy probable, sobre todo al pasar por un bache mientras manejas—, con desviarte solo 1 mm puedes presionar otro botón y provocar una acción no deseada.
Otro desastre es la UX de conexión de dispositivos Bluetooth. Al menos la implementación del Model S 2012–2022 fue una de las peores mezclas de UI que he visto en un producto lanzado. El botón de abajo a la derecha sigue diciendo “Connect” incluso después de que ya está conectado, mientras que en el otro lado de la pantalla, arriba a la izquierda, primero dice “Connecting...” y luego muestra que la conexión se completó.
Esto también es una UI dentro del auto, así que si vas manejando solo puedes mirarla por un instante. La UI de Bluetooth de Tesla por sí sola es tan magníficamente mala que podría llenar un capítulo entero de un libro de UI.
Un candado cerrado significa que la puerta está cerrada con seguro, y si lo presionas, la puerta se abre.
La palabra “Open” del maletero significa que el maletero está cerrado, y si la presionas, el maletero se abre.
Cuando quiero apagarlo, vuelvo a presionar el botón para abrir el control completo y luego presiono el botón de apagado. La temperatura la subo o bajo haciendo clic en el botón y luego deslizando a la izquierda o a la derecha.
A mí me parece bastante intuitivo. La próxima vez que maneje voy a probar también apagarlo manteniéndolo presionado; parece bastante útil.
Viendo que las implementaciones siempre son tan malas, me pregunto si no habrá algo gravemente enredado en la propia especificación de Bluetooth.
Hace tiempo tenía algunos interruptores pulsadores de NASA, y adentro tenían dos focos. Si el interruptor estaba apagado, ambos estaban apagados; al presionar el botón se encendía un foco amarillo, mostrando que la operación del interruptor había sido recibida.
Cuando el dispositivo que se quería encender efectivamente se encendía, se prendía una luz verde y la amarilla se apagaba. El estado amarillo era una confirmación de que se había accionado el interruptor, y el verde confirmaba que la acción deseada realmente había ocurrido; un mecanismo interesante de retroalimentación de estado.
Poner la etiqueta fuera del interruptor también funciona bien[2].
[1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header...
[2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
En su lugar, ponía un botón para cada opción y hacía que se iluminara el botón correspondiente al estado actual. Por ejemplo, un toggle de encendido/apagado lo convertía en dos botones: “on” y “off”. Al principio ambos estaban grises; si desde el hardware llegaba un SOH indicando estado encendido, el botón on se ponía verde; si indicaba apagado, el botón off se ponía rojo.
Si se perdía la comunicación durante un rato, atenuaba todos los colores para indicar que el estado estaba desactualizado. Al presionar un botón, seguía mostrando el estado anterior hasta que llegara el nuevo estado, pero atenuaba solo ese grupo de botones.
El usuario podía ordenar directamente on u off en cualquier momento, sin importar qué estado creyera tener la UI. En cambio, un toggle solo puede cambiar a “el otro estado”.
También reemplacé los radio buttons por grupos de botones con el nombre de cada estado, y solo coloreaba el elemento que la UI creía que era el actual. La mayoría de los estados neutrales eran azules; cuando tenían un significado de bueno/precaución/malo que el operador quisiera resaltar, usaba verde/amarillo/rojo.
Era un diseño inusual, pero en general los operadores lo entendían sin capacitación aparte. Los botones se veían como botones y parecían clicables, el espaciado dejaba claro que formaban un grupo, y en las UI de los 90 el gris era el valor predeterminado, así que el botón con otro color destacaba naturalmente como el estado actual.
No sé si eso funcionaría hoy, en un entorno donde los elementos de UI usan cualquier color por razones estéticas o para empujar una conversión, y solo a veces transmiten información. También experimentamos con mostrar al mismo tiempo el estado de comando y el estado recibido, como los botones de NASA, pero todos esos intentos resultaron más confusos.
Oh, checkbox, 1990-2009. Era perfecto e inequívoco, pero por alguna razón los diseñadores de smartphones lo odiaron.
Si no está marcado muestra “Not Urgent”; si está marcado, “Urgent”. Lo marqué y desmarqué varias veces rápido, pensé que había indicado que no era urgente y luego presioné enviar.
El checkbox predeterminado del navegador es demasiado pequeño para tocarlo con el pulgar en un smartphone, así que cuesta usarlo con frecuencia.
El peor ejemplo que he visto es la UI de la pantalla del tablero de Tesla. Sobre el dibujo del auto hay etiquetas que no parecen botones y dicen “Open”.
Eso se lee claramente como que esa parte está abierta, pero en realidad no significa eso. Esa etiqueta es un botón para abrir esa parte, y el usuario no tiene forma de saberlo.
En general, la UX de Tesla está muy por delante de la de otros autos, pero estos pequeños detalles son muy frustrantes.
Parece que cada quien lo percibe distinto.
Parece que se podría evitar usando algo como “Do open” o “Is open”, pero ¿a un hablante nativo le sonaría raro?
El problema central de un botón de alternancia es que un solo objeto contiene al mismo tiempo el estado del sistema y la acción que lo cambia.
Por eso no queda claro si el “ON” que aparece en el botón es el estado actual o la acción que se ejecutará al presionarlo.
La solución es separar en cierta medida el estado y la acción. Hay varias formas de hacerlo; una es poner la etiqueta fuera del botón, como en una de las respuestas del enlace.
Si no se trata de un interruptor sino de un botón de alternancia como el ejemplo de Teams, se puede dejar el ícono igual y cambiar otra propiedad del botón. Por ejemplo, dejarlo en estado presionado para mostrar que está en “ON”, como se hizo durante décadas sin problemas.
Estoy de acuerdo con la conclusión, pero tanto cuál es el estado actual como a qué estado se cambiará al alternar deben quedar claros. Demasiadas veces termino probando el interruptor para recién después darme cuenta de que no hacía falta cambiarlo.
El caso de reproducir/pausar es interesante, porque parece contradecir la conclusión. Pero sigue un precedente físico bien entendido y, por lo general, también está claro si la música o el video se está reproduciendo. Por eso, aunque el ícono del botón no cambie, el usuario puede entender qué ocurrirá si lo presiona.
Volviendo a los toggles y la UI, cambiar el color del toggle de gris claro a un gris apenas más claro es extremadamente poco útil. Pongan una etiqueta. Si la etiqueta no encaja con el motivo de diseño, necesitan conseguir un mejor diseñador.
Los diseñadores de software no siguieron eso y crearon la práctica de alternar entre los íconos de reproducir/pausar, generando nueva confusión. No fue tanto por razones de facilidad de uso, sino porque los botones 3D esqueuomórficos pasaron de moda.
La única ventaja de mostrar el estado aparece cuando hay problemas. En especial con audio, donde es muy común: silencio activado, audífonos desconectados, el driver de audio de Linux volvió a romperse, y situaciones similares.
Incluso ahora, cuando veo un botón de reproducir/pausar, me da un poco de disonancia cognitiva, y como no puedo estar 100% seguro de qué significa exactamente el botón de pausa, cuando hay algún problema a veces simplemente lo presiono dos veces.
Por ejemplo, Spotify no tiene espacio para poner una etiqueta detrás de cada botón. También necesita espacio para mostrar la portada del álbum, y yo quiero eso.
No es un problema de conseguir un mejor diseñador: las restricciones de espacio existen de verdad. Algunas funciones tienen que poder hacerse con un solo toque. No quiero que el modo aleatorio quede escondido detrás de un menú emergente.
Un botón de alternancia debería mostrar el estado actual. Una casilla de verificación es un buen ejemplo.
Muted []yMuted [x]son bastante claros.La cosa se complica cuando el diseñador crea una UI donde la conexión entre las palabras y el diseño visual no es clara. Por ejemplo, algo como
Mute Off [---( )]oMute On [( )---]mezcla acciones dentro de la descripción del estado, y ya no se entiende qué significa.Altavoz [()---] Altavoz tachadoMuted [x]podría leerse como que algo falló.Entenderlo de otra forma requiere aprender UX de computadoras, lo cual es lo opuesto a ser obvio. O tal vez, como en “X marks the spot”, podría significar que es el objetivo en el que hay que hacer clic cuando quieres silenciar.
[1] Unicode U+2714 https://www.compart.com/en/unicode/U+2714
[2] p. ej. https://www.githubstatus.com/
Los botones de alternancia son confusos porque no se puede saber la intención del diseñador. Es difícil saberlo a menos que se muestren juntas las dos opciones.
Silenciar On[---()]OffUn botón existe para ser presionado, así que debe comunicar qué ocurrirá al presionarlo.
Debería mostrar ambas cosas, como un interruptor analógico. Debe mostrar el estado actual de forma clara y sin ambigüedades, y al mismo tiempo mostrar el estado al que cambiará.
El toggle deslizante izquierda-derecha de Apple logró esto muy bien. Se ve claramente dónde está el toggle ahora, hacia dónde cambiará, y si la configuración actual tiene la función activada con el fondo azul o desactivada con el fondo gris.
Uno de los diseños que me gustaba tenía una luz de estado junto al interruptor, y cuando el estado se encendía, esa luz se prendía; ahora no puedo encontrarlo.
Lo mejor era que también resolvía la demora de las tareas asincrónicas. Presionabas el interruptor, el interruptor alternaba, y un momento después se encendía la luz. Era muy satisfactorio porque daba la certeza de que la interacción realmente había hecho algo.
El problema es si representa un estado o una acción. Un diseño específico podría no haber sido ambiguo, pero con solo la descripción sí lo es.
Claro, solo funcionaría si el usuario no tiene desde el principio el brillo de la pantalla demasiado alto.