Formulário de contacto sem backend: opções honestas

Um formulário HTML consegue recolher dados no navegador, mas não envia email sozinho. Para a mensagem chegar a algum destino é necessário um programa de email, um serviço externo ou código num servidor. Ignorar esta diferença cria uma das experiências mais frustrantes num site pequeno: apresentar uma confirmação falsa e perder a mensagem.

Opção 1: ligação de email simples

Uma ligação mailto: abre o programa de email configurado no dispositivo. É simples e transparente, mas nem todas as pessoas têm uma aplicação associada. Também não oferece controlo sobre o formato final nem confirmação de entrega.

É uma solução razoável quando o volume de contactos é baixo e o endereço de email já é público.

Opção 2: formulário que prepara o email

O formulário usado atualmente no Besttein valida nome, email, assunto, mensagem e aceitação da política. Depois constrói um assunto e corpo e abre o programa de email. A página explica que o visitante ainda precisa de confirmar o envio.

Esta opção melhora a organização sem fingir que existe backend. A desvantagem continua a ser a dependência do programa de email.

Opção 3: serviço externo de formulários

Existem serviços que recebem o pedido e encaminham a mensagem. Antes de usar um, é necessário avaliar limites, proteção contra abuso, localização dos dados, preço, política de privacidade e comportamento quando o serviço falha.

O site deve identificar o fornecedor na política de privacidade e não carregar scripts desnecessários antes de o visitante interagir.

Opção 4: endpoint próprio

Um backend próprio oferece mais controlo, mas precisa de validação no servidor. Nunca se deve confiar apenas nos atributos HTML ou no JavaScript do navegador, porque um pedido pode ser enviado diretamente.

O servidor deve limitar tamanho, validar formato, rejeitar campos inesperados, controlar frequência, escapar qualquer conteúdo apresentado e impedir injeção em cabeçalhos de email.

Validação que ajuda pessoas

Mensagens como “erro” são pouco úteis. O formulário deve indicar que campo precisa de atenção e manter os dados já escritos. Labels visíveis, instruções curtas e foco claro são mais importantes do que efeitos visuais.

Campos devem ser mínimos. Para uma questão geral, nome, email, assunto e mensagem costumam chegar. Pedir telefone, morada ou empresa sem necessidade aumenta fricção e dados a proteger.

Proteção contra spam

Um honeypot é um campo escondido da navegação normal que bots básicos podem preencher. Ajuda, mas não é proteção completa. Num backend real, deve ser combinado com limites de frequência, registos de segurança proporcionais e, apenas quando necessário, desafios adicionais.

CAPTCHAs podem introduzir problemas de acessibilidade e privacidade. Devem ser usados depois de avaliar alternativas menos intrusivas.

Privacidade

A política deve explicar que dados são enviados, para quê, durante quanto tempo e através de que fornecedores. Um formulário não precisa de uma caixa de consentimento para todos os fundamentos possíveis, mas a informação deve ser clara antes do envio.

Se o contacto serve para responder a um pedido iniciado pela pessoa, o tratamento pode apoiar-se nesse pedido. A redação e o fundamento devem corresponder ao funcionamento real.

Como escolher

• Site pessoal com poucos contactos: email ou preparação por mailto:;
• Projeto sem servidor, mas com necessidade de fiabilidade: serviço externo cuidadosamente escolhido;
• Aplicação com processos próprios: endpoint no servidor, validação e monitorização;
• Informação sensível: evitar email comum e procurar uma solução adequada ao risco.