Travel & Tourism Site: DUNE CITY

#Dune City, um site escrito ao mesmo tempo que o edifício

O conteúdo deste site foi produzido em paralelo com a obra, e isso condiciona tudo o resto. As plantas mudaram durante o projeto. Algumas frações foram renumeradas. As fotografias chegaram por fases, primeiro imagens tridimensionais, depois registos do estaleiro e só no fim interiores acabados. Um site institucional descreve algo que já existe; aqui a descrição andou à frente do betão durante mais de um ano, e o modelo de conteúdo teve de aguentar que a mesma ficha trocasse de material sem que ninguém tocasse num template.

O complexo é o Dune Resort, em Mielno, na língua de areia que separa o mar Báltico do lago Jamno, cerca de dez quilómetros a norte de Koszalin. O promotor é o Firmus Group e o projeto de arquitetura saiu dos ateliers SAS e Mellon. São trezentos e trinta apartamentos, de uma a quatro assoalhadas, e o edifício B acolhe uma zona de bem-estar de utilização anual com piscinas interiores. O trabalho incluiu a camada de identidade além do próprio site, e é por isso que esta entrada aparece em duas categorias do portefólio.

Trezentos e trinta frações é um número inofensivo num folheto e outra coisa por completo num modelo de dados. Cada fração tem área, piso, orientação, tipologia, edifício, fase de venda, estado e preço. Pelo menos metade destes campos muda ao longo do tempo. O site de um promotor não é, portanto, uma montra com fotografias: é uma interface sobre uma base de dados que continua a mexer-se enquanto alguém a lê.

A implementação decorreu ao longo de cerca de seis semanas e entrou em produção em 2017. Como programador WordPress construí um tema à medida e os módulos que apresentam a oferta. O layout e a colocação dos elementos vieram do cliente, e foi sobre essa base que montei os templates e o modelo de conteúdo.

#Principais funcionalidades e módulos

O módulo de mapas junta a integração com a API do Google Maps e a biblioteca Leaflet.js, e serve tanto o mapa do terreno como as plantas interativas. A separação entre os dois é deliberada. O mapa do terreno responde à pergunta sobre onde fica isto em relação à praia e ao passeio marítimo, e é aí que os dados geográficos fazem sentido. Uma planta de piso não é um mapa do mundo, é uma imagem com regiões clicáveis, e conduzi-la pelo mesmo mecanismo de um mapa termina num escalonamento que se desfaz no telemóvel.

A pesquisa e a ordenação assentam em campos personalizados e taxonomias, com os resultados obtidos de forma assíncrona por AJAX. Filtrar por várias dimensões ao mesmo tempo é o ponto em que um catálogo imobiliário costuma cair, porque cada atributo acrescentado multiplica o número de combinações. Uma implementação ingénua consulta a base uma vez por cada interruptor, e com trezentas e trinta frações e seis filtros isso passa a dezenas de consultas por clique. Aqui o conjunto de valores disponíveis é calculado uma vez e mantido em cache, e uma alteração de filtro substitui a lista de resultados em vez de recarregar a página.

A integração com sistemas externos por REST API sincroniza disponibilidade, estados de reserva e atualizações da oferta. É a parte mais sensível de toda a montagem, porque a fonte de verdade sobre o estado não é o site, é o sistema comercial do promotor. Qualquer atraso nessa sincronização tem um custo muito concreto: alguém telefona por causa de uma fração vendida ontem, e a primeira frase da conversa comercial é uma correção.

As ferramentas analíticas mostram que frações são mais consultadas e como o interesse se distribui pelas fases. Para o promotor isto é informação operacional e não um relatório para uma reunião: se uma tipologia acumula visitas e não gera contactos, o problema está no preço ou na descrição, e ambos podem mudar na mesma semana.

A camada de desempenho assenta em cache com Redis e Memcached e em distribuição de conteúdo por CDN. A tensão aqui é exatamente a inversa da de um site de imagem: o site de um promotor tem de ser rápido e estar atualizado ao mesmo tempo, e na arquitetura de cache essas duas propriedades puxam em sentidos contrários.

#Soluções técnicas e compromissos

O tema foi construído totalmente responsivo e modular, sobre HTML5 e SASS. A modularidade não é aqui um adorno de arquitetura, é a resposta ao ciclo de vida deste tipo de empreendimento. As fases são lançadas umas a seguir às outras, cada uma recebe o seu edifício, a sua bolsa de frações e a sua campanha, e o site tem de absorver uma fase nova sem reconstruir templates. Um projeto em que o edifício A está escrito à mão em dezena de sítios custa uma semana no edifício C em vez de uma hora.

