Não há dúvidas que a Internet, através da Web, é um sucesso como meio de comunicação. Tanto seu número de usuários como a quantidade de informações que ela integra tendem a continuar crescendo "assustadoramente" nos próximos anos. No entanto, existe uma grande preocupação no que diz respeito à qualidade da interação usuário/Web e usuário/usuário através da Web [Nielsen 99]. Se não houver significativos avanços neste sentido, a Web poderá se tornar um "gigantesco cemitério de informações" [Gershon 96].

Esta seção introduz a questão, mostrando alguns resultados do campo de IHC (Interação Homem-Computador), que estuda a relação homem/máquina desde muito antes do surgimento da Web (Seção 1.1). A Seção 1.2 analisa as razões que têm levado os desenvolvedores de software a se interessarem por aplicações na Web, e as limitações da mesma como meio de interação.

1.1. Interação Homem-Computador (IHC)

A interação entre um usuário e um programa se dá através da interface com o usuário (UI - User Interface). Os pesquisadores de IHC determinam a "qualidade" da interface (e, conseqüentemente, da interação) através do conceito de "usabilidade", definido como uma combinação dos seguintes fatores [Shneiderman 92]: facilidade de aprendizado, alta velocidade para a execução de tarefas, baixa taxa de erro no uso, satisfação subjetiva do usuário e retenção da forma de uso com o tempo.

Para garantir a eficiência da interação, o projeto de UIs requer o conhecimento não só da tecnologia apropriada, mas também de fatores humanos (conhecimento do usuário e seu comportamento, das tarefas que ele executará, das tarefas que a máquina executará, dentre outros fatores). Uma diretriz básica para o desenvolvimento de interfaces é realizar o projeto centrado no usuário [Hix 93]: o projetista deve procurar fazer sempre o que for melhor para o usuário, mesmo que isso seja mais difícil para ele (o projetista).

O estudo da IHC envolve profissionais de várias áreas (engenharia de software, ciência comportamental, lingüística, ergonomia, psicologia cognitiva, etc) e seus resultados certamente serão de grande importância para a "sobrevivência" da Web no futuro, pois mostrarão as diretrizes a serem seguidas para garantir uma eficiente interação com a Web [Nielsen 99].

Não é objetivo deste trabalho se aprofundar no estudo da IHC. Uma boa introdução ao tema pode ser encontrada nesta mesma publicação [Souza 99].

1.2. A Web como meio de interação

A explosão de popularidade da Internet através da Web, aliada às tecnologias que permitem maior dinamismo e flexibilidade de interação com a Web (por exemplo, CGI, ECMAScript e Java, que serão vistas na Seção 2) têm levado muitos pesquisadores e desenvolvedores a utilizarem-na como meio de interação com as aplicações [Horowitz 98], [Ibrahim 97], [Rice 96].

As grandes vantagens em se desenvolver aplicações disponibilizadas via Web estão associadas à fácil acessibilidade: as aplicações ficam disponíveis a uma cada vez mais ampla gama de usuários da Web e elas podem ser acessadas de praticamente qualquer lugar (de casa, do trabalho, ou mesmo em trânsito, através da computação móvel). Somada a estas vantagens, ainda existe a independência de plataforma das aplicações Web.

No entanto, as tecnologias básicas da Web (HTTP e HTML) ainda impõem algumas limitações no que diz respeito à interação com as aplicações. Dentre estas limitações, destacam-se:

• Falta de controle sobre a aparência da interface. A linguagem HTML deixa este tipo de decisão a cargo dos browsers. Browsers diferentes podem gerar UIs com disposições diferentes dos widgets (elementos da interface) [Ibrahim 97], [Rice 96].
• Dificuldade na construção de UIs independentes de plataforma. A aplicação pode ser executada em máquinas e conexões com desempenhos completamente diferentes, variando desde PCs com conexões dial-up a sofisticadas estações de trabalho com conexões ATM. Os requisitos para a construção de UIs são bastante diferentes nestes casos extremos. A solução seria separar o conteúdo da apresentação, sendo esta última otimizada de acordo com a plataforma utilizada [Nielsen 99].
• O protocolo HTTP não suporta o conceito de sessão. Cada acesso ao servidor é feito de maneira independente, não guardando nenhuma informação sobre acessos anteriores. Isto dificulta o desenvolvimento de aplicações que exigem a manutenção de estado entre os sucessivos acessos ao servidor (por exemplo, aplicações de comércio eletrônico, que precisam guardar os dados do cliente e o que ele coloca no "carrinho de compras"). Atualmente já estão sendo realizados esforços para a criação do HTTP-NG (HTTP Next Generation) [Nielsen 98], que será um protocolo mais simples, flexível e poderoso para a troca de informações na Internet.
• Lentidão de realimentação (feedback). Geralmente, a interface Web só muda de estado após a conexão com o servidor e a realização do processamento necessário. Esse processo demora bem mais do que o usuário está acostumado em interfaces fora da Web.
• A aplicação não tem como interromper a atividade do browser para alguma comunicação assíncrona. A comunicação na Web é sempre iniciada pelo cliente, não havendo suporte para a comunicação iniciada pelo servidor, nem para a comunicação cliente/cliente ou servidor/servidor [Rice 96]. Isso dificulta a implementação de aplicações que exigem comunicação ponto-a-ponto ou um papel mais ativo do servidor [Bentley 97].
• A arquitetura não provê suporte direto para a replicação da informação, o que é necessário para o trabalho desconectado, para a rápida realimentação e para a confiabilidade do sistema [Bentley 97].
• O HTTP não garante taxa de transmissão mínima, tornando a Web pouco adequada para meios contínuos, tais como áudio e vídeo (importantes para UIs mais sofisticadas).

2. Ferramentas

Esta seção mostra como a Web evoluiu de um meio estático (HTML puro) para um meio onde é possível a transmissão de aplicações embutidas nas páginas (applets Java). O objetivo é mostrar o estado atual da Web, enfatizando suas limitações no que diz respeito à criação de interfaces com usuários.

2.1. HTML (HyperText Markup Language)

A linguagem HTML [HTML 98] é uma das tecnologias que formam a base de sustentação da Web. Ela é basicamente um padrão para a apresentação de hipertexto, com recursos razoáveis de estruturação do texto, com inclusão de imagens e multimídia, além da criação de âncoras que fazem a interligação entre documentos relacionados.

A HTML também possui um conjunto de widgets. No entanto, este conjunto é bastante limitado, restrito basicamente a botões, checkboxes, listas de seleção, caixas para entrada de texto e imagens mapeadas. Além disso, não há como ter um controle maior sobre a aparência da interface, pois isso fica a cargo dos browsers; esse é o preço pago pela independência de plataforma.

Além destas limitações da HTML, há uma série de características dos browsers que dificultam a implementação de interfaces mais sofisticadas na Web [Rice 96]:

• O servidor só é contactado ao selecionar uma âncora ou um botão do tipo "submit". O servidor não recebe informações sobre as atividades intermediárias de interação, tais como a digitação de texto em um formulário, a seleção de uma checkbox, etc. Isso impossibilita a criação de interfaces com realimentação imediata.
• Qualquer alteração na página exige que ela seja inteiramente retransmitida. Não há como fazer uma atualização incremental de apenas parte da página.
• Os browsers armazenam as últimas páginas visitadas em memória cache. Isso permite que o usuário volte para páginas anteriores. No entanto, em aplicações interativas, estas páginas armazenadas em cache podem representar estados anteriores do diálogo com o usuário. Como o estado dos dados no servidor já pode ter mudado, a interação com páginas anteriores pode resultar em transações incoerentes.

XML (Extensible Markup Language) [XML 98] é uma metalinguagem para a criação de novas linguagens de marcação (markup). Uma linguagem de marcação define a maneira de descrever a informação em uma certa classe de documentos. A HTML, por exemplo, é uma linguagem de marcação que define a estrutura de documentos hipertexto. Na prática, a XML permite que seja definido um novo conjunto de rótulos (tags), adequado à classe de documentos que se deseja representar. Por exemplo, um documento de informações médicas poderia conter um rótulo <alergias>, que imediatamente permitiria ao browser alertar a equipe médica sobre possíveis riscos no tratamento [Bosak 97]. A HTML, por ter um conjunto restrito de rótulos, não permite este tipo de extensão.

É importante ressaltar que a XML não é uma versão estendida da HTML, mas sim uma versão simplificada da SGML (Standard Generalized Markup Language), a "metalinguagem-mãe" para a descrição de novas linguagens de marcação. A XML pretende não só remover da Web a inflexibilidade da HTML, mas também a complexidade da SGML, com a qual é muito difícil de se trabalhar.

Ainda existe muita discussão sobre a relação XML e HTML, e se as vantagens que a XML traz compensam a dificuldade adicional de se criar novas sintaxes e browsers capazes de entendê-las. No entanto, o que já está claro, é que a XML não resolve os problemas de interação da HTML anteriormente citados, pois ela só atua na estruturação, e não na apresentação dos documentos (browsers diferentes continuarão a apresentar os documentos de maneiras diferentes, por exemplo).

Já está sendo elaborada também uma proposta de extensão da HTML 4.0: a DHTML (Dynamic HTML). A DHTML pretende criar páginas muito mais interativas do que as atuais. Com a DHTML será possível, por exemplo, alterar a cor de elementos da interface quando o cursor passar sobre eles, permitir que os usuários mudem a posição de imagens na página, e muitas outras coisas que só eram possíveis por meio de applets Java. Uma das idéias centrais da DHTML é a utilização de CSS (cascading style sheets), cuja sintaxe define elementos cuja posição, estilo e aparência podem ser alterados depois que a página é carregada no cliente. O uso de CSS implementa a tão esperada separação entre conteúdo/estrutura e apresentação de uma página Web. De maneira similar, a XML também propõe a utilização de style sheets através da XSL (Extensible Stylesheet Language) [XSL 99]. No entanto, a falta de acordo entre Microsoft e Netscape tem dificultado a padronização destas tecnologias [Phillips 98].

2.2. CGI (Common Gateway Interface)

O CGI [CGI 96] representou um grande avanço no que diz respeito à interação na Web, pois por meio dele é possível interagir com um servidor de informações capaz de gerar páginas dinamicamente como resposta às ações dos usuários.

O CGI é um padrão que permite que programas externos se comuniquem com os servidores de informação Web. Na prática, ao invés de acessar um documento HTML no servidor, o cliente aciona um programa do servidor que realiza algum tipo de processamento e retorna um HTML criado dinamicamente. A Fig. 1 ilustra a diferença entre uma interação direta com o documento HTML e outra utilizando um programa CGI.

O CGI estabelece as regras para a troca de dados entre o servidor Web e o programa externo. Desde que siga essas regras, o programa pode ser escrito em qualquer linguagem de programação que seja capaz de ler valores de variáveis de ambiente e de escrever para a saída padrão. Um exemplo de programa CGI escrito em Perl é visto a seguir [CGI 97] (neste trabalho os exemplos de código têm as linhas numeradas para efeito didático, eles não são numerados na realidade):

    1 #!/usr/bin/perl
    2
    3 $t = "Hello World!";
    4 print <<EOT
    5 Content-type: text/html
    6
    7 <TITLE>$t</TITLE>
    8 <H1>$t</H1>
    9 EOT

