Como é possível decifrar caracteres em imagens via software, a solução que muitos adotam em seus captchas (imagens com texto aleatório para se redigir) é complicar a imagem com rabiscos e distorções, os resultados são imagens difíceis de decifrar até mesmo por humanos. Veja o exemplo do RapidShare:

Imagens aleatórias misturadas com o texto complicam bastante a leitura e induzem a erros, mas se sua visão for baixa as coisas podem ser ainda piores. Quem nunca errou várias vezes seguida uma confirmação assim?

Outro problema também bastante sério é a acessibilidade, o cadastro do Windows Live Hotmail tenta contornar este problema dando a opção de ouvir um áudio ao invés de utilizar a imagem:

Particularmente não ouvi som algum tanto no Firefox como no Internet Explorer, e também se deve levar em conta que este recurso é complexo e de difícil implementação.

É necessário estudar possibilidades que vão alem de combater o spam, que não atrapalhem o usuário quando ele pretende cadastrar-se, entrar em contato por um formulário ou postar um comentário. Existem soluções mais humanas e inteligentes para barrar o spam.

Fazer perguntas simples que qualquer um seja capaz de responder é uma alternativa que vem se espalhando principalmente em blogs. Veja uma lista de perguntas muito utilizadas:

• Quanto é 2 + 2?
• O Fogo é quente ou frio?
• A chuva é seca ou molhada?

As possibilidades são inúmeras. Mas lembre-se de informar ao usuário a razão desta pergunta (impedir o spam), uma nota ao lado ou por perto resolve. O problema desta solução é que não tem utilidade para sites muito visados por spammers, se tiverem interesse em atacar exclusivamente a ele fica fácil quebrar esta proteção.

Outra solução bastante inteligente e complexa é o uso de Honeypots, neste caso armadilhas voltadas a detectar spambots. Na web podem ser campos escondidos que apenas um bot preencheria facilitando a identificação de spam sem exigir nada do usuário. Um exemplo seria:

<label for="campo">
Isto é um Honeypot, esconda-o por CSS e avise que deve ficar em branco
</label>
<input type="text" name="campo" id="campo" />

Se o campo receber algum dado provavelmente será spam. Mas este método assim como o anterior é fácil de ser quebrado se seu site é um alvo exclusivo.

Não existe solução definitiva de combate ao spam, não é possível detectar automaticamente todos, mas com as medidas certas podemos barrar uma boa quantidade deles e não prejudicar o usuário. Soluções simples como perguntas e honeypots são as melhores opções para a maioria dos sites, apenas os mais visados como RapidShare e Windows Live Hotmail ainda dependem do velho captcha.

O briefing é uma etapa importantíssima do desenvolvimento web, suas informações possibilitam os desenvolvedores a criarem produtos que atendam as expectativas dos clientes e principalmente, que gerem bons resultados.

Meses atrás coloquei em prática a idéia de criar um modelo de briefing em modo colaborativo, convoquei desenvolvedores através da WD Design e uma boa quantidade se ofereceu a ajudar. Mas infelizmente não houve resultado positivo, alguns dias depois o documento estava esquecido.

Olhando aquele documento totalmente desestruturado e abandonado resolvi reestruturá-lo para então compartilhar aqui já que pode ser útil para alguns leitores. Não existe modelo de briefing que atenda as necessidades de todos, portanto sinta-se a vontade para modificar ou utilizar apenas algumas partes deste documento.

• Modelo de briefing no Google Docs
• Modelo de briefing em DOC
• Modelo de briefing em PDF

Minha única recomendação é não tornar o documento muito extenso, não é muito vantajoso fazer seu cliente responder um formulário imenso e cansativo.

Achei realmente muito bonito. Mas isso me faz pensar: Será que todos os usuários perceberão que se trata de um Checkbox/Radio Button? Quando estão acostumados com a aparência padrão encontrada em seus sitemas operacionais ou mesmo navegadores, pode gerar certa confusão apresentar Checkboxes e/ou Radio Buttons totalmente diferentes (mesmo mais agradáveis).

Preservando a aparência padrão dos elementos você facilita a vida do usuário na hora de reconhecê-los, um exemplo clássico são links na cor azul e sublinhados, tão defendidos por Jakob Nielsen. Mas acho que a maioria concorda que isso é visualmente desagradável, ou no mínimo pouco criativo. Então o que fazer?

Tente conciliar os dois lados, customize seus formulários e links, mas faça de modo que sempre se pareçam com formulários e links. O usuário não deve parar para pensar “será que isso é um link?” ou “será que isso é um checkbox?”. É totalmente possível servir um site com bom design e ao mesmo tempo fácil de ser usado, e os resultados são ótimos.

O problema:

Um arquivo PNG carrega informações de correção de cores (GAMMA) pra que evite que ocorra distorções de cores nas imagens. Por ironia esse é um dos problemas encontrados na adoção desse formato.
O problema aparece do fato dos browsers tratarem tradicionalmente os valores RGB especificados no CSS (e HTML), GIF e JPEG de maneira idêntica. Já o PNG a informação GAMMA armazenada para usar o valor correto dos valores RGB não coincide com os outros elementos (css, gif, html…) pq nem todos os browsers interpretam essa informação da mesma maneira: alguns a ignoram completamente, enquanto outros aplicam um ajuste de GAMMA arbitrario.

E a solução:

é possível remover esse GAMMA do PNG assim os navegadores exibirão as imagens da mesma maneira que GIF´s JPEG´s … Mas isso não é bem verdade para todos os navegadores (SAFARI 1.3) uma outra alternativa seria tentar alterar valor do gamma offset, neste caso não tem jeito… vc só vai conseguir agradar um dos dois mais problemáticos com png´s (IE ou SAFARI 1.3).
Caso vc queira agradar o Safari 1.3 vai ter q usar o gamma offset de 0.5181347
No caso do IE o valor do gamma offset seria de 0,555555
(o Photoshop´s acima da versao 5.0 salvam o gamma offset com 0,45000)

Depois de tratar a imagem PNG com o TweakPNG (programa também citado pelo Vitorio) e manter as outras duas imagens intactas temos:

E capturas de tela para consagrar o resultado…

Firefox 2.0.0.2

Opera 9.10

Internet Explorer 6

Internet Explorer 7

Agradeçam o Vitorio pela dica.

Todos já sabem que o Internet Explorer 6 tem suas dificuldades com o formato de imagens PNG e que sua versão 7 supostamente superou isso, digo supostamente pois me deparei com um problema que irei documentar neste artigo.

Não sei se esse experimento já foi realizado anteriormente, mas enfim, o objetivo é analisar três arquivos de imagens com extensões diferentes totalmente preenchidos com a cor #2F3B6F. As extensões são PNG, JPG e GIF.

Se você usa o Internet Explorer (não importa a versão) já deve estar vendo a imagem em PNG com uma coloração diferente, mas para confirmar seguem capturas de tela. As imagens estão na mesma ordem que foram apresentadas acima, por CSS coloquei bordas para melhor visibilidade.

Firefox 2.0.0.1

Opera 9.10

Internet Explorer 6

Internet Explorer 7

É possível notar que nenhum dos navegadores interpreta a imagem PNG com perfeição mas os resultados no Opera e Firefox são toleráveis. Já o Internet Explorer apresenta um problema mais sério alterando bastante a cor original do arquivo.