Pedro Lamarão

Este texto é mais um “brain dump” da minha lembrança e dos meus pensamentos sobre a história das aplicações da Internet em geral e da Web em particular. Escrevi a partir da minha memória sem consultar referências, o que assegura que muitos erros factuais devem ter sido cometidos. Eu espero que essas lembranças e reflexões sejam úteis no debate do quê e do como em desenvolvimento com meus queridos M. e M. sobre a relação entre as nossas missões pessoais e a problemática atual das “redes sociais”.

As aplicações USENET permitiam a comunicação de um-para-muitos organizadas ao redor do conceito de usuário e grupo de notícias. Usuários poderiam obter uma listagem dos grupos disponíveis, solicitar as mensagens do grupo e enviar mensagens para o grupo. A criação de grupos era reservada para os administradores do sistema. A nomenclatura dos grupos obedecia uma estrutura hierárquica representando uma árvore de tópicos, do mais abrangente ao mais específico, permitindo a descoberta de grupos por tópico. Grupos e mensagens são duradouros no serviço. Os arquivos de décadas de mensagem da USENET foram adquiridos pelo Google e estão atualmente disponíveis no Google Groups. O design universal era uma árvore com os tópicos raiz permitindo o usuário seguir de nó em nó até descobrir os grupos do seu interesse. O usuário assinaria certos grupos para a aplicação obter as mensagens mais recentes. Um painel de grupos estaria ou na lateral ou no topo. Com foco em algum grupo, o painel central elástico exibiria a listagem de mensagens por um algoritmo híbrido entre ordem cronológica inversa e mensagens não lidas, de modo a tornar acessíveis as mensagens não lidas mais recentes. O design das aplicações da USENET e do correio eletrônico eram realmente muito similares e muito rapidamente ambas as aplicações se aglutinaram em ferramentas híbridas de correio e newgroups.

As aplicações IRC permitiam a comunicação de um-para-um e de um-para-muitos organizadas ao redor do conceito de usuário e canal. Usuários poderiam criar canais livremente, entrar e sair de canais, e descobrir canais a partir de catálogos de canais ativos (i.e. com alguém dentro). O design universal da aplicação era um painel lateral com a lista de “nicks” dos membros do canal e um painel central elástico com a lista de mensagens ocupando basicamente todo o espaço mais um controle de entrada de texto embaixo. A lista de mensagens montava-se por um algoritmo simples de ordem cronológica inversa: do mais recente ao mais antigo, com as mensagens antigas “transbordando” para fora da visão, acessíveis somente por mecanismo de paginação como “barra de rolagem”. O IRC não incluía nenhum mecanismo nativo de durabilidade, nem de perfis, nem de canais, nem de mensagens; sua operação nativa era focada no tempo presente. Soluções para durabilidade foram eventualmente introduzidas no sistema na forma de “bots” com poder de “super usuário” capazes de assegurar o controle de nomes de usuário, o controle de canais e às vezes um registro persistente das mensagens.

Não é preciso alongar sobre a Web. Seu conceito original era uma espécie de enciclopédia viva que permitisse uma pessoa debruçada sobre um artigo, ao identificar um tópico de interesse dentro do artigo, rapidamente seguir para o próximo tópico por virtude de uma estrutura de “hipertexto”, textos conectados por estruturas de “hyperlink”. A Web era portanto um meio de comunicação de um-para-muitos orientada a “mensagens” de longa duração participantes de uma enorme malha de mensagens hiperligadas entre si. A aplicação era e ainda é uma máquina de renderização de hipertexto. Não há mecanismo nativo nem de descoberta, nem mesmo de criação. A Web era um meio de transporte, um acordo informal de transportar hipertexto e aplicações de renderização de hipertexto, e nada mais.

A aplicação ICQ especializou a comunicação um-para-um. No ICQ original, haviam apenas os usuários e sua lista de contatos. A descoberta de contatos ocorria primariamente por fora do sistema, no mesmo sentido que ainda hoje se troca números de telefone. A lista de contatos cadastrados era persistente, como um caderno de endereços e telefones. Além da lista de contatos, as próprias mensagens possuíam um grau de durabilidade, de modo que a mensagem enviada hoje poderia ser lida amanhã. O design do ICQ usava janelas destacadas, com uma pequena lista de contatos a partir da qual se poderia abrir janelas de mensagem específica para cada usuário. Nas janelas de mensagens, encontrávamos a representação clássica de um painel central elástico com mensagens em ordem cronológica inversa e embaixo um controle simples de entrada de texto. Eventualmente, as capacidades de descoberta de contato por “email”, “número de telefone” e outros itens de identificação individual foram acrescentadas.

