Fintech Solution: car-mechanic-huntington.co.uk

#car-mechanic-huntington.co.uk, um site profissional para uma oficina automóvel

O projeto car-mechanic-huntington.co.uk apresenta os serviços de uma oficina automóvel e permite marcar hora. O público são proprietários de viaturas da zona, pessoas a perseguir uma avaria concreta e pequenas empresas que mantêm alguns carros em circulação. O site entrou em produção em 2012 e o trabalho demorou cerca de seis semanas.

#Quem edita este site fá-lo entre dois trabalhos

Vale a pena começar por uma restrição que não é técnica e que, ainda assim, decide metade das escolhas técnicas. Uma oficina não tem redação. Quem mexe no conteúdo é o proprietário ou quem estiver no escritório, entre um trabalho e o seguinte, muitas vezes com o telefone a tocar.

Daqui saem três consequências. A primeira é que alterar o horário de funcionamento tem de ser possível sem conhecimentos técnicos e sem qualquer hipótese de desalinhar a maquetização ao gravar. A segunda é que aquilo que muda com frequência tem de viver em campos próprios e não dentro de um bloco de texto livre, porque texto livre convida a formatação colada de outro lado. A terceira é que a quantidade de sítios onde a mesma informação aparece tem de ser mínima: se a morada está escrita em quatro sítios, um deles vai ficar desatualizado, e não será o da página de contacto.

É essa a razão concreta para o WordPress neste projeto, e não uma preferência de ferramenta. A superfície de edição era o requisito com mais peso depois da marcação.

#A marcação não é um campo de formulário

O módulo de marcações parece um formulário de contacto com um campo de data. Não se comporta como tal, porque distribui algo de que existe uma quantidade finita.

Uma oficina não tem agenda no sentido em que um consultor tem agenda. Tem elevadores e tem mecânicos, e uma marcação é a combinação dos dois durante um tempo que depende do trabalho. Uma mudança de óleo e uma avaria elétrica intermitente ocupam partes do dia completamente diferentes. Um modelo de dados que guarda a marcação como data e hora parte na primeira manhã em que duas pessoas querem as oito e existe um elevador.

Daí decorre a decisão que é o cerne do módulo. A disponibilidade mostrada no navegador é a fotografia de um instante que já passou. Entre a lista ser desenhada e o botão ser carregado passam com frequência dez ou quinze minutos, porque a pessoa vai confirmar se consegue faltar de manhã. A verificação tem de correr outra vez no servidor no momento da escrita, e tem de correr de maneira a que dois pedidos não atravessem a mesma hora livre. Uma interface que apenas esbate as horas ocupadas parece correta e produz a primeira marcação dupla assim que duas pessoas coincidem na página.

A segunda consequência diz respeito à cache. Quase tudo num site de oficina é estável: descrição dos serviços, como chegar, horário. Esse conteúdo pode ficar muito tempo em cache. A vista de disponibilidade é exatamente o contrário, porque o seu único valor é estar atualizada. Uma configuração que guarda tudo sem exceção serve sem hesitar uma fotografia da agenda com uma semana, e ninguém dá por isso até um cliente estar à frente de um portão fechado. A vista de marcações fica por isso excluída da cache de forma explícita, não por acaso.

Falta explicar porque foram escritos pontos de acesso próprios em vez de instalar uma extensão de marcações. As extensões deste género modelam um cabeleireiro ou um consultório: um profissional, uma cadeira, uma duração fixa. Dobrar esse modelo para aceitar um segundo eixo e uma duração variável custa mais do que escrever o caminho de escrita, e deixa pressupostos alheios exatamente onde um pressuposto errado termina num cliente a quem foi dada a hora das nove e que não é atendido.

#Funcionalidades-chave e tecnologias utilizadas

O layout responsivo coloca em primeiro lugar, em ecrã estreito, aquilo que se procura mesmo a partir de um telemóvel: o número, a morada e o caminho. O texto da oferta vem depois, porque a pergunta por uma oficina costuma ser feita de um parque de estacionamento ou da berma, e não de uma secretária.

