Modo (interfaz de usuario)

En el diseño de interfaces de usuario , un modo es una configuración distinta dentro de un programa informático o cualquier interfaz de máquina física , en la que la misma entrada del usuario producirá resultados percibidos diferentes de los que produciría en otras configuraciones. Los componentes de la interfaz modal incluyen las teclas Bloq Mayús e Insertar del teclado estándar de la computadora , las cuales normalmente ponen la escritura del usuario en un modo diferente después de ser presionadas, y luego la devuelven al modo normal después de ser presionadas nuevamente.

Una interfaz que no utiliza modos se conoce como interfaz sin modo . ^[1] Las interfaces sin modo evitan los errores de modo , en los que el usuario realiza una acción apropiada para un modo mientras está en otro modo, al hacer que sea imposible para el usuario realizarlos. ^[2]

En su libro The Humane Interface , Jef Raskin define la modalidad de la siguiente manera:

"Una interfaz hombre-máquina es modal con respecto a un gesto dado cuando (1) el estado actual de la interfaz no es el locus de atención del usuario y (2) la interfaz ejecutará una entre varias respuestas diferentes al gesto, dependiendo del estado actual del sistema". (Página 42).

En el sentido de Raskin y según su definición, una interfaz no es modal siempre que el usuario sea plenamente consciente de su estado actual. Raskin se refiere a esto como "locus de atención" (de la palabra latina locus que significa "lugar" o "ubicación"). Normalmente, un usuario es consciente de un estado del sistema si el cambio de estado fue iniciado deliberadamente por el usuario, o si el sistema da algunas señales fuertes para notificar al usuario del cambio de estado en el lugar donde se produce la interacción. Si el locus de atención del usuario cambia a un área diferente, el estado de la interfaz puede representar un modo, ya que el usuario ya no es consciente de él.

Larry Tesler definió los modos como "un estado de la interfaz de usuario que dura un período de tiempo, no está asociado con ningún objeto en particular y no tiene otra función que la de dar una interpretación a la entrada del operador". ^[3]

Esta sección necesita una ampliación con una descripción detallada de los usos típicos de los modos. Puedes ayudar agregándole algo más. ( Diciembre de 2010 )

Se han descrito varios ejemplos de software como modales o que utilizan modos de interfaz:

• Editores de texto : normalmente están en modo de inserción de manera predeterminada, pero se puede activar y desactivar el modo de sobreescritura presionando la tecla Insertar .
• Bravo (editor) : el primer editor modal WYSIWYG creado para computadoras Xerox Alto en Xerox PARC por Butler Lampson y Charles Simonyi
• vi – tiene un modo para insertar texto y un modo independiente para ingresar comandos. También hay un modo " ex " para emitir comandos más complejos (por ejemplo, buscar y reemplazar). En circunstancias normales, el editor regresa automáticamente al modo anterior después de emitir un comando; sin embargo, es posible pasar permanentemente a este modo usando Shift-Q .
  • Derivados, como Vim y Neovim
• Emacs – tiene el concepto de "teclas de prefijo", que activan un estado modal al presionar la tecla de control más una tecla de letra. Emacs luego espera pulsaciones de teclas adicionales que completen una combinación de teclas . Esto difiere de vi en que el modo siempre termina tan pronto como se llama al comando (cuando se completa la secuencia de pulsaciones de teclas que lo activa). Emacs también tiene muchos modos "mayores y menores" que cambian los comandos disponibles y pueden invocarse automáticamente según el tipo de archivo para editar más fácilmente archivos de ese tipo. Los modos de Emacs no se limitan a la edición de archivos de texto; existen modos para la exploración de archivos , la exploración web , IRC y el correo electrónico y sus patrones de interacción son equivalentes al software de aplicación dentro del entorno de Emacs. Los modos están escritos en Emacs Lisp y es posible que no todos los modos estén incluidos en todas las versiones.
• Cisco IOS : ciertos comandos se ejecutan en un "modo de comando".
• Las herramientas seleccionadas de una paleta en aplicaciones de edición de fotografías y dibujo son ejemplos de una interfaz modal. Algunos editores de imágenes avanzados tienen una función que permite acceder a las mismas herramientas de forma no modal al presionar una tecla, y permanecen activas mientras se mantenga presionada la tecla. Al soltar la tecla, la interfaz vuelve a la herramienta modal activada por la paleta.
• Los videojuegos pueden utilizar los modos de juego como mecánica para mejorar la jugabilidad .
• Las ventanas modales bloquean todo el flujo de trabajo en el programa de nivel superior hasta que se cierra la ventana modal. ^[4]

