Sitio Web Corporativo: DUNE Resort

#Lo que ocurre dieciocho meses después del lanzamiento

El sitio de una promotora no se juzga el día de la publicación, sino año y medio más tarde. Para entonces el inventario ha cambiado varias veces, en el departamento comercial ha entrado alguien nuevo y flota la pregunta de si lo que muestra la web sigue siendo cierto. La mayoría de los proyectos de esta categoría se pierde justo ahí, y no por la tecnología, sino porque mantener el contenido resulta más caro de lo que nadie calculó.

Por eso la decisión de partida no fue estética ni de rendimiento, sino de mantenimiento: cada cambio cotidiano tiene que costar un solo gesto. Un estado de venta es un campo de selección, un precio es un campo numérico, una planta nueva es la sustitución de un fichero en un único sitio. Nada de esto exige conocer la plantilla y nada de esto puede estropear más que su propio registro. Donde esa regla no se cumple, donde un mismo dato hay que mantenerlo en dos lugares, aparece una contradicción en pocos meses; a partir de ahí quien edita deja de fiarse del sitio y, en consecuencia, deja de actualizarlo.

La segunda precaución tiene que ver con las palabras que se desplazan a medida que avanza la obra. La piscina significa una piscina exterior en una fase y dos exteriores más una interior en otra. El complejo significa primero un edificio y después tres. Un texto redactado como si el estado final ya existiera se lee el primer día como una promesa y el día cuatrocientos como un error. Todo lo contable vive por tanto en los datos y no en una frase.

#DUNE Resort, complejo de apartamentos en la costa báltica polaca

DUNE Resort se levanta en la parte oriental de Mielno, junto al paseo marítimo, en la ul. Pionierow. El inversor es Firmus Group, un grupo promotor con capital noruego que opera en Pomerania Central. El complejo llegó a tres edificios con 330 viviendas en total, piscinas exteriores e interior, zona de fitness y restauración dentro del recinto. El primer edificio, con 114 viviendas, abrió en 2013; después llegaron otros dos, de 153 y 63 apartamentos. Nuestra implementación se realizó en 2017 y duró alrededor de seis semanas.

Esa cronología pesa más de lo que parece. El sitio no describe un edificio terminado, sino una promoción que cambia el número de viviendas, las plantas y la lista de servicios durante su propia vida. Un modelo de contenidos que dé por supuesto un inventario fijo obliga a rehacer las plantillas en cada fase, y ese es exactamente el momento en que las webs de promotora suelen sustituirse en lugar de ampliarse.

#Una vivienda es un registro

El fallo habitual en esta categoría es tratar cada vivienda como una subpágina con descripción. La superficie, la planta, el número de habitaciones y el estado de venta acaban dentro del texto, es decir, en el único sitio donde nada se puede ordenar ni comparar. En el primer trimestre llega la petición de un filtro y en el segundo la de un mapa, y ambas obligan a extraer otra vez cifras de párrafos que mientras tanto han editado a mano varias personas.

Aquí una vivienda es desde el principio un registro con campos. Superficie, planta, tipología, orientación de las ventanas, edificio, estado y el enlace al plano son atributos independientes; el texto comercial es uno de los campos y no el soporte de los datos. El mismo registro alimenta la lista de resultados, la marca sobre el plano de situación, la ficha de la vivienda y la exportación que usa el departamento comercial, de modo que un único cambio de estado se ve en los cuatro sitios a la vez.

El segundo beneficio aparece más tarde. Antes o después, el equipo de ventas pregunta cuántos dos dormitorios quedan en el edificio dos, cuáles miran a poniente y cómo se reparte la disponibilidad por superficie. Con los datos en campos eso es una consulta y la respuesta tarda un minuto. Con los datos en descripciones, la respuesta ocupa una tarde de navegación manual y hay que rehacerla tras cada cambio de oferta.

#Disponibilidad frente a caché

