Funcionalidad del 'botón Atrás', ¿qué tan importante es?

Cada vez es más común que las aplicaciones "ricas" rompan el botón de retroceso. Siempre he sostenido que esta era una mala forma, pero ¿tal vez esa vista está desactualizada?

¿Alguna vez está bien romper el botón de retroceso? Y si es así, ¿cuáles son los criterios?

Solo rompa el botón de retroceso si se espera (si tiene sentido no regresar después de un evento en su sitio web).

Mozilla realizó un estudio sobre cómo las personas usan su navegador y los resultados para el botón de retroceso son impresionantes:

El botón Atrás se usa con mucha más frecuencia que cualquier otro elemento de navegación (con lo que nos referimos a los botones Atrás, Adelante, Recargar, Parar y Inicio). El 93.1% de los participantes del estudio usaron el botón Atrás al menos una vez, y en promedio, cada usuario hizo clic en Atrás 66.2 veces durante los 5 días : eso es 3 veces más clics que el botón Recargar, 10 veces más que el botón Inicio y más de 30 veces más que el ¡Botones de avance y parada!

fuente

Uso mucho el botón Atrás y odio cuando no puedo usarlo.

Romper el botón de retroceso es como romper el pedal del freno en un automóvil. Los usuarios esperan que funcione siempre y cuando de repente no se produce el caos. El botón de retroceso podría ser la función de interfaz de usuario más utilizada en un navegador, por lo que alterar su comportamiento puede, en el mejor de los casos, no hacer nada bueno y, en el peor de los casos, provocar confusión y abandono del usuario (o aumentar los costos de atención al cliente). Incluso si lleva al usuario de vuelta a donde estaba, eso no es lo que esperaban .

Se debe evitar romper el botón de retroceso.

Romper el botón de retroceso puede estar bien en algunos casos, pero casi siempre es innecesario. Lo he visto mucho con formularios de varios pasos en los que publicas de una página a la siguiente. Lo que debe hacer en este caso es desde su página de formulario (1), publicar en una página diferente (2) que (por ejemplo) almacena cosas en la sesión, luego redirigir a otra página (3). Cuando el usuario presiona el botón Atrás, pasará de (3) a (1).

Incluso con los RIA puede usar hashes / anclas de URL (es decir page.html#section) y monitorearlos en busca de cambios. Gmail hace esto para las diferentes 'páginas' como Inbox, Compose, Settings, etc. Esta pregunta sobre Stack Overflow te ayudará si quieres implementar eso.

Es importante romper el botón de retroceso en los sitios donde el usuario realiza la prueba, algunos sitios bancarios. En general, no es una buena idea.

La razón principal por la que es "cada vez más común" es que algunos marcos RIA no admiten el botón de retroceso o requieren que piense activamente en cómo incorporar su uso en su aplicación. Sin embargo, la mayoría de los marcos ofrecen cierto soporte para la navegación, como el soporte de Silverlight 3 para marcos y controles de página , solo tiene que saber cómo usarlo de manera efectiva. El mismo marco de navegación se usa en las aplicaciones de Windows Phone 7.

Los estudios han demostrado que casi 1/3 de los clics cuando se usa el navegador está en el botón Atrás (de Don't Make Me Think). Sinceramente, no creo que haya una buena razón para que el botón de retroceso no funcione. las personas deberían poder navegar por su sitio como mejor les parezca.

Mi experiencia ha sido que, a menos que esté utilizando un marco contenido, como una aplicación DENTRO del contexto de un navegador (como Silverlight mencionado anteriormente), y tenga una navegación clara y adecuada en su lugar, simplemente no es una buena idea comenzar a jugar con Funcionalidad predeterminada. En los casos en que lo he visto usado, casi siempre ha habido problemas con otro navegador que es incompatible con JavaScript o una sesión que no siempre se guarda correctamente, y cuando alguien "accidentalmente" presiona el botón, las cosas tienden a no continuar como se esperaba.

Creo que puedo resumir las respuestas como

Nunca debes hacer eso a menos que no puedas evitarlo. Incluso entonces no deberías.

Suena bien.

Para no descartar cómo los usuarios "frecuentes" presionan el botón Atrás, o que simplemente no es una "buena idea" "romperlo", ofrecería una sugerencia diferente: el botón Atrás debería llevar al usuario a algún lugar antes que el usuario llegó a donde están ahora. En muchos casos tiene más sentido y es más útil no recuperarlos con un clic de enlace hacia atrás (y puede ser mucho más fácil de implementar). Por ejemplo, navegue por un álbum de fotos. El usuario hace un clic para seleccionar el álbum, se le presentan miniaturas. Otro clic en una miniatura muestra esa imagen con enlaces siguientes / anteriores. En este punto, el usuario navega por el álbum. Cuando terminan, vuelven a hacer clic. En este punto, es más conveniente e intuitivo volver a la miniatura que a la imagen anterior.

En resumen, el botón Atrás debe hacer algo, pero exactamente lo que debe hacer depende de la aplicación.