Larry Tesler, de PARC, diseñó ideas para un procesador de textos sin modalidad a partir de los comentarios obtenidos en una prueba de usuario con la recién contratada Sylvia Adams, en la que se le pidió que improvisara algunos gestos para corregir las marcas de corrección en el texto digital. ^[5] Esta prueba convenció al gerente de Tesler, Bill English, de los problemas con su interfaz modal anterior.

Los modos suelen estar mal vistos en el diseño de interfaces porque es probable que produzcan errores de modo cuando el usuario olvida en qué estado se encuentra la interfaz, realiza una acción que es apropiada para un modo diferente y obtiene una respuesta inesperada y no deseada. ^{[6] [7]} Un error de modo puede ser bastante sorprendente y desorientador mientras el usuario se enfrenta a la repentina violación de sus expectativas de usuario.

Los problemas surgen cuando un cambio en el estado del sistema ocurre sin que nadie se dé cuenta (iniciado por el sistema o por otra persona, como el usuario que estaba usando la máquina anteriormente) o si después de un tiempo el usuario se olvida del cambio de estado. Otro problema típico es un cambio repentino de estado que interrumpe la actividad de un usuario, como el robo de foco . En una situación así, puede suceder fácilmente que el usuario realice algunas operaciones con el estado anterior en mente, mientras que el cerebro aún no ha procesado por completo las señales que indican el cambio de estado.

• La fuente más común de errores de modo puede ser la tecla Bloq Mayús . Otros modos comunes disponibles en los teclados de PC son las otras teclas de bloqueo , Bloq Num y Bloq Despl y, a menudo, la tecla Insertar . Las teclas muertas para diacríticos también crean un modo a corto plazo, al menos si no proporcionan una retroalimentación visual de que se modificará el siguiente carácter escrito. Si bien las teclas de bloqueo en los teclados de PC están diseñadas con la intención de que se utilicen como teclas modales, el diseño de hardware de IBM PC no requiere que estas ni ninguna otra tecla específica sean modales, sino que permite que el software trate cualquier tecla como modal. (El BIOS de PC normalmente implementa los estados Bloq Mayús, Bloq Num y Bloq Despl, por lo que la modalidad de estas teclas puede parecer intrínseca, pero no es ni técnica ni prácticamente necesario utilizar el BIOS para la E/S del teclado y, de hecho, la mayoría de los sistemas operativos modernos no utilizan la E/S del teclado del BIOS).
• Los usuarios de PC cuyo idioma no se basa en el alfabeto latino suelen tener que interactuar utilizando dos distribuciones de teclado diferentes : una local y una QWERTY . Esto da lugar a errores de modo relacionados con la distribución actual del teclado: muy a menudo, se pierde la sincronización del modo de "distribución actual" entre el usuario y la interfaz, y el texto se escribe en una distribución que no es la deseada, lo que produce texto sin sentido y confusión. Las teclas del teclado en elementos de la interfaz de usuario como "(y/n)" pueden tener el efecto contrario si se traduce un programa.
• Un ejemplo frecuente es la aparición repentina de un cuadro de diálogo de error modal en una aplicación mientras el usuario está escribiendo, lo que es una forma de robo de foco ; el usuario espera que el texto escrito se introduzca en un campo de texto, pero el cuadro de diálogo inesperado puede descartar toda la entrada, o puede interpretar algunas pulsaciones de teclas (como "Y" para "sí" y "N" para "no") de una manera que el usuario no deseaba, lo que a menudo desencadena una acción destructiva que no se puede revertir . Los programadores pueden mitigar esto implementando un breve retraso entre la visualización del cuadro de diálogo modal y el comienzo de aceptar la entrada del teclado.
• El editor de texto de Unix vi puede ser notoriamente difícil para principiantes precisamente porque utiliza modos y porque las versiones anteriores configuraban la indicación de modo para que estuviera desactivada de forma predeterminada.
• En muchos videojuegos, el teclado se utiliza tanto para controlar el juego como para escribir mensajes. Los usuarios pueden olvidar que están en "modo de escritura" cuando intentan reaccionar a algo repentino en el juego y descubren que los controles no responden (y en su lugar, la barra de texto está llena de teclas de comando presionadas).

