Os pontos que surgiram na conversa foram os seguintes:

Falta de foco:

Acreditamos que este seja o principal problema. Em nenhum momento falou-se claramente “isso serve pra aquilo” – só se falou que era um milhão de possibilidades, que as pessoas iam ter orgasmos com os recursos mágicos, só que… Não se falou como. Os exemplos apresentados do que fazer com a ferramenta foram pífios e, até onde eu sei, ninguém fez algo que fosse digno de nota usando o Wave.

Interface diferente “Pero no mucho”:

A idéia vendida foi de uma interface revolucionária. A estrutura ousa muito pouco (repare que a diagramação e distribuição, exceto pela caixa de texto, é quase a do Gmail) e, no pouco que ousou, ficou confuso e sem atrativos – caso do box de texto, que tem um monte de recursos mas nenhum exatamente novo.

Por exemplo pra que diabo fazer uma enquete se pode-se usar um Spreadsheet com o próprio Google Docs com mais recursos e sem todo o ruído visual do Wave ao redor?

Excesso de expectativa

Criou-se muita expectativa de revolução para uma ferramenta que foi lançada inacabada. Mesmo que tivesse uma proposta inovadora, a chance de causar uma boa impressão foi totalmente perdida – muitos usuários não dão segundas chances para ferramentas, especialmente se vierem a se sentir “burros” ao usar.

Alguém lembra do vídeo de uma hora e tra-la-lá apresentando o produto e das pessoas em extase assistindo à demonstração? Até a risada gravada do chaves parecia mais sinceras que aquilo.

Ferramentas tardias

Vários recursos desejáveis relacionados à usabilidade só surgiram muito depois do lançamento, como uma forma de aviso sobre novos waves ou a possibilidade de excluir-se de uma lista Wave (embora implementado é MUITO ruim a navegação e são vários cliques até conseguir).

Tudo bem que melhorias podem sempre ser feitas posteriormente, mas creio que a idéia deles que as pessoas querem ficar conectadas às outras para sempre em tudo que for compartilhável é bem errada – até porque, se verdade fosse, divórcio não existiria.

O Wave não é uma onda, é uma ilha

Na ânsia de tentar ser a nova ferramenta de comunicação da internet, rede social, messenger, email e chat tudo ao mesmo tempo, não foi criada forma alguma de interface com outras ferramentas já existentes. Sequer um RSS.

Entendemos que, de forma até prepotente, o Google tentou apresentar um novo paradigma e romper com todos os antigos – mas foi inocência demais acreditar que pessoas largariam ferramentas que usam há anos e começassem a focar tudo no Wave, e que elas não quereriam integração com mais nada. Por que não uma possibilidade de conectar algo ao Facebook? Por que, no começo, sequer com o próprio Gmail tinha conexão? Já foram adquiridos muitos hábitos nos últimos 15 anos, e uma cultura deste tipo não é jogada para o alto de uma hora pra outra.

Para saber da dificuldade de mudar um hábito é só pensar quanto tempo demorou pro e-mail substituir o fax. Para algumas empresas, aliás, isso ainda é uma realidade.

Documentação ruim / falta de incentivo aos desenvolvedores

Por conta talvez da já citada falta de foco, a documentação voltada a desenvolvedores (que poderiam ter sido umas das fontes de salvação) foi escrita de maneira péssima, tornando a possibilidade de que boas idéias vindas da comunidade minguasse muito.

Poucos heróis aventuraram-se a fazer algo para o Wave, mas a maioria resolveu esperar para ver no que dava antes de perder precioso tempo estudando algo que pudesse dar em água. E deu.

Entrada por convite

Outra coisa que frustrou pessoas: se você já tem Gmail, conta no Orkut, conta no Picasa, Gtalk e etc, por que cargas d’água precisa ser convidado para usar uma ferramenta que, em tese, já é parte das suas aplicações/contas Google? Convites são feitos para coisas que são extremamente desejáveis e, se feitos ao acaso, gera uma expectativa de “é bom valer a pena”. Dá sensação de pagar pra entrar num clube privado e descobrir lá dentro que é só um boteco comum.

Tudo que se propôs a resolver já tinha solução

Concordo, muita coisa até pode ser melhor solucionado no Wave, caso por exemplo da função de edição conjunta e compartilhamento de documentos. Mas… As pessoas já faziam isso no Google Docs há anos. E já eram familiares à estrutura “word-like” lá utilizada, afinal, todos já estão bem adestrados desde o win 3.11 a usar aquela estrutura. Não importa o quão mais simples seja a interface, para aquele tipo de solução de editor será, sempre, muito difícil propor algo novo.

Integração demais = lentidão

As possibilidade de juntar tudo e todos é tão grande que por vezes é insustentável manter um wave por muito tempo. Tantos são os aplicativos, replys, icones de participantes, referências internas, referências externas, etc, que só com muita memória RAM você consegue usar o Wave de forma decente.

Puxando a Sardinha para o Chrome

O Google pedia descaradamente para você usar o Wave no Chrome. Sim, é mais do que verdade que o Chrome é um tremendo de um browser, com o melhor “motor” para interpretação de Javascript feito até então, não só o Wave, mas tudo que usa Ajax como base para interface web.

O caso é que o usuário não sabe disso. Se o site está lento, para o usuário a culpa não será do IE6, será do site. Mesmo no Firefox, que é um browser bastante decente, fica insuportável de lento, forçando a usar o Chrome.

Não importa o quão verdadeiro é o fato de que o Chrome lida melhor com Javascript com os outros: a campanha/lavagem cerebral pelo browser da casa sempre vai deixar com aquele fundinho de que foi sabotagem nos outros navegadores (coisa que não foi MESMO). E como tem neurótico a rodo nessa terra, especialmente entre desenvolvedores (isso, aqueles mesmos que poderiam ter salvo aspectos da aplicação), é mais um motivo que afasta os potenciais usuários.

O nome do produto não é “iWave”

Se o google wave fosse produzido pela Apple ou fosse uma app para iPhone, os geeks moderninhos certamente ajudariam a vendê-lo como uma idéia de outro mundo.

Falando mais sério, essa foi outra falha na estratégia do Google: eles tentaram fazer algo que a Apple faz há anos, que é vender qualquer idéia como se fosse revolucionária (mesmo que seja só um iPod grandão com menos recursos que o original).

O lance é que a Apple assume essa postura e o risco do produto não dar certo. Eles perdem com o que não da certo, mas é um risco menor: a Apple conhece bem seu público e já percebeu qual é a forma que eles tendem a agir, então raramente dá uma bola fora (e quando dá sabe exatamente o que falar para o público continuar sentindo-se querido e feliz com o status de ser um possuidor de um produto deles).

Conclusão

De megalomania aos problemas de projeto, é realmente uma pena ver uma ferramenta morrer deste jeito, sem chegar a atingir todo seu potencial. Engraçado, pois uma das coisas que comentamos durante o papo é que, depois de algumas experiências, ela era um bom lugar para juntar material de pesquisa e pequenos Brainstorms (com direito até a descobrir nesse exato momento que há um novo recurso voltado para mind map, que sempre foi um recurso do qual sentimos muita falta).

Quando finalmente achamos o que fazer com a ferramenta o Google decide enterra-la.

Na primeira parte dei uma visão simples e geral sobre o que é SEO.

Na segunda, falei sobre o que é e pra que servem as Meta Keywords .

No terceira, o por quê de ainda preocupar-se com Meta Description e o motivo de te-la bem feita.

Nesta parte, a última desta sequência, vou explicar como pode-se “pegar carona” na relevância de outros sites através de links.

Aumentando a relevância por links

Daí o cidadão vai lá e pergunta como fazer o texto dele “subir no Google” e, alguém com um pouco mais de manha, sugere para selecionar as palavras chaves e nomes e linkar para sites externos. O cidadão olha torto e solta os cães, dizendo coisas como “que absurdo, colocar links para sites externos, isso vai tirar os leitores do nosso site e mimimi mimimim mimimim mimimim mimimimimi”.

Sim, eu já ouvi isso…

Em primeiro lugar, ponto de vista humano: as pessoas vão dar é muito mais valor para os textos do site pelo simples fato que a informação oferecida é mais completa – e se o site não tem em si mesmo a informação, o autor aponta, sem medo, pra algum outro que a tenha.

Segundo lugar, ponto de vista dos Search Engines: nossos camaradas buscadores aumentarão a sua importância em muito pelo mesmíssimo motivo citado no primeiro lugar. A lógica é: quanto mais referência para outras páginas/sites com assuntos relacionados, maior a chance do usuário encontrar um conteúdo satisfatório. Levando em conta que os buscadores tem os dados de relevância das páginas que você referenciou de seu texto, quanto maior a qualidade do link dado maior será a relevância emprestada para o seu texto. Entedeu?

Vamos a um exemplo prático que o Alex Borges me indicou: se voce digitar “Restaurante Italiano” no Google hoje, 4 de agosto de 2010, o primeiro resultado será http://www.emsampa.com.br/r_11.htm.

Pelas regras básicas que o SEO sugere, veremos de cara 3 erros graves:

• Erro 1 : URL com link bizarro, que não quer dizer absolutamente nada, ao invés de uma url amigável;
• Erro 2:  Código “sujo” e confuso, inteiro feito em tabela, provavelmente feito com editor visual mal-configurado;
• Erro 3: Número de meta keywords muito alto.

… E por aí vai.  Tem mais erros, mas estes já deveriam ser suficientes pra mandar o link lá pra nona página – mas isso não acontece, ele está em primeiro. Como? Sequer as palavras “Restaurante” e “Italiano” é repetida muitas vezes, qual o segredo pra justo este link estar no topo?

O motivo mais provável é que, pelo fato desta página ter um índice imenso de links para diversos sites de restaurantes italianos, possivelmente com a grande maioria com um pagerank razoável, isso é o suficiente para que o buscador acredite que é uma fonte confiável para a referência “restaurante italiano”.

Em outros casos você poderia, por exemplo, citar uma empresa e linkar diretamente para o site dela – especialmente se o site em questão vier em primeiro no resultado. Em geral, se o site-referência for muito ruim ou inexistente, você ainda pode apelar para a Wikipedia, que é sempre uma ótima saída para este fim.

