Quem procura um restaurante ao telemóvel quer saber três coisas: o que há para comer, se está aberto, e como se encomenda ou reserva. Nos últimos dias fiz ou revi três sites de demonstração de restauração, um restaurante de sushi em Lisboa, uma churrasqueira de take-away em Torres Vedras e uma pizzaria no Algarve, e os três acabaram por girar à volta dessas perguntas. Nenhum deles é cliente; são exemplos que fiz por minha conta.
A ementa é uma página, não um PDF
O restaurante de sushi tinha a ementa inteira num PDF de 25 páginas guardado no Google Drive. No telemóvel, isso quer dizer descarregar um ficheiro pesado, fazer zoom com dois dedos e andar para trás e para a frente. E quem pesquisa no Google pelo nome do restaurante mais "menu" não encontra nada, porque aquele PDF não aparece nas pesquisas.
No demo, a ementa passou a ser uma página normal: 142 pratos em 24 categorias, transcritos do PDF do próprio restaurante, com as fotografias dos pratos recortadas do mesmo documento. Algumas decisões que fizeram diferença:
- Pesquisa ao vivo. Escreve-se "salmão" e a lista filtra enquanto se escreve, sem ligar a acentos nem a maiúsculas.
- A referência de cada prato. Naquela casa pede-se escrevendo o código do prato num papel. Por isso cada prato mostra o código, e a pesquisa também encontra pelo código.
- Funciona sem JavaScript. A pesquisa é um extra. Se não carregar, a ementa continua toda lá, legível, com as categorias.
- Dados estruturados. A página descreve a ementa com os tipos
Menu,MenuSectioneMenuItemdo schema.org, para que os motores de busca percebam o que é cada coisa.
Uma nota sobre as ementas com QR code nas mesas: o QR code não é o problema, o destino é. Se aponta para um PDF, o cliente tem a mesma experiência má, só que sentado. Se aponta para uma página como esta, resolve.
Pôr à frente o que funciona
Na churrasqueira, o site existe para uma coisa: ligar e encomendar. Os dois números estavam na página, mas o fixo vinha primeiro em todo o lado. Esse fixo é o que os próprios donos anunciaram no Facebook como avariado, pedindo aos clientes que encomendassem para o telemóvel.
Num site assim, o primeiro número tem de ser o que atende. Agora o telemóvel vem à frente em todos os botões, na lista de contactos, no rodapé e nos dados estruturados. O fixo continua lá, identificado, porque ainda aparece no Google e pode voltar a funcionar.
Encomendar com hora de levantamento
O demo tem também uma página de encomenda antecipada: escolhe-se o que se leva, o dia e a hora, e paga-se ao balcão. Os horários são os reais da casa: fecha à terça, ao domingo só abre ao almoço, e não se pode marcar para daqui a dez minutos, só com pelo menos meia hora de antecedência. Os preços e o total são de exemplo, e no fim a página diz claramente que nenhuma encomenda foi criada. Num site real, o pedido chegaria ao balcão e seria confirmado ao cliente.
O ponto não é a tecnologia. É que quem encomenda à hora de almoço não tem de ficar agarrado a um telefone ocupado, e a casa recebe os pedidos por ordem, com hora marcada.
A barra de categorias, e os pequenos erros que a partem
Numa ementa longa, uma barra de categorias que fica presa no topo enquanto se desce é o que torna a página usável: carrega-se em "Sobremesas" e salta-se para lá. Parece simples, e parte com facilidade.
No demo do sushi, a barra desaparecia debaixo do aviso fixo no topo que todos os meus demos têm. Um elemento fixo e um elemento "sticky" competem pelo mesmo espaço, e a margem que empurra a página para baixo não chega para os separar. A correção foi o aviso publicar a sua altura como variável de CSS e a barra prender-se logo abaixo dela, em computador e em telemóvel.
Num site de restaurante real, o mesmo acontece com um cabeçalho fixo, um aviso de cookies ou uma barra de encomenda. Vale a pena confirmar três coisas no telemóvel:
- A barra de categorias fica visível enquanto se desce.
- Ao carregar numa categoria, o título não fica escondido por baixo da barra (resolve-se com
scroll-margin-top). - A barra desliza na horizontal quando as categorias não cabem no ecrã.
Uma ementa em duas línguas
Em Lisboa, no Algarve ou em qualquer zona com turistas, uma ementa em inglês não é um luxo. O demo do sushi tem a ementa em português e em inglês, com um botão para mudar de língua no topo e a indicação certa para os motores de busca de que as duas páginas são a mesma ementa em línguas diferentes. Duas regras: os nomes dos pratos que não se traduzem ficam como estão, e os códigos e preços são os mesmos nas duas versões.
Preços: só os que se podem defender
Na pizzaria, a lista publicada pela própria casa tinha erros evidentes. Publicar esses preços no site seria repetir o problema. O demo ficou com os nomes reais dos pratos e uma linha a dizer que os preços se confirmam no restaurante. Não é o ideal, mas é melhor do que um preço errado que o cliente vai reclamar ao balcão.
O que o dono tem de conseguir mudar sozinho
Uma ementa muda. Um prato sai, outro entra, o preço do frango sobe. Se cada alteração obriga a ligar a quem fez o site, a ementa fica desatualizada em poucos meses, e uma ementa desatualizada é pior do que nenhuma.
Por isso, antes de entregar um site de restaurante, fica decidido como o dono muda sozinho pelo menos isto: pratos, preços, horário e aquele aviso de "fechado para férias". Há várias formas de o fazer, desde um WordPress a algo mais simples feito à medida. O que não pode acontecer é descobrir isto depois de o site estar no ar. E o horário também tem de ser atualizado na ficha do Google, que permite ao dono editar a ementa e o horário, para que os dois digam o mesmo.
Em resumo
- A ementa numa página que se lê e pesquisa no telemóvel, não num PDF.
- O telefone que atende, e uma forma de encomendar, sempre à vista.
- Uma barra de categorias que funciona de verdade no telemóvel.
- Inglês, se recebe turistas.
- Só preços que se podem confirmar, e um dono que os consegue mudar.
Se tem um restaurante, uma churrasqueira ou um take-away e quer uma ementa assim, fale comigo. Os demos de restauração estão juntos na página site para restaurante e take-away.