TidBits

Estou inspirada em posts de listas, principalmente listas que dizem o que você não deve fazer. O de hoje é sobre os erros de SEO que podem prejudicar o pagerank do seu site, sem muito enrolação, vamos direto aos tópicos para não tirar a relevância das palavras-chaves desse post (rs..):

1. Escolher as keywords erradas
Por mais que você conheça seu público e o seu site, nunca utilize somente o chutômetro pra definir as keywords que você vai trabalhar. O importante não é o termo com o qual você define seu site, e sim como o seu usuário busca pelo seu conteúdo. Utilize ferramentas de métricas de keywords, como o Google Trends (que compara os volumes de buscas de diferentes palavras-chaves). Verificar volume de busca e uso da concorrência também é bacana no Google Adwords.

2. Esquecer da tag title
Existem dois grandes motivos para não se esquecer dessa tag. A primeira é que ter a keyword no title reforça a relevância de sua página para aquela palavra-chave específica. A segunda é que o titulo da página é exibido no resultado dos buscadores. Uma página chamada “Untitled-1″ não costuma ser muito atraente aos usuários. Só ilustrando a questão, clique se quiser ver as 1.910.000 páginas (do Brasil) que retornam a busca por “Untitled Document”.

3. Fazer o site todo em flash
Mesmo que o Google tenha anunciado que irá começar a ler os sites em Flash, a tecnologia ainda é insuficiente . Além de prejudicar acessibilidade, e estar em desacordo com as próprias diretrizes de qualidade recomendadas pelo Google, os sites em flash não são vasculhados e indexados. Quando essa opção não pode ser descartada, a alternativa é fazer uma versão HTML do site, ou extrair o conteúdo de alguns XMLs para ser indexado. Há uma documentação do próprio Google sobre isso, para quem se interessar.

4. Menus com javascript
Os crawlers também não lêem Javascript, e, consequentemente não o indexam (e lógico, não seguem os links indicados por ele). Isso faz que as outras páginas do site não sejam encontradas pelo googlebot quando ele estiver passeando pelo seu site. Uma solução para esse problema é manter um sitemap.xml e avisar o Google sobre ele (veja como aqui).

5. Preocupar-se demais com metags
Quando nem existia o termo e o conceito de Search Engine Optimization, a metakeywords eram realmente importantes. Encher a metadescription de palavras-chaves também era uma boa opção. Mas o Google ficou mais espertinho, e cada vez mais justo, e fez as metatags perderem sua importância na hora de conferir relevância à um site. Por isso, o principal das metatags, é fazer uma description realmente atrativa, que convença o usuário que te econtrou no Google, que o conteúdo de sua página é relevante o bastante para ele (lembre-se que a média de caractéres exibidos é 160). Já as keywords, duas ou três palavras-chaves devem ser utilizadas em média, para não se diminuir a relevância de suas palavras principais.

6. Usar apenas imagens no header
Nunca despreze a importância de um h1 e h2 para o buscadores. Coloque títulos como títulos, sempre que possível. Se o site exige um header com uma fonte que não seja de sistema, a alternativa é utilizar o h1 com image replacement (- que é a colocar a figura como o background do elemento, no CSS).

7. Não utilizar URLs amigáveis
Utilizar técnicas como o mod_rewriter para fazer que as páginas dinâmicas tenha URLs amigáveis é fundamental para que seu conteúdo possa ser encontrado. Um bom exemplo de um site que deveria usar e isso e não usa é o site da Abril: o conteúdo de todas as revistas está online, mas é quase impossível de encontrar pelos buscadores.

8. Utilizar técnicas blackhat
Fazer spam de palavras-chaves escondidas pelo css, exibir páginas diferentes para usuários utilizando cloaking, redirects que passam o usuário pela página com keywords e conduzem o usuário rapidamente para a página correta, enter várias outras técnicas que trazem o usuário para um conteúdo não relevante. Todas essas técnicas são conhecidas como blackhat, e podem fazer aumentar as visitas do seu site a curto prazo, mas quando descobertas, todas elas são punidas pelo Google – que joga sua página para os últimos resultados ou mesmo remove ela da indexação.

9. Participar de “farmlinks” e ter backlinks ruins
Nesse caso, o ditado representa a verdade “diga-me com quem você anda, que eu te direi quem voê é”. Participar de farmlinks (sites que existem somente para distruibuir backlinks), ou fazer trocas de links com conteúdos que não tenham relação com seu conteúdo não é um bom caminho. Não se sabe ao certo, mas alguns dizem que o Google mede não só o Pagerank, mas o “Pagetrust” do seu site, para saber se aquele conteúdo é realmente relevante, ele também analisa os links que você fez, se apontam para sites bem classificados ou sites que foram punidos pelos buscadores.