• La confusión de modos fue parte de los eventos que llevaron a la pérdida del vuelo 447 de Air France en 2009, y la pérdida de vidas de 228 personas. Los pilotos reaccionaron a una pérdida de altitud tirando de la palanca, lo que habría sido una reacción apropiada con el piloto automático completamente habilitado, lo que habría puesto al avión en una configuración de ascenso. Sin embargo, los sistemas del avión habían entrado en un modo de menor automatización ("ley directa" en términos de Airbus) debido a un sensor de velocidad aerodinámica bloqueado, lo que permitió a los pilotos poner el avión en una configuración de pérdida con el morro alto, de la que no se recuperaron. ^[8]
• Según la NTSB , uno de los factores que contribuyeron al accidente del vuelo 214 de Asiana Airlines en 2013 fue "la complejidad de los sistemas de dirección de vuelo del piloto automático y del acelerador automático... que aumentaron la probabilidad de error de modo". ^{[9] [10]}
• El 17 de enero de 2015, el buque de suministro de alta mar "Red7 Alliance" chocó contra una compuerta de una esclusa del canal de Kiel en Alemania, dañándola gravemente. Una investigación concluyó que las palancas que controlaban los propulsores azimutales del buque no se utilizaron de forma adecuada al modo en que estaban configurados, lo que provocó que el buque acelerara en lugar de detenerse en la esclusa. ^[11]
• El 21 de agosto de 2017, el destructor de la Armada estadounidense USS John S. McCain chocó con un petrolero comercial en el estrecho de Malaca, lo que provocó la muerte de diez miembros de la tripulación. Una investigación realizada por el ejército estadounidense concluyó que, inmediatamente antes de la colisión, los controles del timón y de propulsión se habían redistribuido entre las estaciones del puente y que la tripulación del puente no estaba plenamente al tanto de esa redistribución. ^[12]
• El 10 de abril de 2018, el buque de suministro de 5000 toneladas VOS Stone se desprendió de una plataforma eólica en construcción en el mar Báltico. El capitán del buque decidió poner el timón en un modo alternativo para realizar una prueba del sistema. La comunicación insuficiente con el oficial de guardia provocó una pérdida temporal de control, una colisión con la plataforma, lesiones a tres miembros de la tripulación y daños importantes. ^[13]
• El 19 de abril de 2020, un avión de combate F-35A fue destruido en un accidente de aterrizaje en la Base Aérea de Eglin . Las investigaciones concluyeron que la aeronave estaba mal configurada con el modo incorrecto de acelerador automático , lo que provocó que la aeronave se volviera incontrolable al aterrizar. ^{[14] [15]}

