it-swarm-es.com

¿Debería una IU basada en web confiar en el botón de retroceso del navegador?

El botón de retroceso es una excelente opción de "salir del callejón sin salida" que proporcionan los navegadores. ¿Debería una interfaz de usuario confiar en el botón Atrás como el único método para permitir que un usuario acceda a la página anterior o la interfaz de usuario debe proporcionar un botón adicional específico del sitio para volver a la pantalla anterior?

Un escenario común que viene a la mente con esto es un sitio de comercio electrónico que tiene una lista de productos. Un usuario hace clic en uno de los productos para ver una página de detalles. Luego, después de ver los detalles, les gustaría volver a la lista para hacer clic en otro producto y ver sus detalles. ¿Debería la IU suponer que un usuario utilizará el botón de retroceso del navegador o el sitio web debe proporcionar un enlace o botón que permita a los usuarios "Volver a sus resultados", dejando el botón de retroceso del navegador como una opción alternativa?

80
Benjamin S

Una aplicación web debería siempre esforzarse por ser compatible con el botón de retroceso del navegador. Es decir, usar el botón Atrás debería tener resultados deterministas dentro de esa aplicación que coincidan con el comportamiento esperado (consistencia global).

Un escenario común que viene a la mente con esto es un sitio de comercio electrónico que tiene una lista de productos. Un usuario hace clic en uno de los productos para ver una página de detalles. Luego, después de ver los detalles, les gustaría volver a la lista para hacer clic en otro producto y ver sus detalles. ¿Debería la IU suponer que un usuario usará el botón de retroceso del navegador o el sitio web debe proporcionar un enlace o botón que permita a los usuarios "Volver a sus resultados", dejando el botón de retroceso del navegador como una opción alternativa?

Sin embargo, una aplicación web generalmente no debe confiar únicamente en el botón de retroceso del navegador para toda la navegación que pueda considerarse relacionada.

Lamentablemente, una de las principales razones para esto es que algunas personas tienen miedo de presionar el botón de retroceso dentro de ciertas aplicaciones web debido a un comportamiento de control/estado roto o inconsistente del navegador que se encuentra en muchas AJAX web pesada aplicaciones, donde el uso del botón de retroceso puede no resultar en el efecto que la persona que lo usa anticipó.

En segundo lugar, si la página se generó desde una nueva pestaña (o un marcador), puede que no haya un botón de retroceso. Si bien la persona que usa la aplicación debería tener la pestaña original abierta, si quiere para poder acceder a la página de la que provienen, asegúrese de darles una forma de hacerlo desde el contexto de la página en la que se encuentran actualmente.


Usando su ejemplo, digamos que la lista era una página de venta estática (en lugar de una búsqueda dinámica). ¿Qué sucede si la persona que navega por el sitio marca un producto individual y luego cierra esa sesión? Cuando cargan ese marcador, ¿qué opciones de navegación desea que estén disponibles para ellos? ¿Qué opciones de navegación crees que querrán tener a mano? Es una buena idea hacer que estas sean consistentes componente de su interfaz de usuario, por lo tanto, no vale la pena confiar únicamente en el botón Atrás en otros casos.

Para ampliar un poco esto, proporcionar opciones de navegación hacia atrás dentro de su interfaz de usuario le da control sobre su presentación: esto significa que puede calmar la ansiedad sobre el resultado de una acción delineando claramente lo que hará el uso del control.

Por ejemplo, considere si alguien tendría alguna incertidumbre sobre lo que podría hacer lo siguiente:

  • Back (Volver a donde ? también se aplica al botón de retroceso del navegador, porque todos sabemos que no siempre hace lo que esperamos , dependiendo de la aplicación web, y las personas no saben qué hará su aplicación hasta que lo intenten, lo que puede ser un punto de duda)
  • Back to listings (¿qué listados? Si vengo aquí desde un marcador, ¿tengo alguna idea de lo que estaba haciendo que me trajo aquí?)
  • Back to [associated product category] (Bueno, eso es bueno, es funcional y no es una preocupación por no ser determinista, pero probablemente debería estar representado en otro lugar)
  • Back to the January Sale Event (¡hey! ¡Eso es lo que estaba viendo cuando vine aquí! Es lo suficientemente específico como para esperar terminar ... a dónde esperaría ir) (también conocido como el mapa de contexto de navegación que me llevó a esta página)

(y probablemente desee utilizar una redacción como "Más de" en lugar de "Volver a", según el contexto en el que termine utilizando dicho control y cuando la navegación desde este se vincule claramente con resultados específicamente relacionados)

Ese último ejemplo le brinda lo que desea luchar: una reducción de la ansiedad para las personas que usan su aplicación al dejar en claro cuál será el resultado relacionado.

