Desenvolvimento e-commerce: QUALITY WATCH

O projeto Quality Watch foi criado para apresentar os serviços de uma empresa especializada em padrões de atendimento, gestão de qualidade, experiência do cliente, jornada do cliente e customer intelligence. A Quality Watch é uma agência de estudos de mercado sediada em Varsóvia, cuja atividade registada é a investigação de mercado e de opinião pública, e cuja parte mais reconhecível da oferta é o Mystery Shopping, a par de estudos de satisfação e testes de conhecimento para equipas comerciais e de atendimento. A implementação arrancou em 2017 e demorou cerca de seis semanas, em WordPress com tema próprio.

#Uma ligação que vai viver anos na caixa de correio de outra pessoa

Convém começar por aqui, porque foi este o critério que decidiu quase tudo o resto. Quem pede orçamento a uma agência deste tipo raramente é quem assina. Na prática está do outro lado uma responsável de qualidade ou um diretor de rede comercial que anda a juntar material para convencer terceiros. O texto tem de sobreviver a sair do navegador e entrar numa apresentação interna: o que é o método, como são escolhidos os auditores, o que traz o relatório, como se desenrola uma visita.

Daí a primeira decisão técnica. Cada método recebeu um endereço estável, um título principal próprio e dados estruturados próprios. Enviar uma ligação e depois explicar em que separador é preciso clicar é uma falha de arquitetura de informação, não uma falha de quem recebe. Endereços que mudam ao sabor de reorganizações internas anulam todo o trabalho feito antes deles.

A segunda decisão tem que ver com o comprimento do texto. Conteúdo consultivo deste género é longo por natureza, porque o cliente quer perceber em que difere uma visita a um concessionário de uma chamada para a linha de apoio. Ao mesmo tempo, a mesma página tem de poder ser lida na diagonal em dois minutos por alguém que está apenas a montar uma lista de fornecedores. A resposta não é cortar, é dispor o conteúdo em camadas.

#Seis designações comerciais, um único mecanismo

Colocadas lado a lado, as designações mostram a dificuldade real. Mystery Shopper, Mystery Client, Mystery Caller e Mystery E-mail descrevem o mesmo mecanismo de investigação aplicado a quatro canais de contacto diferentes. O mapeamento da jornada do cliente e as auditorias de qualidade são outra coisa, com outro orçamento, outro interlocutor e outro calendário. Uma página que despeja as seis numa lista de tópicos deixa o leitor com a ideia de uma empresa que faz muita coisa e nada em concreto.

Graças a esta estrutura, a Quality Watch comunica o valor dos seus métodos sem os misturar. O visitante percebe primeiro em que diferem os canais e só depois quais são as variantes setoriais. Esta ordem foi a única discussão de conteúdo no projeto que valeu mesmo a pena ter.

#Modelo de conteúdos e o preço que ele cobra

Dispor em camadas soa a desenho e é, na verdade, um problema de modelação de dados. A versão óbvia, uma página longa com acordeões, aguenta até ao momento em que a agência começa a vender o mesmo método a vários setores. Aí a descrição para retalho e a descrição para automóvel diferem em três parágrafos de vinte, e mantidas em separado criam três sítios onde uma correção tem de ser feita três vezes.

Por isso o modelo separa método e aplicação. O método é um registo e descreve o mecanismo: quem observa, em que papel, o que é anotado e em que forma volta o resultado. A aplicação é um registo próprio e descreve o contexto setorial. O template junta os dois no momento em que a página é servida. O custo é real e merece ser dito: quem edita tem de compreender a separação antes de escrever algo novo, e um caso atípico demora mais a publicar do que demoraria colar um parágrafo pronto. O ganho aparece por volta da décima quinta variante, ou seja ao fim de cerca de um ano.

Os estudos de caso exigiram mais conversa do que código. Uma agência de estudos trabalha com dados que, na maioria, não pode atribuir. O registo trata por isso a versão anónima como estado normal e não como exceção: setor e dimensão da rede são campos próprios, a marca é opcional. Quando o campo da marca está vazio, o template não deixa um buraco onde devia estar um logótipo, monta o cartão de outra maneira. Parece um pormenor até metade da lista de referências ter esse campo vazio.

