Eis alguns truques rápidos para inserir os vídeos do YouTube nos seus posts a alta resolução e para colocar o fotograma de início do vídeo no instante desejado.

Como visualizar os vídeos em alta resolução

Este código visualiza a filmagem em baixa resolução:

<object width=”425″ height=”344″>
<param name=”movie” value=”http://www.youtube.com/v/MuqiGrWBRqE&hl=en&fs=1″></param>
<param name=”allowFullScreen” value=”true”></param>
<param name=”allowscriptaccess” value=”always”></param>
<embed src=”http://www.youtube.com/v/MuqiGrWBRqE&hl=en&fs=1″ type=”application/x-shockwave-flash” allowscriptaccess=”always” allowfullscreen=”true” width=”425″ height=”344″></embed>
</object>

Se a filmagem é em alta resolução basta adicionar o código &fmt=18 (codificada se torna &ap=%2526fmt%3D18) à URL do vídeo, deste modo:

<object width=”425″ height=”344″>
<param name=”movie” value=”http://www.youtube.com/v/MuqiGrWBRqE&amp;hl=en&amp;fs=1&amp;ap=%2526fmt%3D18“></param>
<param name=”allowFullScreen” value=”true”></param>
<param name=”allowscriptaccess” value=”always”></param>
<embed src=”http://www.youtube.com/v/MuqiGrWBRqE&amp;hl=en&amp;fs=1&amp;ap=%2526fmt%3D18” type=”application/x-shockwave-flash” allowscriptaccess=”always” allowfullscreen=”true” width=”425″ height=”344″></embed>
</object>

E eis que o mesmo vídeo será executado com uma qualidade notavelmente maior:

Estas são as opções disponíveis:

• &fmt=18: resolução 480×360

• &fmt=22: resolução HD 720p

É óbvio que se o vídeo não foi baixado em alta resolução toda e qualquer modificação não adiantará nada. Eis as especificações de alta resolução no YouTube.

[Via Kottle]

Como selecionar o fotograma inicial dos vídeos

Neste caso também basta adicionar um parâmetro que indique o ponto de partida do vídeo expresso em segundos: &start=X (codificado &amp;start=X). Pegando novamente o exemplo anterior em baixa resolução eis o vídeo que inicia do terceiro minuto:

<object width=”425″ height=”344″>
<param name=”movie” value=”http://www.youtube.com/v/MuqiGrWBRqE&amp;start=180“></param>
<param name=”allowFullScreen” value=”true”></param>
<param name=”allowscriptaccess” value=”always”></param>
<embed src=”http://www.youtube.com/v/MuqiGrWBRqE&amp;start=180” type=”application/x-shockwave-flash” allowscriptaccess=”always” allowfullscreen=”true” width=”425″ height=”344″></embed>
</object>

[Via scriptol]

Lembro-me ainda de um livro pequenino, mas muito interessante, escrito por David Siegel que intitula-se “Futurize Sua Empresa”. Naquela época eram outras circunstâncias porque se vivia uma fase de transição entre a euforia do primeiro boom da rede e os primeiros quentíssimos falimentos (estou falando de 2000/2001), e aquele livro continha poucos e simples conceitos que ilustravam os pontos essenciais para afrontar um projeto web.

Não me esqueço do tom brincalhão que o autor usava em alguns passos, especialmente quando ilustrava aos leitores quais eram os principais perigos dos que se devia escapar quando se pegava um projeto web para realizar.

Nunca mais um livro descreveu tão bem o transcorrer dos meus anos que estavam por vir, e os descreveu com uma precisão tão grande que comecei a suspeitar que exista um tipo de fórmula matemática que determina as dinâmicas de causa e efeito dos profissionais de TI.

Em particular, o livro descrevia não tanto as situações de tipo técnica que um projetista web deve afrontar no seu trabalho, mas aquela confusão de relações humanas e pessoais que, de fato, eram o nó a se desfazer na fase de implementação de um projeto web para um cliente.