Además, esto le brinda un comportamiento adicional más allá de lo que necesariamente está disponible en solo el botón Atrás. Si bien el botón Atrás simplemente debería funcionar, este control está presente si alguien abre la página dos meses después. Si hacen clic en él, puede presentar la página relacionada para el "Evento de venta de enero", pero con un mensaje en la parte superior que dice que el evento ya terminó, lamentamos que se haya perdido las increíbles ofertas que teníamos, pero vea [ estos nuevos eventos/productos/etc.


Estos puntos de navegación son una oportunidad no solo para tener un control de respaldo de navegación posterior con el que sabe que la persona que usa la aplicación se sentirá cómoda interactuando, sino también uno donde usted controla dónde va, y que le brinda la oportunidad de comunicarse con el usuario en un contexto bastante estrictamente administrado. Pueden, si se administran correctamente, proporcionar más funcionalidad que el botón de retroceso del navegador solo, mejorando la experiencia en lugar de simplemente saturar la pantalla con controles/funcionalidad directamente duplicados.

Si va a implementar controles de navegación hacia atrás, hágalos claros, consistentes y constantemente disponibles (al menos en los tipos de página donde tengan sentido). Intente proporcionar un valor adicional sobre lo que solo representa el botón Atrás, tanto para usted como para las personas que usan su aplicación.

Si solo va a duplicar literalmente la funcionalidad del botón de retroceso del navegador con un control que dice atrás o tiene un icono representativo similar ... no se moleste. Solo asegúrese de que el comportamiento del botón de retroceso del navegador funcione correctamente. (que siempre deberías estar haciendo de todos modos)

80
taswyn

Si. Debe confiar en el botón de retroceso del navegador.

Los usuarios esperan que el botón esté allí, así que asegúrese de que sea funcional.

¿Pero debería imitar el mismo botón con su funcionalidad?
Si su aplicación o sitio web lo necesita, sí, pero no siempre es exactamente lo mismo.
En algunos casos, como su ejemplo de una tienda web, un botón que simplemente dice "atrás" o una flecha puede no ser suficiente. En este ejemplo, una navegación de ruta de navegación está en orden, o un botón o enlace que dice "volver a los resultados" (algo más de contexto por el bien del usuario).

27

Confiar es la palabra incorrecta

Estás preguntando si deberías confiar en el botón, que no deberías. También está preguntando si debería ofrecer otra opción. Lo que podrías, y en ciertas situaciones, deberías.

Así que aquí está la cosa:

botón Atrás

Nunca, nunca, debe romper el comportamiento del botón de retroceso. En todo momento, debe esforzarse por mantener su funcionalidad intacta, ya que es parte del comportamiento de cada navegador. Es el manejo de un usuario sobre la situación, su ayuda en caso de error.

Es un chaleco salvavidas que no debes quitar.

Tu propia interfaz de usuario

En muchos casos, cosas como un rastro de migajas o un botón "atrás" podrían ser útiles. Tal vez porque el botón de retroceso del navegador está oculto en un determinado sistema operativo, tal vez porque es un poco menos sofisticado, o tal vez solo para mantener a los usuarios mirando su aplicación en lugar del navegador.

En general, no puedes equivocarte al agregar un poco de navegación de cortesía.

Conclusión

¿Deberías confiar en eso? Puede hacerlo, siempre y cuando se asegure de no romperlo cuando no lo haga. ¿Deberías agregar el tuyo? Si parece conveniente, si lo usarías, sí.

Y por último: medida. Vea si la gente lo usa si lo agrega.

9
Dirk v B

Por lo general, trato de proporcionar ambos botón de retroceso en pantalla y soporte para el botón de retroceso del navegador.

Razones:

  • Si el usuario está inmerso en el flujo de la aplicación, un botón de retroceso en pantalla puede ayudar a mantener el enfoque dentro del flujo y evitar perder la atención del usuario.

  • Apoyar el botón de retroceso del navegador es importante para mí, incluso a un gran costo , porque es un diseño presuntuoso asumir que el usuario solo usará el botón en pantalla en lugar del botón de retroceso del navegador.

Tenga en cuenta que hay algunas raras excepciones en las que desea evitar o romper intencionalmente el comportamiento del botón (por ejemplo, formularios de seguridad).

5
tohster

Nadie no debe confiar únicamente en el botón de retroceso del navegador.

¿Por qué?

Debido a que los teléfonos inteligentes en promedio están creciendo a un ritmo más rápido que el tamaño de las manos de los humanos. Mira dónde están estos botones de retroceso.

Arriba a la derecha (general) Back Button for menus Vista estándar de iPhone (abajo a la izquierda) enter image description here Vista horizontal del iPhone 6 (arriba a la izquierda) enter image description here

Ahora echemos un vistazo a cómo los usuarios sostienen sus dispositivos enter image description hereenter image description here

A veces es difícil alcanzar ese botón de retroceso porque las manos de los usuarios son lo suficientemente grandes como para presionar fácilmente el botón de retroceso predeterminado en todas las posiciones. Por lo tanto, si es posible proporcionar una forma más fácil de atravesar, hágalo.

Vea esta tendencia con respecto al tamaño de la pantalla enter image description here

Otra razón para no confiar en el botón Atrás es porque puede haber secuencias de comandos que impiden que un usuario regrese y obtenga el resultado que espera debido al diseño del sitio web

2
Frank Visaggio
  • el botón de retroceso del navegador DEBE funcionar como se esperaba.
  • su botón de retroceso de la interfaz de usuario web NO DEBE proporcionar un botón de retroceso a menos que haga lo mismo que el botón de retroceso del navegador
    • ejemplo: vista de categoría filtrada en comercio electrónico: si el botón Atrás regresa a la vista de categoría sin filtro, NO DEBE verse como un botón de retroceso, sino más bien como una miga de pan.
  • dEBE proporcionar enlaces de navegación contextual, pero NO DEBEN verse como botones de retroceso

El razonamiento principal detrás del argumento de comportamiento del botón de retroceso: tome este escenario de ejemplo:

  • Filtro nuestros productos con precio <1000
  • Hago clic en un producto para acceder a la página de detalles.
  • Hago clic en el botón de retroceso "ui"
  • Veo la página de categoría con todos los artículos.
  • como cliente, creo que "hice clic en el botón Atrás y los filtros se pierden" (y, por lo tanto, no hay razón para probar el botón Atrás del navegador)
  • Juro proporcionalmente a la complejidad del filtrado que había configurado
  • Si no hubiera un botón de retroceso "ui", probablemente usaría el botón de retroceso del navegador como estoy acostumbrado.
2
Tomáš Fejfar

Creo que no debe confiar exclusivamente en el botón de retroceso del navegador.

  1. Si el usuario está interactuando con su sitio para llegar a algún lado, creo que es razonable que espere poder regresar de la misma manera.
  2. Mostrar dónde se encuentra el usuario dentro del contexto del sitio web es importante para que el usuario tenga un marco de referencia en el sitio general.

* editar para aclarar: definitivamente también debe admitir el botón de retroceso del navegador. Solo quiero asegurarme de que esté claro. Solo estaba agregando las razones por las que no querría confiar exclusivamente en el botón de retroceso del navegador.

1

No, no deberías confiar en el botón de retroceso del navegador.

Si bien es fácil decir que puede esperar que esté presente y que puede esperar que siempre funcione de cierta manera, simplemente ese no es el caso.

Debido a que el botón Atrás existe en una aplicación fuera de la suya, no puede esperar razonablemente que esté presente o funcione de manera específica. Si hay algo que la revolución del diseño receptivo nos ha enseñado, es que no se puede predecir nada sobre el contexto de navegación de un usuario.

¿Qué pasaría si, en 2017, Google decidiera que no querían admitir el botón Atrás en Chrome más?

Podemos gritar herejía todo lo que queramos en este momento, pero Google podría hacerlo por cualquier cantidad de razones que no podemos predecir. También podría M $, Apple, Mozilla o cualquier otro proveedor de navegadores. Entonces te quedarás confiando en una característica que ya no existe.

1
Jordan Foreman

Aquí hay muchas cosas sobre no eliminar o interferir con el botón de retroceso del navegador, pero no creo que eso sea lo que pregunta el interrogador.

El botón de retroceso del navegador está ahí para el usuario y, por lo tanto, no debe formar parte de sus viajes de usuario proyectados. El usuario puede haber personalizado su navegador para que no se muestre el botón de retroceso: si confía en esto, terminará con un viaje roto del usuario.

Tampoco confiaría en nada que probablemente use la función JavaScript "history.back" (efectivamente, presionar un botón de retroceso).

Si su viaje de usuario muestra que es probable que un usuario quiera volver a la página de resultados de búsqueda u otro lugar, entonces debe proporcionar un método explícito para que lo haga: "Volver a sus resultados"

1
Andrew Martin

No lo usaría exclusivamente.

El primer ejemplo que viene a la mente es Google Chrome para Android. Cada "pestaña" es una nueva instancia, por lo que abrir una nueva ventana es similar a comenzar una nueva sesión. En estos casos, el botón Atrás simplemente llevará al usuario a la pantalla de inicio en lugar de regresar realmente. Lo mismo sucederá si un usuario elige "Abrir enlace en una pestaña nueva".

Debido a esa funcionalidad, tener alguna función de navegación en el sitio web permitiría al usuario continuar sin interrumpir el flujo de cosas.

Como nota al margen: tengo entre 40 y 100 pestañas en Chrome debido a esto. Es realmente bastante fácil acumular pestañas usando el navegador normalmente, y no todos los usuarios realmente sabrán cómo para lidiar con este comportamiento.

0
Thebluefish

Hablando no como diseñador sino como usuario; cada vez que tengo que usar el botón de retroceso de mi navegador para continuar navegar un sitio, no puedo evitar considerarlo un falla de la UX del sitio. Cuanto más tengo que usarlo, más frustrado me siento. Las únicas excepciones son instancias como "¿Cuál era la dirección de ese vendedor en la última página?" o "¿Qué puse en ese campo de formulario en la última página de nuevo?", con la intención de volver directamente a la página en la que ya estoy.

En mi humilde opinión, el botón de retroceso nativo debería nunca ser la única salida del usuario de una página, incluso si están tratando de volver a una página de listado anterior. Existen innumerables opciones simples, probadas y efectivas para proporcionar navegación a sus usuarios: una < back to listing enlace en la parte superior de una página, migas de pan o cualquiera de las sugerencias de otras respuestas funcionan bien.

0
CodeMoose