TidBits

O seu browser estar apresentando seu site corretamente não significa que seu código esta correto e também não significa que vai funcionar em mais 40 browsers que são usados atualmente. Programar a interface de um site é bem diferente do que programar numa linguagem server side onde, se você esquecer um “;” ou não fechar um if, seu código nem roda. Programando no lado do cliente, diversos erros de html são “consertados” pela maioria dos browsers. Ou seja, você esquece de fechar uma tag, ou coloca um <h1> dentro de um <a> no seu browser e aparece tudo ok, mas é errado.

Ok, mesmo que o site seja testado no Firefox, ie6, ie7, Safari, Chrome e Opera, quem garante que os navegadores Netscape 6.0, Ant Galio 3.1, Blaze 6.0 ou o Playstation 3 5.0 vão interpretar corretamente também?

E é por isso que devemos validar o código. Existem diversas ferramentas para validação de código.

A mais importante delas, creio que é o HTML validator, uma extensão de firefox. Além de válidar seu (x)html, ele diz o que está errado e como consertar o que é ótimo pra quem está começando a programar interface.

Para validar CSS, a melhor opção é o CSS validator da W3C. Infelizmente não existe (ou não conheço) nenhuma opção desktop. Mas mesmo assim, vale a pena utilizar.

Já o link-checker é um validador de links que analisa seu site e procura por links quebrados, muito útil. A análise é BEM completa, e demora muito tempo, afinal ele checa tudo. Analisando a home do TidBits ele demorou 286 segundos e checou mais de 200 arquivos.

Outras ferramentas como o firebug, ajudam bastante na codificação, principalmente pra detectar erros de JavaScript. E finalmente, para garantir a acessibilidade do seu site, existe diversas opções, duas em português: o Da Silva e o ASES desenvolvido pelo governo eletrônico.

Cameron Adams fez um experimento divertido e o chamou de JS-909, uma mesa de som para construir batidas de músicas. Ela produz som sem utilizar flash, o javascript checa se seu browser é capaz de produzir som, coloca as musicas pra tocar e também inclue um pequeno script para visualizar as batidas em gráficos psicodélicos, no estilo windows media player.

Como não existe um padrão nos browsers para acessar os controles de som ( para, tocar, voltar ). Ele usou a interface de javascript do quicktime para tocar os sons.

Os sons são chamados pela tag <embed> e num determinado evento é criado o embed no dom via javascript.

Veja o exemplo rodando aqui.

O 1º Encontro de Tecnologia da Informação para desenvolvedores web, comentado no post anterior , vai ser realizado nos dias 27 (quinta) em São Paulo e 29 (sábado) de novembro no Rio de Janeiro e vai abordar temas da área que foram escolhidos pelo própio público do evento. A Arteccom está disponibilizando dois ingressos (um para o RJ e um para SP) para o TidBits. E nós vamos dar o ingresso para os nossos leitores. =)

A Belinha queria ir no evento mas não liberaram ela no trabalho. Então, para ganhar um ingresso, responda a seguinte pergunta:

Que desculpa esfarrapada você pode dar a seu chefe que não deixou você ir no evento?

Você pode responder aqui no comentário do post mesmo. É só deixar seu email, seu estado (SP ou RJ), e a resposta.

O evento terá diversas palestras e oficinas interessantes sobre SEO, Scrum, Ruby on Rails. E no final do evento ainda vai rolar um happy hour lá. Veja a programação completa.

A promoção vale só até quarta feira ( 19 de novembro ) as 17 horas.

Promoção encerrada

E os ganhadores foram:

Anderson Campista (RJ)
Mariana Dias dos Santos Nadais (SP)

[]s

Dia 27 de novembro em São Paulo e 29 de novembro no Rio de Janeiro, vai ter o 1º encontro de TI, e o que chama a atenção nesse evento, é que o público que montou a programação. A Arteccom fez uma pesquisa no site www.encontrodeti.com.br com desenvolvedores web para que fossem sugeridos temas e palestrantes para o evento. 512 profissionais da área de TI responderam a pesquisa e os temas mais votados e escolhidos para as palestras foram :

• Linguagens – quais são as mais requisitadas pelas grandes empresas e o valor das formações/certificações
• CMS livres: Drupal x Joomla! x WordPress
• Ferramenta Google Analytics: como analisar acessos e gerar melhores resultados
• Padrões W3C – Como tornar seu site mais leve e mais acessível

E depois de escolhidos os temas, os mediadores dos palestrantes e oficinas propõem um debate no site do ETI para decidir qual especialidade dentro do assunto principal será abordada para as palestras:

Simultaneamente as palestras, ocorrerão algumas oficinas que vão discutir assuntos atuais da área, como Ruby On Rails, SEO, Interoperabilidade e Scrum e depois de tudo isso vai rolar um happy hour.

Veja a programação abaixo:

As oficinas são bem interessantes, me chamaram bastante atenção e o preço (de 42 a 72 reais) é bem inferior ao padrão de eventos no Brasil. Vale a pena ir.

Locais:

São Paulo
Data: 27 de novembro de 2008
Local: Amcham Brasil
Rua da Paz, 1.431 – Chácara Santo Antônio – São Paulo – SP
Telefone: (11) 5180-3728

Rio de Janeiro
Data: 29 de novembro de 2008
Local: Centro de Convenções SulAmérica
Av. Paulo de Frontin, 1 – Cidade Nova – RJ
Telefone: (21) 3293-6700

Inscrições: www.encontrodeti.com.br
Mais informações: (21) 2253.0596

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:

[sourcecode language="html"]

[/sourcecode]

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:

[sourcecode language="css"]
@media screen {
h1 { font-size:28px; color:#ff0;}
}
@media print {
h1 { font-size:14px; color:#000;}
}
[/sourcecode]

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

[sourcecode language="css"]
@media print {
div#header, div#footer, div#sidebar-wrapper,
p.bookmark-me, div.post-footer,
form#commentform, h3.comentar {
display:none;
}
}
[/sourcecode]