Convém situar isto no tempo. Em 2012 o layout responsivo era uma rubrica do orçamento e não um dado adquirido. O flexbox não estava em uso generalizado e a grelha CSS não existia, portanto as colunas montavam-se com blocos flutuantes e os pontos de quebra escolhiam-se contra as larguras reais dos telemóveis que as pessoas traziam consigo. É daí que vem a grelha do Bootstrap: não por moda, mas porque a alternativa era escrever o mesmo de raiz e mantê-lo sozinho durante anos.

A integração com redes sociais traz publicações e avaliações para a página. É aqui que um site fica dependente de um servidor que ninguém aqui controla, por isso o comportamento em caso de falha teve de ser decidido durante a construção. As respostas são guardadas em cache e, quando a origem não responde, a secção mostra o último conteúdo conhecido ou não é desenhada. Uma caixa vazia com uma mensagem de erro na página inicial de uma oficina lê-se como uma queda de todo o site, e não como uma interface externa com uma tarde má.

O trabalho de motores de busca assentou em HTML5 semântico, metadados arrumados e dados estruturados que descrevem um negócio local. Num serviço de proximidade pesam sobretudo três coisas em forma legível por máquina: nome, morada e telefone numa única escrita invariável, o horário e a área servida. Uma divergência entre a morada do site e a dos diretórios externos é um defeito clássico de vida longa, precisamente porque ambas as versões parecem bem a um leitor humano.

#Desafios e soluções de programação

O peso da página foi atacado em três frentes: compressão de imagens, cache do conteúdo que muda pouco e redução do número de ficheiros de estilos e de scripts. Este último ponto tinha em 2012 um peso que hoje não tem, porque os navegadores abriam uma ligação por ficheiro contra um limite baixo de descargas em paralelo. Juntar dez folhas de estilo numa só não era cosmética nessa altura, retirava nove idas e voltas ao servidor.

A migração de conteúdos foi o segundo bloco. Existia uma versão anterior do site e parte dela sobrevivia apenas como cópias arquivadas, que recuperámos através do Web Archive. A metade fácil desta migração é o texto. A metade que costuma ser saltada são os endereços. Um site que esteve anos publicado tem ligações em diretórios locais, em listagens do setor e em mensagens já enviadas a clientes, e nenhuma delas vai ser atualizada por alguém. Cada URL antigo precisa por isso de um novo concreto e de um redirecionamento permanente, em vez de uma varredura geral para a página inicial. A varredura geral fica bem no navegador, porque não aparece erro nenhum, e deita fora tudo o que o endereço antigo tinha acumulado.

Os módulos que adaptam conteúdo ao visitante foram o terceiro desafio e colidem de frente com a cache, porque a cache compensa exatamente por entregar o mesmo documento a muita gente. A saída está em separar: o esqueleto da página e os textos dos serviços são comuns e ficam em cache, enquanto os fragmentos dependentes do visitante são pedidos à parte depois do carregamento. Sem essa separação, qualquer personalização invalida a cache do site inteiro e é preciso escolher uma das duas coisas.

#O mapa é o elemento mais caro da página de contacto

Um mapa incorporado é encomendado pelo cliente em meia frase e custa mais do que o resto da página de contacto junto.

É script alheio, folhas de estilo alheias e uma série de pedidos de mosaicos de imagem, tudo a partir de infraestrutura fora do nosso controlo. Num site pequeno, este único componente pesa habitualmente mais do que todo o conteúdo da página. E corre para cada visitante, incluindo aquele que entrou por um número de telefone e sai dez segundos depois.

A solução passa por não o carregar com a página. Por omissão aparece uma imagem estática com a localização assinalada e a morada em texto ao lado; o mapa interativo arranca apenas quando alguém lhe toca. Quem precisava da morada tem-na de imediato, e quem quer um trajeto dá mais um toque e recebe a ferramenta completa. A ordem é a inversa da intuitiva, e é por isso que a versão pesada acaba tantas vezes como predefinição.

#Ferramentas e tecnologias

