Começando um novo projeto

Olá, estou de volta. Peço desculpas por ter abandonado este blog por muito tempo não tive o tempo e nem a disposição para publicar novos artigos, mas depois de alguns anos de muito estudo e de muito trabalho (enquanto este blog juntou poeira e teias de aranha) finalmente resolvi voltar a escrever sobre os assuntos que me interessam, mas não será mais aqui, e sim em um novo projeto que iniciei recentemente: o Meio Pixel.

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é!

4 motivos para não cobrar menos do que seu trabalho vale

Muitos web designers enfrentam problemas de competitividade na busca por trabalho e acabam optando por cobrar menos sem perceberem que isso pode ter conseqüências desagradáveis, minando a própria carreira. Inspirado neste artigo em inglês e baseado em minhas experiências vou abordar algumas das razões para se ter um cuidado especial com os valores que se cobram.

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.

Cuidado: Anti-spams podem acabar antiusuários

O spam não é uma praga recente na história da internet, quem utiliza email já sofre com ele há alguns anos e quem desenvolve sites e sistemas sabe que formulários devem ter proteção contra ele. O problema é que muitas das proteções para deter spambots prejudicam também aos usuários.

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:

Captcha usado no 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:

Captcha com opção de som usado no cadastro do Windows Live Hotmail

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.

Cuidado! Este livro pode ser perigoso para a web

Surgiu recentemente no WaSP a idéia de rotular alguns livros que podem ser perigosos para a web, sejam livros antigos ou com conceitos que vão contra acessibilidade e padrões web.

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.

WaSP Street Team

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.

403day – Uma péssima iniciativa

O 403day é uma péssima iniciativa que está circulando pela internet, a idéia é que no dia 4 de Março de 2008 os desenvolvedores bloqueiem o acesso via Internet Explorer em seus sites. Não passa de uma idéia infeliz de desenvolvedores que não pensam em seus usuários.

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.

Quem lembra do Joost e seus convites?

Após causar muitos comentários entre blogs do mundo todo, e fazer com que pessoas ficassem loucas atrás de um convite para experimentar o beta, será que o Joost emplacou? Parece que não.

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.

Boas vindas ao Email Standards Project

Baseado na idéia do Web Standards Project surgiu o Email Standards Project, o objetivo é atingir os clientes de e-mail ao invés dos fabricantes de navegadores para que também sigam algumas recomendações importantes.

Email Standards Project logo

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.

Modelo de Briefing

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.

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.

Site nos padrões não significa site bom

Desenvolver sites seguindo fielmente as recomendações do W3C (que agora tem um escritório no Brasil) e trabalhando com tecnologias de última geração são argumentos muito utilizados por agências e desenvolvedores mais antenados, mas apesar de serem pontos importantes, nenhum deles garante o sucesso de uma página na web.

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.

Pense nas possibilidades ao exibir dados

Hoje me deparei duas vezes seguidas com o mesmo erro, uso de plural para descrever o número um. Primeiramente o popular Rec6 se esqueceu de um detalhe em seu contador de votos: caso o artigo contenha apenas um voto (que é a contagem inicial após ser enviado), mas o que mais me surpreendeu foi a segunda ocorrência que estava na página inicial da Apple, onde dizia 1 hours, veja você mesmo:

Página inicial da Apple contendo 1 hoursPágina inicial do Rec6 com 1 votos

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.