A linha 1 do programa anterior identifica o interpretador Perl. A linha 3 define uma variável e a linha 4 estabelece que o programa deve escrever na saída padrão tudo o que vier a seguir, até encontrar "EOT". O que for escrito na saída padrão será enviado ao servidor Web e depois ao cliente. A linha 5 escreve o cabeçalho do protocolo HTTP. Este cabeçalho, seguido de uma linha em branco, deve ser escrito por qualquer programa CGI. A partir da linha 7, o programa escreve o HTML que será visto no browser do cliente. Para poder executar este programa a partir de uma página HTML, ela deve ter uma âncora como a mostrada a seguir:

<a href="programa.cgi">Programa CGI<a>

Programas CGI são muito utilizados em associação com formulários HTML. Desse modo, os dados do formulário preenchido pelo usuário são enviados ao servidor e servem como parâmetros de entrada do programa, que retorna uma página criada em função dos dados do usuário. É assim que funcionam as consultas às bases de dados via Web. O usuário entra com as palavras-chave, que são enviadas ao programa CGI. O programa então realiza a pesquisa e monta uma página HTML com os resultados, página esta que é lida pelo browser do usuário.

O CGI, embora tenha dado um caráter dinâmico à interação na Web e seja adequado para aplicações altamente dependentes do servidor, apresenta sérias limitações para a construção de UIs eficientes. A mais grave delas é a incapacidade de processamento no lado do cliente. Isso causa uma lentidão de realimentação, pois a interface só é alterada após o contato com o servidor e a obtenção do resultado do processamento realizado. Além disso, não há como fazer uma verificação no cliente para garantir que um formulário esteja preenchido corretamente. É sempre necessário enviar os dados para o servidor, onde o programa CGI faz esta verificação e envia mensagens de erro, se for o caso. Esta é uma das limitações superadas pelo ECMAScript.

2.3. ECMAScript

O ECMAScript [ECMA 98] surgiu como complemento/alternativa importante ao CGI, pois com ele é possível realizar algum processamento do lado do cliente Web. Isso favoreceu o desenvolvimento de UIs para aplicações na Web, pois tornou possível dar ao usuário alguma realimentação sem necessariamente se conectar ao servidor.

Na verdade, ECMAScript é uma tentativa de padronização de um conjunto de tecnologias semelhantes de diferentes fabricantes, cujas mais conhecidas são o JavaScript (Netscape) e o JScript (Microsoft). O ECMAScript é definido como "uma linguagem de programação orientada a objetos para realizar processamentos e manipular objetos computacionais dentro de um ambiente hospedeiro" [ECMA 98]. No caso da Web, o "ambiente hospedeiro" é o browser, que deve ser capaz de reconhecer o programa ECMAScript embutido em uma página HTML e realizar o processamento por ele determinado. Para se ter uma idéia do funcionamento de um script, considere o seguinte fragmento de uma página HTML, usado para escrever a data corrente:

    1 <SCRIPT>
    2 now = new Date();
    3 d = now.getDate();
    4 m = now.getMonth() + 1;
    5 y = now.getYear();
    6 document.write("<H3>"+ d +"/"+ m +"/"+ y + "</H3>");
    7 </SCRIPT>

O browser (se for capaz de interpretar scripts), ao encontrar o rótulo <SCRIPT>, entende que o que vem a seguir é um programa que ele deverá interpretar. No exemplo anterior, a linha 2 cria uma variável com a data atual, enquanto as linhas de 3 a 5 criam variáveis com o dia, mês e ano, respectivamente. A linha 6 escreve o trecho HTML "<H3> dd/mm/yy </H3>", onde dd, mm e yy são, respectivamente, dia, mês e ano atuais. Esta é uma maneira de escrever uma página com conteúdo variável, sem necessidade de contato com o servidor, como obriga o CGI.

Uma importante utilidade do ECMAScript é a possibilidade de fazer uma verificação no cliente antes de submeter um formulário HTML ao servidor. No caso de um campo que peça o número de cartão de crédito, por exemplo, um script pode ser usado para verificar se o usuário escreveu o número correto de dígitos, e se há apenas caracteres numéricos escritos. Em caso de erro, a realimentação é imediata, pois não há a necessidade de contato com o servidor.

A combinação CGI/ECMAScript, apesar de representar um significativo avanço, não resolve todos os problemas relacionados à interação na Web. Isso porque o ECMAScript é uma linguagem com funcionalidade limitada. Segundo sua própria definição, ela foi criada para "manipular, customizar e automatizar as facilidades de um sistema já existente" [ECMA 98], não sendo seu objetivo ser uma linguagem auto-suficiente. Ela não possui, por exemplo, recursos para leitura de dados externos e nem recursos para a criação de UIs. Estas limitações são superadas pelos applets Java, que trouxeram para a Web toda a funcionalidade de uma linguagem de programação abrangente, como será visto na próxima seção.

2.4. Java

Esta seção discute a linguagem Java, que é o padrão "de facto" para aplicações na Web. São mostradas algumas funcionalidades desta linguagem, enfatizando aquelas que estão diretamente relacionadas ao desenvolvimento de UIs.

2.4.1. Introdução

Java é uma linguagem de programação de alto nível desenvolvida pela Sun Microsystems, Inc., que se tornou muito popular para a construção de páginas altamente interativas na Web. Isso é feito através dos applets, que são programas Java transmitidos junto com as páginas HTML e executados no computador do cliente (ver Seção 2.4.2).

Independentemente dos applets, Java é uma linguagem de programação orientada a objetos de propósito geral (semelhante a C++) e projetada para ser simples. Todos os recursos considerados desnecessários foram propositalmente deixados de fora da linguagem. Java não possui, por exemplo, apontadores, estruturas, vetores multi-dimensionais e conversão implícita de tipos. Também não há necessidade de gerenciamento de memória em Java, pois ela tem um programa interno (o garbage collector) que automaticamente libera partes ocupadas da memória que não terão mais uso.

Outra característica essencial de Java é ser independente de plataforma. O código-fonte de um programa Java é pré-compilado em bytecodes, que são conjuntos de instruções semelhantes ao código de máquina, mas sem serem específicos de qualquer plataforma. As instruções em bytecodes são verificadas na máquina local antes de serem executadas, garantindo a segurança da linguagem. Os bytecodes podem ser interpretados por Máquinas Virtuais Java (JVMs - Java Virtual Machines) instaladas em qualquer plataforma, sem necessidade de recompilação do programa. Praticamente todos os browsers já incorporam a JVM em sua implementação. Há um esforço em andamento para incorporar a JVM a diversos sistemas operacionais - Microsoft, IBM, Apple, e HP, além da própria Sun, são algumas das empresas que licenciaram a plataforma base de Java com o fim de embuti-la em seus sistemas operacionais.

2.4.2. Applets

Java pode ser usada tanto para o desenvolvimento de programas independentes quanto para o de applets, que são executados dentro de um "ambiente hospedeiro" (o browser). Os applets são tratados pelo browser como qualquer outro tipo de objeto da página HTML, como uma imagem ou um vídeo: ele é transmitido do servidor para o cliente, onde é executado e visualizado dentro do browser.

No arquivo HTML, o applet é incluído por meio do rótulo <APPLET>, como mostrado a seguir:

1. <APPLET code="MeuApplet.class" width=200 height=150>
2. <param name=NomedoParam value="ZZZ">
3. </APPLET>

Ao encontrar as linhas acima o browser cria um espaço gráfico de 200 pixels de largura por 150 pixels de altura na página apresentada, transfere o código do applet do mesmo local de onde a página se originou para a máquina local, e executa o applet dentro deste espaço.

Para ilustrar a utilização dos applets para a construção de UIs, considere o código do applet UmBotao.class mostrado a seguir. Este applet não tem parâmetros e possui apenas um botão. Sempre que o botão é pressionado uma mensagem é exibida na linha de status do browser. Na primeira vez, uma mensagem pré-determinada - Botão foi pressionado - é exibida. Na segunda vez, a string exibida depende da definição da string ActionCommand associada ao botão - por default, o rótulo do botão. As duas mensagens se alternam cada vez que o botão é pressionado.

       1 // UmBotao.java
       2 import java.awt.*;
       3 import java.awt.event.*;
       4 import java.applet.*;
       5
       6 public class UmBotao extends Applet {
       7 /** Cria a UI. */
       8 public void init() {
       9 // define dimensões
       10 setSize(100,100);
       11
       12 // coloca o botão
       13 UmBotaoHandler boh = new UmBotaoHandler(this);
       14 Button bPush = new Button("Enter");
       15 add(bPush);
       16 bPush.addActionListener(boh);
       17 }
       18 }
       19
       20 /** Classe "handler", para lidar com botões.*/
       21 class UmBotaoHandler implements ActionListener {
       22 Applet app;
       23 int number = 0;
       24
       25 public UmBotaoHandler(Applet a) {
       26 app = a;
       27 }
       28
       29 /** Realiza a operação.*/
       30 public void actionPerformed(ActionEvent e) {
       31 if (number%2 == 0)
       32 app.showStatus("Botao foi pressionado");
       33 else
       34 app.showStatus(e.getActionCommand());
       35 ++number;
       36 }
       37 }

As linhas 2, 3 e 4 do exemplo indicam as APIs (Application Programming Interfaces) que devem ser incluídas no programa. Nesse caso, são a java.applet (que trata dos applets), a java.awt (com facilidades para a criação de interfaces gráficas) e a java.awt.event (responsável pelo modelo de eventos usado em Java). A linha 6 inicia a classe, cujo nome é UmBotao e é uma subclasse de Applet. A linha 8 define o método init, executado por ocasião da inicialização do applet. A linha 13 define a classe UmBotaoHandler, que lidará com os eventos gerados pelo botão. As linhas 14 a 16 adicionam o botão à interface e o ligam ao objeto que lidará com os eventos (boh). A linha 21 inicia a classe UmBotaoHandler, que implementa uma interface do tipo ActionListener. As linhas 25 a 27 definem o construtor desta classe e a linha 30 inicia o método que realmente realizará a operação desejada (actionPerformed). A Fig. 2 mostra o applet descrito no exemplo.
 
 

Apesar de oferecerem à Web a possibilidade de construir UIs utilizando toda a funcionalidade de uma linguagem de programação abrangente, os applets ainda têm uma série de limitações (essas limitações variam um pouco, de acordo com a implementação de cada browser):