WordPress para a edição, PHP e MySQL no servidor, HTML5, CSS3 e JavaScript na camada de apresentação, grelha e componentes do Bootstrap para o layout responsivo, mais cópias de segurança automáticas, controlo de versões do código e acompanhamento da visibilidade nos motores de busca. A palavra cópia traz aqui a ressalva de sempre. Uma cópia que ninguém restaurou é um ficheiro e não uma salvaguarda. O restauro tem de ter sido feito pelo menos uma vez, num ambiente separado, porque as lacunas só aparecem durante o restauro e nessa altura há normalmente pressa. Numa oficina com agenda isso inclui confirmar que voltam também as marcações e não apenas as páginas.

As extensões merecem uma nota, porque nela assenta uma decisão de arquitetura: as extensões funcionais usam-se onde compensam, mas a segurança não assenta numa delas, já que uma extensão de segurança é código a correr dentro da aplicação que pretende proteger e só começa a trabalhar quando o pedido já lá chegou. Filtrar o tráfego à frente da aplicação, manter o núcleo atualizado, restringir o acesso à administração e ter uma cópia testada rendem mais do que um painel que conta tentativas de acesso bloqueadas. É por isso que a lista acima tem poucas linhas e nenhuma delas promete proteção por si só.

#Suporte e manutenção no WordPress

A manutenção cobre a correção de avarias, a instalação de atualizações de núcleo, tema e extensões, a revisão de registos, as cópias de segurança segundo a política acordada e as alterações menores de conteúdo e de apresentação. Essa lista tem um limite e vale a pena mostrá-lo. Não inclui a garantia de que uma atualização nunca vai partir nada, porque essa garantia não pode ser dada por um site montado com peças mantidas por equipas independentes. Inclui que as alterações correm primeiro fora de produção e que o caminho de regresso está preparado antes de ser preciso, em vez de improvisado a meio.

Um site com módulo de marcações acrescenta uma obrigação que um site informativo não tem. Qualquer atualização que toque no tratamento de formulários ou no manuseamento de datas é testada contra uma cópia de produção com marcações reais, nunca contra uma instalação vazia. A razão é banal e não de princípio.

Numa instalação vazia a agenda está sempre livre, por isso nenhum teste chega ao caminho onde o módulo pode mesmo partir. Esse caminho são as colisões entre dois pedidos para a mesma hora e os casos-limite nas fronteiras de um dia de trabalho. Pela mesma razão as janelas de manutenção ficam fora do horário da oficina. Um formulário de marcação que não responde exatamente quando alguém quer uma hora custa um trabalho e não uma visita. Esse cálculo decide também o que espera pela próxima janela planeada e o que vale a pena fazer no próprio dia. Quem sente a diferença é o escritório, não o relatório de tráfego.

#Resumo e análise preliminar dos requisitos do cliente

O planeamento começou por um conjunto de perguntas a responder antes de qualquer construção. Ficam aqui porque a ordem do trabalho saiu inteira das respostas.

Para que serve o site e quem serve. O que já constava da lista de requisitos do cliente, que aqui incluía marcações, ligação a perfis sociais e conteúdo ajustado ao visitante. Como devia ligar-se à base de dados existente e o que o calendário permitia. Que exemplos o cliente queria apontar, e neles apontava para interfaces legíveis e uma apresentação clara da oferta. Quanto do site anterior era para manter e quanto era para escrever de novo. E até onde ia o orçamento, que é a pergunta que decide se um âmbito é entregue de uma vez ou por fases.

Primeiro aquilo que leva as pessoas ao site de uma oficina, ou seja serviços, como chegar e contacto; depois as marcações, o elemento mais complexo e o único que muda de facto a forma de trabalhar do escritório; e no fim as integrações externas, as menos críticas e as mais fáceis de acrescentar depois do arranque. O que transita deste trabalho é o método: verificar a disponibilidade de um recurso finito no servidor no momento da escrita, manter fora da cache as vistas que dependem do tempo, adiar componentes externos pesados até alguém os pedir e mapear endereços antigos um a um durante uma migração. O que não transita é o modelo de conteúdos deste projeto nem as suas integrações, escritos para uma oficina e um briefing da categoria Websites. Então por onde começa o projeto seguinte, se não por um modelo pronto? Por uma análise de âmbito, e a proposta vem a seguir.