O mesmo princípio vale para os números. Onde a fonte não pode ser nomeada, o resultado também não pode ser verificado, e nesse caso não deve constar da página como afirmação. A estrutura permite descrever o âmbito de um trabalho, isto é o que foi investigado e como, sem reclamar um desfecho que o leitor não tem forma de confirmar.

#AJAX e REST API, e por que razão não foi enfeite

Durante a execução encontrámos desafios na integração de conteúdo dinâmico e na apresentação de um portefólio de serviços extenso de forma clara. Utilizámos mecanismos de AJAX e endpoints dedicados de REST API, o que permitiu carregar informação sem interrupções e apresentar estudos de caso e opiniões de clientes de forma interativa. Em 2017 esta não era uma escolha evidente para um site de apresentação e não a recomendaria por omissão.

Aqui decorreu da forma da oferta. Como os serviços se sobrepõem, ninguém os lê por ordem. Alguém abre Mystery Shopping, recua, verifica Mystery Caller, compara o âmbito do relatório, recua outra vez. Com recarregamentos clássicos, cada um destes passos custa um ciclo inteiro: novo pedido, template renderizado do princípio, os mesmos recursos descarregados de novo.

O custo desta decisão tem duas partes e nenhuma se esconde. Cada estado do filtro precisa de endereço próprio, caso contrário o visitante não consegue enviar a um colega aquilo que está a ver e um motor de busca não indexa nada além da vista por omissão. E a camada de dados tem de funcionar sem JavaScript, porque sites de consultoria são abertos dentro de ambientes empresariais com políticas de navegador restritivas. A vista base é por isso gerada no servidor, e o caminho assíncrono apenas encurta o percurso onde está disponível.

Os endpoints serviram ainda para algo menos visível. As opiniões de clientes e os resultados publicados mudam mais vezes do que a oferta e passam por um circuito de aprovação interno diferente. Movê-los para um recurso próprio significou que uma atualização deixou de tocar nos templates das páginas de serviço e de invalidar a respetiva cache.

#Desempenho medido contra uma cópia de produção

O estrangulamento deste projeto foi o comportamento sob tráfego real e a invalidação de cache, não o tempo de carregamento da página inicial. A distinção interessa. Uma instalação limpa de WordPress com o mesmo tema responde depressa porque não há nada a calcular: base pequena, relações pouco profundas, uma lista de serviços que cabe numa consulta. O mesmo código contra uma cópia de produção, com o catálogo completo de métodos, aplicações, estudos de caso e taxonomias, comporta-se de outra maneira, porque montar uma lista filtrada toca em várias tabelas ao mesmo tempo.

Por isso os percursos por onde passa o tráfego foram testados numa cópia de produção e não num ambiente vazio. É uma regra que custa algumas horas de preparação e poupa uma semana de espanto depois do arranque. Uma cópia de produção mostra coisas que uma instalação vazia não consegue mostrar: uma consulta invisível com três registos que com duzentos é a operação mais cara da página, ou uma cache que tecnicamente funciona mas é invalidada a cada gravação de qualquer conteúdo, pelo que na prática não existe.

A tensão arquitetural fica exatamente entre cache e frescura. As páginas de oferta podem ser guardadas em cache durante muito tempo porque mudam pouco. O bloco de novidades e opiniões muda com frequência e quem edita espera ver a alteração de imediato. A solução foi separar as duas coisas: o esqueleto e as páginas de serviço ficam em cache longa, enquanto os fragmentos voláteis chegam num pedido próprio, com vida curta e invalidação por registo na gravação em vez de global.

#Formulários e o que acontece depois do clique

Este site recolhe pedidos de proposta e não encomendas, e isso nota-se no código. Um trabalho de Mystery Shopping não se orça com três campos, porque o valor depende do número de locais, das visitas por ciclo, dos canais incluídos e de o cliente querer um relatório agregado ou uma desagregação por local. Um formulário que pergunta tudo à partida afasta as pessoas. Um formulário que não pergunta nada gera pedidos que só se respondem com outra pergunta.