• Os applets podem ser extensos e levar muito tempo para serem transmitidos até o cliente.
• As facilidades para a construção de UIs gráficas eram bastante limitadas nas versões iniciais da linguagem. Hoje em dia, os Java Beans e o Swing permitiram grandes avanços nesse sentido (ver Seção 2.4.4).
• Por serem programas que vêm de um servidor remoto (nem sempre confiável), os browsers precisam implementar uma série de restrições de segurança que acabam criando dificuldades para o desenvolvimento de aplicações interativas [Campione 97]:
• Um applet não pode ler nem escrever arquivos no cliente.
• Não pode iniciar nenhum programa no cliente.
• Não pode ler certas propriedades do sistema.
• Não pode se conectar com outra máquina que não a sua própria servidora.
• Qualquer janela janela aberta por um applet é diferente das janelas abertas por outras aplicações (geralmente está destacado na janela que ela foi aberta por ação de um applet).

2.4.3. Servlets

Apesar do surgimento dos applets, que permitem executar programas Web no cliente, o processamento de programas no servidor (CGI) continuou muito popular por pelo menos três motivos:

1. É totalmente independente do browser, uma vez que todo o processamento é realizado no servidor.
2. Tarefas complexas podem ser executadas de maneira mais eficiente no servidor (geralmente uma máquina mais potente que o cliente).
3. É mais seguro, pois os programas são executados sob o controle direto do administrador do servidor.

Na prática, os servlets fazem o mesmo que programas CGI: recebem dados do cliente, realizam o processamento necessário e retornam um arquivo HTML criado dinamicamente. No entanto, a combinação applets/servlets pode ir muito além disso, balanceando a carga de processamento entre cliente e servidor, e permitindo melhor desempenho das aplicações Web.

2.4.4. Java Beans

Os Java Beans [Beans 99] representam a implementação Java do conceito de componentes de software. Os componentes de software estão para a tecnologia de software assim como os circuitos integrados estão para a eletrônica: são "caixas-pretas" que encapsulam a funcionalidade e oferecem serviços de acordo com uma especificação [Johnson 97]. Eles também devem possuir uma certa capacidade de customização sem a necessidade de alterar seu código. Os componentes de software são projetados para serem reutilizados, permitindo a "montagem" de aplicações a partir da "conexão" de vários componentes.

Os componentes de software, assim como as classes das linguagens orientadas a objetos, escondem a implementação, encapsulam dados e são modulares. Na verdade, praticamente todos os componentes de software são classes de linguagens orientadas a objetos. O que os torna componentes é o fato de seguirem uma especificação de componentes de software [Johnson 97]. No caso da linguagem Java, a especificação de Java Beans [Beans 99] descreve o que uma classe deve fazer para se tornar um componente (um bean). Java Beans, portanto, não é um produto, ou um ambiente de desenvolvimento, mas um conjunto composto de um pacote de funcionalidades (java.beans) e um documento (a especificação) que descreve como utilizar os recursos do pacote para a implementação de componentes de software (que também são chamados de beans).

Com relação à interação, os beans permitem maior dinamismo e flexibilidade, pois os desenvolvedores podem definir componentes independentes que podem ser utilizados e reutilizados em uma variedade de combinações para comporem novos applets e aplicações independentes. Os beans podem ser widgets gráficos, funções não-visuais, applets, e até mesmo aplicações completas, podendo ser construídos por desenvolvedores diferentes e integrados de forma confiável para a "montagem" de uma aplicação completa.

A interação entre os componentes se dá através da geração de eventos. O modelo de eventos de Java Beans usa event listeners, que são elementos que monitoram a ocorrência de um evento desejado e controlam a troca de mensagens entre o bean gerador e o bean interessado no evento (este modelo foi utilizado no exemplo da Seção 2.4.2 - classe UmBotaoHandler). A presença dos event listeners dá flexibilidade ao modelo, pois se um bean enviasse um evento diretamente para o outro, estes componentes ficariam "ligados" entre si, criando uma dependência que tiraria sua capacidade de plug-and-play [Sridharan 97]. A Fig. 3 ilustra a diferença entre o modelo de eventos enviados diretamente ao componente interessado e o modelo usando listeners.
 
 

Figura 3: (a) Modelo de eventos enviados diretamente aos componentes interessados. No caso do automóvel, o freio envia o evento "frear" ao pneu e a bateria, o evento "ligar" ao farol. (b) Uso dos listeners, que entram como intermediários entre o gerador e o receptor do evento. A vantagem deste modelo é manter a capacidade plug-and-play dos componentes: no exemplo, o airbag também pode ser colocado como receptor do evento "frear", sem que para isso o código do freio precise ser alterado.

A tecnologia de Java Beans permitiu o surgimento de uma nova biblioteca de componentes gráficos para a criação de UIs: o Swing [Swing 99]. O Swing representou um grande avanço na construção de interfaces em Java, pois:

• Os componentes Swing são beans, permitindo toda a flexibilidade e capacidade de reutilização desta tecnologia.
• Os componentes são totalmente desenvolvidos em Java, não usando nenhuma implementação dependente de plataforma, ao contrário da java.awt.
• Swing tem componentes com pluggable look & feel, permitindo dar a eles a aparência e o comportamento desejados (por exemplo, eles podem ter a aparência dos widgets do Windows, do Motif, do Macintosh, etc).
• Há compatibilidade com hardware e software projetados para usuários com necessidades especiais, tais como deficientes visuais e pessoas incapazes de utilizar o mouse (por exemplo, há facilidades para o desenvolvimento de interfaces touch-screen).

2.4.5. Java 2D e Java 3D

Como complemento ao Swing, a API Java 2D [Java_2D 98] estende os mecanismos da java.awt para a manipulação e visualização de primitivas bidimensionais, textos, fontes, imagens e cores, trazendo benefícios para a criação de UIs mais sofisticadas.

Com a API Java 2D é possível desenhar formas padrões (retângulo, círculo, etc) e formas arbitrárias (curvas de Bezier, por exemplo), realizar transformações espaciais sobre elas (rotações e translações), preenchê-las com padrões complexos (gradientes, por exemplo), e utilizar transparência na sobreposição de imagens. Estes mesmos recursos também podem ser usados para manipulação de textos.

A correspondente tridimensional da Java 2D é a Java 3D [Java_3D 98], com recursos para a criação e manipulação de geometrias tridimensionais e ferramentas para a construção de estruturas usadas na renderização destas geometrias. A Java 3D tem funcionalidade similar à VRML (ver Seção 4.2.1), embora também introduza alguns conceitos que normalmente não são considerados como partes integrantes de um ambiente gráfico tridimensional, como é o caso do som espacial.

Ao contrário da Java 2D, a Java 3D não faz parte das APIs do núcleo da linguagem Java, precisando ser instalada separadamente. Além disso, a Java 3D tem algum código nativo (i.e., código não-Java, dependente de plataforma) em sua implementação, o que pode complicar o desenvolvimento de UIs, especialmente quando se usa o Swing, que é totalmente independente de plataforma.

Estas duas APIs (principalmente a Java 3D) representam um esforço da plataforma Java em direção às chamadas interfaces pós-WIMP, que são vistas na Seção 4.

2.4.6. JSDT (Java Shared Data Toolkit )

Até aqui, este trabalho tratou do que poderia ser chamado de "o estado atual da interação na Web", pois foram estudadas tecnologias já "amadurecidas" e bastante utilizadas. A partir da próxima seção, o trabalho se concentrará em duas tendências importantes na interação com a Web: aplicações colaborativas (Seção 3) e interfaces pós-WIMP (Seção 4). Como já comentado, a API Java 3D representa um esforço em direção às interfaces pós-WIMP. O JSDT, por sua vez, é o esforço da plataforma Java na direção do suporte às aplicações colaborativas.

O JSDT [JSDT 98] implementa um serviço de envio de dados para vários receptores, para uso no suporte à criação de aplicações multimídia colaborativas altamente interativas. Ele provê o conceito de sessão (i.e., um grupo de objetos associados a um padrão de comunicação comum) e permite comunicação multiponto bidirecional (full-duplex) entre um número arbitrário de entidades conectadas através de diferentes tipos de redes. Além disso, o JSDT provê um eficiente suporte para a comunicação de mensagens multicast, a habilidade de garantir o recebimento seqüencial de mensagens, e um mecanismo de sincronização baseado na passagem de token.

Os recursos implementados pelo JSDT são muito importantes para o desenvolvimento de aplicações colaborativas, que são o assunto da próxima seção.

3. Aplicações colaborativas

A Web com sua estrutura hipertexto oferece a ilusão de ser uma grande base de informações. No entanto, ainda existem barreiras significativas à colaboração efetiva entre os usuários. Apesar da informação ser um recurso compartilhado, os Web browsers ainda são ferramentas para um único usuário, mantendo os usuários separados uns dos outros, já que oferecem pouco suporte para que um grupo de usuários trabalhe de maneira colaborativa sobre a informação compartilhada. As aplicações colaborativas visam remover estas últimas barreiras, permitindo que os usuários se contactem, discutam os documentos e interajam com seus monitores em tempo-real (Fig. 4).
 
 

Figura 4: (a) Web hoje em dia: informação é compartilhada, mas ainda existem barreiras para a efetiva colaboração sobre essa informação. (b) Web colaborativa: usuários interagem entre si e com o objeto de trabalho em tempo-real (adaptado de [Greenberg 97]).

A idéia de aplicações colaborativas altera radicalmente os paradigmas tradicionais para a construção de UIs e para o compartilhamento de informações. Mesmo as aplicações de banco de dados compartilhados são projetadas para que cada usuário trabalhe independentemente dos demais, sem nenhum apoio para que os usuários se comuniquem ou troquem informações. Isso é exatamente o oposto do que pregam as aplicações colaborativas.

Esta seção estuda diversos aspectos de aplicações colaborativas. A Seção 3.1 mostra as dificuldades adicionais que aparecem quando se deseja construir UIs multiusuário (UIs utilizadas ao mesmo tempo por mais de um usuário em máquinas distintas). A Seção 3.2 introduz o conceito de CSCW, uma área que estuda como os recursos computacionais podem ser utilizados para dar apoio às atividades colaborativas. A Seção 3.3 apresenta alguns exemplos de aplicações colaborativas desenvolvidas para a Web.

3.1. Dificuldades de interfaces multiusuário

Ao se projetar uma interface multiusuário, além das dificuldades "convencionais" de UIs monousuário (conhecimento do usuário e das tarefas que ele pretende executar, definição do diálogo homem-máquina, testes de usabilidade, etc), aparecem novas dificuldades inerentes ao próprio trabalho em grupo. No âmago destas dificuldades adicionais está o conceito de percepção ou consciência dos outros usuários (user awareness). A percepção envolve saber quem está usando o sistema, o que eles estão fazendo (alterações ocorrendo no objeto de trabalho) e como estas alterações aconteceram (o que, junto com a comunicação e o conhecimento do contexto, permitem entender porque elas aconteceram) [Dix 97]. Esse conceito, como comentado anteriormente, altera radicalmente os paradigmas tradicionais para o projeto de UIs, pois UIs monousuário são projetadas para que os usuários não tomem conhecimento dos demais usuários que possam estar compartilhando uma mesma base de informações, por exemplo.