A integração de dados de geolocalização exigiu endpoints dedicados que devolvem a posição e os parâmetros de cada fração para desenho dinâmico no mapa. A dificuldade não está em desenhar pontos. Está em que a planta e a lista de resultados têm de mostrar o mesmo estado: quem filtra frações de duas assoalhadas espera que se iluminem na planta exatamente essas. Manter uma única fonte de estado para duas vistas tão diferentes é o trabalho verdadeiro.

O processamento assíncrono por AJAX e REST API melhora a navegação e paga-se num sítio fácil de esquecer. Os resultados de um filtro carregados sem recarregar a página não têm endereço próprio, portanto não podem ser enviados a ninguém nem indexados. A resposta passa por espelhar o estado dos filtros no URL e devolver uma resposta completa do servidor numa entrada direta, mantendo o caminho assíncrono para as alterações seguintes. É praticamente o dobro do trabalho da camada AJAX sozinha, e a única forma de os resultados existirem fora de uma sessão de navegador.

A estrutura de endereços merece parágrafo próprio, porque decide se o empreendimento existe na pesquisa para lá do seu nome. Ninguém procura o nome de um empreendimento antes de o conhecer: procura um T2 em Mielno com vista para o mar. Isto significa que as combinações de filtros têm potencial de pesquisa real, mas só algumas. Todas ao mesmo tempo produzem milhares de endereços quase idênticos, que é a maneira clássica de diluir um site. A saída é escolher uma dezena de combinações que correspondam a perguntas que as pessoas escrevem de facto, dar-lhes endereço e conteúdo próprios, e deixar o resto do espaço de filtros fora do índice.

Vale a pena nomear o compromisso de cache sem rodeios, porque é ele que define o projeto. Descrições, fotografias, plantas e texto de marketing podem ficar em cache durante semanas. O estado e o preço de uma fração não podem lá ficar uma hora. Se as duas camadas caírem sob a mesma política, essa política tem de seguir o intervalo mais curto, o que equivale a abdicar de cache para a maior parte do conteúdo, que nunca precisou de frescura. Separá-las significa que o esqueleto da página e a galeria saem da rede de distribuição, enquanto o fragmento com o estado chega num pedido separado e barato.

A medição de desempenho significa aqui outra coisa que num site institucional. A vista mais pesada não é a página inicial, é a lista de resultados depois de aplicados os filtros, e essa vista não tem endereço fixo, pelo que uma auditoria normal à página inicial nunca lá chega. Os testes têm de seguir os caminhos por onde o tráfego passa de facto, de preferência sobre uma cópia de produção com o inventário completo carregado. Numa instalação vazia com dez frações de exemplo tudo é rápido e não se aprende nada.

O comportamento em campanha é a segunda medição que compensa planear. O promotor lança publicidade sobre uma fase e, numa hora, uma única subpágina recebe mais tráfego do que no mês inteiro anterior. O padrão é previsível, portanto pode ser servido de forma barata: a página da fase fica inteiramente em cache exceto o fragmento de estado, e esse fragmento é leve. Sem essa separação, a mesma campanha significa pagar capacidade de servidor por um dia.

O telemóvel merece uma nota, porque o primeiro contacto com a oferta acontece no telemóvel enquanto a compra se fecha num computador. Uma planta de piso num ecrã de quatrocentos píxeis é ilegível se for tratada como uma imagem para deslizar. As regiões clicáveis têm de ter tamanho de dedo e não de cursor, e num ecrã pequeno isso costuma significar que a planta deixa de ser um mapa e passa a ser uma lista com realce. Não é uma versão móvel simplificada, é outra resposta à mesma pergunta do utilizador.

#O que o comprador procura e o que não cabe num formulário

Quem compra um apartamento à beira-mar percorre um site ao contrário de quem reserva um quarto. Não olha para a oferta, elimina-a. Entra com uma restrição dura, normalmente o orçamento ou a área, corta a maior parte do inventário no primeiro minuto e só depois começa a olhar para as fotografias. Isto inverte a hierarquia habitual de uma página: o filtro é conteúdo de primeira ordem, e a camada visual só começa a trabalhar quando a lista desce para uma dezena de posições.

O segundo critério é espacial e não cabe num formulário. Num empreendimento levantado sobre uma língua de areia, o que conta é de que lado do edifício fica a fração, porque isso decide se a vista vai para o mar, para o lago ou para o bloco ao lado. Nenhum cursor deslizante faz essa pergunta, e por isso a escolha tem de ser possível na planta e no mapa do terreno.