Falar de trabalho da área da informática, de desenvolvimento de sistemas informativos ou de produtos IT em geral não tem sentido se não se correlacionam com as relações humanas que devem ser geridas para concluir o projeto. Qualquer pessoa que faça o meu trabalho sabe bem que o coração de um projeto não é o código fonte nem a manutenção, mas é aquela idéia de base e de conceito, fruto da nossa fantasia e intuição que através dos instrumentos informáticos é traduzida em matéria visível sob a forma de produto acabado. Mas, neste percurso ideal existe uma cruz que todo bom projetista tem que carregar: O Fenômeno.

Photo Credit: David Schauer

Descrever o que é O Fenômeno não é simples, já que não existem tempos e modalidades precisos nos quais ele pode aparecer. Nem é possível saber sob qual pele ele aparecerá, pois O Fenômeno pode aparecer praticamente nos papéis de qualquer um: homem, mulher, responsável técnico do cliente, filho ou conhecido do cliente, mas inevitavelmente, cedo ou tarde, ele aparece. Não tem escapatória.

As condições necessárias e suficientes para ser definido como “fenômeno” são:

• Ser “bom de computador”
• Poder comunicar com o cliente

Mas, vamos por partes. Primeiro vamos analisar os pressopostos e os percursos necessários para a sua aparição.

Um campo aberto

A Internet, ou melhor, a informática é um campo muito inflacionado, pois nela existe um desejo maníaco de ser protagonista (não se sabe bem porque) sem nem mesmo ter as competências necessárias.

Neste campo existem muitas áreas de especialização e setores que são impossíveis de explicar a quem não é do mesmo setor. Mas, por algum motivo misterioso, praticamente qualquer um que é “bom de computador” mergulha de cabeça em competição.

Fico perplexo porque isso não acontece em outros setores. Nunca vi, por exemplo, pessoas boas em construir castelos de areia fazerem concorrência com construtoras, ou nunca vi contadores técnicos competirem com auditores contábeis. Mas, na informática, já se sabe, a guerra é selvagem.

Para falar a verdade, eu concordo com isso, no sentido que são os mesmos mecanismos naturais do mercado que determinam o próprio mercado, e prefiro muito mais esta liberdade do que uma condição elitária em que a priori se estabelece quem é profissional e quem não é simplesmente porque os organismos que têm esse tipo de controle não são garantia de profissionalismo e confiabilidade, pelo contrário (com devidas exceções, claro).

A tentação do cliente

Quando recebemos uma comissão ou encargo para desenvolver um projeto é claro que o cliente nos paga porque somos capazes de realizá-la com a competência que ele ou a sua empresa não tem, ou porque decidiram dar esse projeto em outsourcing delegando, portanto, competência e responsabilidade.

No começo aceitamos a responsabilidade que nos é dada de bom grado por aquela pessoa que nos encarregou o trabalho. Mas, atenção: este tipo de “indispensabilidade” que no início é considerada um alívio para o cliente, aos poucos, com a concretização do projeto e das primeiras entradas, se transforma num desejo de autonomia (no próprio cliente).

Com o projeto em pé, visível e funcionante, o fato de ser indispensável se transforma numa inquietude, para o cliente, que deriva de uma errada sensação de excesso de dependência do autor do projeto. São sinais de que o Fenômeno está por vir!

Chega o Fenômeno

De repende, bem no momento em que o projeto começa a rodar, você percebe no cliente uma certa intolerância com as suas soluções ou com os seus pontos de vista sobre o projeto. O tempo entre as comunicações se prolongam e as respostas se tornam cada vez mais evasivas e intolerantes. Sintoma de que o Fenômeno chegou.

Mesmo se você ainda não o conheceu ou viu, saiba que ele já está trabalhando e, inconsciente das análises de fluxo, das lógicas de projetação e das simples problemáticas que determinaram algumas soluções ao invés de outras, ele está lá a iluminar o cliente tentando analisar o projeto, provavelmente, com pontos de vista diferentes.

Nos últimos 10 anos de trabalho o Fenômeno me apareceu mais vezes, e em geral, sob estas peles:

1. Um responsável de informática da empresa
2. Um parente ou amigo do cliente que é “bom de computador”
3. Um concorrente que também estava tentando pegar esse trabalho

O cliente começa a oscilar

De fato, o problema não consiste em o cliente ter um ponto de vista diferente, já que acredito que essa é uma condição salutar para um bom nível de colaboração entre cliente e prestador de serviço, mas consiste no fato do cliente não ter o conhecimento necessário para avaliar corretamente as opiniões do Fenômeno. Estas opiniões diferentes, portanto, combinadas a uma certa inquietude devida ao fato que agora você é indispensável, determinam o momento mais crítico de todo o projeto. O Fator Fenômeno.

São muitos os pontos que podem se tornar críticos depois da ação do Fenômeno mas, por experiência própria, um dentre todos é o ponto mais fraco que tende a se tornar o ponto de ruptura: o orçamento da manutenção.

Como resolver a situação

Não existe uma fórmula certa pois, existem diferentes tipologias de clientes e diversas tipologias de fenômenos, mas vamos tentar fazer um resumo semi-sério do cenário:

1. Se você percebeu que o cliente está dando crédito ao Fenômeno porque este o convenceu de que é possível economizar no orçamento da manutenção

• Meu caro, esta é a pior situação: TE DESCOBRIRAM. Qualquer coisa que você disser ou fizer será interpretada somente como desculpa para “ganhar dinheiro”. FUJA! Entregue o código fonte e fuja… Mas, deixe o CD nas mãos do Fenômeno e não apareça mais pois, caso contrário, você deverá instrui-lo em coisas que, provavelmente, ele não será capaz de entender!

2. Se você percebeu que o Fenômeno é um parente do cliente…

• Este caso também não é fácil… pois, começa a dinâmica do “vamos fazer tudo em família”. Quer um conselho?! Diga que abriu uma padaria com sua irmã e que mudou de profissão.

O que comunicar ao cliente sempre, absolutamente e claramente no início de cada projeto

A experiência ajuda e é graças a ela que creio ter individuado alguns pontos salientes que o cliente deve digerir antes mesmo que você comece a escrever uma única linha de código a fim de não dar espaço para o Fenômeno, que cedo ou tarde chegará:

1. O risco não consiste no fato de que o projeto web talvez não funcione, mas exatamente o contrário. Se o projeto web funcionar é que você terá dificuldades.

2. O gasto com o desenvolvimento inicial (o start-up) não é nada em confronto com o orçamento da manutenção para um projeto funcionante. Os clientes em geral (ao menos os menos experiêntes, ou mais espertinhos) esperam gastar inicialmente por algo que depois automaticamente trará dinheiro sem mais nenhuma despesa. Tire isso da cabeça dele, absolutamente (veja o primeiro ponto).

3. Explique que o sucesso completo de um projeto web acontece quando o autor do mesmo não é mais indispensável. Porém, isso comporta um gasto considerável em formação. Se o cliente quiser ser independente, é bom que considere isso como parte do projeto que requer planificação, tempo e investimento financeiro.

Se o cliente não compreende estes três simples pontos, é melhor que não se inicie o trabalho pois, decididamente, começo a pensar que para os pequenos profissionais do campo de IT o sucesso não é determinado pelos trabalhos que se pega, mas por aqueles que se deixa!

Em poucas palavras, o objetivo de um bom profissional neste setor não deveria ser a gratificação de um cliente, mas trabalhar para si com projetos próprios.

Até a próxima com um outro fator importante e perigoso: o Fator Papai Noel.

O trackback é um sistema introduzido pelo Movable Type para permitir a conexão entre posts de blogs diferentes. Esta ténica de cross-posting colocou em contato todos os blogs que suportam tal funcionalidade, contribuindo para o crescimento exponencial que este instrumento de self publishing teve nesses anos.

Photo credit: Maurice Schadee

O mecanismo é simples: todos os blogs que aceitam “respostas” aos próprios posts, mesmo de blogs externos, fornecem um identificador único para cada post chamado URL de trackback.

Quando um usuário posta sobre o mesmo em resposta ou em referência a uma notícia lida em qualquer lugar, o fará incluindo no post o URL de trackback da notícia de referência. Nos dois blogs, portanto, os posts serão linkados reciprocamente: em um aparecerá o URL de trackback (qualquer coisa parecida com “estou falando do artigo lido aqui”) e no outro aparecerá a notificação de resposta (parecido com “ei, alguém me respondeu neste endereço”).

O procedimento de trackback, portanto, acontece em dois passos:

• Um blog que “chama” e notifica um comentário. A chamada se chama “Ping”.

• Um blog que responde à chamada comunicando se o comentário foi aceito ou não.

Muitas plataformas têm a gestão de trackbacks integrada por default, mas na rede existem muitos sistemas informativos customizados desenvolvidos ad hoc (como o ikaro.net). Para estes sistemas, portanto, a gestão de trackbacks deve ser desenvolvida manualmente.

São duas as funcionalidades que podem ser implementadas em um sistema de self publishing custom. É possível habilitar o sistema para:

• aceitar respostas de blogs externos (receber ping)

• responder para blogs externos (enviar ping)

O URL de trackback

Agora vamos analisar nosso blog para ver se em qualquer lugar da rede fizeram referência a notícias ou artigos nele publicados. Vamos gerir, portanto, os pedidos de ping. Tecnicamente o ping é uma chamada a um script com o método POST, com a qual se enviam variáveis, tanto com POST quanto com GET. Este script constituirá o URL de trackback.

O fluxo de dados do script é o seguinte:

1. Recepção do ping com os dados enviados através do método POST.
2. Verificação dos dados, se não estiverem corretos envia resposta negativa em formato XML e sai.
3. Se estiverem corretos elabora os dados. Se a elaboração não dá certo envia resposta negativa em formato XML e sai.
4. Envia resposta positiva em formato XML.

Especificação dos dados

Vamos ver os nomes dos parâmetros enviados pelos pings que o nosso script deve gerir:

• MÉTODO GET

1. ID único do nosso post, ao qual o que chama está respondendo – obrigatório

• MÉTODO POST

1. url | o URL único que contém a resposta ao post – obrigatório
2. blog_name | o nome do blog externo – facultativo
3. title | o título da resposta – facultativo
4. excerpt | o texto da risposta – facultativo

Especificação das respostas

As respostas aos pings, tanto positivas quanto negativas, devem ser enviadas em formato XML. O script, portanto, deve enviar o header apropriado (“Content-Type: text/xml”) antes de cada eventual output da fonte.

Resposta êxito positivo:

<?xml version=”1.0″ encoding=”utf-8″?>
<response>
<error>0</error>
</response>

Resposta êxito negativo:

< ?xml version=”1.0″ encoding=”utf-8″?>
<response>
<error>1</error>
<message>Messaggio di errore</message>
</response>

Como vimos nas especificações dos parâmetros, as únicas duas variáveis obrigatórias são o ID enviado com o método GET e o campo “url” que identifica o post que chama.

Esqueleto de exemplo

Vamos mostrar, portanto, um válido esquema de script ampliando um pouco o esquema do script:

1. Verifico se o campo HTTP_GET_VARS['id'] e HTTP_POST_VARS['url'] são válidos
2. Se não são válidos envio a resposta negativa (veja acima) em formato XML
3. Se são válidos, salvo a resposta contida nas variáveis POST blog_name, title, excerpt e a conecto ao post apropriado através de HTTP_GET_VARS['id']
4. Se salvar não deu certo, envio êxito negativo com formato XML
5. Se salvar deu certo, envio finalmente êxito positivo com XML

O ponto 3 é estreitamente dependente de como o sistema informativo administra os dados. Se as informações são memorizadas em uma base de dados deverão ser inseridas na tabela de respostas indicando como chave o ID do post de referência enviado com o método GET.

Se, ao contrário, as respostas são geridas em arquivos XML ou em arquivos de texto ASCII, deverão ser memorizadas com as especificações do sistema informativo em uso.

URL de trackback

Uma vez desenvolvido e salvo em qualquer lugar, o script servirá para fornecer o URL de trackback relativo a cada post do seu blog. Vamos supor que o script tenha o URL http://seu.blog.br/cgi/trackback.cgi, o URL de trackback a ser fornecido aos seus visitantes pelo artigo com id=452 será, por exemplo: http://seu.blog.br/cgi/trackback.cgi?id=452

Esquema de fonte a ser modificada

Segue o shot de um esqueleto de fonte php modificável com base às próprias exigências.

Quando encontrei esse artigo entitulado 10 Absolute “Nos!” for Freelancers publicado no wakeuplater.com pensei que tivesse sido escrito por um eu proveniente de um ramo diferente do multiverso.

Ele elenca as 10 perguntas típicas que os clientes costumam fazer a web designers e desenvolvedores que merecem a mesma resposta: Não!

Photo Credit: baby1

Com certeza, quem trabalha faz tempo com IT como freelancer concorda, enquanto que para quem está entrando nesse terrível ramo profissional ultracompetitivo e inflacionado este elenco deveria representar um testamento a ser impresso em formato gigante, pendurado de frente à mesa e seguido escrupulosamente ao pé da letra.

Eis as 10 perguntas às quais você deve responder sem hesitar com um seguro NÃO!

1. “Deixe-nos ver algum protótipo para nos ajudar a escolher um design/programador?” NÃO!

• Na melhor das hipóteses você dará a eles a confirmação de poderem contar com alguém que trabalha de graça, na pior delas eles utilizarão o seu protótipo para ser desenvolvido por outros. Aconteceu comigo 2 vezes: encontrei sites de potenciais clientes (que tinham rejeitado a minha proposta) desenvolvidos por outros com o meu projeto gráfico e funcional.

2. “Você vai dar um desconto nesse orçamento, não vai?” NÃO!

• Muitas empresas e clientes espertinhos sabem bem como tirar vantagem de jovens profissionais: mantenha distância deles. Dar-lhes um desconto por uma única vez significa dizer “sou muitíssimo grato por terem aceitado que eu preste serviço a vocês”, e no futuro o seu poder contratual valerá menos de zero. Ou aceitam o orçamento ou fora.

3. “Você cuida do registro do nosso domínio e da hospedagem do site?” NÃO!

• Você acredita se eu lhe disser que depois de 6 anos que deixei o mercado ainda tenho que gerir renovação de domínios e hosting de clientes que não se responsabilizam em fazer o transferimento dos serviços deles mesmos? Uma vez, inclusive, recebi um telefonema ameaçador de um cliente porque, segundo ele, eu tinha cacelado o seu site. Quando perguntei se ele tinha renovado o domínio depois de ter recebido os 3 avisos da Network Solution por email ele respondeu: “Por que, tinha que renovar?”.

4. “Gostamos muito desse site: pode fazer um igual?” NÃO!

• Não é um discurso moral ou, pelo menos, não só. Um cliente desse tipo lhe reduz ao nível de um macaco, pense você o que é melhor fazer.

5. “Podemos gerir o pagamento do projeto com as entradas que serão geradas?” NÃO!

• Um cliente que ousa somente propor algo do gênero é um cliente que está de sacanagem: ele já sabe que não lhe pagará.

6. “Tenho uma grande idéia: por que não vamos um pouco além do usual relacionamento cliente/fornecedor e…” NÃO!

• Com isso também tenho uma certa experiência: quando você tem a estranha sensação de que um cliente seu lhe definiu como o “eleito” para um projeto de sucesso garantido fuja! Se existisse realmente um projeto de sucesso garantido ele não lhe envolveria como parceiro e pagaria mesmo assim para você desenvolvê-lo.

7. “Você me passa seu Skype?” NÃO!

• Muitos clientes pensam que o que pagam para ter um trabalho desenvolvido por você corresponda à quota desenbolsada para comprar-lhe como pessoa e ter a sua disponibilidade 24x24x365. Caso contrário, não lhe pediria contatos privados.

8. “Vai, vamos fazer sem entrada: pagamos tudo quando o trabalho estiver pronto.” NÃO!

• Se você não conhece o cliente peça, pelo menos, 50% na assinatura do contrato. Se o conhece basta 30%. Ser pago ao término do trabalho significa não pegar um real ou ver-se abanando a fatura enquanto lhe apresentam o 500ª pedido fora do acordo.

9. “Você não pode usar esse fim de semana excepcionalmente para terminar essa parte?” NÃO!

• Se você fizer isso uma vez terá que fazer para sempre, pois acharão que é normal e pedirão que abra uma exceção sempre. E quando não o fizer você terá que se justificar.

10. “Obviamente a fonte será de nossa propriedade e não poderá ser reutilizada, não é?” NÃO!

• Atenção, parece uma pergunta lícita mas, não é: se o cliente pretende que o código não possa ser reutilizado, então deverá pagar também as partes do código já desenvolvidas anteriormente que você reutilizará para o projeto dele.

Eu sei que parece uma visão pessimista e drástica, mas não é. Talvez, para aqueles que entram no mercado dispondo de trabalhos garantidos ou referências para que serviços lhes sejam encaminhados, não seja bem assim, mas, para quem mete a cara armado somente de entusiasmo e competência esse é o quadro geral de tudo o que se deverá esperar.

Se você é um deles, não duvide e a cada uma dessas perguntas dispare um belo NÃO! E lembre-se que no mercado de web development o sucesso não é determinado por trabalhos que se pega, mas por aqueles que se deixa.

Considere esses “nãos” como balas a disparar com precisão contra paquidermes que se colocam entre você e o seu crescimento profissional.

Acelerar até 5 vezes mais o carregamento das páginas web do seu blog significa:

• uma melhor user experience dos seus leitores e, portanto, mais page views
• menor banda consumida e, portanto, hosting e server mais baratos
• maior confiabilidade para os motores de busca e, consequentemente, melhor posicionamento

Se você está se perguntando quais as competências e qual o trabalho necessários lhe digo logo que bastarão somente 2 minutos. Basta fazer com que a página seja comprimida antes de ser enviada ao browser (exceto as imagens, obviamente, porque já são comprimidas). Essa brincadeira pode aumentar a velocidade de visualização de uma página web em até 500%.

[Photo credit: Misha]

O único requisito é que o site gire no Apache, mas devemos ter acesso ao arquivo .htaccess. Se não o temos poderemos utilizar um outro sistema desde que as páginas sejam escritas em php.

Comprimir as páginas com .htaccess

Baixe o arquivo .htaccess do root do site (se não tem, crie-o) e adicione essas duas instruções ao resto:

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css

<FilesMatch “\\.(js|css|html|htm|php|xml)$”>
SetOutputFilter DEFLATE
</FilesMatch>

Recarregue-o no root e pronto.

Bastaria somente e primeira linha, em teoria, mas a segunda nos permite especificar o sufixo das páginas a comprimir. A esse ponto, todas as páginas serão comprimidas e serão carregadas muito, muito mais rápido.

Comprimir as páginas com php

Se você não pode modificar o htaccess você pode, de qualquer forma, acelerar as páginas desde que sejam em php compilado com suporte a Zlib. Se você não sabe fazer essa verificação:

1. crie a página php.info
2. insira a linha <?php echo phpinfo(); ?>
3. carregue-a no server e visualize-a

Você deverá encontrar uma tabela como esta:

Feito isso bastará adicionar ao início de cada página que você quiser comprimir o seguinte código:

<?php ob_start( ‘ob_gzhandler’ ); ?>

Pronto.

Como verificar se as páginas foram realmente comprimidas

Baixe e instale o Web Developer Tools para Firefox. Abra a página que você quer testar e clique em Ferramentas>Web Developer>Information>View Document Size.

Será mostrado o peso dos elementos de página em formato não comprimido e em formato comprimido. Se essa diferença não lhe for mostrada significa que a página não foi comprimida.

Testei e verifiquei ambos os sistemas e funcionaram muito bem. Eis as duas fontes:

• Compress Web Pages With mod_deflate on Apache
• Compress Your Web

Eis um ótimo guia de Reinhold Weber para desenvolver folhas de estilo (Cascading Style Sheets, ou simplesmente CSS) de uma forma correta e otimal. O encontrei navegando com StumbleUpon, o traduzi e o repropus.

Photo Credit: urbanangel

O que evitar

• In-line CSS (especificar os estilos diretamente nas tags do texto)
• Dimensões absolutas dos caracteres
• Utilizar ápices únicos nos path das imagens
• Redeclarar valores já herdados
• Aplicar margens de células ou bordas a elementos de dimensões absolutas
• Posicionar elementos com coordenadas absolutas
• Denominar estilos e classes baseado em suas aparências

Recomendações a seguir

• Declarações do estilo CSS em uma única linha
• Comente o código
• Organize o arquivo CSS
• Indentifique a fonte, se necessário
• Simplifique a leitura do código
• Utilize um sistema comum de nomes para classes e estilos
• Elenque os estilos em ordem alfabética
• O ponto e vírgula “;” não é necessário para a última declaração
• Não é necessário declarar grandezas (px/em/%) iguais a 0
• Para as cores utilize o formato hexadecimal abreviado
• Defina as pseudo-classes para os links na ordem LoVe/HAte (Link, Visited, Hover, Active)
• Defina os elementos das margens (padding ou border) na ordem TRouBLed (Top, Right, Bottom, Left)
• Baseie o nome das classes ou das ID mais sobre suas funções que sobre suas aparências
• Aprenda a gerir as características da hereditariedade nas regras CSS
• Administre maiúsculas e minúsculas com os estilos
• Dê uma olhada nas fontes das folhas de estilo dos sites mais relevantes
• Busque inspiração dentre os gurus do design

Simplifique a sua vida quando desenvolve as folhas de estilo

• Teste os seus estilos no browser mais atual e evoluído e depois nos outros, e não vice-versa
• Quando estiver em dúvida, valide a fonte
• Na fase de desenvolvimento integre as declarações na página, quando estiver on-line importe-as de um arquivo externo
• Instale a web developer toolbar para Firefox
• Tenha a mão uma livraria de classes CSS prontas

Sabia que?

• É possível marcar classes múltiplas para elementos únicos
• Graças a isso é possível descompor um único estilo em classes que têm uma única variável ou constante, e destiná-las em sequência aos elementos da página
• Você pode se proteger dos spams com CSS
• É possível utilizar o php para tornar os estilos CSS dinâmicos

O artigo completo é 50+ CSS Best Practices and Coding Guidelines. Aconselho também 25 Sites You Shouldn’t Have Missed In 2005 do Vitaly Friedman’s Notebook. Boa leitura!

De um ótimo post de Josiah Cole eis um elenco de erros muito comuns, mas que devem ser evitados absolutamente, que são cometidos no desenvolvimento de um web site.

Redimensionar o browser do visitante

Redimensionar dinamicamente a janela do browser dos seus visitantes através do javascript pode fazer você se sentir potente e é uma das técnicas mais usadas em sites de arte e mídias em geral, mas… não o faça nunca por dois motivos: é uma técnica muito usada nos spam sites e dá ao visitante uma desagradável sensação de invasão.

Abrir o site em uma pop-up

Você tem 2 segundos para capturar a atenção do visitante que navega de um site para outro em poucos segundos. Quando se carrega uma página o usuário quer ver informação, não links para abrir o site em uma pop-up.

Esta técnica é muito usada pelos Flash developers, mas é uma técnica fracassada.

Criar versões do site baseado na velocidade de conexão do usuário

Quantas vezes deve ter acontecido a você: “Versão para conexão lenta – Versão para banda larga”. É como se você colocasse em frente à sua loja um cartaz escrito: “Loja do povão desse lado – Loja elegante do outro (mas, precisa esperar 30 segundos e usar gravata)”. O que você faria?

Aprender a usar flash e dispensar de vez os desenvolvedores

Flash é somente um instrumento que pode melhorar alguns aspectos de um projeto como a interface para o usuário, acesso às mídias, etc. Mas, não é o instrumento mais adequado para fidelizar usuários e organizar informações. Aliás, se até mesmo a Macromedia.com (desenvolvedores de Flash) decidiu não desenvolver o seu site completamente em flash é porque tem um motivo…

Tentar recriar os standards de navegação

Se em anos e anos de desenvolvimento web os menus de navegação estão no alto ou à esquerda há um motivo. A criatividade é sempre um valor complementar dos projetos web, mas tentar modificar os standards de usabilidade consolidados em anos de trabalho pode se revelar contraproducente.

Não considerar a compatibilidade com Firefox

Tudo bem, o Firefox cobre uma fatia de mercado ainda modesta se comparada a Internet Explorer (cerca de 10%), ainda que esteja em crescimento constante. Também é verdade que a compatibilidade com o Explorer cobre a maior parte dos usuários, mas Firefox é o futuro. E se um site não é plenamente compatível com o Firefox significa que foi desenvolvido por um profissional não atento e não receptivo às tendências das grandes redes que estão olhando para standards abertos e para a interoperabilidade. E isso é ruim.