Casi todo en un sitio así es estático. Infografías, descripciones, plano de situación y lista de servicios cambian quizá dos veces al año. Un solo valor no se comporta así: si una vivienda concreta sigue libre. Puede cambiar a las once de la mañana de un martes y es lo único de la página que un comprador serio necesita antes de llamar por teléfono.

Esa asimetría define la arquitectura. Servir páginas desde caché es lo que hace rápido a un sitio cargado de imágenes, y una página cacheada que presenta como disponible una vivienda vendida es peor que una página lenta. El comprador llama por un piso que se fue la semana anterior y la primera frase de la conversación comercial se convierte en una rectificación. La solución no fue cachear menos, sino partir la página en la parte que puede permanecer mucho tiempo en caché y la parte pequeña que no puede estar en caché en absoluto, y dejar esa segunda parte tan reducida que recalcularla no cueste nada.

En la práctica, el armazón de la página, las imágenes, las descripciones y el plano son comunes a todos los visitantes y se cachean de forma agresiva. La disponibilidad y el precio llegan por un punto de acceso propio y deliberadamente mínimo que no devuelve más que identificadores y estados. Tiene una vida corta y se invalida en el momento en que alguien cambia un estado en el panel. Redis sostiene la caché de objetos detrás de las consultas que construyen los listados, Memcached guarda sesiones y fragmentos de vistas, y una red de distribución se sitúa delante de todo, sobre todo por las imágenes, que en un sitio de este tipo pesan más que el resto junto.

#El mapa y las dos escalas

El mapa interactivo vende, no decora. Muestra la posición de los edificios respecto al paseo y a la playa, permite elegir planta y seleccionar una vivienda sobre el plano. La dificultad real no está en dibujar un mapa, sino en conciliar dos escalas: el plano de situación del conjunto y el plano de una planta concreta. Son dos sistemas de coordenadas y el visitante se mueve entre ellos esperando que el edificio que ha pulsado en la vista general abra la planta correcta y no un listado de todas.

Los planos se hicieron en formato vectorial, con áreas pulsables asociadas a identificadores de vivienda, en lugar de coordenadas superpuestas a una imagen de mapa de bits. La diferencia se nota en la primera revisión del proyecto: con mapa de bits, cualquier corrección invalida todas las áreas y hay que marcarlas de nuevo; con formato vectorial se sustituye el fichero y las asociaciones se mantienen. En una promoción entregada por fases, eso es la diferencia entre una hora y dos días por cada actualización de plano.

La búsqueda trabaja por atributos y no por palabras. Superficie, número de habitaciones, planta, orientación y estado son criterios de valores cerrados, así que una consulta se resuelve contra un índice en vez de recorrer texto. Con varios cientos de viviendas eso importa, porque la implementación ingenua vuelve a consultar la base de datos cada vez que se activa un filtro. El conjunto de valores disponibles se calcula una vez y se mantiene en caché, y cambiar un filtro sustituye la lista de resultados sin recargar la página.

#Integraciones y comportamiento ante fallos

Los datos de disponibilidad y reservas no se generan en el sitio. Se generan en el sistema del departamento comercial y la web es su consumidora. El intercambio va por REST API, de forma asíncrona, con validación en el lado receptor, porque los datos procedentes del sistema de otro acaban llegando en un formato que nadie anunció.

La decisión más importante afectaba al fallo. El comportamiento por defecto de la mayoría de extensiones es mostrar un error o una sección vacía, lo que en una página de venta se lee como una caída completa del sitio y hace más daño que no mostrar nada. Aquí cada canal tiene un valor de reserva: la última respuesta conocida en caché y, cuando tampoco existe, una variante estática de la sección que indica que el departamento comercial confirma la disponibilidad actual. El visitante ve una página sin un módulo, no un mensaje de error. Un sistema externo inaccesible es un suceso para la monitorización, no para el usuario.

