Informática y Sistemas (β)

2009/10/02 - 2 octubre 2009

Evitando inconsistencias de datos por navegación hacia atrás en sitios web

el botón de la discordia

el botón de la discordia

Cuando se consolidó la plataforma web como vehículo de implementación de aplicaciones, muy por encima de las basadas en ejecutables Windows (dominantes hasta entrando al nuevo milenio), comenzaron a presentarse problemas nuevos y algunos de difícil solución. Estos problemas se deben mayormente a que la www (world wide web) fue pensada inicialmente como canal de comunicación, y solo con su masificación se empezaron a explotar nuevas prestaciones comerciales y operacionales. Uno de los grandes problemas, y que hasta el día de hoy no se encuentra enteramente resuelto en la mayoría de los sitios que visito es el de la navegación hacia atrás. Y una buena arquitectura debe considerar la navegación de un sitio conforme a ciertos criterios de usabilidad, que en este caso no estan bien estandarizados por lo que hay que prestarles mayor atención.

Los exploradores son aplicaciones locales que “leen” o intercambian información de la web a través de las páginas que muestran. Pero estas páginas, a pesar de los botones y controles que tengan son solo contenido y tienen nula injerencia en la aplicación del explorador que oficia de contenedor. Y los exploradores suelen tener funcionalidades de navegación hacia atrás, para volver rápidamente sobre los pasos que recorrió el usuario. Este botón es el que presenta el principal problema para los desarrolladores que tratan de diseñar un sitio web transaccional u operativo; ya que muchas operaciones actualizan necesariamente las páginas y al navegar hacia atrás se ven muestras desactualizadas de información o datos que generalmente se están recuperando del cache con valores que tenían anteriormente. Si a partir de esta versión desactualizada se tratará de realizar alguna operación, las validaciones del lado cliente se comportarán como si fuera una página actual real y tratarán de enviar los nuevos cambios que se realicen al servidor; los que muchas veces provocan resultados inesperados y casi siempre desastrosos desde el punto de vista de la consistencia de los datos y del funcionamiento del sitio.

ejemplo de aviso de página expirada

ejemplo de aviso de página expirada

Hay algunas técnicas bastante difundidas para tratar de paliar esta deficiencia, como incorporar un redireccionamiento hacia adelante (history.forward) que solo tiene efecto cuando se trata de retroceder, o hacer vencer las páginas a medida que se avanza en la navegación por ejemplo; pero que a mi criterio son soluciones de compromiso poco elegantes. En general, manipular la navegación como en el primer caso ante los ojos del usuario genera un comportamiento no esperado que causa inseguridad y desconfianza en el funcionamiento del sitio; en tanto que el segundo caso, el aviso de página expirada sale como un aviso del mismo explorador, en una página de error y aquí se peca de dejar al usuario afuera de la aplicación (del propio sitio web) sin instrucciones o botones de enlace que le permitan recuperar la actividad que venía desarrollando; lo que naturalmente deja a cualquier usuario en desconcierto y sin saber a ciencia cierta cómo proseguir.

En general, para un comportamiento de navegación coherente y amigable se deben cumplir con los siguientes principios:

  • La navegación hacia atrás no debe estar permanentemente prohibida, ya que es un recurso al que muchos usuarios están acostumbrados y en cierto modo es útil mientras no se violen la consistencia de los datos.
  • La navegación hacia atrás solo debe impedirse a partir de una actualización de datos por parte del usuario. Los cambios producidos por el sistema son muy difíciles de evaluar desde el cliente, y se deben controlar desde el servidor.
  • Se deben evitar los errores producidos por el envío de datos desde páginas desactualizadas, o permitir que fluyan aunque supuestamente no sean dañinos.
  • Cuando se detecte una operación realizada desde una página desactualizada, se debe notificar al usuario de la situación por una página propia del sitio, y ofrecer los enlaces alternativos para seguir operando dentro del mismo.

Si bien estas restricciones de navegación son enunciadas en forma simple, la implementación de una solución que se rija por las mismas tiene muchas dificultades técnicas. Una forma que encontré para satisfacer este comportamiento es el utilizar descriptores únicos de navegación, alojados por igual en la sesión (variables de sesión) y escondidos en la misma página (por ejemplo en su viewstate). Con cada página que se levante desde el ciente, se aloja el descriptor en el viewstate, y a partir de allí se controla con cada refresco de la misma que ambos valores sean idénticos. A medida que se navega hacia adelante, varias páginas pueden compartir un mismo valor del descriptor, lo que facilita al navegar hacia atrás que la validación sea siempre positiva y su refresco permitido. Lo que se debe controlar es que si desde una página se produce una operación de cambios de datos por parte del usuario o que se considere que invalida las páginas navegadas previamente, este evento debe generar un nuevo descriptor que se alojará en sesión y en la página. A partir de este instante, todas las paginas que se lean a continuación tendrán en su viewstate el nuevo valor por lo que se las podrá recorrer en navegación desordenada sin problemas; pero si se retrocede hasta una página con el valor de viewstate fijado con el descriptor anterior, cualquier operación realizada sobre la misma pasará por la validación de comparación con el valor actual de sesión, detectándose la situación prohibida. A partir de este punto es fácil controlar la situación y derivar en un redireccionamiento a la página de aviso al usuario donde se le notifique esta situación y se le dé las instrucciones para recuperar la operación del sitio.

Con esta técnica siempre tuve buenos resultados, y permite dar confianza y seguridad a los usuarios; lo que es sumamente importante en portales donde se realicen operaciones transaccionales o que involucren generación de documentos o compra de especies.

(tiny)

Anuncios

Dejar un comentario »

Aún no hay comentarios.

RSS feed for comments on this post. TrackBack URI

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Crea un blog o un sitio web gratuitos con WordPress.com.

A %d blogueros les gusta esto: