user interface - funciona - ¿Cambiar OK-Cancelar y Cancelar-Aceptar para imponer la interacción del usuario?

google assistant (21)

Esto se inspira en la pregunta ¿ Aceptar-Cancelar o Cancelar-OK? .

Recuerdo haber leído en alguna parte sobre el concepto de cambiar OK-Cancelar / Cancelar-Aceptar en ciertas situaciones para evitar que el usuario haga clic en ventanas emergentes de información o cuadros de diálogo sin leer su contenido. Por lo que recuerdo, esto también incluyó mover la ubicación del botón OK (horizontalmente, de izquierda a derecha) para evitar que el usuario simplemente recuerde dónde hacer clic.

¿Esto realmente tiene sentido? ¿Es esta una buena manera de forzar al usuario a "pensar / leer primero, luego hacer clic"? ¿Hay algún otro concepto aplicable a este tipo de situación?

Estoy pensando especialmente en una aplicación relacionada con la seguridad, en la que presionar irreflexivamente el hábito por hábito puede dar lugar a una situación potencialmente peligrosa, mientras que Cancelar conduciría a un estado seguro.

Al final del día no puedes forzar a un usuario a hacer algo que no está dispuesto a hacer ... siempre encontrará una forma de evitarlo

Teclas de acceso directo para eludir el requisito de mover el mouse a un botón en movimiento.
Desplazarse hacia abajo hasta el final del EULA sin leerlo para permitir continuar.
Iniciando el software y luego tomando su taza de té mientras esperas que la pantalla molesta habilite el botón OK.

La forma más confiable en que he visto esto es dar una pregunta de opción múltiple basada en lo que está escrito. Si no obtienen la respuesta correcta, no pueden continuar ... por supuesto, después de un par de veces, se darán cuenta de que solo pueden elegir cada una de las respuestas hasta que el botón se habilite y luego hacer clic en él. Una vez más, significa que no leen lo que se escribió.

Solo puede ir tan lejos antes de tener que responsabilizar al usuario de sus acciones. Decirle al usuario que sus acciones están registradas lo hará más cuidadoso; si se lo hace responsable, es más probable que haga las cosas bien. Especialmente si hay un mensaje cuidadosamente elaborado que dice algo así como:

Esto se registra y usted será responsable de cualquier repercusión de esta decisión. Me ha indicado que elimine la tabla ALL_CORPORATE_DATA. Si lo hace, la base de datos de toda la empresa dejará de funcionar y se detendrá.
Debe seleccionar la casilla de verificación para indicar que acepta esta responsabilidad antes de poder elegir continuar ...

Y luego una casilla con "Sí, acepto la responsabilidad de mis acciones" y dos botones:

"SÍ, QUIERO ELIMINARLO", este botón solo debe habilitarse si la casilla de verificación está marcada.
"OH MAL, ESO NO ES LO QUE SIGNIFICO EN ABSOLUTO", este botón siempre se puede habilitar.

Si eliminan la tabla y las cuadrículas de la empresa se detienen, son despedidos. Luego se restaura la copia de seguridad y todo el mundo está contento como Larry [quienquiera que sea Larry] de nuevo.

Como siempre con cualquier cosa con la interacción del usuario, tiene un pequeño espacio entre ayudar al usuario y ser molesto. No sé exactamente cuáles son los requisitos, pero tu idea parece correcta (juego de palabras) para mí.