A primeira questão associada à percepção dos usuários diz respeito à visualização da aplicação compartilhada. Uma possibilidade é usar interfaces WYSIWIS (What You See Is What I See) [Stefik 87], em que todos os usuários compartilham a mesma visão da interface. A grande vantagem do WYSIWIS é ser de simples implementação e fornecer um forte senso de contexto compartilhado (por exemplo, é possível se referir a algo pela sua posição na tela). No entanto, interfaces WYSIWIS são inflexíveis e apresentam uma série de incovenientes, entre os quais: não permitem que usuários tenham espaço de trabalho privativo; a tela pode ficar tumultuada com janelas que só estão sendo usadas por outros usuários; os cursores dos outros usuários (telepointers) atrapalham o trabalho. Visando uma maior flexibilidade e também a superação dos incovenientes citados, o WYSIWIS pode ser relaxado em várias dimensões. O relaxamento no espaço aplica o WYSIWIS apenas para alguns objetos visíveis (por exemplo, janelas e cursores). O relaxamento no tempo permite atrasos na sincronização entre os usuários. O relaxamento na população permite que apenas um subgrupo de usuários compartilhe a mesma visão. O relaxamento na congruência permite que usuários alterem sua visão local da aplicação sem que os outros sejam afetados (o usuário pode minimizar janelas que não lhe interessam, por exemplo).

As interfaces WYSIWIS mostraram que a representação dos telepointers tendem a distrair o usuário, atrapalhando seu trabalho. Como alternativa para indicar onde outros usuários estão trabalhando e o que eles estão fazendo, podem ser usadas barras de rolagem multiusuário, radares ou miniaturas [Greenberg 99]. Barras de rolagem multiusuário são um conjunto de barras de rolagem, cada uma representando a posição de um usuário no documento compartilhado. Através da barra de rolagem multiusuário pode-se "seguir" um usuário, "colando" sua barra de rolagem à dele. Radar é uma visão geral em miniatura do documento sobreposta por áreas coloridas que indicam o ponto de vista de cada usuário. Miniaturas são espécies de ícones que mostram a visão de cada usuário.

Um outro aspecto ainda relacionado à percepção dos usuários é o feedthrough, que é a alteração da interface em resposta à interação dos outros usuários. O feedthrough se torna um problema especialmente crítico na Web, pois exige um canal de comunicação entre os vários usuários (clientes) [Dix 97]. As soluções encontradas lidam com a granularidade do feedthrough: nem todas as ações dos usuários precisam ser passadas aos demais, apenas as ações finais (por exemplo, quando se move um objeto para outra posição, os usuários remotos só precisam receber a posição final do mesmo).

No extremo oposto à percepção dos usuários está a questão da privacidade e do anonimato. A privacidade é importante para que os usuários possam, por exemplo, escrever rascunhos e anotações antes de mostrar algo para os demais usuários. A falta de um espaço de trabalho privativo pode inibir a participação de usuários em um trabalho colaborativo. Aliada à questão da privacidade, está a questão do anonimato. O anonimato é conflitante com a efetiva percepção dos usuários, que exige o conhecimento dos participantes. No entanto, o anonimato é necessário em situações de tomada de decisões (votação, por exemplo), especialmente quando há divergências de interesse no grupo. Em resumo, a "visibilidade" dos usuários deve ser limitada, de modo que as atividades individuais não sejam superexpostas aos demais [Bannon 91].

Independentemente das dificuldades associadas à percepção dos usuários, há uma série de outras que precisam ser tratadas em UIs multiusuário:

• Controle de acesso: muitas vezes pode não fazer sentido permitir que vários usuários tenham acesso a um mesmo widget simultaneamente. Por exemplo, apenas um usuário deve ser capaz de manipular uma barra de rolagem em uma interface WYSIWIS, para evitar "batalhas de rolagem" [Greenberg 99].
• Gerenciamento de sessão: é necessária a figura do gerente, para criar uma nova sessão de trabalho e controlar os direitos de acesso dos participantes (assim evita-se que participantes não cooperativos atrapalhem o andamento do trabalho, especialmente em sistemas abertos como a Web).
• Canais de comunicação: a atividade colaborativa está intimamente associada à comunicação entre os participantes. Portanto, aplicações colaborativas devem prover canais de comunicação eficientes.
• Obstrução por recursos de colaboração: é comum em aplicações colaborativas que recursos de colaboração pouco usados obstruam na UI os recursos mais utilizados [Grudin 94a]. Isso ocorre, por exemplo, em ferramentas de autoria colaborativa, onde recursos para suporte de anotações, tratamento de versões e visualização dos usuários acabam dificultando o processo de escrita individual. Este problema acontece porque os projetistas tendem a superestimar a importância e freqüência do uso dos recursos colaborativos, ignorando que a maior parte do tempo de trabalho de co-autoria é gasto no trabalho de escrita individual.
• Dificuldade de avaliação: é relativamente simples levar um usuário para um laboratório e, em algumas horas, testar a usabilidade de um software monousuário. Entretanto, captar em laboratório a dinâmica social, econômica, motivacional e política dos grupos é praticamente impossível. A avaliação de ferramentas colaborativas requer metodologias da psicologia social e antropologia, já que os usuários são afetadas pela experiência e personalidade dos outros membros do grupo de trabalho [Grudin 88].

CSCW é uma área de estudo interessada no trabalho em conjunto de grupos de pessoas com a ajuda de computadores. É um tema multidisciplinar que envolve profissionais das áreas de computação, automação, antropologia, sociologia, psicologia social, economia, teoria organizacional, educação, e de outras áreas interessadas no estudo do trabalho colaborativo. Talvez por essa razão, sempre houve muita discussão na definição do escopo de CSCW e muita confusão com termos afins, tais como groupware, workgroup computing e group support systems.

Hoje em dia já está clara a diferença entre CSCW e groupware. Groupware é uma área mais técnica, voltada para o desenvolvimento de software que auxilie no trabalho em grupo, enquanto CSCW leva em consideração os fatores humanos do trabalho em grupo para auxiliar o projeto e especificação do suporte computacional a este processo [Wilson 94]. Uma definição bem aceita para o termo groupware o considera como sendo "sistemas computacionais que auxiliam grupos de pessoas engajadas em uma tarefa (ou objetivo) comum e que provêem uma interface para um ambiente compartilhado" [Ellis 91]. Com relação ao CSCW, uma das definições mais conhecidas diz que "CSCW deve ser entendido como um esforço no sentido de entender a natureza e as características do trabalho cooperativo com o objetivo de projetar tecnologias computacionais adequadas" [Bannon 91]. Ainda segundo os mesmos autores, "o foco é entender para melhor auxiliar o trabalho cooperativo".

Um ponto importante que precisa ficar claro quando se fala em trabalho colaborativo é a noção de interdependência nas tarefas. Esta noção serve para diferenciar colaboração de outros tipos de tarefas em grupo, como a interação, por exemplo. Considere a diferença entre dirigir em um comboio e dirigir no trânsito de uma cidade [Grosz 96]. No primeiro caso, os motoristas têm algum sistema de comunicação pré-estabelecido e um objetivo comum que depende do sucesso dos outros motoristas nas suas tarefas (todos os carros do comboio devem chegar ao destino; se algum precisar de ajuda, os outros certamente o socorrerão). Isso caracteriza uma colaboração. Por outro lado, ao dirigir no trânsito de uma cidade não há colaboração, há apenas interação entre os motoristas, pois não há nenhum planejamento prévio das tarefas e o sucesso de cada motorista em atingir seu objetivo não depende do sucesso dos demais motoristas.

Outra característica do trabalho colaborativo é a dependência positiva que um participante tem do outro. Em outras palavras, um participante precisa que o trabalho do outro seja bem sucedido. O caso oposto é quando várias pessoas simplesmente compartilham um recurso. Nesta situação, é preciso haver uma certa coordenação entre as tarefas, mas o trabalho de um apenas atrapalha o trabalho dos outros [Schmidt 92].

Apesar da interdependência positiva entre as tarefas, ela nem sempre é harmoniosa. É preciso haver coordenação entre as atividades para garantir a eficiência da colaboração. Sem coordenação, há o risco dos participantes se envolverem em tarefas conflitantes ou repetitivas. Coordenação é definida como "ato de gerenciar interdependências entre as atividades realizadas para se atingir um objetivo" [Malone 90]. Coordenação é uma das partes constituintes do trabalho de articulação, que é parte integrante do trabalho colaborativo. O trabalho de articulação é o trabalho extra, necessário para que o trabalho conjunto seja obtido a partir da soma dos trabalhos individuais. A Fig. 5 ilustra esta relação. O trabalho de articulação é definido como "conjunto de atividades necessárias para gerenciar a natureza distribuída do trabalho cooperativo" [Schmidt 92]. Fazem parte do trabalho de articulação a identificação dos objetivos, o mapeamento dos objetivos em tarefas, a seleção dos participantes, a distribuição de tarefas entre eles, além da coordenação propriamente dita.

CSCW, pela sua própria multidisciplinaridade, é um tema bastante amplo, que levanta discussões muito interessantes. No entanto, para não fugir do escopo deste trabalho, apenas dois aspectos de CSCW serão analisados mais detalhadamente, pois interessam diretamente ao desenvolvimento de aplicações colaborativas na Web: as taxonomias para a classificação de sistemas colaborativos (Seção 3.2.1) e os requisitos necessários às aplicações colaborativas (Seção 3.2.2).
 
 

3.2.1. Taxonomias

A taxonomia mais utilizada na classificação de sistemas colaborativos leva em consideração dois fatores: o modo de interação e a distribuição geográfica dos usuários [Ellis 91], [Fluckiger 95]. Com relação ao modo de interação, sistemas colaborativos podem ser síncronos (interações ocorrendo em tempo real) ou assíncronos (interações ocorrendo em momentos diferentes). Quanto à localização geográfica dos usuários, um sistema pode ser presencial (usuários presentes fisicamente no mesmo local) ou não-presencial (usuários em locais diferentes). Com base nesta taxonomia, é possível construir uma matriz 2x2 para a classificação de sistemas colaborativos (Fig. 6).

Como mostra a figura, nem sempre é possível enquadrar as aplicações em apenas uma classe. Há exemplos como os espaços de trabalho compartilhados que não dependem da localização geográfica dos usuários; eles são simplesmente ferramentas síncronas. O mesmo é válido para algumas ferramentas de co-autoria (editores multiusuários), que são simplesmente assíncronas.

Devido a esta inadequação da taxonomia para a classificação de alguns sistemas, vários autores propuseram extensões para a mesma. É possível, por exemplo, subdividir as aplicações não-presenciais em virtualmente presenciais, localmente remotas e remotas [Rodden 91]. As virtualmente presenciais são semelhantes às presenciais, apenas não exigindo que os participantes estejam fisicamente próximos. Para isso, as aplicações deste tipo necessitam comunicação de áudio e vídeo em tempo real para "simular" a presença dos participantes externos. As aplicações localmente remotas não simulam a presença dos participantes externos, mas permitem um bom nível de interação com eles, através do compartilhamento de espaços de trabalho, por exemplo. As aplicações remotas são apenas aquelas que não oferecem nenhum "sentimento de presença", como o e-mail, por exemplo.
 
 