10. Não ter as keywords no conteúdo
A keyword não precisa ter peso somente no título e nas metatags. Ela precisa estar por todo o conteúdo, para que o site consiga um bom posicionamento nos resultados de busca. Isso é cuidado do Google, para que não só os títulos sejam relevantes às buscas dos usuários, mas também todo o texto.

Update: Baseado no artigo do Top 10 Seo Mistakes do Webconf

A dias atrás escrevi uma matéria falando de material de estudo sobre padrões web em português . Lendo a apostila criada pelo e-gov, tem um tópico com esse título.

Mas o que é uma “impressão amigável”?

Impressão amigável, é definir um css só para o usuário imprimir o conteúdo.

Quando mandamos imprimir uma página, estamos interessados somente no conteúdo. A página de impressão não deve vir com menu, cabeçalho, rodapé, banner, background do site, ilustrações enormes, etc etc… e é possível retirar esses elementos na hora do impressão com um css a parte.

Não é dificil, no tidbits nós usamos um template pronto de wordpress (que naturalmente, veio sem um css de impressão) e pra colocar eu criar um, não demorou nem 10 minutos.

O uso de folhas de estilo para equipamentos específicos é feito através do atributo media, existem vários tipos de media, mas na prática somente 3 tipos são usados, veja a relação abaixo de medias e dispositivos:

• all – todos os tipos de dispositivos;
• screen – computadores;
• print – impressoras;
• handheld – PDAs, mobiles palmtops;

Existem duas formas de escrever um atributo media que é colocado sempre dentro do <head> é claro:

Chamada externa:

<link media=“screen” type="text/css" href="style.css" rel="stylesheet"/>
<link media=“print” type="text/css" href="print.css" rel="stylesheet" />

<!-- ou assim pra quem prefere com import !-->

<style type="text/css">
@import url("style.css") screen;
@import url("print.css") print;
</style>

Repare que chamamos um css pra tela e um pra impressão.
Quando o atributo media não é declarado o padrão é media=”all”.

ou no css:

@media screen {
	h1 { font-size:28px; color:#ff0;}
}
@media print {
	h1 { font-size:14px; color:#000;}
}

Basicamente é bem rápido, não é necessário mexer em muitas tags, veja o que foi necessário para implementar aqui no tidbits:

@media print {
	div#header, div#footer, div#sidebar-wrapper,
	p.bookmark-me, div.post-footer,
	form#commentform, h3.comentar {
		display:none;
	}
}

Inspirada pelo meu último post, e pelo artigo do Glen Stansberry resolvi aproveitar o momento para incentivar a avaliação não só da usabilidade de um site, mas também do CSS. Agradecendo a dica do Jamaica segue a minha lista “adaptada” do que eu acho que ninguém deve fazer com o CSS do site:

1. Ignorar a compatibilidade de browser
A gente já falou um monte sobre crossbrowser aqui no Tidbits. Já falamos de truques para checar se o seu site está compátivel com todos os navegadores, ensinamos a utilizar os Global Resets para zerar as propriedades automaticamentes setadas pelos browsers, e o Danilo no post anterior falou sobre o CSS compatível sem uso de hacks. Com esse material todo, você não pode nem pensar em deixar o seu CSS “quebrar”…

2. Não validar o HTML e o CSS
Também no post sobre garantir a qualidade do seu site em todos os browsers, eu dei o link de ferramentas de validação. Passem por elas para garantir um código semântico!

3. Não utilizar classes para formatações que se repetem em vários elementos
Se você tem elementos que tem propriedades de formatação iguais, utilize apenas uma class para definir essas propriedades para todos elementos. Se você tem em uma página, por exemplo, todas as fotos e boxes de um site tem borda e flutuam a direita, você pode simplesmente criar uma class para definir esses atributos e invocá-la em todos os elementos que a utilizam. Se, por um acaso, você precisasse mudar a cor da borda, teria que fazer isso em todos os elementos, se não atribuir a propriedade uma única vez.

4. Utilizar nomeclaturas ruins para classes e ids
Isso pode ser uma questão aparentemente insignificante, mas se você precisar fazer qualquer alteração no CSS depois de um tempo, vai se arrepender amargamente de não ter gastado 2 segundos a mais do seu tempo para pensar em um nome mais descritivo do que #box_top ou .coluna_left. Rótulos orientados à posicionamento ou ao formato do conteúdo dificultam a manutenção e substituição desse CSS.

5. Usar CSS para tudo
Quando se abandonaram os layouts com tabelas as tabelas ficaram tão mal faladas que até quando se precisa de tabelas, as pessoas tentam fazê-las da maneira mais díficil. O conceito é “Tableless” e não “Tablenone” – com o perdão do trocadilho infeliz. Enfim, o HTML precisa ser semântico, e quando você exibe dados em uma tabela, nada mais semântico do que utilizar uma tabela mesmo, não?

6. Usar CSS inline
Um dos piores erros que se pode cometer, é não se utilizar o conceito de “layers” (camadas), na hora de desenvolver uma interface. Na época que eu aprendi a mexer com o Photoshop, eu levei um tempo até perceber o qual importante era esse conceito, de manter cada coisa, em um plano diferenciado, e como isso facilitava a aplicação, manutenção e alteração de qualquer erros. Esse conceito é igualmente aplicável para o CSS, mantenha ele sempre em um arquivo externo. Um dos principais problemas remete ao item 3 dessa lista: com o CSS inline, você precisaria atribuir os valores para cada elemento individualmente, o que se transformaria em um caos, quando precisasse fazer modificações no layout.

7. Carregar muitos arquivos de CSS
Dividir o conteúdo do CSS em arquivos separados, facilita a manutenção – até certo ponto. Se você divide demais o CSS, pode acabar dificultando não só a manutenção, pela dificuldade de encontrar o arquivo que exatamente está procurando, como também o carregamento da página. Arquivos de CSS são bem leves (em sua maioria), o problema é que muitas conexões com o servidor, que precisam ser feitas para cada arquivo de estilo que for baixado, normalmente demoram mais que o próprio download. Normalmente, eu e o Danilo utilizamos um arquivo default.css setando propriedades que replicam em todo o site, por exemplo o CSS do Header, Footer, Menu lateral, e coisas do tipo. E criamos para cada área, o arquivo nomedaarea.css com as propriedades específicas da página, ou por exemplo um conteudo.css com as propriedades de css de páginas geradas dinamicamente.

8. Não utilizar o Firebug para acelerar os ajustes do css
O Firebug é uma ferramenta mais importante que o editor de códigos. Se um layout está com problemas de posicionamento, ou você está com dificuldades de entender porque uma div está herdando um padding fantasma de algum lugar, o Firebug ajuda você identificar quais são as propriedades de css que estão influenciando aquele elemento. Além do CSS, ele também facilita visualizar a estrutura do HTML, e identificar possíveis erros.

Acho que seguindo essa lista, já é possível otimizar o tempo de desenvolvimento, e ao mesmo tempo fazer um CSS de melhor qualidade. E se alguém se lembrar de algum outro erro que também poderia ser evitado, fique a vontade para comentar, e construirmos nossa lista juntos

Em quase todo blog tem uma coleção de hacks css, para todos as versões de todos os navegadores, opera, safari, ie6, ie7, firefox 2, firefox 3 etc etc… mas aqui você não vai encontrar, porque? Porquê você não precisa de hacks pra fazer um layout!

O jeito correto de escrever css é encontrar uma estrutura que funcione em todos os navegadores. Não faça o site pensando apenas no seu navegador favorito para depois encher de hacks para os demais e meter a culpa neles.

Navegadores são atualizados sempre, isso quando não surgem novos. A 6 meses atrás não existia o Google Chrome, Firefox 3 e pouco era utilizado internet em celulares no Brasil. Se o layout de um site foi construído errado e “consertado” com hacks, provavelmente o mesmo site está quebrando o layout nesses novos navegadores, por isso não vale a pena. Antes de criar uma hack, pense 10 minutos a mais resolver seu problema de outra forma. Tudo bem, tem hacks que realmente precisamos colocar por falta de suporte do ie6. min-height e max-height, o suporte a imagens alpha ( pgn24 ) tão usado pelos designers hoje em dia e os pseudo seletores :first-child e :last-child. Essas 3 opções, somente essas 3 não tem jeito mesmo, é colocar expression no seu css e filter pro png, mas de resto, nenhuma hack é necessária.

Outras técnicas que não recomendo são: display table, uso excessivo de float, margin com valores negativos, tudo isso não passa de gambearra para fazer o layout ficar no lugar onde está dando erro.

Dicas para ter menos problemas ao construir um css :

Utilize o CSS Global Reset para diminuir as diferenças entre os browsers. Cada browser, coloca por sua conta, qual vai ser o tamanho dos títulos, dos paragráfos, a margin entre elementos, a fonte padrão, o padding da página, etc… Com esse código, essas diferenças caem quase que por completo.

Para elementos fixos (que não tem variedade de tamanho) dentro de um container, tipo botões ou input / label de formulário, pense em utilizar position absolute, é uma técnica muito simples de se trabalhar quando se tem um xhtml válido, pois todos os navegadores interpretam da mesma forma a posição do elemento, ao contrário de float e margin que dão muitos problemas. O site americano Position Is Everything recomenda a técnica e explica melhor como utilizar.

Aqui no TidBits também nós disponibilizamos uma apostila e material de estudo sobre padrões web em português

Jakob Nielsen é um cara polêmico no mundo da usabilidade, talvez pelo fato de ser o mais conhecido analista de usabilidade do mundo, ou talvez seja o mais conhecido analista de usabilidade do mundo pelo fato de ser polêmico. O fato é que ele fala de usabilidade há muito tempo, e mais do que falar, ele sempre promove testes e pesquisas para embasar suas falas (para quem costuma ler os rodapés das pesquisas, ele é o dono da Norman e Nielsen Group – uma grande empresa de pesquisas e análises de dados do mundo).

Ele também escreve uma coluna em seu site (Useit.com), chamada Alertbox, onde constantemente apresenta os resultados de várias dessas pesquisas, ajudando a implantar certos parâmetros de usabilidade que passam a ser adotados por um grande número de profissionais.

Um desses parâmetros, são suas heurísticas. São 10 itens para a avaliação da usabilidade de um site, com intuito de evitar erros comuns – as heurísticas foram baseadas em 294 tipos de erros de usabilidade que o Nielsen comumente encontrava em suas análises – e que podem prejudicar e muito a experiência do usuário em seu site. Uma avaliação heurística, ao pé da letra, é feita por no mínimo 3 e no máximo 5 profissionais especializados nesse tipo de avaliação.

Mas mesmo que você não seja nenhum analista de usabilidade, checar esses itens com certeza irá tornar a experiência do usuário em sua interface uma experiência menos frustante. Vamos às heurísticas:

1. Visibilidade de Status do Sistema
Isso significa que você precisa se certificar de que a interface sempre informe ao usuário o que está acontecendo, ou seja, todas as ações precisam de feedback instantâneo para orientá-lo.

2.Relacionamento entre a interface do sistema e o mundo real
Ou não usar palavras de sistema, que não fazem sentido pro usuário. Toda a comunicação do sistema precisa ser contextualizada ao usuário, e ser coerente com o chamado modelo mental do usuário.

3. Liberdade e controle do usuário
Facilite as “saídas de emergência” para o usuário, permitindo desfazer ou refazer a ação no sistema e retornar ao ponto anterior, quando estiver perdido ou em situações inesperadas.

4. Consistência
Fale a mesma língua o tempo todo, e nunca identifique uma mesma ação com ícones ou palavras diferentes. Trate coisas similares, da mesma maneira, facilitando a identificação do usuário.

5. Prevenção de erros
Na tradução livre das palavras do próprio Nielsen “Ainda melhor que uma boa mensagem de erro é um design cuidadoso que possa prevenir esses erros”. Por exemplo, ações definitivas, como deleções ou solicitações podem vir acompanhadas de um checkbox ou uma mensagem de confirmação.

6. Reconhecimento ao invés de lembrança
Evite acionar a memória do usuário o tempo inteiro, fazendo com que cada ação precise ser revista mentalmente antes de ser executada. Permita que a interface ofereça ajuda contextual, e informações capazes de orientar as ações do usuário – ou seja – que o sistema dialogue com o usuário.

7. Flexibilidade e eficiência de uso
O sistema precisa ser fácil para usuários leigos, mas flexível o bastante para se tornar ágil à usuários avançados. Essa flexibilidade pode ser conseguida com a permissão de teclas de atalhos, por exemplo. No caso de websites, uso de máscaras e navegação com tab em formulários são outros exemplos.

8. Estética e design minimalista
Evite que os textos e o design fale mais do que o usuário necessita saber. Os “diálogos” do sistema precisam ser simples, diretos e naturais, presentes nos momentos em que são necessários.

9. Ajude os usuários a reconhecer, diagnosticar e sanar erros
As mensagens de erro do sistema devem possuir uma redação simples e clara que ao invés de intimidar o usuário com o erro, indique uma saída construtiva ou possível solução.

10. Ajuda e documentação
Um bom design deveria evitar ao máximo à necessidade de ajuda na utilização do sistema. Ainda assim, um bom conjunto de documentação e ajuda deve ser utilizado para orientar o usuário em caso de dúvida. Deve ser visível, facilmente acessada, e com oferecer uma ferramenta de busca na ajuda.

Ví hoje no DGmike que saiu uma matéria no Ajaxian dizendo que o Firefox 3.1 que deve sair em breve vai suportar as tags de áudio e vídeo. Atualmente o formato suportado pra vídeo é somente o ogg mas outros formatos estão sendo discutidos para serem implementados no futuro.

Para chamar, vai ser bem simples:

<video src="videos/teste.ogg" autoplay="autoplay">
Seu navegador não suporta vídeo
</video>

E se quiser mandar dar play ou pause com javascript, será bem simples também:

<script type="text/javascript">
    document.getElementsByTagName('video')[0].play()
</script>

Ou por jQuery:

<script type="text/javascript">
    $('video')[0].play();
</script>

O HTML5 está apenas iniciando a ser implementado nos novos browsers, mas dá pra ver que vai mudar muita coisa, dando muito mais ferramentas a nós, programadores de interface.