Los modos tienen como objetivo captar toda la atención del usuario y hacer que reconozca el contenido presente en ellos, en particular cuando se requiere una confirmación crítica del usuario. ^[16] Este último uso es criticado por ser ineficaz para su uso previsto (protección contra errores en acciones destructivas) debido a la habituación . En realidad, se recomienda en cambio hacer que la acción sea reversible (proporcionando una opción de "deshacer"). ^[17] Aunque los modos pueden tener éxito en usos particulares para restringir operaciones peligrosas o no deseadas, especialmente cuando un usuario mantiene el modo activamente como un cuasimodo .

Los modos se utilizan a veces para representar información pertinente a la tarea que no encaja bien en el flujo visual principal. ^[16] Los modos también pueden funcionar como convenciones bien entendidas, como las herramientas de pintura. ^[7]

Los defensores de la interacción modal ^{[¿ quiénes? ]} pueden argumentar que muchas actividades comunes son modales y los usuarios se adaptan a ellas. Un ejemplo de interacción modal es el de conducir vehículos a motor. Un conductor puede sorprenderse al ver que al presionar el pedal del acelerador el vehículo no acelera hacia adelante, probablemente porque el vehículo se ha colocado en un modo operativo como estacionamiento, punto muerto o marcha atrás. Las interfaces modales requieren capacitación y experiencia para evitar errores de modo como estos.

El experto en interfaces Jef Raskin se manifestó enérgicamente en contra de los modos y escribió: "Los modos son una fuente importante de errores, confusión, restricciones innecesarias y complejidad en las interfaces". Más adelante, señala: "No es casualidad que las malas palabras se denoten con #&%!#$&", escribe mi colega, el Dr. James Winter; es "lo que solía hacer una máquina de escribir cuando escribías números con la tecla Bloq Mayús activada". Raskin dedicó su libro The Humane Interface a describir los principios de una interfaz sin modo para computadoras. Esos principios se implementaron en los sistemas Canon Cat y Archy .

Algunos diseñadores de interfaces han tomado recientemente medidas para hacer que las ventanas modales sean más obvias y fáciles de usar, oscureciendo el fondo detrás de la ventana o permitiendo que cualquier clic del ratón fuera de la ventana modal fuerce el cierre de la ventana (un diseño llamado Lightbox ^[18] ), aliviando así el riesgo de errores modales. Jakob Nielsen afirma que una ventaja de los diálogos modales es que mejoran la conciencia del usuario. "Cuando hay algo que necesita ser reparado, es mejor asegurarse de que el usuario lo sepa". Para este objetivo, el diseño Lightbox proporciona un fuerte contraste visual del diálogo sobre el resto de elementos visuales. Sin embargo, aunque un método de este tipo puede reducir el riesgo de interacciones erróneas involuntarias, no resuelve el problema de que la ventana modal bloquea el uso de las funciones normales de la aplicación y, por lo tanto, impide al usuario realizar cualquier acción para solucionar la dificultad, o incluso desplazarse por la pantalla para ver la información que necesita para elegir correctamente entre las opciones que presenta la ventana modal, y no hace nada para aliviar la frustración del usuario por haber llegado a un callejón sin salida del que no puede escapar sin alguna consecuencia más o menos destructiva.

A Larry Tesler , de Xerox PARC y Apple Computer , le disgustaban tanto los modos que consiguió una matrícula personalizada para su coche que decía: "NO MODES". Usó esta matrícula en varios coches desde principios de los años 80 hasta su muerte en 2020. Junto con otras, también utilizó la frase "Don't Mode Me In" durante años como grito de guerra para eliminar o reducir los modos. ^{[19] [20]}

Bruce Wyman, el diseñador de una mesa multitáctil para una exposición de arte del Museo de Arte de Denver ^[21] sostiene que las interfaces para varios usuarios simultáneos deben ser amodales, para evitar poner en foco a un solo usuario. ^[22]

Se recomiendan alternativas a los modos como el comando de deshacer y la papelera de reciclaje cuando sea posible. ^[23] El investigador de HCI Donald Norman sostiene que la mejor manera de evitar errores de modo, además de indicaciones claras del estado, es ayudar a los usuarios a construir un modelo mental preciso del sistema que les permita predecir el modo con precisión. ^[24]