Outra possível extensão da taxonomia apresentada é subdividir as aplicações não-presenciais e as assíncronas em duas categorias: previsíveis e não-previsíveis [Grudin 94b]. Aplicações não-presenciais previsíveis permitem uma certa noção dos locais onde se encontram os demais participantes (e-mail e ferramentas de co-autoria são exemplos), as não-previsíveis interagem com usuários em locais não conhecidos (mensagens enviadas para grupo de discussão, por exemplo). De maneira similar, as atividades assíncronas previsíveis restringem ou pelo menos oferecem uma noção do tempo em que ocorrerá a interação (ao enviar e-mail para um colega, por exemplo, é possível prever com certa segurança quando ele será respondido). As assíncronas não-previsíveis acontecem em tempos dificilmente conhecidos a priori (autoria colaborativa em ambientes abertos, por exemplo).

Além da classificação espaço-temporal, os sistemas colaborativos também podem ser divididos em quatro categorias, de acordo com o tipo de aplicação [Wilson 94]: comunicação, espaço de trabalho compartilhado, informações compartilhadas e suporte à atividade em grupo.

As aplicações para comunicação são os exemplos mais conhecidos de groupware. Em geral, sistemas de comunicação não provêem nenhum tipo de suporte especial para o trabalho em grupo. Nesta categoria se enquadram ferramentas de e-mail, chats e video-conferência.

As aplicações de espaço de trabalho compartilhado provêem uma área de trabalho comum, onde dois ou mais participantes podem trabalhar conjuntamente. Exemplos de ferramentas nesta categoria são os whiteboards compartilhados e os editores multiusuários (nos quais vários usuários têm acesso a um documento sendo editado, e podem estar simultaneamente alterando partes diferentes dele).

Aplicações para compartilhamento de informações permitem que duas ou mais pessoas armazenem, acessem e manipulem informação compartilhada. Bancos de dados compartilhados são exemplos deste tipo de ferramenta. Sob esta óptica, a Web pode ser vista como ferramenta colaborativa, pois permite que as pessoas compartilhem informação (embora ela não suporte formas mais colaborativas de lidar com esta informação, tais como co-autoria e anotações) [Dix 97].

As aplicações para o suporte à atividade em grupo provêem facilidades para atividades específicas do trabalho em grupo, tais como agendamento de reuniões, brainstorming, auxílio na tomada de decisões, argumentação, votação, etc. Este tipo de ferramenta, também conhecido como GSS (Group Support System), tem como objetivo aumentar a produtividade de reuniões, seja acelerando o processo de tomar decisões ou melhorando a qualidade das decisões resultantes [Ellis 91].

Estas quatro categorias não são mutuamente exclusivas. Um grande número de sistemas possui ferramentas em mais de uma das categorias acima. Um sistema para reuniões, por exemplo, pode possuir recursos de video-conferência (comunicação) aliados a uma área de trabalho compartilhada, onde todos os participantes podem fazer alterações em documentos [Wilson 94].

3.2.2. Requisitos

Esta seção apresenta uma proposta informal para a análise de aplicações colaborativas baseada em um apanhado geral de requisitos encontrados na literatura. Esta proposta, juntamente com as taxonomias da seção anterior, servirão para a análise das ferramentas apresentadas na Seção 3.3.

O primeiro aspecto analisado é a comunicação, que é parte essencial da colaboração. Sua importância pode ser verificada nas taxonomias apresentadas na seção anterior, pois comunicação estabelece a dimensão temporal dos sistemas (comunicação síncrona ou assíncrona) e também define uma classe de aplicações na segunda taxonomia apresentada. A comunicação também é o núcleo do trabalho de articulação das atividades colaborativas.

O desafio que CSCW apresenta às tecnologias de comunicação é como tornar a comunicação entre usuários remotos tão eficiente quanto a interação face a face [Ellis 91]. Na verdade, sabe-se que a tecnologia não substitui a interação face a face, mas apresenta meios alternativos de comunicação, que podem ser mais apropriados em certas situações. O desafio é aplicar as combinações tecnológicas mais adequadas para cada tipo de interação (i.e., saber quais meios de comunicação são mais adequados para cada tipo de trabalho colaborativo).

Um tipo de comunicação durante muito tempo negligenciado nas pesquisas de groupware foi a comunicação informal. Hoje em dia, os pesquisadores reconhecem a importância deste tipo de comunicação em um ambiente de trabalho. Este tipo de comunicação "acidental" ocorre quando, por exemplo, dois colegas se encontram no corredor e discutem um tópico de interesse comum, ou quando um grupo se reúne informalmente para o coffe break e conversa sobre algum assunto relacionado ao trabalho. Ao contrário da comunicação informal, a comunicação formal segue um modelo de conversação pré-estabelecido, que pode ser representado por alguma ferramenta formal (redes de Petri, teorias lingüísticas, etc). No entanto, é sabido que nem os padrões de comunicação e nem a estrutura dos grupos são estáveis no decorrer de um trabalho colaborativo, o que torna estes modelos de conversação bastante limitados e de pouco "realismo social" [Kling 91]. Por esta razão, tem sido cada vez mais comum o desenvolvimento de sistemas oferecendo oportunidades para a realização de encontros informais à distância, tanto para a comunicação entre indivíduos quanto para a comunicação entre grupos.

Além da diferenciação entre comunicação formal e informal, também é possível classificá-la em comunicação direta e interação indireta. A comunicação direta (ou explícita) se dá através da transmissão de texto, gestos, vídeo e/ou áudio entre os participantes (é o que se chama normalmente de comunicação). A interação indireta (ou implícita) se dá através do objeto de trabalho (por exemplo, um texto ou imagem compartilhados) [Reinhard 94].

A discussão dos parágrafos anteriores enfocou a necessidade de flexibilidade para o modelo de comunicação utilizado no trabalho colaborativo. Generalizando esta idéia, a flexibilidade de uma aplicação colaborativa pode ser analisada do ponto de vista técnico, funcional, do campo de aplicação e também do ponto de vista social. Flexibilidade técnica está relacionada à portabilidade e capacidade de adaptação do sistema nos diversos ambientes computacionais. Uma aplicação é considerada flexível tecnicamente se permitir que o trabalho colaborativo seja realizado em diferentes plataformas de hardware, sistemas operacionais, interfaces gráficas, com vários formatos de áudio e vídeo e diferentes dispositivos de entrada e saída [Reinhard 94]. Flexibilidade funcional está relacionada à classificação espaço-temporal apresentada na seção anterior. Um sistema que se enquadre nas várias categorias daquela taxonomia e permita o "chaveamento" entre os vários modos de interação e localização geográfica dos usuários é mais flexível no aspecto funcional. Flexibilidade do ponto de vista do campo de aplicação está relacionada à outra taxonomia; um sistema que suporte mais tipos de aplicações (de comunicação, de espaço de trabalho compartilhado, etc) é mais flexível sob este aspecto.

A flexibilidade do ponto de vista social é bem mais complexa, tendo sido tema de vários trabalhos que tentam alertar os projetistas de sistemas colaborativos sobre as características dinâmicas e pouco previsíveis do trabalho em grupo [Kling 91], [Schmidt 91]. A primeira dificuldade na modelagem do trabalho em grupo diz respeito às ações "localizadas". Cada participante, em certas circunstâncias, poderá se encontrar em situação única, desconhecida dos demais participantes e terá de lidar com ela individualmente (por exemplo, em caso de documentos perdidos, dados incompletos, quebra de equipamento, etc). Para lidar com estas contingências locais, o participante muitas vezes se vê obrigado a violar o critério global, já que nenhum critério se aplica a todas as contingências [Schmidt 91]. Nestas situações, cada participante lidará com o problema segundo suas próprias heurísticas, que podem ser diferentes para cada um. Outro aspecto ainda mais importante diz respeito à consideração das diferenças de interesse, poder e status dentro de um grupo. É muito comum encontrar na literatura teorias e sistemas colaborativos que adotam uma visão utópica do trabalho em grupo, considerando apenas os aspectos positivos da colaboração e ignorando conflitos, competições, coersões, etc [Kling 91]. A flexibilidade do ponto de vista social exige que a aplicação leve em consideração estes fatores.

Em resumo, para serem flexíveis, aplicações colaborativas não devem impor padrões de trabalho (ou comunicação) pré-estabelecidos. Na verdade, elas devem prover facilidades que permitam aos usuários interpretar e explorar estes modelos formais, mas deverá sempre caber ao usuário a decisão de usá-los, modificá-los ou rejeitá-los [Schmidt 91].

Um último aspecto da análise de aplicações colaborativas diz respeito à implementação. Com relação à arquitetura utilizada, os sistemas podem ser hard-wired, centralizados, replicados ou híbridos [Peng 93]. Na configuração hard-wired, os componentes da rede são construídos com o propósito de realizar funções específicas do sistema. Um exemplo seria um espaço de trabalho compartilhado totalmente baseado em vídeo; as câmeras, monitores e projetores seriam interconectados para a geração, transmissão e projeção das imagens dos participantes e de seus trabalhos. A configuração centralizada segue o modelo cliente-servidor, onde todos os participantes só podem se comunicar com o servidor central, que realiza o processamento necessário e retransmite as mensagens. Dentre as vantagens da configuração centralizada estão sua relativa simplicidade de implementação, facilidade para garantir consistência no estado da aplicação (existe apenas uma cópia executando no servidor), além de permitir clientes mais simples e evitar os complexos algoritmos distribuídos [Shirmohammadi 98]. A configuração replicada ou distribuída executa uma cópia da aplicação em cada máquina. As vantagens desta configuração incluem a geração de menos tráfego na rede, já que as mensagens não precisam passar pelo servidor, e uma maior escalabilidade do sistema (o servidor se sobrecarregaria acima de um determinado número de clientes). Tentando unir as vantagens destas duas últimas configurações, surgiu a configuração híbrida. Nesta configuração, cada cliente executa uma cópia (completa ou parcial) da aplicação e há também a presença de um servidor central, responsável por tarefas como a garantia de consistência entre os clientes, sincronização e tratamento de colisão de eventos (por exemplo, dois usuários querendo editar a mesma parte de um documento).

Aplicações colaborativas também podem ser implementadas como conscientes da colaboração ou com colaboração transparente. As conscientes da colaboração são aquelas desenvolvidas especialmente para o trabalho colaborativo e têm conhecimento do número de usuários e seus papéis individuais na colaboração [Reinhard 94]. As de colaboração transparente são aplicações originalmente desenvolvidas para um único usuário, usadas de maneira colaborativa através de um sistema de compartilhamento de aplicações. São chamadas de colaboração transparente porque, embora múltiplos usuários possam interagir e compartilhar visões da aplicação, elas não têm "conhecimento" de que estão sendo usadas por mais de um usuário (o suporte à colaboração é feito externamente à aplicação).

3.3. Exemplos