La validación en el lado receptor hace además algo que rara vez se menciona. Un registro sin superficie, o con un estado fuera del conjunto conocido, se rechaza y se notifica en lugar de aterrizar en la página como celda vacía de una tabla. Una sola fila defectuosa destruye la credibilidad de todas las filas correctas que la rodean, y el visitante no tiene forma de distinguirlas.

#Presentación, imágenes y omisiones deliberadas

El tema es propio, modular, construido sobre HTML5 y SASS. La disposición y la colocación de los elementos las aportó el cliente, así que nuestra parte fue traducir eso a plantillas, comportamiento responsivo y un modelo de contenidos que aguante el mantenimiento. SASS se gana su sitio no por acortar la escritura, sino por dar al color de marca y a la escala tipográfica un único lugar en vez de cuarenta, lo que en una promoción ampliada por fases se traduce directamente en el coste del siguiente edificio.

La imagen es a la vez el contenido principal y el gasto principal. Una infografía de apartamento con vistas al mar no se puede comprimir hasta que el mar se convierta en una mancha, y una galería a resolución completa cargada de entrada puede pesar más que todos los demás recursos juntos. Por eso las imágenes se sirven en varios tamaños elegidos según el ancho de la ventana, y todo lo que queda bajo la primera pantalla espera a que el visitante llegue hasta ahí.

Lo que el sitio no tiene también cuenta. No hay contador de viviendas vendidas, porque una cifra así toma vida propia y al cabo de un trimestre nadie recuerda qué se incluyó en ella. No hay calculadora de rentabilidad, porque produciría un número que después nadie confirmará, y en una página de inversión un número sin confirmar es un compromiso y no un argumento. La omisión deliberada es aquí un resultado de trabajo legítimo y no un hueco en el alcance.

#Nuestras acciones

Para la promotora de DUNE Resort construimos un sitio con presentación interactiva de la promoción, plano de situación, búsqueda de viviendas por atributos y un mecanismo que mantiene los estados alineados con el sistema del departamento comercial. El recorrido lleva al visitante desde la vista del conjunto hasta una vivienda concreta y de ahí al contacto, sin retrocesos y sin volver a introducir criterios que ya había fijado una pantalla antes.

La frase más importante de esta sección es que las pruebas de los recorridos principales se hicieron sobre una copia de producción y no sobre una instalación limpia. El rendimiento de un sitio con varios cientos de registros, una galería y una integración activa no tiene nada que ver con el de una instalación nueva con tema de demostración, de modo que medir sobre la segunda habría dado un resultado tranquilizador y falso. Los casos límite son aquí una vivienda sin plano, un edificio en proceso de alta y un estado que no figura en el diccionario. Ninguno de los tres aparece si no hay datos reales delante, y solo ahí se pueden corregir antes del arranque.

Tras el arranque, el sitio recibió monitorización básica, analítica y control de caché, es decir, el mínimo para notar que algo ha dejado de funcionar antes de que lo note el departamento comercial.

#Resumen

Tres edificios entregados en momentos distintos, varios cientos de viviendas con tipologías diferentes y una zona común con piscinas, fitness y restauración. Eso no cabe en una sola pantalla, y el sitio tenía que ordenar esa complejidad en lugar de repetirla. De ese encargo salen todas las decisiones técnicas anteriores: la vivienda como registro con atributos, los planos en formato vectorial ligados a identificadores, la disponibilidad separada del resto cacheable de la página e integraciones que al fallar degradan una sección en lugar de una página entera.

Lo que pasa al siguiente proyecto inmobiliario es la forma de trabajar, con el modelo de contenidos antes que la plantilla, la separación entre datos volátiles y estáticos en la capa de caché y las pruebas contra una copia de producción. El modelo de contenidos en sí y las integraciones se quedan aquí, porque se construyeron alrededor de los datos de un cliente y de la forma de una promoción concreta. La siguiente implementación empieza por un análisis de alcance, y el presupuesto viene después.

Más información en el sitio web: duneresort.pl