Las centrales de reserva de hoteles firman contratos con ellos y les dan una dirección web a la que pueden acceder para actualizar sus precios y su disponibilidad. Estas webs tienen miles de visitas ya que los hoteles actualizan sus precios a menudo; hacen cambios desde una vez a la semana hasta media docena al día. Son especialmente críticas las épocas de ferias y congresos ya que hay que llenar el hotel maximizando el beneficio, atendiendo a la competencia y la tendencia de las ventas. Es injusto para el cliente pagar más por lo mismo pero muchos hoteles no podrían competir de ninguna forma.
Las páginas de administración que ponen a disposición del hotel son sorprendemente diferentes unas de otras. El objetivo es simple: Poner un precio a cada día y un número de habitaciones a la venta. Se complica considerablemente cuando existen varios tipos de habitación y uso (Doble, Triple, Apartamento, Estudio, uso individual, cama supletoria), varios tipos de ocupantes (adultos, niños, niños menores de x años), varios tipos de regímenes: (sólo alojamiento, alojamiento y desayuno, media pensión, pensión completa, todo incluido), estancias mínimas, anticipación de compra, distintos contratos dependiendo del mercado...
Tantas opciones hacen que los desarrolladores de estos paneles de administración se planteen ayudar al usuario que no tiene por qué saber nada de informática. Estas terribles ayudas derivan en páginas web que sólo funcionan en Internet Explorer, que abusan del (mal) uso de javascript
y que están hechas con frameworks y entornos WYSIWGY (What you see is what you get) como ASP.NET, que puede derivar en páginas web terribles.
Un problema de estas páginas es que no están desarrolladas para el público, son extranets a las que se accede con contraseña, por lo que el presupuesto que tienen para ello está bastante limitado. Prefieren vender más que dar mejor servicio a sus proveedores por lo que se esmeran en el front-end para clientes.
En mi trabajo he tenido que estudiarme estas páginas de arriba a abajo sin tener más que el código fuente y mis herramientas para webscraping (que merecen un post aparte). Casi todas tienen errores graves ya sea de desarrollo o de usabilidad por lo que puedo decir que he aprendido bastante sobre lo que hay que evitar.
Algunas disfunciones técnicas que me he encontrado son:
- Un _viewstate de 100Kb. El _viewstate es un parámetro que incluyen las páginas ASP.NET. Se le conoce como la "administración de estado" ya que guarda la información (codificada) de todos los elementos de una página web como inputs de texto, etiquetas, desplegables... Guarda propiedades como el color del fondo, los items de un desplegable, la posición, etc.
- Utilización de entornos de programación que facilitan el desarrollo. Estos entornos, entre los que se incluye ASP.NET con su _viewstate, son muy comunes. ¿Para qué pagar a un desarrollador que entienda conceptos como POST, GET, HTTP, cabeceras, variables de sesión, cookies, cachés y bases de datos, si podemos comprar por 6.000€ una aplicación que lo hace todo y poner a un becario a ejercitar el ensayo-error? Estas aplicaciones pueden ayudar mucho a agilizar el desarrollo pero hay que estudiarlas y controlarlas bien antes de empezar un proyecto. Suelen generar HTML muy, muy feo y repetir mucho código.
- Un caso concreto de utilización de estos entornos fue una de las páginas que guardaba cada cambio que se hacía en el calendario y generaba 10 líneas javascript. ¡Cada vez que se hacía un cambio crecía el tamaño del html! Era el browser del cliente el que tenía que procesar todos los cambios, desde que se cargó el contrato. Cuando desarrollamos el webscraping estaba en 300Kb de .html y al par de meses ya ocupaba un MB.
- Comprobar el usuario y la contraseña sólo al principio. En un entorno bajo usuario y contraseña se debe comprobar en cada página y en cada petición que el usuario es quien debería ser. Hay varios métodos para esto siendo el guardar un identificador de sesión en cookie, el más utilizado. Sin entrar en detalles, al modificar un parámetro llamado típicamente "idhotel", "idh", "id_hotel" y ponerle un número cualquiera, es fácil hacer modificaciones a hoteles a los que teóricamente no se tiene acceso. Cuando descubrimos una de estas vulnerabilidades se avisa al intermediario pero nunca han contestado. Dan ganas de irse de viaje por un euro la noche si no fuera porque el problema se lo pasan al hotel.
- De validar la página ni hablamos. Se puede ir olvidando un recepcionista de consultar una extranet desde el móvil (cosa que no veo tan descabellada) o un discapacitado de manejar centrales.
- Hay extranets con pocas opciones que permiten introducir sólo un número de habitaciones y precio. No tienen mucho más y pueden sobrevivir sin javascript perfectamente.
- Para configuraciones más completas se pueden basar en un precio base: al introducir el precio de la doble estándar, se genera la Doble Uso Individual un 10% más barata, una triple un 20% más cara, etc. No es nada habitual.
- Basadas en tarifas. Las tarifas se definen por contrato previamente y se les da un nombre orientativo. Así al poner una tarifa llamada "Oferta 2" se establecería la doble a 100€, la DUI a 90€, la triple a 120€, etc. en vez de tener que especificar precio para los tres usos al cambiar de tarifa.
- Basada en niveles. Como la basada en tarifas pero en vez de llamar "Oferta 2" a la tarifa, se le pone un precio orientativo como "100€" que corresponde con el precio, típicamente, de la habitación doble con uso doble. Es mi opción favorita.
- Calendarios en ventanas nuevas. Ya de por sí, un pop-up es molesto, pues más lo es si es sólo para elegir una fecha.
- Lo mejor que he visto es la extranet de atrapalo.com. Hasta te ponen comentarios para webscrapers, lo cual es un detallazo. Consiste en una tabla enorme con una columna para cada tipo de habitación, estancias mínimas y desayunos y un día para cada fila. El precio se introduce a mano al céntimo. Por javascript se puede modificar esta tabla por rangos y marca las modificaciones que se hagan a la tabla.
No hay comentarios:
Publicar un comentario