O terceiro fator é próprio desta localização. Mielno é uma terra de época, mas comprar um apartamento não é uma decisão de época, e uma parte considerável dos compradores trata a operação como investimento para arrendamento e não como segunda casa. São duas conversas distintas conduzidas nas mesmas páginas. Quem compra para si pergunta pela tipologia e pelo sossego. Quem compra para arrendar pergunta quantas semanas por ano a fração pode ser alugada e se o edifício tem algo que prolongue a época. A zona de bem-estar de utilização anual no edifício B responde precisamente a essa segunda pergunta, e por isso não pode ficar na arquitetura de informação como mais um cartão de comodidades ao lado do estacionamento.

Falta a confiança. Um empreendimento vende algo que, no momento da compra, muitas vezes ainda não existe, pelo menos não no estado em que será entregue. Tudo o que o site apresenta como facto tem de ser verificável ou estar assinalado com clareza como imagem tridimensional. É uma decisão editorial com consequência técnica direta: as imagens de projeto e as fotografias de obra têm de ser distinguíveis dentro do modelo de conteúdo, e não despejadas na mesma galeria.

#O nosso trabalho

Para o Dune City entregámos o site com os módulos de mapa, a pesquisa e a sincronização externa, de modo que um visitante consiga verificar a oferta em vigor sem percorrer à mão uma dezena de subpáginas, mais a camada de identidade alinhada com o restante material do empreendimento.

A numeração das frações é o que mais frequentemente se parte um ano depois do arranque, e não no dia do arranque. Muda durante a obra com mais frequência do que qualquer pessoa assume enquanto desenha o modelo de dados, e se o identificador da fração for também o número que o cliente vê, cada alteração parte ligações que já circulam em mensagens de correio e em documentação comercial. Separar o identificador interno da etiqueta visível custa um campo na base de dados e poupa uma semana de correções.

As fotografias são o segundo desses sítios. As sessões de interiores acontecem normalmente depois da entrega do primeiro edifício, portanto o site vive de imagens de projeto durante mais de um ano. O momento da troca é crítico para a credibilidade: se imagens de projeto e fotografias partilham a mesma galeria, o que fica depois é uma mistura em que ninguém sabe o que está a ver. Por isso os dois tipos de material têm estado próprio no modelo, e a vista consegue mostrá-los lado a lado com legenda clara em vez de substituir um pelo outro em silêncio.

A tabela de preços é o terceiro. Os promotores alteram preços por fase e muitas vezes preferem não os publicar na íntegra, disponibilizando-os depois de um contacto. Isso obriga a que o preço seja um campo separado com regra de visibilidade própria, e não um parágrafo escrito dentro da descrição. Os três casos têm a mesma natureza: aquilo que muda de forma independente tem de ser campo próprio, ou cada alteração passa a ser trabalho de redação numa dezena de sítios ao mesmo tempo.

#Resumo

O Dune City é um projeto em que a camada de apresentação é a parte menos interessante do trabalho. A dificuldade mora no modelo de dados, em sustentar um único estado através da lista, da planta e do mapa, na sincronização com o sistema comercial e na separação entre o que pode ficar em cache e o que tem de estar fresco.

Nesta página não há métricas de resultado. Número de contactos, ritmo de vendas e percentagens de crescimento pertencem ao investidor e não ao caso de estudo de quem executa, e nenhuma delas poderia ser aqui ligada a uma fonte verificável. O que passa para o projeto seguinte é a ordem das perguntas: apurar o que muda e com que frequência, e escolher a tecnologia depois disso.

Convém dizer, por fim, quem fica com o resultado deste trabalho depois de a venda terminar. Parte do complexo é gerida por um operador de arrendamento, a City Apartments, com perto de duzentas e cinquenta frações sob administração, e é essa operação que passa a usar o mesmo endereço quando a fase de promoção acaba. Do lado do proprietário, quem comprou para arrendar continua a precisar de páginas que descrevam o edifício e a envolvente muito depois de deixar de existir uma fração à venda. Do lado do visitante, o que resta é um catálogo que continua a responder às mesmas perguntas de orientação e de tipologia. A arquitetura de informação teve de prever esses três leitores em vez de assumir que o site morre com a última fração vendida, e as duas direções habituais de expansão, integração mais profunda no sistema comercial e suporte da fase pós-venda, servem exatamente esse período. Cada uma delas é um âmbito próprio, orçamentado depois de análise.