Multiplexado

Até o ano de 2003, eu trabalhava um bocado com aplicações de Internet Rica. Desde aquela época, nossa equipe já comentava sobre certa ineficiência dos processos convencionais de arquitetura de informação e design para web quando aplicados em projetos de aplicações com interações mais ousadas.

Naquele tempo, recebíamos as interfaces já pré-concebidas, com um conjunto de wireframes e as telas desenhadas que deveriam dizer como a aplicação deveria funcionar. Ou pelo menos é isso que esses documentos tentavam dizer.

O fato é que as pessoas que construíam esses artefatos estavam acostumadas a projetar sites convencionais. A interação se resumia a transposição de um documento a outro. Era criticado o "teletransporte" entre as telas, como o Ricardo Figueira gostava de dizer pra gente, na época que ele era meu chefe.

O “Teletransporte” que ele falava era facílimo de representar em wireframes. Tentei escrever um exemplo bem bobo na figura a seguir, para dar uma idéia dos documentos que eu recebia para trabalhar, no papel de programador daquele tipo de software.

O fluxo normal de um sistema e seus fluxos alternativos acontecia sempre na navegação entre telas (ou documentos). O Wireframe era composto por um “passo-a-passo”, com o desenho do mouse clicando em botões e links, junto com textos “racionais” sobre o que estava acontecendo na tela.

No fim das contas, nada mais era que uma tentativa de representação linear de um negócio multidimensional. Uma mesma tela poderia estar inserida em diversos contextos, mas o Wireframe mostrava mesmo na prática apenas um ou dois deles.

Em termos de experiência de navegação para o usuário, praticamente toda a retroação ao usuário vinha depois de um “reload” bruto. E a coisa funcionou assim durante um bom tempo. As pessoas se acostumaram com isso. A metáfora do “documento” web que tinha ficado “dinâmico” acabou virando padrão, e ainda permanece em muitos sites, sistemas e cabeças até hoje.

A superação da metáfora do “documento” em aplicações de interface rica

Quando falamos de aplicação rica aqui nesse texto, pode ser em qualquer plataforma que permita a aplicação deste conceito. Se é Flash ou Ajax não importa tanto. O fato é que trabalhar com esse tipo de projeto adiciona um bocado de atividades não presentes no processo de desenvolvimento tradicional da web.

Uma aplicação bem projetada pode permitir que condensemos e simplifiquemos os passos das atividades dos usuários. Quando estamos livres da metáfora documental, não ficamos presos à recarga das telas para fazer alguma coisa. Recuperamos a capacidade de alternar dinamicamente as informações de uma interface. Não faz muito sentido projetar isso da mesma forma que se projeta um site ou sistema web tradicional.

A estrutura rígida de documento na metáfora antiga começa a desaparecer quando os elementos na tela passam a não se comportarem tão linearmente. As possibilidades de interação passaram a ser semelhantes ao que acontecia na arquitetura cliente-servidor lá de antigamente. Os componentes podem ter mais estados. A comunicação pode acontecer a qualquer momento, sob a demanda da interação ou em resposta a algum evento interno do sistema.

Sobre a maturação do Ajax e Flash para programar isso, o que eu acredito de coração é estamos passando da época da “farofada tecnicista” sobre o assunto. Independente da plataforma do projeto, o nosso foco de atenção é que as pessoas estão se acostumando com os benefícios de poder usar interfaces mais inteligentes em qualquer plataforma. Junto com isso, cresce também a curva de rejeição das pessoas a produtos baseados em modelos ultrapassados de interação.

Linkando com o usabilimundo

Alguns dos últimos posts do Fred tratam desse problema, talvez num enfoque mais acadêmico e profundo. Van Amstel afirma que a metodologia tradicional do Design Centrado no Usuário não é suficiente para os novos desafios que os projetos da chamada Web 2.0 traziam. E eu concordo com ele.

Não pretendo chegar a um nível processual como o Fred, mas uma coisa que estou procurando por meses a fio é um artefato alternativo ao Wireframe para a prototipação de aplicações mais inteligentes e complexas, resolvendo uma faceta mais prática do desafio maior que é melhorar tudo no futuro.

Características desse tal artefato que procuramos:

• Capacidade de planejar projetos interativos mais ousados e complexos, com uso de prototipação em PAPEL e de leitura inteligível e eficiente.
• Capacidade de descrever todos os elementos que compõem uma interface rica, bem como o modelo de eventos que esses elementos possuem (visão ANALÍTICA da interface).
• Capacidade de descrever a relação existente entre os componentes da interface e como eles se comportam quando aplicados em conjunto nos contextos de operação possíveis (visão SINTÉTICA da interface).
• Capacidade de gerar projetos ricos de maneira independente da plataforma que for escolhida para o desenvolvimento.

Enquanto isso, na sala de justiça...

Estou trabalhando junto com meus amigos Wellington Saamrim e Ignácio Mouras na busca de soluções caseiras para esse problema. A primeira abordagem foi a construção de “máquinas de estado” para componentes, numa espécie de Wireframe turbinado e não baseado em “telas”, mas sim em componentes. É sobre isso que pretendo escrever mais adiante no site.

Se alguém tiver algum material bom sobre esse assunto, por favor, me envie. De repente a gente fica perdendo tempo viajando enquanto podem já existir coisas boas para poder aprender, usar e compartilhar.

Ah, vale lembrar o puxão de orelha que recebi do Caparica, por não ter terminado a série sobre Wireframes que estou escrevendo aqui no site. Capa, valeu pelo toque! Vou tocar esse negócio logo! =) Agora que já estou com um pouco mais de prática na troca de fraldas do meu filhote, ganho um pouco mais de tempo para atualizar o site.

Obrigado a todos que chegaram até aqui. Até breve!