Esto me dará dolor de cabeza. Especialmente cuando accidentalmente cierro la aplicación y olvido guardar mi archivo :(

Veo otro buen ejemplo de forzar al usuario a "leer" antes de hacer clic: Firefox siempre atenuó el botón (también conocido como desactivar) el botón "Aceptar". Por lo tanto, el usuario tiene que esperar alrededor de 5 segundos antes de poder hacer nada. Creo que este es el mejor esfuerzo que he visto al forzar al usuario a leer (y pensar )

Otro ejemplo que he visto es en la página "Licencia y acuerdos" del instalador. Algunos de ellos requieren que el usuario se desplace hasta el final de la página antes de que pueda pasar al siguiente paso.

Lo que he hecho en algunos casos fue comparar la hora del mensaje que se muestra con el momento en que se descarta. Si fue menos de ''x'' cantidad de segundos, se recuperó una copia de seguridad. Esto los forzó, en la mayoría de los casos, a leer realmente lo que estaba en la pantalla en lugar de simplemente hacer clic a ciegas.

Bastante fácil de hacer, también ...

Algo como esto:

Dim strStart As DateTime = Now While Now < strStart.AddSeconds(5) MessageBox.Show("Something just happened", "Pay Attention", MessageBoxButtons.OK) If Now < strStart.AddSeconds(5) Then strStart = Now Else Exit While End While

Los atajos de teclado todavía se comportarían como antes (y se sorprendería de la poca gente que realmente usa ratones (especialmente en aplicaciones LOB).

Vista (y OSX IIRC) se han movido hacia la idea de usar verbos específicos para cada pregunta (como "Enviar" / "No enviar" cuando una aplicación quiere bloquearse y quiere enviar un crashdump a MS)

En mi opinión, me gusta el enfoque utilizado por Outlook cuando una aplicación intenta enviar un correo electrónico a través de COM, con un temporizador antes de permitir el uso de los botones (también afecta a los atajos de teclado)

NO. Si dificulta que el usuario haga clic en Aceptar por error y los obligue a pensar, aún así solo pensarán más acerca de cómo hacer clic en Aceptar; no pensarán en lo que están tratando de realizar. Vea el artículo del experto en usabilidad Aza Raskin: nunca use una advertencia cuando quiera decir Deshacer . Citar:

¿Qué hay de hacer que la advertencia sea imposible de ignorar? Si lo que está causando el problema es la habituación en el lado humano, ¿por qué no diseñar la interfaz de modo que no podamos formar un hábito? De esa manera siempre nos veremos obligados a parar y pensar antes de responder la pregunta, por lo que siempre elegiremos la respuesta que queremos decir. Eso resolverá el problema, ¿verdad?
Este tipo de pensamiento no es nuevo: es el enfoque tipo-la-en-palabra-de-esta-frase-para-continuar. En el juego Guild Wars, por ejemplo, eliminar un personaje requiere primero hacer clic en el botón "eliminar" y luego escribir el nombre del personaje como confirmación. Lamentablemente, no siempre funciona. En particular:
Nos lleva a concentrarnos en la tarea no cotidiana que tenemos entre manos y no en si queremos tirar nuestro trabajo. Por lo tanto, la advertencia imposible de ignorar es poco mejor que una advertencia normal: terminamos perdiendo nuestro trabajo de cualquier manera. Esto (perder nuestro trabajo) es el peor pecado de software posible.
Es notablemente molesto, y porque siempre requiere nuestra atención, necesariamente nos distrae de nuestro trabajo (que es el segundo peor pecado de software).
Siempre es más lento y exige más trabajo que una advertencia estándar. Por lo tanto, comete el tercer peor pecado, requiriendo más trabajo de lo que es necesario.

[Si quieres un Microsoftish, este por un tipo .NET en MSDN dice lo mismo!]

NOOOOOOOOOOOO!

En uno de nuestros productos tenemos una opción de usuario para requerir Ctrl + clic para los comandos relacionados con la seguridad.

Pero sorprender al usuario con botones que cambian de lugar o se mueven es un mal diseño en mi libro.

No lo cambie, solo confundirá más de lo que ayudará.

En cambio, haz clic en FireFox y no activar el control durante 5 segundos. - solo asegúrate de incluir un temporizador o algún tipo de indicador de que les estás dando la oportunidad de leerlo. Si hacen clic en él, corta el temporizador, pero requiere que hagan clic una vez más.

No sé cuánto mejor será, pero podría ayudar.

Solo recuerda, como dijo el hombre: No puedes arreglar estupideces.

No, no tiene sentido. No vas a "hacer" que los usuarios lean. Si la decisión es tan crucial, entonces es mejor que encuentres una forma de mitigar el peligro en lugar de entregarle a un usuario presumiblemente descuidado un arma cargada.

Hacer el botón "seguro" por defecto (activado por enter / barra espaciadora / etc.) Es una buena idea, simplemente porque si sorprenden al usuario, una pulsación de tecla destinada a la ventana esperada no desencadenará accidentalmente la acción inesperada. Pero incluso en ese escenario, debe tener en cuenta que para cuando el usuario se haya dado cuenta de lo que hizo, la opción ya se habrá ido (junto con cualquier texto explicativo en el cuadro de diálogo). De nuevo, es mejor que encuentres otra forma de darles información.

Parece que su usuario está pasando por un tipo de asistente de entrada en la aplicación de seguridad.

Algunas ideas como alternativas para mover botones.

Tenga una pantalla final para revisar todas las entradas antes de presionar el ok final.
Ten un cuadro de confirmación después de que hayan presionado para explicar el resultado de esta acción.
Una exención de responsabilidad que requiere que usted acepte marcar una casilla antes de que el usuario pueda continuar.

Pero si las OK / Cancels no son consistentes, eso puede desanimar o molestar al usuario.

Y no lo haga como algunos CLUF donde un usuario se ve obligado a desplazar un panel hacia abajo antes de que se pueda hacer clic en el botón Aceptar. A veces, simplemente no podrá hacer que un usuario lea todo cuidadosamente.

Si realmente necesitan leerlo, ¿debería pasar un poco antes de que aparezcan los botones? Esto también podría ser molesto para el usuario, pero si es una pregunta muy crítica, valdría la pena.

Editar: O requiere algún tipo de mecanismo adicional que simplemente hacer clic para "aceptar" la decisión muy importante. Una casilla de verificación, tecla presionar, contraseña, etc.

Por favor, no hagas esto a menos que realmente estés realmente seguro de que es absolutamente necesario. Este es un caso de tratar de arreglar el descuido y la estupidez por medios tecnológicos, y ese tipo de cosas casi nunca funciona.

Lo que podría hacer es usar verbos o sustantivos en lugar de los típicos títulos de botón Aceptar / Cancelar de Windows. Eso le dará un beneficio de atención instantánea sin sacrificar la previsibilidad.

Recomiendo informar al usuario que esta es una operación crítica al usar texto en rojo y explicar por qué es una operación insegura.

Además, en lugar de dos botones, tiene dos botones de opción y un botón "Aceptar", con el botón de opción "No continuar" seleccionado como predeterminado.

Esto presentará al usuario una interfaz poco común, aumentando la carga cognitiva y ralentizándolo. Que es lo que quieres aquí.

Si usa Ok y Cancel como su interfaz, siempre le permitirá al usuario omitir su mensaje o pantalla. Si luego reorganizas Ok y Cancel , molestarás a tu usuario.

Una solución a esto, si su objetivo es asegurar la comprensión de los usuarios, es:

Pregunta al usuario sobre el contenido. Si hace clic en Aceptar, está aceptando la Opción 1, o si hace clic en Aceptar, está aceptando la opción 2. Si eligen la respuesta correcta, permitan la acción.
Esto molestará al usuario, por lo que si puede realizar un seguimiento de los usuarios, solo hágalo una vez por mensaje.

¿Por qué no reformular la interfaz de usuario para hacer del OK la "opción segura"?

El problema se resuelve mejor con una combinación de buenos comentarios, comunicación de un modelo de sistema y tolerancia incorporada.

A favor del mecanismo de confirmación habla la simplicidad de la implementación. Desde el punto de vista del programador, es la forma más fácil de trasladar la responsabilidad al usuario: "Oye, te he preguntado si realmente te quieres pegar un tiro en el pie, ¿no? Ahora no hay nadie a quien culpar sino a ti mismo ... "

Desde el punto de vista del usuario:

Hay una penalización de productividad al tener que confirmar la operación dos veces cada vez, aunque los errores reales ocupen solo una fracción del número total de acciones, cualquier cambio de botones, interrumpir el flujo de trabajo habitual o insertar una pausa en la confirmación solo aumenta la penalización.
El mecanismo en realidad no proporciona mucha red de seguridad para usuarios frecuentes cuyos reflejos funcionan antes que la mente consciente. Personalmente, muchas veces he hecho una compleja secuencia de acciones solo para darme cuenta un momento después al observar las consecuencias de que mi cerebro de alguna manera tomó el camino equivocado.

Una mejor para el usuario, pero una solución más compleja (desde el punto de vista del desarrollo de software) sería:

Cuando sea posible, comunique con anticipación qué efecto exacto tendrá la acción en el sistema (por ejemplo, el desbordamiento de pila muestra la vista previa del mensaje arriba del botón Publicar su respuesta).
Dé una respuesta inmediata para confirmar una vez que se haya llevado a cabo la acción (SO resalta la respuesta presentada recientemente, gmail muestra una confirmación cuando se envía un mensaje, etc.).
Permitir deshacer o corregir posibles errores (es decir, en el caso de SO eliminar o editar la respuesta, Windows permite restaurar un archivo de la papelera de reciclaje, etc.). Para ciertas acciones no reversibles, todavía es posible otorgar una capacidad de deshacer, pero solo por un período de tiempo limitado (es decir, permitir cancelar o cambiar un pedido en línea durante los primeros 10 minutos después de su envío, o dejar de recuperar un correo electrónico durante el primer 60 segundos después de haber sido "enviado", pero en realidad puesto en cola en la bandeja de salida, etc.).

Claro, este es un trabajo mucho más inicial que insertar un cuadro de mensaje de confimación, pero en lugar de cambiar la responsabilidad, intenta resolver el problema.

Me pregunto si está pensando en la opción que existe en Visual Basic, donde puede establecer varias solicitudes y opciones de respuesta; y una opción es permitirle cambiar Cancelar y Aceptar en función de cuál debería ser el valor predeterminado; por lo que el usuario podría simplemente presionar enter y la mayoría del tiempo obtener la acción adecuada.

Si realmente quieres ir en esta dirección (lo que creo que es una mala idea, y estoy seguro de que también lo harás después de un pequeño reflejo y de leer todas las publicaciones), sería aún mejor incluir una pantalla de capcha para OK.

NO lo hagas, por favor. Esto no tendrá ningún efecto positivo: está tratando de EVITAR que las personas hagan clic en Aceptar en lugar de en Cancelar, haciendo que potencialmente hagan clic en Cancelar en lugar de Aceptar (está bien, pueden intentarlo de nuevo). ¡Pero! también podría lograr que las personas hagan clic en Aceptar cuando realmente quieran cancelar y eso podría ser un verdadero desastre. Simplemente no es bueno.

No estoy realmente para OK / Cancelar. Se usa en exceso y requiere que lea los balbuceos para decir lo que está confirmando o cancelando. Sigue la idea de la interfaz de usuario de MacOSX: el botón contiene una frase simple y fácil que es significativa por sí misma. Ejemplo: usted cambia una extensión de archivo y aparece un cuadro de diálogo que dice:

"Are you sure you want to change the extension from .py to .ps?" If you perform the change, the document could be opened by a different application. (Use .ps) (Keep .py)

Es mucho más comunicativo que OK / Cancelar, y su pregunta se vuelve casi superflua, es decir, solo necesita mantener activo el botón de la derecha, que parece ser el estándar.

En lo que respecta a la pregunta en bruto que planteaste. Nunca hacerlo. Nunca. Ni siquiera a punta de pistola. La consistencia es un requisito importante para las GUI. Si no eres consecuente, arruinarás la experiencia del usuario, y es más probable que tus usuarios vean esto como un error que como una característica (de hecho, sería un ERROR). La consistencia es muy importante. Para romperlo, debes tener una muy buena razón, y no debe haber otra forma diferente y estándar para lograr el mismo efecto.

Si debe usar un cuadro de diálogo, coloque leyendas descriptivas en los botones dentro del cuadro de diálogo.

Por ejemplo, en lugar de los botones Aceptar y Cancelar, pídales que digan "Enviar factura" y "Retroceder", o lo que sea apropiado en el contexto de su diálogo.

De esa manera, el texto está justo debajo del cursor y tienen una buena oportunidad de comprensión.

El sitio de la Guía de interfaz humana de Apple es una gran referencia y muy legible. Esta página en ese sitio habla sobre Diálogos.

Aquí hay una imagen de ejemplo:

Esto es lo que respondí a la pregunta del botón Enviar / Restablecer y creo que el mismo principio se puede usar aquí. El orden en realidad no importa en lo que respecta a asegurarse de que el usuario pueda distinguir los dos botones. En el pasado, lo que he hecho es utilizar un botón para (enviar / aceptar) y usar un enlace para el botón (reiniciar / cancelar). Los usuarios pueden decir instantáneamente que estos dos elementos son funcionalmente diferentes y, por lo tanto, los tratan de esa manera.