Esta seção analisa algumas aplicações colaborativas para a Web, utilizando as taxonomias e os requisitos levantados nas seções anteriores. Foram escolhidas aplicações para a Web que fossem atuais, bem documentadas e com alguma repercussão nas publicações mais importantes da área.

3.3.1. GroupWeb

O GroupWeb é um browser que permite a um grupo de usuários compartilhar visualmente e navegar conjuntamente através de páginas HTML em tempo real [Greenberg 96], [Greenberg 97]. Ele foi desenvolvido pelo Departamento de Ciência da Computação da Universidade de Calgary, Canadá.

Como qualquer Web browser, o GroupWeb é capaz de visualizar páginas HTML. No entanto, usuários geograficamente dispersos podem realizar sessões de trabalho onde suas janelas principais se tornam espaço de trabalho compartilhado. Além da janela do browser, uma sessão GroupWeb oferece uma janela de gerenciamento (onde são indicados os nomes dos participantes da sessão) e uma janela de anotações (que serve também para a comunicação textual - chat - entre os participantes). Portanto, o GroupWeb se enquadra nas categorias de ferramenta de comunicação síncrona não-presencial (chat), espaço de trabalho compartilhado síncrono não-presencial (anotações na página Web) e compartilhamento de informações não-presencial tanto síncrono (navegação conjunta) quanto assíncrono (browser convencional). A Fig. 7 ilustra esta classificação.
 
 

No que diz respeito à percepção dos usuários, o GroupWeb usa telepointers (i.e., os ponteiros do mouse de todos os demais são visualizados pelo usuário) e barras de rolagem coloridas, indicando em que posição do texto se encontram os demais usuários. A visualização segue um esquema WYSIWIS relaxado, permitindo que cada usuário tenha sua janela de tamanho diferente. É também possível uma navegação individual pelo documento ou uma navegação sincronizada com algum outro usuário. A implementação usa a arquitetura replicada, pois cada usuário tem sua própria cópia do GroupWeb, que se comunica diretamente com as outras.

3.3.2. BSCW (Basic Support for Cooperative Work)

O BSCW é uma ferramenta desenvolvida pelo GMD FIT (Institute for Applied Information Technology, German National Research Centre for Computer Science) [Bentley 97], [Marock 98]. Uma de suas metas principais é ser acessível a partir dos browsers convencionais, sem a necessidade de instalação de nenhuma ferramenta adicional nos clientes. Para isso, são usados servidores Web convencionais, estendidos com o sistema BSCW através de scripts CGI (implementação centralizada, consciente da colaboração).

O BSCW estende a capacidade da Web com recursos sofisticados de armazenagem de documentos, gerenciamento de versões, administração de membros e de grupos, edição colaborativa e conferências textuais. O sistema é baseado na noção de espaço de trabalho estabelecido por membros do grupo para coordenar e organizar o trabalho. Um espaço de trabalho pode conter vários tipos de objetos, tais como documentos, imagens e links para outras páginas. Estes objetos estão organizados em hierarquias de pastas. Membros de um determinado grupo podem colocar objetos no espaço compartilhado e também transferir objetos de lá para o seu sistema local (para ler ou editar um documento, por exemplo).

A colaboração assíncrona se dá através de espaços de trabalho compartilhados, onde os membros do grupo podem armazenar, gerenciar e editar conjuntamente os objetos. Há também uma ferramenta para discussão assíncrona (newsgroup). Portanto, o BSCW oferece recursos para comunicação, compartilhamento de espaço de trabalho e de informação de maneira assíncrona e não-presencial.

Em suas versões mais recentes, foram incorporados recursos para o planejamento, preparação e documentação de reuniões (suporte à comunicação formal) através do "objeto meeting". Na verdade, o objeto meeting serve para colher as informações necessárias ao estabelecimento de uma reunião síncrona, que será realizada no horário estabelecido, podendo ser face a face ou por meio de ferramentas de conferência externas ao BSCW. Por essa razão, é mais correto classificar o objeto meeting como uma ferramenta assíncrona não-presencial para suporte a reuniões (a preparação da reunião é feita antes). A comunicação e a colaboração síncrona propriamente ditas são feitas por ferramentas externas (embora o acesso a elas seja automático, desde que o cliente esteja devidamente configurado). O único recurso síncrono diretamente incluído no BSCW é uma ferramenta de chat (comunicação). A Fig. 8 ilustra a classificação do BSCW.
 
 

Além dos recursos acima mencionados, o BSCW tem um bom suporte para a percepção dos usuários presentes no ambiente e um razoável esquema de articulação (controle de acesso aos grupos, autenticação, direito de acesso aos objetos e mecanismo de soft-lock para acesso concorrente - i.e., o usuário não é bloqueado, mas é avisado quando outro usuário está editando o mesmo documento). A visualização não segue o esquema WYSIWIS, permitindo uma configuração local a critério do usuário (o sofisticado esquema de configuração de interface do BSCW é um das suas características mais interessantes, pois é uma forma de lidar com o problema de adaptação às diferenças entre os usuários, que é um dos aspectos desejados para a flexibilidade social). Também são tratados aspectos como controle de versões, privacidade (há espaço de trabalho privativo) e anonimato (objetos podem ser definidos como "públicos", de modo que usuários anônimos possam acessá-los).

3.3.3. JETS (Java Enabled Telecollaboration System)

O JETS é um sistema desenvolvido pela Universidade de Ottawa [Shirmohammadi 98], [JETS 98]. Ele é totalmente implementado em Java e acessível através de qualquer Web browser que suporte applets. Do ponto de vista do desenvolvedor, o JETS pode ser considerado como uma API para o desenvolvimento de applets multimídia compartilhados, provendo mecanismos de consistência, controle de acesso e passagem de dados.
 
 

Para o protótipo do sistema, foram desenvolvidos applets de whiteboard multimídia compartilhado (além da capacidade de desenho dos whiteboards convencionais, este suporta documentos HTML, imagens, apresentações Powerpoint e de vídeo), visualizador VRML e um applet para gerenciamento de sessão (inclusive com possibilidade de votação). O JETS, portanto, se enquadra em todo o espectro de aplicações síncronas não-presenciais (Fig. 9): comunicação (existe um chat agregado ao whiteboard), espaço de trabalho compartilhado (whiteboard e browser VRML), compartilhamento de informação (documentos HTML e apresentações via whiteboard) e suporte a reuniões (ferramentas de gerenciamento e votação).

A visualização segue um esquema WYSIWIS relaxado, pois cada applet é visto igualmente por todos os participantes, mas cada um aparece em uma janela diferente, e a localização delas fica sob o controle dos usuários. Não há, portanto, suporte para o trabalho privativo. Com relação ao anonimato, há uma ferramenta de votação que envia votos anonimamente para o gerente da sessão. A implementação é centralizada (todos os clientes devem se conectar ao servidor).

3.3.4. CBE (Collaboratory Builder?s Environment)

O CBE [Lee 96] foi desenvolvido pela Universidade de Michigan com o objetivo de ser uma ferramenta para o desenvolvimento de "colaboratórios" (laboratórios virtuais, onde pesquisadores podem interagir com os colegas, compartilhar dados e informações, ter acesso a instrumental, etc, independentemente da localização geográfica). Ele foi implementado em Java e é acessível através de Web browsers convencionais (desde que suportem Java).

A arquitetura do CBE é baseada nos conceitos de salas, usuários, applets e grupos de applets. O conceito de sala é semelhante ao de espaço de trabalho do BSCW. Uma sala consiste de múltiplos applets e dados. Cada usuário que entra numa sala recebe em seu desktop uma cópia dos applets daquela sala, de modo que ele possa interagir com os outros usuários da sala, que também possuem os mesmos applets. O conjunto de applets do mesmo tipo constitui um grupo de applets e pertence a um mesmo grupo de comunicação multicast. Uma sala pode ter vários grupos de applets. Alguns protótipos desse ambiente já foram implementados em Java com applets de chat e whiteboard compartilhados.

A existência do chat, do whiteboard e de dados na sala, respectivamente, permitem enquadrar o CBE nas categorias de aplicação de comunicação, espaço de trabalho e informação compartilhados. A idéia é que o trabalho nas salas seja realizado de maneira síncrona, mas o CBE garante persistência no estado das salas depois das sessões de trabalho, de modo que as interações também possam ocorrer de maneira assíncrona. A Fig. 10 mostra a classificação do CBE.

O CBE trata de maneira eficiente a questão da privacidade (há salas particulares). Também existe uma diferenciação de papéis entre os usuários. Há o administrador, que controla o acesso a cada sala, cria ou retira grupos de applets da sala e interage com os applets. Há o usuário membro, que só difere do administrador porque não pode alterar o controle de acesso à sala. Há também o observador, que pode apenas observar os estados dos applets da sala, sem poder alterá-los. A implementação é centralizada; um usuário se comunica com os demais através de um servidor.
 
 

3.3.5. TeamWave

O TeamWave [TeamWave 98] é um sistema para trabalho colaborativo baseado na metáfora de "locais virtuais compartilhados", semelhante à metáfora de salas do CBE. O grupo de trabalho pode criar quantas salas forem necessárias, cada uma delas servindo como espaço para reuniões, armazenamento de documentos, trabalho em conjunto e interação entre os participantes. Conceitualmente, o TeamWave é similar ao CBE, com a vantagem de ter disponível muito mais ferramentas para serem usadas nas salas. A desvantagem do TeamWave é ser uma solução proprietária e exigir instalação do software cliente e servidor (não é acessível através de um browser convencional).

O estado das salas é persistente, de modo que elas podem ser usadas tanto para interações síncronas quanto assíncronas. O TeamWave também oferece ferramentas que permitem enquadrá-lo em todo o espectro de aplicações não-presenciais (Fig. 11). Há ferramentas de comunicação textual (chat e quadro de mensagens), de espaço de trabalho compartilhado (whiteboard), de compartilhamento de informações (browser Web, base de dados, armazenamento de arquivos, dentre outros) e de suporte a reuniões (agenda eletrônica, planejamento de reuniões, brainstorming e votação).

Além da variedade de ferramentas disponíveis, o TeamWave demonstra preocupação com a percepção dos usuários, pois oferece recursos como cartão de visitas (para identificação dos usuários), telepointers, barras de rolagem indicando a visão que os outros usuários têm, além de ferramenta de radar. A implementação não é WYSIWIS, pois embora os usuários compartilhem o mesmo conteúdo das ferramentas, eles podem ter visões diferentes das mesmas. Há a possibilidade de criação de salas privativas. A ferramenta de votação permite o anonimato.
 
 

O TeamWave oferece suporte tanto para a comunicação informal quanto para a formal (ferramenta de planejamento de reuniões). O gerenciamento ocorre através do controle de uma série de ações (quem pode entrar na sala, criar applets, etc). A arquitetura utilizada é a centralizada, pois os clientes devem se conectar a um servidor TeamWave localizado em uma máquina conectada à Internet.

3.3.6. Análise comparativa

