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.

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

Padronização para elementos comuns em sites

Qual a vantagem real disso? Um desenvolvedor esperto perceberá que, usando ou criando os devidos plugins, a extração e conversão de dados para qualquer formato em uma página é muito mais fácil. Um exemplo interessante disso é o hCard, que permite puxar e exportar dados cadastrais ou eventos em um formato reconhecível por qualquer gerenciador de e-mails  (seja online, seja um outlook da vida).  Num futuro pode-se até pensar em browsers que já venham com funções nativas voltadas que use este tipo de recurso, valendo-se de APIs como o Google Maps ou o Yahoo Maps, por exemplo.

E claro, como toda padronização, ela auxilia na usabilidade,  pois facilita a vida de vários “interpretadores” (screen readers, browsers, aplicativo Air, etc) na forma de usar a informação fornecida.

Melhora na qualidade para indexadores de busca

Não encontramos dados do quanto de relevância os buscadores estão a dar para os microformats, embora tanto o Google quanto Yahoo já tenham anunciado suporte. De qualquer forma, o fato dos algorítimos de busca interpretarem qualquer coisa como texto (mesmo que sejam tags), já indica que os microformatos por si só são “alimentadores de relevância” por natureza.

Um exemplo que pode ser visto é este:  quando realizamos uma esta busca no Google, um dos resultados apresentados (o terceiro, logo abaixo do título) já possui quantidade total de reviews a respeito do estabelecimento procurado.  Isto é possível graças ao hReview que, como o proprio nome sugere, serve para destacar uma opinião sobre um produto, serviço ou quaquer outra coisa.

Humanamente “entendível”

Ao contrário de outros formatos de proposta similar, os microformats tem como conceito ser primeiro compreensível por seres humanos e somente depois por máquinas.  A sintaxe é muito mais intuitiva, mais simples de compreender e memorizar. Acredito que essa é de longe sua principal vantagem sobre o RDFa, por exemplo, que não só é um código mais complexo como ainda por cima possui uma série de padrões diferenciados. Outra vantagem sobre RDFa é que os microformatos permitem ao desenvolvedor a escrever BEM menos código, mantendo uma sintaxe simples, limpa e totalmente intelígivel para qualquer outra pessoa que mexa no código depois – mesmo que não familiarizada com estas definições (no futuro pretendemos entrar novamente no assunto RDFa x microformatos, agora não é o momento).

Aplicável ao HTML 5, XHTML 2

As próximas versões de HTML e XHTML tem, entre outras propostas, aplicar para a web do futuro o conceito de Web Semântica (aquela história de que toda informação deve ser um ‘pacote completo’ de dados e referências, manja?), o que vai suprir parte da necessidades propostas pelos Microformats. Embora muita gente já esteja usando estas definições, a web ainda não está pronta para lidar com eles – Por que não usar os microformatos, que não impactarão em absolutamente nada na codificação e já são aceitos e usados? Ele não conflitará em absolutamente nada com HTML 5 ou XHTML 2 e, de lambuja, ainda ajudará os buscadores a indexar e classificar seu site de forma bastante precisa.

Problemas com microformats

Em 2008 a BBC renunciou ao uso dos microformatos por conta do formato hCalendar. Este formato cria um problema de acessibilidade por usar a tag abbr como marcador e não como uma abreviação propriamente, o que confunde boa parte dos screen readers. Num contexto normal, ela seria usada assim:

<abbr title="Organização Mundial de Saúde">O.M.S</abbr>

Um screen reader habilitado para ler siglas por extenso leria este trecho como “Organização Mundial de Saúde”.

No caso do hCalendar, a tag é usada da seguinte forma:

<abbr title="20070312T1700-06">March 12, 2007 at 5 PM</abbr>

O screen reader não leria como data,  mas sim  “Vinte milhões, sete mil e trezentos e 12 TÊ mil e setecentos traço zero seis”.  Já existe um fix para isso sugerido pela própria Microformats.org (que são os pais da criança), usar span no lugar de abbr.

Até onde testamos e pesquisamos este foi a única problema registrado. Usamos o FANGs para emular a acessibilidade para deficientes visuais.

Mas é só isso?

Por enquanto sim. O assunto é extenso demais para ser tratado num único post – num futuro não muito distante voltaremos a ele e nos aprofundaremos em pontos mais específicos. Enquanto isso não ocorre, a lista abaixo fornece uma bela gama de coisas para brincar. Divirta-se!

Microformatos – Referências

http://microformats.org – site oficial do projeto. Todas referências, exemplos, geradores automáticos, wiki e lista de discussão estão lá.

http://en.wikipedia.org/wiki/Microformat – tópico na wikipédia, a informação técnica resumida.

https://addons.mozilla.org/pt-BR/firefox/addon/4106 – Operator, ADD-on do firefox que detecta e importa dados de microformatos. Tem alguns problemas ainda, mas já dá uma bela visão de usos.

https://addons.mozilla.org/pt-BR/firefox/addon/402 – FANGS: um emulador de screen reader. Infelizmente, após a atualização do Firefox para a versão 3.5 ele perde a compatibilidade. Espero que resolvam logo este problema, estava usando-o para uma pesquisa de acessibilidade.

http://www.semanticfocus.com/blog/entry/title/microformats-vs-rdf-how-microformats-relate-to-the-semantic-web/ – Artigo que aprofunda-se um pouco na discussão a respeito do formato RDFa vs Microformats.

http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snippets.html – mostra a implementação feita pelo google para o formato hReview

http://www.google.com/search?q=Drooling+Dog+BarBQ – Link para a busca com o resultado do google.