O Meio Pixel tem o objetivo de ser um blog muito mais sério e profissional do que este, é um blog sobre design, programação e outros assuntos relacionados à web que contará com a publicação semanal de artigos relevantes e bem desenvolvidos. Como ele está caminhando para  tornar meu antigo blog pessoal obsoleto, em breve estarei desativando-o, assim ele não dividirá atenção com o Meio Pixel.

Ficou interessado por esse novo projeto? Acesse lá então, se puder dê uma força assinando o feed, curtindo a página no Facebook ou seguindo o perfil no Twitter, assim você pode ficar por dentro de tudo o que será publicado, mas é claro sem abandonar o conforto do seu agregador de conteúdo favorito. Se quiser, também pode ler mais sobre o  Meio Pixel para entender melhor o projeto.

De qualquer maneira, se você acompanhou este blog pessoa e está lendo isso agora, muito obrigado pela sua atenção por todo este tempo, e é claro que espero vê-lo novamente todas semana lá no Meio Pixel. Até!

1. Cobrar menos é ganhar menos

Você pode até ganhar mais se o fato de cobrar pouco te ajudar a pegar mais trabalhos, mas a verdade é que você terá que trabalhar muito mais para ganhar uma mesma quantia que ganharia cobrando preços coerentes. Se o valor de sua hora de trabalho cai é um mau sinal, não se iluda.

2. Prepare-se para clientes desagradáveis

Muitos clientes em potencial não chegarão a você por conhecerem suas habilidades ou experiência mas sim por saberem de seus preços abaixo da média. Esses são os que geralmente não entendem a relação custo versus qualidade e irão pedir algo muito bom por um preço muito baixo.

3. A qualidade de seu trabalho é questionada

Enquanto preços muito baratos podem passar a imagem de serviço de baixa qualidade, preços coerentes podem ajudar na imagem de seu serviço e atrair clientes que valorizem mais seu trabalho (mas que mesmo assim não pretendem lhe dar dinheiro de graça). Outro detalhe é que cobrando pouco você aceita que seu trabalho vale pouco.

4. A qualidade de seu trabalho de fato pode cair

Quando você não está satisfeito com o projeto e o valor que está recebendo pode acabar pensando “com o que estou ganhando não preciso fazer melhor que isso” e acaba entregando algo com qualidade inferior ao seu melhor. Eu já pensei isso e acredito que muitos outros profissionais também.

Conclusão

Saber cobrar valores coerentes é muito mais importante do que parece, algumas das conseqüências de cobrar preços muito baixos são ganhar menos, atrair clientes desagradáveis e prejudicar sua carreira. Prefira ser contratado por suas habilidades e experiência explicando quais soluções pode oferecer e porque vale a pena pagar bem por elas.

Geralmente você só vai conseguir alcançar seus melhores resultados se receber um pagamento justo para isso, sem contar que ser bem pago por realizar bons trabalhos pode fazer muito bem para o ego, algo importante para uma profissão que depende bastante da criatividade.

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.

Existem diversos livros que ensinam a estruturar layouts com tabelas, escrever (X)HTML não semântico, construir sites não acessíveis e criar páginas com código proprietário que funcionam apenas em navegadores sem suporte a padrões.

A idéia é orientar que o livro rotulado não é recomendado e que há uma lista de outros muito melhores indicados pelo WaSP (em inglês). Não é simples livrar as bibliotecas públicas e de instituições de livros ruins, mas cada um pode imprimir os rótulos (em inglês), colocar nas devidas obras e evitar que mais mentes inocentes sejam corrompidas por elas.

O objetivo depende totalmente de pessoas dispostas a participarem, isso torna a idéia um pouco utópica e talvez não gere grandes resultados. Mas não deixa de ser uma iniciativa legal. É possível verificar a participação de algumas pessoas por este grupo no Flickr.

O Internet Explorer é sim uma pedra no sapato dos desenvolvedores, mas o que se pede é no mínimo absurdo. Bloquear visitantes que usem o IE é tão ridículo quanto um site não funcionar no Firefox ou Opera, e aposto que não sou o único que odeia quando isso acontece.

O usuário não tem culpa alguma se o navegador que veio instalado por padrão em seu sistema operacional atrapalha nosso trabalho, então qual a razão de descontar a raiva nele? Não crucifiquem as pessoas erradas.

Simplesmente não sigam esse movimento, existem outras maneiras mais inteligentes de ajudar como convencer amigos e familiares a trocarem seus navegadores, ou até mesmo fazer propaganda do Firefox em seu site ganhando comissões do AdSense.

Não há dúvidas que a idéia dos convites fez a popularidade do programa decolar, mas parece que ele não foi capaz de agradar muito. Reclamaram que havia pouco conteúdo disponível e a qualidade também não ajudava muito, particularmente mal consegui assistir alguns minutos de qualquer programação que escolhesse.

É importante fazer seu produto conhecido, mas após isso ele deve agradar o usuário. O contrário acontece com muitas distribuições de linux e algumas aplicações que originam do sistema do pinguim, como o Miro (antigo Democracy), que eu concordo quando ele diz ser melhor que o Joost.

Apenas me pergunto quem ainda usa o Joost, ou então se existem pessoas que preferem o Joost mesmo após conhecer o Miro.

Os fundadores colocam que o e-mail em HTML traz mais resultados e oferece uma experiência melhor ao usuário, a importância de estabelecer padrões estaria em criar e-mails com código limpo (assim com carregamento rápido), mais acessíveis e com renderização igual independente de cliente de e-mail.

É um caminho muito longo até que todos os grandes clientes de e-mail se adequem ao Email Acid Test, isso se levarem o projeto a sério. O melhor que podemos fazer para ajudar é divulgar o projeto e apoiar, será um ótimo ganho para a maioria se os objetivos forem alcançados.

Mas o e-mail em HTML ainda me parece bastante distante, ao menos para quem deseja formatações semânticas através de CSS, por enquanto devo me contentar com texto puro, ou então com apenas uma ou duas tags dentro dos e-mails.

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.

Antes de pensar nas tecnologias a serem utilizadas em um projeto é necessário compreender qual a solução que o projeto deve oferecer, seja ampliar os negócios de uma loja vendendo também pela internet, oferecer um serviço que facilite a vida do usuário ou uma infinidade de outros objetivos possíveis. O desenvolvimento deve ser focado em soluções antes de tecnologias.

Uma maneira efetiva de alcançar este objetivo é investir em usabilidade, facilitar ao máximo a vida do visitante é aumentar as chances de se obter resultados positivos. Design bom não é algo bonito (visto que beleza é relativa), design bom é aquele fácil de usar e que passa a imagem desejada.

Ao desenvolver um projeto concentre-se em criar soluções que atinjam os objetivos do cliente ou da iniciativa. Documentos em XHTML válidos e uma aplicação construída com Ruby on Rails podem facilitar para os desenvolvedores, mas pouca diferença fazem para o usuário ou seu cliente.

Frequentemente vejo erros semelhantes na contagem de comentários de alguns blogs, e com o WordPress isso é muito fácil de ser resolvido. A Template Tag comments_number possui parâmetros diferentes para três casos: nenhum comentário, um comentário e n comentários. Uma solução elegante com sua utilização seria comments_number('Nenhum Comentário', '1 Comentário', '% Comentários'); em seu tema.

Erros como estes podem resultar em um ponto negativo na credibilidade do site e até mesmo quebrar o layout. É sempre importante examinar todas as possibilidades de exibição e tratá-las adequadamente com instruções condicionais.