Nas seções anteriores foram analisados alguns sistemas que visam dar suporte a algum tipo de colaboração na Web. Todos têm em comum o fato de serem não-presenciais, suportarem algum tipo de comunicação (geralmente textual) e terem espaço de trabalho e informações compartilhados.

O BSCW é mais voltado para o trabalho assíncrono, embora esteja caminhando na direção de prover suporte síncrono. Os sistemas voltados para o trabalho síncrono, por outro lado, tendem a garantir persistência de estado entre as sessões síncronas, de modo a suportar o trabalho assíncrono (o CBE e o TeamWave são exemplos). Isto confirma a tendência dos sistemas serem cada vez mais flexíveis no que diz respeito à funcionalidade e ao campo de aplicação. A flexibilidade social, apesar de ter sua importância reconhecida, ainda não está satisfatoriamente tratada, provavelmente por causa da complexidade da mesma e da dificuldade em mapear as questões sociais em soluções tecnológicas.

Os sistemas analisados também demonstraram que a preocupação com a percepção dos usuários está tendo cada vez maior importância no desenvolvimento de groupware. Quanto ao trabalho de articulação, a capacidade de gerenciamento está presente principalmente nas ferramentas síncronas e a coordenação, de uma maneira geral, é realizada apenas de maneira implícita (com algoritmos de controle de concorrência internos ao sistema). Uma análise geral permite considerar que as ferramentas apresentadas oferecem apenas uma pequena parte das características desejáveis em sistemas CSCW.

Todas as aplicações apresentadas usam o paradigma tradicional de interação homem-máquina, baseado na metáfora de desktop. Avanços recentes na capacidade de processamento dos computadores e na eficiência de transmissão pelas redes têm permitido o surgimento de novos tipos de UIs, utilizando outras metáforas. Este é o assunto da seção que se segue.

4. Novos paradigmas

Esta seção estuda novos paradigmas para a construção de interfaces na Web. Estes paradigmas saem da metáfora de desktop das aplicações atuais (interfaces WIMP - Windows, Icons, Menus, Pointing device) e propõem novas formas de apoio à interação. É dada uma ênfase especial à realidade virtual, cuja metáfora se baseia nas interações do mundo real.

4.1. Interfaces Pós-WIMP

As interfaces WIMP são baseadas em janelas, ícones, menus e um dispositivo apontador (geralmente o mouse). Elas utilizam a metáfora de desktop e funcionam por meio do mecanismo de point and click (apontar e "clicar"), i.e., os objetos gráficos que compõem a UI são mostrados na tela e, para interagir com eles, o usuário deve levar o ponteiro até eles e "clicar". Este tipo de UI já existe desde a década de 70 e pode ser considerado a terceira geração de UIs [van Dam 97].

A primeira geração (décadas de 50 e 60) foi marcada pela ausência praticamente total de interação com o computador. A entrada de dados ocorria por meio de cartões perfurados e a saída era impressa em papel. A interação mais sofisticada se dava por meio de chaves e luzes indicando o estado da máquina. A segunda geração de UIs (a partir da década de 60) foi caracterizada por monitores alfa-numéricos, através dos quais os usuários podiam interagir com os computadores por meio de comandos. É o tipo de interação dos sistemas DOS e Unix.

O surgimento das interfaces WIMP foi um grande avanço no sentido de diminuir a distância cognitiva entre a intenção e a execução desta intenção (i.e., o usuário deve focalizar a tarefa e não a tecnologia para realizar a tarefa). Apesar do sucesso das interfaces WIMP, elas apresentam uma série de problemas [van Dam 97]:

• Aplicações muito complexas são difíceis de utilizar porque, embora os widgets sejam individualmente fáceis de usar, o agregado de recursos cria um alto grau de complexidade.
• Os usuários ainda gastam muito tempo manipulando a interface, e não a aplicação (muitos point and click).
• Os widgets são bidimensionais, sendo inapropriados para aplicações tridimensionais (o mapeamento de tarefas 3D em controles 2D não é "natural") [Fernandes 98].
• O uso do mouse e teclado não é apropriado para usuários com certos tipos de deficiência.

4.2. Realidade Virtual

A realidade virtual (RV) consiste em um conjunto de técnicas para simular um mundo real ou imaginário e dar ao usuário a sensação de estar "presente" no mundo simulado. Um ambiente de RV pode ser imersivo ou não-imersivo. Nos ambientes imersivos, o senso de "presença" no mundo virtual é mais forte, pois o usuário usa equipamentos sofisticados como capacetes (head mounted displays) e caves [Buxton 98], ficando "isolado" do mundo real. Nos ambientes não-imersivos o usuário interage com o mundo virtual através da tela do computador.

Uma forma de usar técnicas da realidade virtual em UIs é em sistemas de realidade aumentada (augmented reality), que permitem a visualização de dados/informações virtuais sobre o ambiente físico ao redor do usuário. Um exemplo de uso da realidade aumentada é para o conserto de equipamentos: o usuário com óculos especiais consegue ver o interior da máquina e ler o manual de cada peça. Outro exemplo de uso é na visualização de dados científicos [Fuhrmann 98].

As seções seguintes abordam três outras formas de interação através da RV. A Seção 4.2.1 introduz a VRML, que é o padrão para a construção de aplicações de RV na Web. A Seção 4.2.2 discute os ambientes virtuais colaborativos, onde vários usuários podem interagir no mundo virtual. Finalmente, a Seção 4.2.3 apresenta o conceito de tele-imersão, cujo objetivo é fazer com que o usuário se sinta fisicamente presente em um ambiente remoto.

4.2.1. VRML (Virtual Reality Modeling Language)

Do ponto de vista da Web, a VRML [VRML 97] pode ser vista como uma espécie de HTML tridimensional, ou seja, uma linguagem independente de plataforma para a publicação de páginas Web tridimensionais. No entanto, ela é muito mais que isso. O principal objetivo da versão atual da VRML (VRML 97) é prover ricos ambientes tridimensionais interativos, permitindo ao usuário definir mundos estáticos e animados, e interagir com estes mundos [Magalhães 97].

A visualização de um mundo VRML se dá através de um browser VRML, normalmente um plug-in de um Web browser convencional. O browser VRML lê e interpreta o arquivo de descrição do mundo virtual, o "desenha" em uma janela, e provê uma interface para que o usuário possa andar pelo ambiente criado e interagir com objetos dele.

O paradigma para a criação de mundos em VRML é baseado em nós, definindo o "grafo da cena", uma hierarquia de grupos e formas organizados como uma árvore genealógica. Os nós filhos no grafo são formas geométricas, fontes luminosas, sons, etc. Os nós pais gerenciam os grupos de nós filhos, que podem ser pais de outros nós, criando uma hierarquia em forma de árvore [Nadeau 99].

Cada nó VRML define um nome, um tipo, e um valor default para seus parâmetros. Há dois tipos de parâmetros possíveis: campos (fields) e eventos (events). Os campos podem ser modificáveis ou não. Eventos podem ser enviados para outros nós por um parâmetro do tipo "eventOut" e recebidos por um "eventIn"; eles sinalizam mudanças causadas por "estímulos externos" e podem ser propagados entre os nós do ambiente através de roteamentos (Routes), que conectam um eventOut a um eventIn do mesmo tipo (Fig. 12).
 
 

Há vários tipos de nós em VRML. Por exemplo, há nós geométricos (que definem a forma dos objetos do ambiente), nós de iluminação, nós de agrupamento (que agrupam nós, criando a estrutura hierárquica do arquivo) e, particularmente importantes para a interação com os usuários, nós sensores e intrerpoladores. Antes tratar destes nós mais avançados, é conveniente mostrar o código para a criação de um mundo VRML simples, apenas com primitivas geométricas básicas.

VRML também permite o reuso de nós previamente criados e a prototipação, possibilitando a definição de um novo tipo de nó a partir da combinação de nós existentes. Em outras palavras, é possível encapsular e reutilizar um sub-grafo do ambiente. A prototipação permite inclusive a criação de cenas distribuídas, pois o sub-grafo (protótipo) pode ser definido em um arquivo remoto (cujo URL é dado).
 
 

Para tornar os mundos VRML interativos e dinâmicos, foram criados dois tipos de nós especiais: sensores e interpoladores.

Os sensores geram eventos baseados nas ações do usuário. O nó TouchSensor, por exemplo, detecta quando o usuário aciona o mouse sobre um determinado objeto (ou grupo de objetos) e gera um eventOut. Este eventOut pode ser ligado a outros eventIns e iniciar uma animação, por exemplo. Os sensores são responsáveis pela interação com o usuário, mas não estão restritos a gerar eventos a partir de ações dos usuários. O TimeSensor, por exemplo, gera automaticamente um evento a cada pulso do relógio, servindo como temporizador em animações.

Os interpoladores, por sua vez, definem valores-chave que são interpolados de acordo com uma função linear. Por exemplo, o nó PositionInterpolator permite a definição de n posições e n instantes de tempo (cada instante associado a uma posição-chave). Se usado juntamente com um TimeSensor, o PositionInterpolator gera um evento a cada pulso do relógio, representando a posição referente a cada instante de tempo, resultado da interpolação linear das posições-chave.

Os eventos gerados por sensores e interpoladores, ligados a nós geométricos, de iluminação ou de agrupamento, podem definir comportamentos dinâmicos para os elementos do ambiente. Um exemplo típico é ilustrado na Fig. 15 [Tamiosso 97]. Neste exemplo, um TouchSensor é ligado a um TimeSensor, fazendo com que o relógio comece a funcionar quando o usuário "clica" sobre um determinado objeto do ambiente. O TimeSensor é ligado a um PositionInterpolator, enviando valores de tempo para a função de interpolação. O PositionInterpolator por sua vez é ligado a um nó geométrico, definindo a nova posição do objeto a cada instante.
 
 

Apesar de ser um recurso poderoso, o roteamento de eventos entre nós não possibilita o tratamento de várias classes de comportamento. Por exemplo, não é possível escolher entre duas trajetórias pré-definidas. Para superar esta limitação, a VRML define um nó especial chamado Script, que permite ao usuário conectar o mundo a um programa externo, onde os eventos podem ser processados. Este programa, teoricamente, pode ser escrito em qualquer linguagem de programação mas, na prática, Java e JavaScript são as linguagens comumente usadas.

Os nós Script, através dos programas a eles associados, trazem a lógica de decisão e o gerenciamento de estados para mundos VRML. Estes programas são capazes de receber, processar e gerar eventos que controlam o comportamento dos objetos do mundo. Através dos nós Script é possível usar técnicas mais sofisticadas que a interpolação para a geração de animações. Por exemplo, um TimeSensor pode ser ligado a um nó Script associado a um programa que calcula a posição de um objeto baseado numa função f(t). A nova posição calculada pelo programa pode então ser enviada como um eventOut a partir do nó Script e ligada a um nó geométrico, cujo objeto associado se moverá de acordo com f(t). Este tipo de integração entre VRML e programa externo é ilustrado na Fig. 16 [Tamiosso 97].
 
 