Bom, acredito que seguindo estes passo, já é possível melhorar e muito a relação com os buscadores. Obvio que é mais extenso que isso e, por conta das regras mudarem todo dia, dá pra pirar muito mais dentro deste assunto.

Para saber mais:

SEO na Wikipedia – história, teoria e mais algumas regras básicas.

Blog oficial do Google – melhor referência de todas para aprofundar-se no assunto. Se qualquer regra muda, se há alguma boa prática a ser seguida, certamente sairá aqui.

Google Webmaster Tools – Ferramentas para verificar qualidade de conteúdo do ponto de vista do buscador, diagnósticos de meta tags redundantes, etc.

Yahoo Site Explorer – mesma pegada do link anterior, mas nas regras do Yahoo.

Google Trends – Mas e aí, as pessoas procuram mais pela palavra “Carro” ou por “Automóvel”? Qual delas trará mais acessos? O Google Trends te ajuda com isso.

Artigos Mestre SEO - particularmente eu não gosto muito deste site, por vezes tenho a impressão que muito do material é só reescrito de tempos em tempos com palavras diferentes, tornando-o um pouco redundante – mas eu sou chato pra cacete com algumas coisas, então pode ser só cisma minha. De qualquer forma, mesmo com o porém que eu falei, tem bastante coisa legal e vale a consulta para tirar dúvidas.

E este é o final desta série, senhoras, senhores e crianças. Quem quiser debater o assunto pode entrar em contato comigo pelo próprio blog ou pelo twitter.

Até!

Em meio às tecnologias para troca de dados e comunicação entre aplicações pela web como REST, SOAP, WSDL etc, se destacam também as APIs que fornecem dados com simples requisições http diretamente do site via browser, sem a necessidade de processamento do lado do servidor pelo cliente do serviço. Para esses casos temos o JSONP como uma alternativa “bem em conta” para resolver problemas conhecidos. O objetivo desse post é dar uma introdução do que é e como usar o JSONP.

AJAX vs JSONP

Tecnicamente, JSONP não é AJAX, vamos a uma explicação bem breve da diferença:

AJAX se trata de requisições assíncronas por meio dos objetos XMLHttpRequest e XMLHttpResponse, que trafegam dados no formato XML ou texto puro. Esses dados são manipulados pelo programa javascript, que finalmente monta seus trechos de html sem a necessidade do recarregamento da página.

Já o JSONP requisita dados de forma assíncrona, assim como o AJAX, porém não utiliza os objetos XMLHttp e  só trabalha com objetos no formato JSON.

JSON – JavaScript Object Notation

Formato de dados que vem sendo fortemente utilizado para transporte de dados entre aplicações, principalmente web. Está ganhando seu espaço devido a sua simplicidade de implementação e leveza. É um subconjunto das notações de objetos javascript. Além disso, a manipulação dos dados em um objeto JSON requer um parse simples (usando o método eval do javascript) e não se faz necessária a navegação por DOM entre os nós e atributos de um XML, e por isso a preferência pelo JSON ao invés de XML para ajax na web.

Same Origin Policy

Existe uma limitação para o uso do Objeto XMLHTTPRequest no que se trata de requisições entre diferentes sites. Existe um padrão de segurança, implementado por linguagens de programação, nesse caso o javascript, chamado Same Origin Policy, ou Política de Mesma Origem. Essa recomendação de segurança impede que um documento leia ou envie informações para outra origem.

São considerados de origens diferentes quaisquer documentos que estejam em domínios diferentes, portas diferentes ou que utilizem protocolos de comunicação diferentes entre si.

Considerando a url: “http://www.afronteirafinal.com/”, podemos ter requisições que irão ter sucesso ou falhar nas seguintes situações:

JSONP – JSON with Padding

JSONP é entendido como um “pseudo-protocolo” que permite realizar requisições http e trafegar dados no formato JSON entre documentos de origens diferentes.

Como funciona:

A implementação do JSONP e bastante simples, porém é necessário que o serviço responsável pela entrega os dados forneca a opção de entrega na estrutura necessária para que os dados possam ser manipulados.

Não existem restrições para o carregamento de imagens e scripts de outras origem, por meio do atributo “src” das tags. A técnica por tras do JSONP se aproveita dessa possibilidade para carregar scripts externos conforme a necessidade, manipulando o DOM da página.

O que faz acontecer o JSONP é a inclusão de uma TAG “script” no header “<head>” da página. Essa tag “script” recebe um atributo “src” apontando para o site externo, que responde objetos no formato JSON , esse resultado é “parseado” e fica disponível para manipulação via JavaScript.

O que é o “padding”?

Padding ou prefix é o nome passado na requisição ao serviço, para que na resposta o método envolva os dados em formato JSON após a resposta. Quando a requisição é feita dessa forma:

<script type="text/javascript" src="http://domain1.com/getjson?jsonp=parseResponse" target="_blank"></script>

A palavra “parseResponse” será a o nome da função que envolverá o json, como um callback. O resultado será algo parecido com isso:

parseResponse({“name”:”Jujuzinho”, ”idade”:10, brinquedos:[“bola”,”pipa”,”ioiô”]})

Você, como um esperto desevolvedor, já terá declarado esse método (parseResponse) em seu programa, e este saberá como sabiamente utilizar os dados recebidos.

Suporte nos frameworks

Os frameworks JavaScript geralmente dão um bom suporte às implementações do JSONP, resolvendo a maioria das questões que teríamos que nos preocupar fazendo tudo “na unha”.

No caso do jQuery, ele abstrai as particularidades entre jsonp e ajax e incorpora o JSONP com mais um formato de dados para o seu objeto Ajax.

Em caso de dúvidas, primeiro procure a documentação do framework porque certamente ele trará informações de como implementar jsonp sem mais traumas.

No próximo episódio…

No próximo post sobre o assunto falaremos sobre o futuro. Como será feito o transporte de dados pela web. Protocolos de comunicação de verdade para rodar no browser. Que projetos já estão em andamento e como eles poderão resolver problemas que travam o avanço da comunicação entre apps web.

A palavra “Deficiente visual” é abrangente demais – podemos falar de daltônicos, míopes (que é meu caso, por exemplo), hipermétropes, fotofóbicos e etc, e não é objetivo falar sobre tudo isso nesse artigo. Logo, acho que usar a palavra “cego” (que não vejo por onde possa ser ofensiva) define muito bem o tipo de usuário com o qual estamos preocupados.

Por que essa preocupação? Veja bem, isso não é “bondade”, diria até que está mais para uma obrigação. Além, é claro, de permitir igual acesso ao máximo de pessoas possível, lembre-se que é mais um recurso que pode aumentar o número de usuários e, por consequência, fideliza-los.

Internet acessível

Há toda uma gama de recursos atualmente que auxiliam pessoas com necessidades especiais a ter acesso à internet. Estes aparatos podem variar de simples varinha para auxiliar pessoas com movimentos restritos até complexos hardwares para cegos-surdos que convertem textos para braile.

No caso específico dos cegos, o recurso mais comum é o Screen Reader – que nada mais é do que um programa que converte palavras para áudio. Infelizmente, segundo um vídeo no Webaim, percebe-se a grande maioria dos websites não é escrito de forma que possa ser facilmente compreendido por estas ferramentas.

Acessibilidade: por onde começar?

Acima de tudo, acessibilidade tem em seu princípio a regra de ouro de qualquer programa ou aplicação web, a regra KISS! (Keep it simple, stupid! – ou em tradução livre “mantenha isso simples, estúpido!”). Quanto mais robusto e simples o seu código, melhor a qualidade do texto “narrado” pelo Screen Reader. Evite usar scripts complexos no corpo da página, gambiarras que sujem o código (em especial POGs de crossbrowser) e atributos desnecessários.

Seu site precisa ser navegável via teclado

Um cego nunca usará o mouse para navegar uma vez que ele não teria como saber onde posicionar o cursor, o que o obriga a navegar basicamente usando o TAB e enter do teclado. Pode parecer estúpido citar isso aqui uma vez que, à primeira vista, parece um pensamento óbvio – mas é fato que são poucos os desenvolvedores e designers param e pensam a respeito das implicações que isso traz para a interface, tanto no design quanto na construção html/css.

Linearidade

Quando construir a página certifique-se que todo o conteúdo está disposto de forma linear, de forma que com o css desabilitado o texto esteja sequencial. Muitas vezes, por questão de facilitar o alinhamento crossbrowser, é comum inverter dois boxes de posição e ajusta-los via css. Isso faz com que o Screen Reader leia boxes de forma invertida também.

O melhor teste para ver se a linearidade está correta é desabilitar o css do Browser e checar como o texto se alinha na página – o ideal é que os boxes fiquem um abaixo do outro.

Vá direto ao ponto

Esta é a coisa mais simples que pessoas poderiam fazer para melhorar a acessibilidade de um site e que infelizmente não é difundida o suficiente: ao montar a página coloque no topo um link “ir direto para o conteúdo” e linka-lo à uma ancora no ponto que o texto começa. Este link não necessariamente precisa ter visual, ele pode ser escondido de forma que só é acessivel pelo screen reader. Dica: eu não tenho certeza se os screen readers mais modernos entendem quando o bloco está com “display:none”, então, por via das dúvidas, uma sugestão de código para esconder este link é o seguinte:

.escondeLink {

position:  absolute;

display:block;

margin-top:  -4000px;

}

Repare que desta forma você não “apagou” o link da página, somente tirou-o da área visual do browser.

O ideal para aplicação desta ancora é que ela esteja logo após a abertura da tag BODY. Um exemplo de como deve ser usado pode ser visto no próprio http://www.webaim.org .

Outra preocupação para não ter problema com os robôs do google, é fazer uma indicação explícita que esses links não devem ser indexados, já que as âncoras podem ser interpretadas como uma nova URL:

<a rel="nofollow" href="http://afronteirafinal.com#conteudo">
A Fronteira Final
</a>

Cuidado com chamadas nos links e comandos JavaScript

Esta regra é similar à aplicada a SEO: evite criar links que não deixem claro seu destino. Evite ao máximo “clicando aqui”, “clique”, etc.

Sempre dê preferência por ser específico, usando coisas como por exemplo “Conheça o site A Fronteira Final” à “Conheça o site a fronteira Final clicando aqui“. Cegos e buscadores agradecerão por este simples cuidado.

Outra coisa a respeito dos links é que eles TEM QUE APONTAR PARA ALGUM LUGAR. Evite chamar funções javascript nos links pois isso tende a confundir os Screen Readers e outros softwares de interpretação. E lembrando: dependendo da forma como o comando JS responde, pode ser que ele iniba a navegação via teclado.

Efeitos OnMouseOver e OnMouseOut

Só para enfatizar o tópico anterior, eventos relacionados a ações do mouse estão entre os grandes vilões da acessibilidade. Tenha sempre em mente que estes dois comandos ou qualquer outro evento relacionado diretamente à captura de mouse devem ser descartados se afetarem a navegação via teclado ou proporcionarem qualquer tipo de informação que só possa ser assimilada de forma visual.

Alt nas imagens

Outra regrinha que também vale para SEO: sempre coloque a descrição correta nas imagens do seu site de forma clara e concisa. Escrever “Circo” ao invés de “Foto do Cirque du Soleil em apresentação no Morumbi” é algo que pode fazer muita diferença quando você não tem a referência visual.

Cor/imagem como informação

Evite ao máximo usar qualquer informação que dependa de cor, imagem ou animação para compreensão plena do texto. Se não houver como escapar, tente criar algum recurso textual (alt, legenda, um parágrafo falando o que é o signo acima) que amenize ao máximo este problema. Tente usar este tipo de recurso apenas no ambito da estética.

Tabelas e formatos especiais

Evite a todo custo tabelas complexas. O Screen Reader vai tentar le-la da esquerda para a direita, ficando difícil de compreender o tipo de conteúdo que ela contém.

Outro cuidado é com formatos diferenciado como os Microformatos. Pode usar sem medo, desde que os Microformatos sejam aplicados de forma correta.

Tabelas, quando necessárias, devem ser escrita de forma semanticamente correta para que o Screen Reader, evitando qualquer confusão para a interpretação de Screen Readers ou qualquer outro recurso. Veja o exemplo abaixo:

<table><caption>texto</caption>
<thead>
<tr>
<th> texto</th>
<th> texto</th>
<th> texto</th>
<th> texto</th>
</tr>
</thead>
<tfoot>
<tr>
<th> texto</th>
<th> texto</th>
<th> texto</th>
<th> texto</th>
</tr>
</tfoot>
<tbody>
<tr>
<th> texto</th>
<td>texto</td>
<td>texto</td>
<td>texto</td>
</tr>
<tr>
<th> texto</th>
<td>texto</td>
<td>texto</td>
<td>texto</td>
</tr>
<tr>
<th> texto</th>
<td>texto</td>
<td>texto</td>
<td>texto</td>
</tr>
</tbody>
</table>

Outro formato que merece cuidado é o formulário, que deve ter todos os campos, labels e teclas de acesso nos lugares corretos.

<form id="form" method="post" action="#">
<fieldset>

<legend>Dados pessoais</legend>
<label for="nome">Nome</label>
<input id="nome" name="nome" type="text" title="Nome" alt="Nome" tabindex="1" accesskey="n" />
<label for="email">E-mail</label>
<input id="email" name="email" type="text" title="E-mail" alt="E-mail" tabindex="2" accesskey="e" />
</fieldset>
<fieldset>

<legend>Destinatário</legend>
<label for="departamento">Selecione o departamento</label>
<select id="departamento" name="departamento" title="Departamento" tabindex="3">
<optgroup label="Departamento 01">
<option value="nomefunc01" title="Nome do funcionário 01">Nome do funcionário 01</option>
<option value="nomefunc02" title="Nome do funcionário 02">Nome do funcionário 02</option>
</optgroup>

<optgroup label="Departamento 02">
<option value="nomefunc01" title="Nome do funcionário 01">Nome do funcionário 01</option>
<option value="nomefunc02" title="Nome do funcionário 02">Nome do funcionário 02</option>
</optgroup>
</select>
</fieldset>
<fieldset>
<legend>Mensagem</legend>

<label for="mensagem">Escreva sua mensagem</label>
<textarea id="mensagem" name="mensagem" cols="100" rows="10" title="Escreva sua mensagem" tabindex="4" accesskey="m"></textarea>
<input id="enviar" name="enviar" type="submit" value="Enviar" title="Enviar" alt="Enviar" tabindex="5" accesskey="s" />
</fieldset>
</form>

Para saber mais

Seguindo essas regras simples a qualidade do seu site aumentará bastante mas, como em tudo que se relaciona com internet, é um assunto “saco sem fundo”, daqueles que quanto mais você estuda mais tem a estudar. Alguns sites para procurar mais informação à respeito:

http://www.webaim.org/ – citado duas vezes no texto, é uma organização focada em acessibilidade e possuí material vastíssimo sobre o assunto.

http://brasilmedia.com/Acessibilidade-na-Web.html – A Brasil Média pegou parte do material do Webaim e verteu para o português.

http://www.acessibilidadelegal.com/ Um bom site em português também, mas este com produção própria de artigos. Vai um pouco mais fundo nos tópicos levantados neste artigo.

http://www.w3c.br/index-3dez-1.htm – Quer entender como um cego navega? A W3C lançou um hotsite que simula esta experiência.

http://imasters.uol.com.br/artigo/12814 – Ótimo artigo de Horácio Soares sobre como realizar os testes de usabilidade, com vários links e referências de programas, validadores e sites com orientações valiosas.

Segurança (ou falta de)

Especialistas em segurança afirmam que da forma como o IE 6 é desenhado é muito difícil garantir sua segurança.

Uma das maiores falhas de segurança Internet Explorer é o fato dele ser executado com o mesmo nível de acesso do usuário logado. Os malwares que exploram as vulnerabilidades do browser se aproveitam desse nível de acesso, já que grande parte dos usuários de Windows (XP por exemplo), se conectam ao sistema com usuário Administrador ou perfil de acesso que o valha. Existem ferramentas para limitar o nível de acesso do Internet Explorer, mas poucos usuários as conhecem ou se preocupam em instalar. E só pelo fato dessa segurança não estar presente por padrão, o pobre usuário do IE ja inicia a navegação vulnerável.

Esse problema de nível de acesso ocorre também com outros navegadores do mercado que rodam em ambiente windows. O problema é que o navegador é tão integrado ao Windows que uma falha de segurança é uma ameaça potencial ao próprio sistema operacional.

Não existe ambiente 100% seguro, nem mesmo navegador 100% a prova de falhas, mas o fato é que o Internet Explorer 6 é campeão em falhas críticas de segurança e, com a descontinuidade do projeto, as atualizações (que nem são tão frequentes quanto precisavam ser) vão deixar de acontecer.

Compatibilidade com CSS

O Internet Explorer 6 foi lançado muito tempo depois da especificação do CSS 2. Mesmo assim, o browser não tem compatibilidade completa com itens especificados para o CSS 1.

A grande maioria dos browsers modernos, já dão algum suporte a versão 3 do CSS que ainda em desenvolvimento. Hoje ja é possível criar detalhes de layout de forma muito simples e limpa. A nova especificação do CSS 3 promete resolver muitos problemas visuais encontrados hoje no desenvolvimento dos layouts, mas enquanto uma parcela tão grande de internautas continuar utilizando um navegador antigo e sem padrões, a migração será muito difícil.

Muitas implementações do CSS 3 não estão previstas nem para versões mais novas do IE. Repare como o há falta de suporte a muitas implementações:

http://www.quirksmode.org/css/contents.html

A Web está deixando de suportar o IE6

O IE 6 já está quase no seu 10° ano de vida e alguns sites já não dão mais suporte, conscientes das dificuldades para manter produtos na web que funcionem no navegador, e do número de restrições que este traz para projetos de interface.

O Google, por exemplo, já tem há algum tempo feito campanhas para que os usuários de seus produtos atualizem seus browsers. E agora definitivamente a empresa deixará de dar suporte ao IE6, retirando inicialmente o suporte dos produtos Google Docs e Google Sites.

Deseja contribuir para a erradicação do IE6?

Aqui vão algumas iniciativas e campanhas contra o “grande vilão” das interfaces modernas:

http://www.ripie6.com/

http://www.ie6nomore.com/

http://dearie6.com/

A versão 1.4, lançada no dia 14 de Janeiro traz muitas novidades interessantes, além de aperfeiçoamentos que ainda precisavam ser feitos. Uma boa melhorada na performance dos scripts fazem essa versão ainda mais competitiva nos aspectos em que perdia para outros grandes frameworks do mercado (ver comparativo de performance entre os frameroks js) aqui ou aqui.

Muitos metodos comuns tiveram melhorias consideráveis de performance nesta nova versão, entre esses estão: css(), attr(), addClass(), removeClass(), hasClass(), html(), remove(), empty() … e muitos outros.

Em varios casos eles citam aumentos de desempenho que chegam superam em até 4x a implementação da versão anterior, muito dessa melhora se obteve atraves da refatoração do código.

As mudanças de performance dos scripts foram muito consideráveis, alguns métodos ganharam “poderes” que antes não tinham, vale a pena dar uma olhada no changelog para conferir métodos que ganharam novas possibilidades de assinaturas.

O único aspecto negativo que encontramos até agora foi o peso da nova versão, agora com 23 kb (Minified,GZIP), contra os 19kb(Minified, GZIP) da sua versão antecessora (v 1.3.2). Acreditamos ser até uma mudança razoável se analizarmos o número de implementações e re-escritas que foram feitos para a nova versão.

Vale destacar algumas das muitas novidades dessa versão. Aos poucos vamos listando mais métodos interessantes:

detach()

O método “detach” armazena o elemento selecionado em uma variável para uso posterior, e o remove da árvore DOM. Funciona de maneira similar ao já existente método “remove”, porém mantendo uma referência para ele sem destruir. Resumidamente ele “recorta(destaca)” um fragmento de html para ser utilizado em outro ponto do código.

Ex:

<span class="origem">

    <p>Item 1</p>

    <p>Item 2</p>

    <p>Item 3</p>

    <p>Item 4</p>

    <p>Item 5</p>