Por uma variedade de razões, um investimento desproporcional nas tecnologias da Web causaram as diferentes aplicações da Internet serem reproduzidas na forma de “aplicação Web”.

Arquivos somente leitura de grupos de discussão rapidamente encontraram representação na forma de hipertexto, tanto para newsgroups da USENET quanto para malas diretas do sistema de correio eletrônico.

Com a introdução de componentes de “formulário” ao hipertexto, a capacidade mínima necessária para “enviar” foi alcançada, e as diferentes aplicações de comunicação começaram a ser trazidas para dentro da web: web mail, web forum e web chats. As primerias aplicações se esforçavam para representar newsgroups, correio e chat em uma mídia e uma ferramenta ao mesmo tempo conveniente e inadequada.

Ferramentas como LiveJournal e Blogger viabilizavam publicar na web resolvendo para o usuário o desafio técnico de produzir os arquivos, armazená-los em algum lugar e serví-los por algum endereço. Nesse sentido, essas foram ferramentas de automação para a operação da infraestrutura. A parte crítica da aplicação era o editor de posts, que o hipertexto original não foi desenhado para representar. A função crítica do editor de posts era gerar o hipertexto para o usuário, com sua estrutura interna em HTML, a partir de uma representação acessível de “parágrafos” e “estilos” básicos como itálico e negrito, e possivelmente colocar uma imagem enfiada no meio do texto. Esses sistemas aproveitavam a durabilidade intríseca da Web como grande enciclopédia de hipertexto, mas, inicialmente, não ofereciam uma solução nativa para a descoberta de publicações.

Até hoje, representar um “rich text editor” em uma aplicação web é uma área de pesquisa e novos produtos ainda vem sendo criados no mercado de componentes de software.

Ferramentas como Flicker e Tumblr aplicaram o mesmo princípio de automação para a geração de web sites no conceito de álbum de fotos ou galeria de arte. A parte crítica da aplicação era o mecanismo de upload para o envio dos arquivos de imagem. A ausência do problema de renderização de texto facilitou a essas ferramentas a geração de web sites com layouts mais sofisticados, como os grids de imagens.

Ferramentas como SixDegrees e Friendster aplicaram o mesmo princípio para a geração de web sites no conceito de perfil de usuário. A parte crítica da aplicação era seu modelo de perfil, com coisas como nome, foto, residência, gostos pessoais etc. e o modo como essas coisas eram editadas. Pequenos itens de informação somente números e caracteres não exigiam resolver o problema de renderização de texto. As ferramentas de geração de perfil puderam experimentar livremente com o layout da informação gerada. Estas ferramentas, mais enfaticamente do que todas as outras, incluiam a lista de links para web sites de amigos e de interesses no seu modelo.

LinkedIn representa bem a experimentação com diferentes formatos de web site auto-gerados. Sua missão original era a criação de “curriculum vitae” e contatos profissinais, o que podemos considerar um caso extremamente particular de perfil de usuário.

Enquanto isso, os conceitos originais de chat, correio e forum encontraram seus caminhos na Web. Notavelmente, serviços como Slashdot e Reddit fizeram avançar os mecanismo da comunicação um-para-muitos preservando o design original da BBS e da USENET, do “quadro de anúncios” e do “grupo de discussão”. Apesar de esses dois exemplos, Slashdot e Reddit, serem bem diferentes, eles compartilham uma característica de inovação: ambos resolveram o problema da curadoria pela aplicação de um sistema de “mérito” baseado em “votação”. Slashdot se posicionava como uma forma de noticiário. Os usuários submetiam notícias e o serviço organizada visões em um formato aproximado ao de um serviço de notícias. Para resolver o problema da relevância, Slashdot se estruturava em tíeres, onde toda criação nova penetrava nos tieres de menor relevância. Usuários engajados leitores dos tieres menores “votavam” nas publicações. O serviço interpretava uma alta quantidade de “votos” como alta relevância, fazendo as notícias subirem no sistema tíeres. Assim, o tíer principal, representado na home page, era ocupado apenas pelas notícias mais “votadas”. Fórums do Reddit aplicam o mesmo princípio. Usuários interessados somente no sumário dos artigos e comentários mais importantes tem condição de “filtrar” o conteúdo por uma “relevância” calculada a partir dos votos positivos e negativos dos usuários. O próprio julga a “relevância” de web sites com base em um cálculo onde links para o web site significam “votos”, web sites mais linkados sendo considerados mais relevantes.