O compromisso separa primeiro contacto de qualificação. Os campos obrigatórios são poucos e as extensões aparecem apenas quando o visitante indica que já sabe o que procura. Tecnicamente isso significa validação no servidor e não apenas no navegador, porque validação do lado do cliente é conforto e não um controlo. Significa também proteção contra spam que não obrigue a transcrever caracteres de uma imagem, já que aqui cada passo adicional no percurso custa um pedido.

Falta uma decisão que parece trivial e não é: o limite de comprimento do campo de mensagem está alto o suficiente para não cortar um pedido verdadeiro. Um limite curto corta a mensagem a meio de uma frase e quem escreveu nunca fica a saber, porque só vê o ecrã de confirmação. Esse erro não aparece em registo nenhum nem em teste nenhum, apenas numa conversa que não chegou a existir.

#Layout do cliente, ordem discutida em conjunto

A disposição dos elementos e a camada visual vieram do cliente. A nossa parte foi transformar isso em templates, comportamento responsivo e um modelo de conteúdos que se mantenha depois do arranque. A estética não esteve em causa, a ordem da informação esteve.

O site foi concebido com foco em responsividade por uma razão concreta: boa parte do tráfego é alguém que recebeu a ligação por correio e a abre no telemóvel entre duas reuniões. Num ecrã pequeno a ordem das secções deixa de ser questão de gosto, porque o visitante vê dois ecrãs e ou percebe o que esta empresa faz, ou volta à caixa de entrada. HTML5, CSS3 com o pré-processador SASS e JavaScript garantem um layout limpo e comportamento estável, mas não decidem por ninguém o que fica no topo.

As tabelas comparativas mereceram atenção própria. A comparação entre métodos é o conteúdo principal deste site, e uma tabela cujos cabeçalhos não estão associados às células é, para um leitor de ecrã, uma sequência de palavras sem estrutura. Essa associação é barata quando o template é construído e cara de acrescentar depois, por isso entrou logo.

#O que não resultou à primeira

Uma descrição de projeto sem esta secção é um folheto. A primeira versão do filtro de serviços guardava a seleção no endereço, mas não guardava a posição de deslocamento. Quem abria um método e voltava com o botão anterior aterrava no topo da lista e tinha de procurar outra vez onde estava. Com seis entradas ninguém repara. Com uma lista que cresceu para várias dezenas depois de entrarem as variantes setoriais, é exatamente por aí que alguém desiste de continuar a ver.

A segunda correção foi nas imagens. As fotografias de referência foram carregadas na resolução em que chegaram do cliente, bastante maior do que qualquer vista do site. As variantes de tamanho são geradas automaticamente, mas apenas para ficheiros carregados depois de a configuração estar no sítio, pelo que o material migrado do site anterior ficou com os originais. Dar por isso exigiu olhar para o peso de transferência de uma subpágina concreta e não para uma medição da página inicial, que por acaso era leve.

O terceiro ponto não foi um defeito mas um compromisso, e continuo a achá-lo acertado. Abdicámos de personalizar o conteúdo consoante o setor do visitante. Era exequível e soava atraente, mas obrigaria a distinguir visitantes a um nível em que a cache deixa de fazer sentido, e o benefício só apareceria com um tráfego de outra ordem de grandeza. O setor é, em vez disso, uma escolha que o visitante faz de propósito, num clique, e essa escolha viaja dentro da ligação.

#Manutenção técnica depois do arranque

Para manter o serviço ao nível a que foi entregue, oferecemos manutenção técnica contínua, com atualizações regulares, monitorização de registos, cópias de segurança sistemáticas e alterações funcionais correntes. As atualizações passam primeiro por um ambiente de testes, porque num site com tema próprio e endpoints próprios são precisamente esses, e não o núcleo do WordPress, que costumam partir numa subida de versão.

O que se transporta deste projeto para o seguinte é a camada técnica: JavaScript, HTML5, CSS3, SASS e AJAX ficam parecidos de cada vez. O que não se transporta é o modelo de conteúdos nem as integrações, porque ambos nasceram para os dados de um cliente e para um pedido concreto. O projeto seguinte começa por uma análise de âmbito, e a proposta vem depois dela e não antes.

Cliente: Quality Watch
Âmbito do trabalho: Desenvolvimento web, layout

Para saber mais, visite o site: qualitywatch.pl