</span>

<span class="destino"></span>

<input type="button" value="Recortar" class="btnRetirar" />

<input type="button" value="Colar" class="btnAdicionar" />

<script src="jquery-1.4.js" type="text/javascript"></script>

<script type="text/javascript">

    $().ready(function() {

        var itens

        $(".origem p").click(function() {

            $(this).addClass("selecionado")

        })

        $(".btnRetirar").click(function() {

            itens = $(".origem .selecionado").detach();

       })

       $(".btnAdicionar").click(function() {

           itens.appendTo(".destino")

           itens = null

       })

    })

</script>

isPlainObject()

Verifica se o objeto foi criado utilizando “{}” ou “new Object”

Ex:

<div id="isPlainObject"></div>

<script src="jquery-1.4.js" type="text/javascript"></script>

<script type="text/javascript">

    $().ready(function() {

        obj1 = new Object

        obj2 = {}

        obj3 = {a:"asd", b:"asdfg"}

        obj4 = []

        obj5 = "asdfg"

        obj6 = function () {}

        $("#isPlainObject").html(

            "<p>jQuery.isPlainObject(new Object) -> " + jQuery.isPlainObject(obj1) + "</p>" +

            "<p>jQuery.isPlainObject({}) -> " + jQuery.isPlainObject(obj2) + "</p>" +

            '<p>jQuery.isPlainObject({a:"asd", b:"asdfg"}) -> ' + jQuery.isPlainObject(obj3) + "</p>" +

            "<p>jQuery.isPlainObject([]) -> " + jQuery.isPlainObject(obj4) + "</p>" +

            '<p>jQuery.isPlainObject("asdfg") -> ' + jQuery.isPlainObject(obj5) + "</p>" +

            "<p>jQuery.isPlainObject(function () {}) -> " + jQuery.isPlainObject(obj6) + "</p>"

        )

    })

</script>

isEmptyObject()

Verifica se o objeto está vazio

Ex:

<div id="isEmptyObject"></div>

<script src="jquery-1.4.js" type="text/javascript"></script>

<script type="text/javascript">

    $().ready(function() {

        obj1 = new Object

        obj2 = {}

        obj3 = {a:"asd", b:"asdfg"}

        obj4 = []

        obj5 = "asdfg"

        obj6 = function () {}

        $("#isEmptyObject").html(

            "<p>jQuery.isEmptyObject(new Object) -> " + jQuery.isEmptyObject(obj1) + "</p>" +

            "<p>jQuery.isEmptyObject({}) -> " + jQuery.isEmptyObject(obj2) + "</p>" +

            '<p>jQuery.isEmptyObject({a:"asd", b:"asdfg"}) -> ' + jQuery.isEmptyObject(obj3) + "</p>" +

            "<p>jQuery.isEmptyObject([]) -> " + jQuery.isEmptyObject(obj4) + "</p>" +

            '<p>jQuery.isEmptyObject("asdfg") -> ' + jQuery.isEmptyObject(obj5) + "</p>" +

            "<p>jQuery.isEmptyObject(function () {}) -> " + jQuery.isEmptyObject(obj6) + "</p>"

        )

    })

</script>

Para ver os exemplos em funcionamento, clique aqui

Referencias:

api.jquery.com

jquery14.com

Talvez pelo termo “Framework” estar tão associado à idéia de facilitar o desenvolvimento “back-end” do sistema, que a primeira vista podemos encarar um “Framework CSS” como alguma coisa que vai processar folhas de estilo do lado do servidor, que vai gerar CSS dinamicamente ou algo do tipo.

Se você (assim como eu), também teve essa percepção sobre o assunto antes de explorá-lo, pode ter ficado com uma impressão ruim a respeito dos frameworks CSS.

Não podemos dizer que é um erro de nomenclatura. A palavra “framework” significa “estrutura” e se encaixa perfeitamente no contexto, se observarmos o propósito dos frameworks. Mas talvez a primeira impressão que a palavra deixa seja um motivo para que essas ferramentas não sejam aproveitadas e respeitadas como merecem.

Veremos mais adiante que apesar das inúmeras diferenças, podemos fazer várias comparações entre um framerwork css com um framework de software. Falemos um pouco então sobre o que eles são e como eles podem nos ajudar muito no desenvolvimento.

O que é?

É uma biblioteca compatível com padrões web, cross-browser, otimizada, com estilos CSS básicos pré-definidos que resolvem a maioria das situações comuns de desenvolvimento das interfaces web na linguagem CSS. Em suma, é um ou mais arquivos *.css válido(s), pronto(s) para uso e homologado(s) na maioria dos navegadores do mercado.

Vantagens:

Aqui vão alguns bons motivos para aderir ou pelo menos explorar as possibilidades dos CSS frameworks.

Equipe de desenvolvimento

A grande maioria dos CSS frameworks é desenvolvida pela comunidade, pelos melhores especialistas no assunto. É muito luxo você poder contar com equipes assim pra resolver problemas estruturais para o seu projeto não é? rs

Cross-browser