Iniciar automaticamente a música

Se você usa um canal de áudio no seu site siga estes dois conselhos: não inicie a música automaticamente, dê ao visitante a possibilidade de ligá-la quando quiser escutá-la e, sobretudo, dê a possibilidade de desligá-la!

Usar metáforas e duplo sentido

Existem muitos sites bons por aí para permitir-se ao luxo de mascarar as próprias mensagens e fazer seus visitantes perderem tempo na tentativa de entender tudo o que você quer dizer. Fale claro, use poucas palavras, mas mire e faça de modo com que a sua mensagem saia da home page clara e objetiva como um tapa que pega de surpresa o visitante.

Pesquisei e selecionei entre os meus sites preferidos no StumbleUpon alguns recursos CSS muito simples de serem utilizados, com exemplos e fontes para copiar, colar e personalizar no seu próprio blog. Propositamente selecionei recursos que podem ser utilizados por usuários não experientes em desenvolvimento CSS e HTML. Têm também alguns utilitários gráficos realmente simpáticos, em perfeito estilo web 2.0. Bom divertimento e bom trabalho!

Menu de navegação CSS

Há 11 barras de ferramentas CSS em estilo web 2.0 prontas para utilizar. Os menus são visualizados na página e funcionam perfeitamente. Basta abrir a fonte para pegar o código e utilizá-lo no seu blog e, eventualmente, personalizá-lo. Você notará que as etiquetas das barras de ferramentas podem ter algumas imagens de fundo: você encontrará os nomes das imagens nas específicas CSS e poderá baixá-las clicando em http://exploding-boy.com/images/cssmenus/.

Teaser Box

São aquelas caixas que evidenciam uma mensagem no contexto geral de uma página web. Ótimas para chamar a atenção dos visitantes. Na página você encontrará tanto o CSS quanto o código HTML para colocá-lo em operação. Aqui também você pode capturar as gifs necessárias pegando-as no mesmo percurso da página web.

CSS Image Popup

Ainda não sei se convém ou não, de qualquer modo, este script CSS permite que você aumente uma imagem através de uma pop-up sem inseri-la na janela do browser. Aqui você pode ver em funcionamento o pequeno script. O CSS é encontrado em picpopup.css.

Submit buttons para formulários web

Se você ama particularidades, o botão de envio de formulários no estilo web 2.0 não pode faltar. Aqui você pode encontrar um guia muito simples com os códigos HTML e CSS para criar o botão.

Evidenciando links visitados

Aqui estão algumas idéias realmente originais e muito simples para personalizar o estilo dos links visitados (Vlink) através do CSS.

Mensagem de erro ou aviso

Simples e ótimo CSS que evidencia uma mensagem de erro ou um simples aviso de maneira eficaz e não invasiva. Os alertas e os erros, do ponto de vista comunicativo, constituem um ponto crucial desde sempre e este código CSS resolve o problema de maneira excelente.

Tabs Generator

Gera online as etiquetas das barras de ferramentas e dos menus de navegação CSS. Você pode configurar praticamente tudo: altura, largura, borda, raio de curvatura, cor, gradiente, orientação e outros. Uma vez gerado o preview você pode salvar a etiqueta baixando-a no seu computador para utilizá-la como fundo nas etiquetas das toolbar CSS.

CSS menu library

São 12 menus CSS prontos para copiar, colar e utilizar no seu blog.

Brilliant button maker

Simpático aplicativo online que permite gerar botões 80×15 no estilo “Powered by FeedBurner”. Ótimo nível de personalização.

Badges 2.0 Generator

Os badges são medalhas que são colocadas nas páginas web para chamar a atenção dos visitantes. Aqui você encontra uma enorme coleção de badges prontos para serem utilizados ou você pode gerar um online personalizando tanto o texto como o aspecto gráfico.

Web 2.0 Logo Creator

É uma aplicação online muito simples que permite que você gere um logo web 2.0 com gradiente, reflexo e símbolo beta.

Strip Generator

Vamos nos esquecer da tela de fundo? Strip Generator permite que você crie online fundos de tela e tirinhas em formato horizontal para completar a obra. Ótimo nível de personalização.