Diversos conceitos de web site deram origem a diferentes tipo de automação em um período de bastante experimentação de formato. Com a crescente facilidade de gerar e publicar web sites veio naturalmente uma crescente quantidade de publicações distintas e uma crescente quantidade de atualizações dentro de cada publicação. O problema original da descoberta de web sites se desdobrou gerando um problema particular da descoberta de quais web sites foram atualizados depois da sua última visita.

Cada uma dessas ferramentas deu a solução natural para estes dois problemas dentro do seu pequeno mundo. O Blogger, por exemplo, sabe muito sobre os blogs que hospeda, tanto sabe que eles existem, quais são suas meta características (por exemplo, um sistema de categorias) e quando eles foram atualizados. Sistemas internos de busca para descoberta por palavra-chave ou categoria resolveram internamente o problema da descoberta. Um pequeno editor de texto para uma única linha de texto com um botão “buscar” é suficiente. Embarcar aspectos do conceito de “correio” permitiu à ferramenta trazer para dentro de si a noção de “mensagem não lida” como solução para a comunicação de que um blog foi atualizado. Todo usuário tem uma caixa postal interna unidirecional para a qual o sistema pode enviar mensagens comunicando “notificações”.

Enquanto o problema da descoberta de web sites rapidamente alcançou a solução dos “motores de busca”, o problema da descoberta de atualizações não teve soluçãp bem sucedida. O mero fato da atualização até teve. A definição de formatos de metadados para web, e a aplicação desses formatos para soluções de “sindicância”, são até hoje utilizadas dentro de conceitos onde isso é suficiente. Esses formatos e técnicas são utilizados hoje com sucesso por podcasts para notificar podcast players sobre sua lista de episódios incluindo naturalmente a informação de episódios recentes. O sonho de produzir um leitor universal de conteúdo capaz de agregar todas as fontes de interesse do usuário em uma única visão, porém, não se realizou, por razões diversas. Entre elas, a heterogeneidade da informação dificulta sua renderização adequada, e um resultado desagradável é desmotivador tanto para o autor quanto para o leitor.

Ferramentas como MySpace e Facebook transformaram o conceito de “notificações” tornando-as de um objeto secundário auxiliar para uma característica central do serviço: ficar sabendo o que está acontecendo com os outros. Todo tipo de atualização se tornou objeto de notificação, a criação de um novo link de “amizade” com outra pessoa, mudança de endereço, formatura na escola, nascimento de um filho, um novo gosto musical. Iniciando com o conceito de gerador de perfil, ocuparam novos espaços dentro da nascente lógica de “rede social”, onde a informação em movimento são os eventos na vida das pessoas.

Twitter trouxe para o jogo um variante surpreendente que se provou extremamente bem sucedida. Aparentemente posicionado dentro do conceito de blog, constrangeu o objeto post a uma variante extremamente reduzida tanto em expressividade quando em comprimento. Com isso, obteve a capacidade de representar posts facilmente em uma visão de linha, desse modo transformando o próprio sistema de blog em uma imensa máquina de notificações. Tweets se provaram extremamente adequados para empurrar notificações arbitrárias para “seguidores”, servindo para todo tipo de ator social, como agências de notícias.

Os conceitos de microblogging e da agregação de objetos de todo tipo em linhas temporais alcançaram então a condição de conceitos universais, assim como os mecanismo de cálculo de relevância a partir de votos, ou “likes”. Hoje, nós entendemos uma “plataforma” como uma aplicação web capaz de gerar nossos perfis de usuário, de representar nossas ligações interpessois, de nos prover um hipertexto para o acesso direto a essas pessoas e coisas, de nos prover uma mídia onde possamos empurrar composições híbridas de texto e imagem com finalidade qualquer (argumentação, piadas, notícias diversas), e de nos prover uma visão ou acesso de todos esses objetos publicados por autores do nosso interesse mixados em uma visão linear fundamentalmente temporal, das “coisas recentes”.