web-development-kb-es.site

Operaciones de dos pasos y convenciones de botones

Nuestra aplicación web tiene tres operaciones diferentes que proceden de la siguiente manera:

  1. Al usuario se le presenta una ventana emergente donde se seleccionan diferentes configuraciones.
  2. El usuario puede hacer clic en un botón etiquetado con la operación (por ejemplo, "Fusionar") o "Cancelar".
  3. Si el usuario avanza, la aplicación procesa la operación, lo que puede demorar unos minutos y se presenta otra ventana emergente que resume lo que sucederá. En este punto, la operación no está comprometida y el usuario puede elegir continuar o cancelar.

Aquí es donde nuestras tres operaciones no están alineadas. En un caso, la opción es Continuar/Cancelar, en otro es Listo/Cancelar y finalmente tenemos Finalizar/Cancelar.

¿Cuál de estos es el mejor? ¿Hay una mejor alternativa? Si es así, ¿hay argumentos de apoyo?

3
carrier

Por lo general, trato de mantenerme alejado de las etiquetas de botones genéricas como estas y ser lo más específico posible. Sus etiquetas me parecen muy "base de datos" y me recuerdan las herramientas diseñadas por programadores para dominios muy abstractos (como ... editores de bases de datos).

Consulte esta pregunta relacionada sobre el posicionamiento del botón Aceptar/cancelar para más discusión:

¿Aceptar/Cancelar a la izquierda/derecha?

En mi respuesta allí, me vinculé a la investigación de Jakob Nielsen sobre los botones OK/cancelar , donde señala que:

A menudo es mejor nombrar un botón para explicar lo que hace que usar una etiqueta genérica (como "OK"). Una etiqueta explícita sirve como "ayuda justo a tiempo", dando a los usuarios más confianza para seleccionar la acción correcta.

Por ejemplo, algunos ejemplos:

  • De 37 señales ' Basecamp :

    Add this item from Basecamp

  • Desde nuestra herramienta de creación de prototipos, Artesanía :

    Upgrade to max from Handcraft

Además, podría considerar omitiendo la alternativa . En algunos casos, esto puede tener sentido. Creo que es bueno incluir una opción de "cancelar" si el usuario está a punto de hacer un compromiso significativo, como comprar algo o una operación CRUD que involucra una gran cantidad de datos.

Pero para algo simple, como tuitear, especialmente cuando hay una reversión fácil disponible después de la operación de confirmación, debería estar bien omitir el botón explícito "cancelar", ya que generalmente es obvio que no continuar no confirmará nada.

Un gran ejemplo es el formulario de comentarios de StackExchange, que solo tiene un botón "Agregar comentario" y no hay forma de ocultar el formulario o cancelarlo. ¿No quieres agregar un comentario? ¡No hagas clic en "Agregar comentario"!

10
Rahul

Suena como un asistente. Aquí hay un ejemplo:

  1. El usuario inicia la función de fusión.
  2. Aparece una ventana emergente, titulada Fusionar .
    Contiene configuraciones para el comando y Next > y Cancel botones.
  3. El usuario cambia la configuración y hace clic en Next >.
    La aplicación procesa la operación por unos momentos.
  4. Aparece la siguiente página del asistente. Tiene los botones Finish y Cancel.
    Si el usuario hace clic en Finish, se completa la operación; Cancel cancela todo.

Otro enfoque es hacerlo un proceso de un solo paso, pero permitir deshacer. Esto puede o no ser posible, dependiendo de la operación.

  1. El usuario inicia la función de fusión.
  2. Aparece una ventana emergente que contiene la configuración del comando y los botones Merge y Cancel.
  3. El usuario cambia la configuración y hace clic en Merge.
    La aplicación procesa la operación por unos momentos y la completa.
  4. La pantalla muestra los resultados de la operación e incluye un botón Undo. Si el usuario hace clic en Undo, la operación se revierte.
3
Bennett McElwee

Dos puntos que me gustaría hacer:

1) Si el proceso de fusión real se inicia después de la segunda pantalla (con resúmenes), entonces el botón "Fusionar" debería estar en esa segunda pantalla. Lo que me lleva a decir que en el primero, el botón debería decir algo como "Vista previa de resultados de fusión" o similar porque este es el siguiente resultado que obtendrá el usuario, en el flujo de proceso que comenzó.

2) Esta es una especie de sugerencia espeluznante, pero quizás tenga sentido tener tres botones en la primera pantalla: "Vista previa de combinación", "Cancelar" y "Combinar sin vista previa". Esto ahorraría algo de tiempo para el usuario que sabe lo que está a punto de hacer y no quiere esperar las estadísticas y luego comprometerse con su decisión. Solo una idea...

0
Jüri

Si en realidad no está realizando la "combinación" después de hacer clic en Combinar, no debería llamarla Combinar.

A menudo, lo que se usa en forma de etapas múltiples es una convención Continuar/Enviar. Continuar implica que debe continuar a la siguiente etapa, pero eso no implica que se haya comprometido todavía.

En el caso de una tienda en línea, el proceso de pago a menudo requiere que el usuario proceda a través de algunos formularios, proporcionando dirección y detalles de pago. No hasta que la página donde finalmente puedan confirmar el pedido sea un botón "Realizar pedido" o "Comprometerse a comprar".

Usaría un botón "Vista previa de combinación" o "Continuar" y luego en la página donde se comprometen, use un botón "Realizar combinación" o "Enviar".

0
Nick Bedford