Esto se demuestra, por ejemplo, con algunas señales de stop en las intersecciones de carreteras. Un conductor puede estar condicionado por una señal de stop de cuatro direcciones cerca de su casa a asumir que las intersecciones similares también serán de cuatro direcciones. Si resulta que solo hay dos direcciones, el conductor podría continuar si no ve otros autos. Especialmente si hay una vista obstruida, un auto podría pasar y chocar al primer auto de costado. Un diseño mejorado alivia el problema al incluir un pequeño diagrama que muestra cuáles de las direcciones tienen una señal de stop y cuáles no, mejorando así la conciencia situacional de los conductores.

Los controles modales se ubican mejor donde el foco está en el flujo de tareas. ^[23] Por ejemplo, una ventana modal se puede colocar al lado del elemento de control gráfico que desencadena su activación. Los controles modales pueden ser disruptivos, por lo que se deben hacer esfuerzos para reducir su capacidad de bloquear el trabajo del usuario. Después de completar la tarea para la cual se activó el modo, o después de una acción de cancelación como la tecla Escape , volver al estado anterior cuando se descarta un modo reducirá el impacto negativo.

En el libro The Humane Interface , Jef Raskin defendió lo que denominó cuasimodos , que son modos que se mantienen en su lugar solo a través de una acción constante por parte del usuario; dichos modos también se denominan modos de resorte . ^[25] El término cuasimodo es una combinación del prefijo latino quasi- (que significa casi , hasta cierto punto ) y la palabra inglesa "mode".

Las teclas modificadoras del teclado, como la tecla Shift , la tecla Alt y la tecla Control , son ejemplos de una interfaz cuasimodal.

La aplicación entra en ese modo mientras el usuario esté realizando una acción consciente, como presionar una tecla y mantenerla presionada mientras se ejecuta un comando. Si la acción de mantenimiento se detiene sin ejecutar un comando, la aplicación vuelve a un estado neutral.

El supuesto beneficio de esta técnica es que el usuario no tiene que recordar el estado actual de la aplicación al invocar un comando: la misma acción siempre producirá el mismo resultado percibido. ^[26] Una interfaz que utiliza solo cuasimodos y no tiene modos completos sigue siendo amodal según la definición de Raskin.

La función StickyKeys convierte un modo cuasi-modo en un modo serializando las pulsaciones de teclas modificadoras con las teclas normales, de modo que no sea necesario pulsarlas simultáneamente. En este caso, la mayor posibilidad de un error de modo se compensa en gran medida con la accesibilidad mejorada para usuarios con discapacidades físicas.

• Postura de aplicación
• Sorpresa de automatización
• Mensaje de error
• Interfaz gráfica de usuario
• Interacción hombre-computadora
• Diseño de interacción
• Ventana modal
• Modalidades y modos
• Estado (informática)
• Modo de texto

• Buxton, William AS (1995). "Fragmentación y fraseo y el diseño de diálogos entre humanos y computadoras". En Baecker, Ronald M.; Grudin, Jonathan; Buxton, William AS; Greenberg, Saul (eds.). Lecturas en interacción entre humanos y computadoras: hacia el año 2000 (2.ª ed.). San Francisco, California: Morgan Kaufmann. pp. 494–499. ISBN 978-1-55860-246-5.acmid212970.

• La falta de modalidad en el glosario de UsabilityFirst
• Falta de modalidad en las directrices HIG de Apple
• Definición de error de modo en Usability First
• Un ejemplo de un error de modo en Excel
• John Rushby. Uso de la comprobación de modelos para ayudar a descubrir confusiones de modos y otras sorpresas de automatización. Un artículo que analiza un método automático para localizar errores de modos.
• Jakob Nielsen sobre los modos con resorte