A combinação VRML/Java através dos nós Script é bastante poderosa, pois o programa associado ao nó pode controlar toda a interação e o comportamento dos elementos do mundo virtual. O programa associado ao nó Script também pode se comunicar com outros programas externos (por exemplo, o programa responsável pela UI), o que abre inúmeras possibilidades para novas aplicações, inclusive os ambientes virtuais colaborativos, que são vistos na próxima seção.

4.2.2. Ambientes Virtuais Colaborativos (CVEs)

Um CVE (Collaborative Virtual Environment) é uma simulação em tempo real de um mundo real ou imaginário, onde usuários estão simultaneamente presentes e podem navegar e interagir com objetos e outros usuários [Hagsand 96]. As seguintes características definem um CVE [Waters 97]:

• Permite que um grupo de usuários separados geograficamente interaja em tempo real (ferramenta síncrona não-presencial, embora a persistência de estado do ambiente permita também o trabalho assíncrono).
• Permite número elevado de usuários.
• É tridimensional para os olhos e ouvidos, ou seja, movimentos no ambiente mudam a perspectiva visual e auditiva do usuário.
• Usuários são representados como objetos do ambiente (a representação do usuário no ambiente é chamada avatar).
• Muda continuamente em todos os aspectos (novos usuários entrando, saindo, movendo-se, mudando estado dos objetos, etc). Isso cria uma dificuldade adicional, pois não é suficiente uma "representação inicial" do ambiente armazenada em algum lugar da Web, como as home pages hoje em dia. É necessário passar aos usuários que entram o estado atual do ambiente.
• Usuários, além de interagirem entre si, podem interagir com simulações computacionais. CVEs, portanto, podem ir além da imitação da realidade, permitindo situações que não existem no mundo real.
• Comunicação verbal é a base da interação entre usuários.

CVEs também serão importantes na área de educação: para aprender uma nova língua, pode-se criar por exemplo uma Paris virtual, onde alunos e professores assumiriam papéis nessa sociedade virtual (agentes de software também poderiam fazer parte deste CVE). Aprender-se-ia francês e algo sobre a vida na França.

Os CVEs também podem levar a uma revolução nas bases de dados, oferecendo a possibilidade de trabalhar "dentro" dos dados, ao invés de trabalhar simplesmente "com" os dados [Benford 95]. Para isso, são desenvolvidos os chamados PITS (Populated Information Terrains). Uma das motivações para o desenvolvimento dos PITS é a constatação que a visualização direta dos dados pode suportar uma navegação geral através dos mesmos que os atuais paradigmas baseados em pesquisas não permitem. Além disso, a percepção de como os outros usuários estão utilizando os dados é importante tanto em situações onde a cooperação é requerida, como no estabelecimento de contato com pessoas com interesses semelhantes e no "bloqueio social" dos dados (i.e., as pessoas negociam acesso aos ítens de dados da mesma maneira que compartilham recursos no mundo real).

As pesquisas na área de CVEs vêm sendo conduzidas por duas comunidades distintas: a comunidade da Internet e a comunidade militar. Estas duas comunidades tomaram caminhos diferentes no desenvolvimento de CVEs, discordando sobre quais aspectos são mais importantes. A comunidade da Internet, encabeçada por empresas comerciais e universidades, enfoca a disponibilidade para a grande massa de usuários. Para eles, CVEs devem ser executados nos tipos de computadores e conexões da maioria dos usuários. Até bem pouco tempo, isso exigia sacrifício da comunicação por voz, da imersão e do realismo. A comunidade militar, por sua vez, sempre se interessou mais por simulações realistas, imersivas e que suportassem milhares de usuários simultaneamente, com o objetivo de treinamento para situações de combate. Geralmente esse tipo de sistema exige hardware próprio de elevado custo, impossibilitando sua utilização pelo usuário comum [Waters 97].

É possível definir uma taxonomia para CVEs de acordo com o local onde são armazenados os dados relevantes ao estado do ambiente e de seus objetos [Macedonia 97].

• Ambiente homogêneo replicado: o estado de cada participante é iniciado a partir de uma base de dados homogênea contendo as informações do mundo virtual. Cada participante recebe cópia do estado inicial e só precisa ser comunicado das mudanças de estado. Nesse tipo de ambiente é grande a quantidade de pequenas mensagens transmitidas. Ele também é relativamente pouco flexível e, com o tempo, tem tendência ao aparecimento de inconsistências entre os participantes devido à perda de mensagens (Fig. 17).

Figura 17: Ambiente homogêneo replicado.

• Ambiente com dados compartilhados centralizados:há uma base de dados localizada em servidor central, compartilhada por todos os usuários. Todas as alterações de estado realizadas pelos usuários devem ser comunicadas apenas ao servidor, que redistribui a mensagem a todos os participantes. Como a base de dados é definida como um único recurso, apenas um usuário pode alterá-la de cada vez. A vantagem com relação aos CVEs do tipo anterior é que estes estão menos sujeitos a inconsistências devido à base de dados ser centralizada. No entanto, o servidor é muito sobrecarregado e tende a se tornar o fator limitante do sistema. Além disso, o tráfego de mensagens é muito grande (as mensagens - maiores que a do caso anterior - são enviadas primeiro para o servidor e então distribuídas para os participantes). A Fig. 18 ilustra este tipo de CVE.

Figura 18: Ambiente com dados compartilhados centralizados.

• Ambiente com dados compartilhados distribuídos, atualização ponto a ponto: os dados são replicados parcial ou totalmente em cada participante desse tipo de ambiente. Não existe um servidor central, como nos casos anteriores e as alterações são comunicadas aos participantes via multicast. A grande vantagem desse tipo de ambiente é não ter o servidor limitando o desempenho do sistema. No entanto, existem problemas de escalabilidade devido aos custos para a manutenção da confiabilidade e consistência de dados. Além do mais, a comunicação ponto a ponto é mais frágil no aspecto da segurança (todos os participantes têm os mesmos privilégios) e tende a sobrecarregar os participantes com mensagens (Fig. 19).

Figura 19: Ambiente com dados compartilhados distribuídos, atualização ponto a ponto.

• Ambiente com dados compartilhados distribuídos, cliente-servidor: variante do modelo cliente-servidor, onde os dados estão divididos entre os participantes e a comunicação é mediada por servidor central. Esse tipo de ambiente (Fig. 20) supera os problemas característicos da comunicação ponto a ponto (dificuldade de consistência, por exemplo). No entanto, a presença de um servidor pode servir como fator limitante do sistema, especialmente em ambientes com número elevado de usuários (os sistemas existentes usam técnicas para reduzir a comunicação entre os participantes e conseqüentemente o uso deste servidor).

Figura 20: Ambiente com dados compartilhados distribuídos, cliente-servidor.

Alguns exemplos de CVEs são o DIVE, desenvolvido pelo SICS (Swedish Institute of Computer Science) [Hagsand 96], o NPSNET [Macedonia 94], e o Community Place, da Sony [Lea 97]. O DIVE se enquadra na categoria de ambiente com dados compartilhados distribuídos, atualização ponto-a-ponto. O NPSNET usa uma variação do mesmo modelo do DIVE e o Community Place usa o modelo de dados compartilhados distribuídos, cliente-servidor.

4.2.3. Tele-Imersão

A tele-imersão, freqüentemente associada à realidade virtual, tem como objetivo fazer com que o usuário se sinta fisicamente presente em um ambiente remoto (virtual ou não). A presença é "simulada" ao usuário através de um complexo sistema de transmissão de imagens, som e sensação táctil. A tele-imersão é definida como uma efetiva combinação de [Tele-imersão 97]:

• Tecnologias de RV imersivas (estilo cave).
• Sistemas avançados de telecomunicação de alta velocidade.
• Extensões das tecnologias de imersão para reconhecer presença e movimentos de indivíduos, "trilhar" essa presença e movimentos, e projetá-los em ambientes virtuais realistas.

À primeira vista, tele-imersão pode ser confundida com CVEs ou aplicações imersivas de RV, mas ela é um conceito mais avançado. Eis algumas diferenças:

• A tele-imersão, como já diz o nome, é necessariamente imersiva, enquanto os CVEs podem não ser.
• A tele-imersão tem uma preocupação maior com o realismo do ambiente e com as sensações sonoras e tácteis.
• A tele-imersão não é restrita a aplicações de RV, pois também é usada em situações onde o ambiente não é virtual, mas composto por imagens reais (no caso da manipulação de robô, as imagens vistas pelo tele-operador são geradas por câmeras instaladas no próprio robô e transmitidas em tempo-real).

5. Conclusão

Este trabalho mostrou que nos últimos anos a Web tem continuamente englobado importantes recursos que tornam a interação com os usuários mais eficiente. O mais importante destes recursos heterogêneos até o momento é a plataforma Java, que permitiu que a Web se tornasse realmente um ambiente para a execução de um grande número de aplicações. No entanto, apesar destes avanços, ainda existe um longo caminho a ser percorrido até que a Web possa ser efetivamente usada como meio de interação entre seus usuários, principalmente em aplicações que exigem transmissão rápida e confiável de uma quantidade elevada de mensagens ou dados.

A primeira parte do trabalho (Seções 1 e 2) mostrou o apoio oferecido atualmente à interação na Web, destacando a plataforma Java. A segunda parte do trabalho (Seções 3 e 4) apresentou problemas mais complexos de interação, cujas soluções ainda são em grande parte experimentais. Na Seção 3 foram estudadas as aplicações multiusuário (colaborativas), que se preocupam com a interação usuário/usuário através da Web. O que se pode concluir da discussão realizada é que hoje em dia a Web ainda não apresenta os recursos necessários para uma eficiente interação multiusuário. Na Seção 4 foram estudadas novas formas de interação com a informação e com os outros usuários, com destaque para a realidade virtual. Embora a VRML já seja um padrão razoavelmente estabelecido e conhecido na Web, ainda são necessários grandes avanços na transmissão e apresentação de dados via Web.

Existem muitos outros aspectos da interação na Web que não foram tratados por estarem relacionados à interação com a informação (preferiu-se dar prioridade aos aspectos relacionados à interação com os usuários): apresentação da informação (quais mídias são mais apropriadas), navegação na informação (o problema de ficar "perdido no hiperespaço"), pesquisas (o que tem sido feito para tornar os resultados das pesquisas mais úteis ao usuário), dentre outros. Estes aspectos são igualmente importantes e devem ser considerados em pesquisas mais aprofundadas sobre o futuro da Web.

O objetivo deste trabalho foi desenvolver uma visão crítica com relação à Web, mostrando que ainda é necessário um grande esforço de pesquisa e desenvolvimento para se criar uma infra-estrutura global de informação (GII - Global Information Infrastructure) [Gershon 96]. A GII seria o próximo passo além da Web, permitindo não só acesso ainda mais amplo à informação, sem as limitações impostas atualmente pela Web e Internet, mas também formas de interação mais elaboradas, que permitem conectar diversos usuários simultaneamente.

Referências Bibliográficas