As estruturas definidas pelos CSS frameworks são testadas na maioria dos navegadores do mercado. Quem utiliza, não precisa se preocupar com o que é oferecido pelo framework, porque já houve uma equipe preocupada em testar cada detalhe em todos os navegadores.

Agilidade

A principal vantagem que esperamos de qualquer framework: Agilidade. No mundo da internet isso é primordial, recursos de desenvolvimento são escassos, o trabalho é grande e as mudanças são constantes. Ganhar tempo para conseguir dar o máximo de qualidade naquilo que realmente precisa se feito é extremamente necessário.

Flexibilidade

Na maioria dos CSS Frameworks podemos escolher configurações que se adequem ao nosso projeto, sendo assim podemos fazer a escolha mais “econômica” se tratando de consumo de banda e peso de página, e que vai nos oferecer os recursos que necessitarmos para o projeto entre esses recursos estão:

• . Grid customizado,
• . Tipografia,
• . css-reset,
• . Folhas de estilo otimizadas por mídia (Impressão, Tela/Projetor).
• . Suporte para layouts fluídos
• . Templates com estruturas SEO-friendly

Padrão de Código

Com o tempo, os desenvolvedores vão se acostumar com o padrão estrutural das páginas e isso poderá facilitar muito o trabalho, não só do desenvolvedor como do webmaster. Mais um ganho enorme em agilidade de desenvolvimento e qualidade.

Suporte / Documentação

Eu ainda não conheço equipe que faça documentação da implementação de CSS, como estruturar ou utilizar cada classe, ID ou coisas assim. Utilizando um framework você e sua equipe “ganham de brinde”, na maioria dos casos, uma ótima documentação e guia de consulta.

Mitos / Paranóias

Talvez pra alguns seja melhor mais saber o que um CSS framework NÃO é antes mesmo de saber o que ele realmente é. Segue uma lista de falsidades sobre o assunto:

- O trabalho do Webmaster se torna dispensável com os CSS frameworks.

Não!!!! Assim como um framework de software, o framework não faz nada sozinho. Além do mais as decisões relacionadas a escolha de um bom framework, com a configuração ideal para o projeto também é responsabilidade do webmaster. Não há porque temerem pelos seus empregos (pelo menos não por isso )

- O framework gera código automaticamente

Também Não!!! Apesar de existirem algumas iniciativas para tornar o CSS dinâmico, processado server-side. <desabafo>Sou completamente avesso a essas tecnologias e ficarei assim até que me provem que realmente isso pode ser útil, e que compensa substituir um CSS bem escrito que não consome mais recursos de servidor)</desabafo>, Os CSS frameworks que tem como objetivo gerar código dinamicamente.

- O Webmaster vai “desaprender” como faz CSS usando framework

Mais uma bobagem! Assim como um desenvolvedor não esquece como se programa quando usa um framework de software, o webmaster também não esquece como se faz HTML/CSS usando um framework. Se alguém até aqui ainda acha que não precisa mais conhecer (bem) CSS por causa de um framework, por favor, reinicie a leitura, obrigado!

- CSS Frameworks são pesados

Mais um engano. A grande maioria deles são bem leves e geralmente oferecem uma versão “minified”, ou seja, compactada. Você certamente teria que desenvolver “na unha” aquelas linhas de código de qualquer forma e talvez nem escreveria tão otimizado quanto.

Desvantagens

Como nem tudo são flores e aqui não é uma Central de Vendas de frameworks, existem sim desvantagens ao se utilizar CSS frameworks que devem ser pesadas na hora da escolha:

Bugs herdados

Se por um acaso a versão que você tiver utilizando tenha algum bug esse poderá ser herdado pelos seus elementos, já que como o próprio nome da tecnologia diz: são estilos em cascata.

Excesso de código

Como qualquer framework, nós nunca utilizamos 100% dos recursos oferecidos em nossos projetos, isso faz com que algumas linhas de código estejam perdidas sem nunca serem utilizadas. Por isso, a escolha do framework e da configuração deve ser bem pensada antes de começar o projeto.

Lista de CSS frameworks

Existem muitas opções de frameworks no mercado. Uma rápida pesquisa na rede trará vários deles, alguns bem completos, outros nem tanto, mas cabe á equipe optar pelo que melhor atende e explorá-lo. A dica é que não variar muito entre frameworks para que não haja confusão no padrão de nomenclaturas de classes, estruturas etc, porque no fim das contas vai exisitir uma curva de aprendizado do framework em que os usuários vão ter que se adaptar. Também não precisamos tornar um framework como “a única salvação” como se fosse uma religião ou time de futebol (Isso acontece muito quando se trata de framework de software). É preciso estar sempre atento às outras boas alternativas que existem por aí.

Como qualquer framework, é importante que a decisão sobre o seu uso seja bem planejada na concepção do projeto. Pode ser uma experiência arriscada migrar ou até mesmo atualizar um framework, uma vez que ja existe toda uma estrutura “pendurada” nele. Fica a dica.

- Blueprint – http://www.blueprintcss.org/

- YUI Grids – http://developer.yahoo.com/yui/grids/

- YAML – http://www.yaml.de/en/

- Elastic – http://elasticss.com/

- 960 Grid System – http://960.gs/