RESUMOEste artigo apresenta um framework que resumeaspectos relevantes no suporte a awareness emsistemas de groupware. Awareness (ou percepção)é o conhecimento sobre o grupo e suas atividadespassadas e presentes, e constitui ponto vital para otrabalho cooperativo, sem o qual este trabalho ficadescoordenado e perde em qualidade e eficiência.O framework aqui apresentado comporta−se, naverdade, como uma classificação ampla e únicapara os requisitos necessários a um suporte aawareness adequado. Sobre este framework foramclassificadas diversas ferramentas de groupwaredisponíveis, formando assim uma visão geral dasrealizações neste domínio.

KEY WORDS: awareness, groupware, CSCW.

1 INTRODUÇÃO

A busca por maior eficiência na solução deproblemas complexos fez com que atividadespassassem a ser resolvidas em grupos, com oobjetivo de fazer com que a produção do grupotodo supere a de cada membro isolado. Entretanto,cooperar não é algo fácil. Sua definição de"trabalhar ou agir em conjunto para um objetivocomum" não captura vários aspectos desseprocesso [2]. Um destes aspectos é a falta decontexto sobre as atividades dos colegas e dogrupo, a qual pode gerar redundâncias,inconsistências e contradições dentro do trabalhodo grupo. Isso pode gerar um trabalho truncado,sem coesão de idéias, ou incompleto, prejudicandoo seu resultado em qualidade e eficiência, podendoaté não atingir seus objetivos.

Para evitar este tipo de situação, é necessário daraos membros do grupo acesso a este contexto, aoque se dá o nome de awareness ou percepção.Awareness é o conhecimento geral sobre asatividades e sobre o grupo. É o conhecimentosobre o que aconteceu, o que vem acontecendo, oque está se passando agora e o que poderáacontecer dentro das atividades do grupo, e sobreo próprio grupo, seus objetivos e sua estrutura.

Dada sua importância, o estudo da percepção eseus mecanismos de suporte têm sido alvo dediversas pesquisas na área de TrabalhoCooperativo Suportado por Computador (CSCW),produzindo uma série de resultados publicados aolongo dos anos. Este artigo objetiva organizar aessência destes resultados através de umframework, contendo as principais característicaspara o suporte a awareness, apresentando−secomo uma proposta de classificação ampla para osmecanismos de suporte a awareness disponíveis.Para tanto, este artigo inicia com uma rápidarevisão sobre o que é awareness e segueapresentando a classificação, feita através de seisquestões básicas que analisam as necessidadesde sistemas de groupware síncronos eassíncronos, e termina com alguns e exemplos deferramentas de groupware classificados e asconclusões deste artigo.

2 CSCW E AWARENESS

A área de CSCW vem buscando, desde o seuprincípio, meios de suportar adequadamente otrabalho em equipe. Contudo, este suporteapresenta vários problemas. Um destes problemasé a falta de contexto entre os participantes, queocorre quando os membros de um grupo detrabalho desconhecem o que seus colegas estãofazendo, ou não sabem onde suas atividades seencaixam no trabalho como um todo, nem qual é asituação desse trabalho. Segundo Borges et al. [3],esse contexto é um ponto importante em sistemascooperativos, estendendo−se para não somente oconteúdo das contribuições individuais, mastambém o seu significado para o grupo como umtodo e seu objetivo.

O fornecimento deste contexto aos membros deum grupo é chamado awareness ou percepção.Awareness pode ser conceituada como sendo acontextualização das atividades individuais atravésda compreensão das atividades realizadas poroutras pessoas [1]. Em outras palavras,awareness refere−se a ter conhecimento dasatividades do grupo, saber o que aconteceu, o queestá acontecendo e/ou o que poderá vir aacontecer, além do próprio conhecimento do que é

AWARENESS EM SISTEMAS DE GROUPWARE

Manuele Kirsch Pinheiro(manuele@inf.ufrgs.br) José Valdeni de Lima(valdeni@inf.ufrgs.br)

Instituto de Informática Universidade Federal do Rio Grande do Sul

Av. Bento Gonçalves, 9500 − Bloco IV− Agronomia Porto Alegre − RS − Brasil

Caixa Postal: 15064 − CEP 91501−970

Marcos R. S. Borges(mborges@nce.ufrj.br)

Núcleo de Computação Eletrônica Universidade Federal do Rio de Janeiro

Rio de Janeiro − RJ − Brasil − Caixa Postal 2324 − CEP 20001−970

este trabalho e o grupo. Generalizando,"awareness significa uma compreensão do estadototal do sistema, incluindo atividades passadas,status atual e opções futuras" [22].

Estar atento aos colegas e às atividades por elesdesempenhadas representa papel importante nafluidez e na naturalidade do trabalho [14], o que fazda awareness peça chave para qualquer forma decooperação, uma vez que perceber, reconhecer ecompreender as atividades dos outros é umrequisito básico para a interação humana e acomunicação em geral [22]. Por exemplo, ainteração em um mesmo local tem alto grau deawareness. Pode−se facilmente saber se umcolega está no escritório, se está trabalhando emum projeto ou se está de mau humor e, com otempo, aprende−se também sobre sua agenda,hábitos e interesses. Tudo isso contribui paraconhecer melhor os colegas, criando uma basepara as interações, sem a qual estas ficam maisformais e menos fluídas [15]. Awareness permite acada usuário coordenar e estruturar seu trabalho,pois possibilita ao mesmo perceber e compreenderno que os demais estão trabalhando. Ela tambémmostra oportunidades para comunicação informal eespontânea, suportando o estabelecimento e amanutenção de convenções no grupo. Sempercepção, o trabalho cooperativo coordenado équase impossível [22]. Considerando, por exemplo,o caso do desenvolvimento cooperativo desoftware, é necessário que os membros tenhamnoção do contexto de suas atividades no contextogeral do processo para que possam perceber oandamento das atividades realizadas pelos demaise compreender como os resultados gerados porestas atividades podem ser conjugados com osseus próprios, para mais rapidamente chegaremao resultado final [1]. Neste caso, a ausência desuporte à percepção torna quase impossível aprodução de um software consistente e dequalidade, de forma eficiente.

Estas informações de percepção são, segundoMariani [16], fornecidas por um conjunto demecanismos, que dão ao usuário indicação dasatividades dos demais. Estes mecanismosfornecem oportunidade aos indivíduos deganharem uma compreensão do trabalho de seuscolegas e usar esta informação para coordenarsuas atividades para o grupo [10]. Entretanto, oconceito de percepção envolve um vasto conjuntode informações, de modo que, usualmente, osmecanismos de suporte apresentados na literaturatêm abordado somente um subconjunto destasinformações. Com isso, pôde−se identificar umconjunto limitado de características importantes,que vêm sendo observadas nas propostas destesmecanismos. A identificação deste conjuntopermitiu a delimitação de um framework com taiscaracterísticas importantes, que idealmentedeveriam ser observadas pelas ferramentas de

groupware. Sobre este framework, apresentado napróxima seção, pode−se distribuir os mecanismosde suporte à percepção hoje mais difundidos,criando assim uma classificação geral para oassunto, a qual poderá também ajudar nacondução de novas contribuições. O frameworkaqui proposto age também como uma reunião dasprincipais contribuições encontradas nabibliografia, fornecendo uma visão geral do quevem sendo desenvolvido nos últimos anos quantoa awareness.

3 FRAMEWORK PARA AWARENESS

A análise de vários mecanismos de suporte àawareness propostos na bibliografia identificou umconjunto de características importantes. Estascaracterísticas giram em torno de 6 questões (oque, quando, onde, como, quem e quanto), cadauma identificando aspectos vitais para ofornecimento de awareness dentro de ferramentasde groupware síncronas e assíncronas, e quejuntas definem o framework apresentado nesteartigo. Em ambientes síncronos, os membros dogrupo precisam estar trabalhando simultaneamente(a interação síncrona descreve a situação ondemais de um usuário está acessandoconcorrentemente a dados compartilhados [16]),como em videoconferências. Já em um ambienteassíncrono, pode haver um intervalo de tempoentre a atuação de um usuário e sua percepçãopor seus colegas (a interação assíncrona ocorrequando os usuários estão compartilhando umobjeto sobre um período estendido [16]), ou seja,os usuários não precisam estar trabalhandosimultaneamente para que o objetivo seja atingido.

Com isso, sistemas de groupware síncronos eassíncronos diferem quanto as suas necessidadespor awareness, uma vez que usuáriosobrigatoriamente trabalhando ao mesmo tempoterão necessidades de percepção diferentesdaqueles que não precisam trabalharsimultaneamente. Dessa forma, torna−seimportante, ao analisar cada uma das seisquestões mencionadas acima, observar se trata−se de um ambiente síncrono ou assíncrono.

3.1 O que

A primeira questão a ser analisada é "o que" e serefere a quais as informações devem serfornecidas aos usuários. Estas informações estãointimamente ligadas a dois aspectos principais: asatividades e os papéis.

As atividades são a base do trabalho cooperativo,pois o objetivo a ser alcançado geralmente édividido em atividades menores, distribuídas entreos membros do grupo. Conhecer esta distribuição

é conhecer as atividades dos colegas, e isto émuito importante para o andamento do trabalho,tanto síncrono quanto assíncrono. Em ambientesíncrono, é mais importante saber detalhes sobreas atividades sendo realizadas no momento,enquanto que em um sistema assíncrono, comonão há garantia sobre o momento em que umatarefa será realizada por um colega, é maisinteressante ter uma visão ampla das atividades.

Assim, pode−se dizer que, em ambientessíncronos, o maior interesse está em informaçõesdetalhadas, nas atividades vistas em um “micro−nível", pois os membros estão trabalhando aomesmo tempo, tornando importante a percepçãodas atividades de seus colegas nos mínimosdetalhes. Um exemplo é o Groupkit, um toolkit paraa construção de groupware síncronos edistribuídos para a realização de conferências. OGroupkit fornece uma coleção de widgets, como oTelepointer, utilizado principalmente para acomunicação de gestos. Segundo Roseman eGreenberg [18], os gestos são um mecanismo decomunicação rico, que permite aos participantesindicar relações entre artefatos, chamar a atençãopara um artefato em especial, etc. Através dosTelepointers é possível visualizar a movimentaçãodo mouse feita pelos colegas, o que fornece umaboa idéia do que cada um está fazendo,fornecendo uma noção em micro−nível dasatividades realizadas.

O mesmo não ocorre em ambientes assíncronos,onde um nível de detalhamento tão grande não étão adequado, podendo atrapalhar o trabalho dosmembros. Nestes ambientes, devido à existênciade um possível espaço de tempo entre asatividades dos membros, é mais importante teruma idéia global das atividades realizadas peloscolegas, ter uma visão em “macro−nível” destas.Um exemplo é encontrado dentro do Alliance, umeditor cooperativo assíncrono que permite a umgrupo geograficamente distribuídos pela Interneteditar conjuntamente documentos estruturados.Seu funcionamento se baseia na fragmentação dodocumento em partes, de acordo com a atribuiçãode papéis para os autores, definindo seus direitossobre cada um dos fragmentos [7], [20], [8]. Dentrodo Alliance, o suporte a awareness é feito por umsistema de notificação, que permite que co−autores recebam os fragmentos inteirosatualizados, de forma que estes não percebem asatividades de seus colegas em detalhes, massomente em um macro−nível, recebendo apenas oresultado já publicados destas atividades.

Os papéis são elementos de destaque em umambiente cooperativo, pois representam a noçãode hierarquia dentro do grupo. Eles indicam asresponsabilidades e possibilidades dos membrossobre o trabalho. Assim, os papéisdesempenhados fornecem uma forte indicaçãosobre o tipo de informação de awarenessnecessária ao seu desempenho. Por exemplo, asinformações necessárias para um participantediferem das necessárias a um coordenador. Acoordenação é fundamental em atividadescooperativas e o fornecimento de awarenessespecífico para a coordenação é importante, tantoem sistemas síncronos quanto assíncronos [10].Se o coordenador do grupo tem disponíveismecanismos de percepção próprios, com oseventos relevantes ao seu papel, achará mais fácila tarefa de conduzir o grupo a um resultado bemsucedido [5],[4].

Para executar suas funções, um coordenadorprecisa de informações de percepção maiscompletas que as de um participante. Ele precisaestar atento ao andamento do trabalho como umtodo, desde as atividades de cada membro, até osomatório de todas elas. Precisa de informações,como prazos e status, para tomar decisões edirigir os esforços da equipe para os pontos maisnecessários. Um exemplo deste tipo de percepçãodiferenciada é apresentado na Figura 1, onde ocoordenador tem uma visão geral da participaçãodos membros numa discussão, através destaimplementação conhecida como Participameter. OParticipameter mostra o nível de participação dosmembros como uma percentagem da participação

Figura 1 Implementação do Participameter [5]

Tabela 1 Características para a pergunta "o que"

Ambientes Síncronos Ambientes Assíncronos

O que Atividades Micro−nível Macro−nível

Papéis Diferenciação das informações de acordo com o papel desempenhado

total [5]. Este pode ser observado na Figura 1,incluindo detalhes na parte inferior da figura sobreas percentagens de cada elemento ("contrib","reads" e "remarks") para cada contribuição.Observa−se também a associação entre valorespercentuais e um padrão de cores, permitindo umarápida assimilação da informação.

Logo, ao fazer a pergunta "o que", identificam−seduas características importantes no suporte àpercepção: as atividades e os papéis, os quaisconstituem dois tipos de informações que devemser característicos para o suporte à percepção. ATabela 1 apresenta o resumo da questão "o que".

3.2 Quando

A segunda questão que deve ser feita ao sepensar em awareness é “quando”: quando ocorremos eventos geradores das informações deawareness e quando se dá a apresentação destasinformações.

As informações de awareness são geradas poreventos que ocorrem durante o trabalho do grupo,e de acordo com seu momento de ocorrência,estes eventos vão ser mais ou menos úteis àpercepção. Pode−se dividir a ocorrência doseventos em quatro momentos: o "passado", paraeventos que ocorreram em um intervalo de tempono passado; o "passado contínuo", para eventosque começaram no passado, mas que continuamválidos até agora; o "presente", para eventos queestão ocorrendo neste momento e o "futuro",representando as opções futuras para o grupo. Opassado inclui eventos que já ocorreram há algumtempo e cujos resultados podem não ser maisválidos. Um exemplo de seu suporte é o SISCO,um sistema distribuído e assíncrono para o apoio apreparação de reuniões, através de um ambienteque permite a discussão dos temas a seremtratados na reunião, sem a obrigatoriedade datomada de decisão [2]. O SISCO inclui em suaarquitetura uma memória de grupo que armazenaas contribuições feitas durante a pré−reunião,facilitando o fornecimento de percepção doseventos ocorridos no passado

O passado contínuo representa aqueles eventosque, apesar de terem iniciado no passado,

continuam valendo até o presente, como são, porexemplo, os fragmentos dentro do Alliance, ondeapenas aqueles que ainda não foram substituídaspor novos são visíveis aos autores.

O presente compreende os eventos que estãoacontecendo agora, como o movimento do mouseou a alteração da posição de uma barra derolagem. Um exemplo de sistema que fornece estapercepção é o COPSE/CUTE. O COPSE(Collaborative Project Support Environment) é umambiente para o desenvolvimento cooperativo desoftware, enquanto o CUTE (Collaborative UMLTechnique Editor) é um editor,construído sobre oCOPSE, com suporte a aspectos de cooperaçãona modelagem de softwares orientados a objetos,focando as atividades de diagramação destes [9].Dentro do CUTE, a inclusão de novos elementos(classes ou relacionamentos), ou mesmo a maissimples alteração em um destes elementos, éimediatamente replicada nos workspaces dosdemais.

Por fim, o futuro representa as opções do grupo,os eventos que ainda poderão ocorrer, mas queprecisam fazer parte da percepção do usuário. É,por exemplo, o caso de um alarme que avisequanto à aproximação dos prazos para asatividades. A chegada do prazo limite é o eventogerador e só ocorrerá no futuro, mas o alarme, quefornece a percepção deste evento, se dá antes.

Alguns destes momentos são mais ou menosimportantes de acordo com o ambiente utilizado.Em ambientes síncronos, por estarem os membrostrabalhando ao mesmo tempo, é vital fornecer apercepção dos eventos que estão ocorrendo nomomento presente, e em ambientes assíncronos,como há um possível espaço de tempo entre aatuação dos colegas, é vital manter o contextosobre o que foi feito (eventos no passado) e doque ainda está sendo feito (passado contínuo),para que os participantes possam encaixar suaspróprias atividades nas do grupo. Em ambos oscasos, a percepção de eventos futuros representauma opção interessante para manter os membrosatentos aos possíveis rumos do trabalho.

O interesse pelos eventos ocorridos em um ououtro momento vai determinar outra importantecaracterística para suporte à percepção, o tempode utilidade da informação e, por conseqüência, asua persistência. Até quando as informações de

Tabela 2 A questão "quando" para percepção

Ambientes Síncronos Ambientes Assíncronos

Quando Eventos Passado

Presente Passado Contínuo

Futuro Futuro

Apresentação Imediata Posterior (a critério do usuário)

Persistência/Tempo de Utilidade Baixa Alta (critério de caducidade)

percepção são úteis para o trabalho do grupo?Serão estas informações persistentes? Emsistemas síncronos, o interesse maior se concentrano momento atual, então não há necessidade demanter as informações de percepção por maistempo do que aquele momento, pois passado este,elas não serão mais úteis. Logo, o tempo deutilidade destas informações é baixo, e porconseqüência, há a necessidade de uma baixapersistência. Já em sistemas assíncronos, como ointeresse maior reside na percepção de eventos nopassado ou no passado contínuo, as informaçõesseguem sendo úteis ao grupo, mesmo tendopassado o momento de sua ocorrência, havendo anecessidade por uma alta persistência.

Todavia, deve−se determinar um limite para estearmazenamento, um limite onde estas informaçõesperdem sua utilidade. Eventos em um passadocontínuo só são úteis ao grupo enquanto foremverdadeiros, podendo ser descartados assim quedeixarem de ser. Já eventos no passado são úteismesmo quando não forem mais verdadeiros, edevem ser mantidos até certo ponto, exigindo adefinição de um critério de caducidade, queinutiliza estas informações. Este critério pode serum tempo de vida fixo, ou o fornecimento dasinformações para um ou mais membros, oumesmo combinações de eventos.

Outra característica importante com relação àquestão “quando” refere−se ao momento daapresentação das informações de percepção. Emsistemas síncronos, como o interesse está noseventos presentes, quanto mais cedo for dada apercepção destes eventos, melhor (imediato). Jáem sistemas assíncronos, há um intervalo detempo entre os eventos geradores e os demaismembros os perceberem, logo, a informação éapresentada possivelmente em um momentoposterior à ocorrência dos eventos,, sendoadequado permitir o próprio usuário decidir omomento de receber estas informações. Exemplossão o CUTE, que por trabalhar com eventospresentes, possui uma baixa persistência eapresenta as informações dos eventosimediatamente a sua ocorrência, e o Alliance, queapresenta eventos no passado contínuo, mantendouma alta persistência nestas informações atravésde seus fragmentos.

A Tabela 2 resumiu o que foi discutido sobre aquestão “quando”: quando ocorrem os eventos, atéque ponto as informações geradas são úteis equando apresentar estas informações.

3.3 Onde

A terceira questão que deve ser feita quando oassunto é percepção é onde as informações sãogeradas e apresentadas.

Ao se trabalhar em grupo, trabalha−se sobre umconjunto de objetos dispostos dentro de um espaçode trabalho (workspace), compartilhados entre osmembros. A percepção do que está ocorrendoneste espaço compartilhado é chamada deworkspace awareness. Trata−se do conhecimentodo que está acontecendo no workspacecompartilhado no momento atual, e é um elementonatural dentro de ambientes físicos de trabalho.Para Gutwin e Greenberg [13],[14], umparticipante, em uma reunião face a face, pode vertodo o workspace físico e quem estiver nele. Podeinteragir com artefatos físicos, fornecendo aosdemais informações sobre a natureza e oprogresso das atividades. Estes sãoconhecimentos naturais e inerentes em ambientesfísicos, mas não em um workspace virtual, onde osrecursos de dispositivos de entrada e saída sãomenores, se comparados aos ambientes físicos,mas impõem menos restrições sobre as interações[14], [13].

O fornecimento de workspace awareness emsistemas síncronos é vital para que os membrosdo grupo trabalhando simultaneamente tenhamnoção de todas atividades realizadas dentro doworkspace compartilhado. Neste contexto, oGroupkit oferece vários widgets para ofornecimento de workspace awareness, comotelepointers, multi−user scrollbars e o GestaltViewer, para a localização dos colegas noworkspace, apresentado na Figura 2.

Em ambientes assíncronos, como não há meios decertificar a presença dos membros no workspaceem um mesmo intervalo de tempo, o foco deawareness localiza−se nos objetos compartilhadospor estes membros. É através destes objetos quea comunicação entre os membros se dá, atravésda manipulação e do histórico de manipulaçãodestes objetos compartilhados, que mostram o quehouve e está acontecendo dentro do trabalho emgrupo, criando assim o contexto para as atividades

Figura 2 Exemplo de Widget para workspace awareness [18]

de cada membro. Segundo Dourish [10], o artefatocompartilhado é, em ambientes assíncronos,essencialmente o único espaço compartilhadodisponível aos participantes, sendo peça chave nacolaboração assíncrona. Um exemplo disto é oprojeto POLITeam, que desenvolveu umgroupware integrado, com suporte para o trabalhocooperativo assíncrono e distribuído, comcomponentes de workflow, processamentocoordenado de documentos e tarefas, e gatewaycom a WWW [17],[22]. O POLITeam mantém umhistórico de eventos gerados dentro do ambientecompartilhado, atrelando cada evento ao objetosobre o qual o evento foi realizado.

Tanto em sistemas síncronos quanto assíncronosé de inteira responsabilidade do projetistadesenvolver um ambiente capaz de dar suporteadequado, seja a workspace awareness, seja aobjetos compartilhados. Para tanto, é necessárioapresentar uma metáfora adequada ao tipo deinformação desejada. Podem ser usadas tantometáforas de escritório quanto de sistema. Asmetáforas de escritório, ideais para sistemassíncronos, representam elementos do ambiente detrabalho real, presentes no dia−a−dia dosparticipantes, como salas e mesas, minimizando apossibilidade de má interpretação. Um exemplo é ogroupware DIVA, um protótipo de ambiente deescritório virtual.

As metáforas de sistema relacionam o groupwarecom versões monousuárias do sistema, como oAlliance, cuja interface se assemelha a de umeditor HTML padrão. Esta metáfora utilizada afetao modo como as informações são capturadaspelos participantes, havendo a necessidade deenriquecê−la adequadamente com as informaçõesde awareness, a fim de permitir aos participantesuma percepção mais clara das atividades dogrupo, enfatizando os aspectos de cooperação efornecendo aos usuários a sensação de estaremrealmente trabalhando em grupo.

A Tabela 3 resume as considerações colocadasacima quanto à questão “onde”, onde asinformações são geradas e apresentadas,relacionando−se ao espaço de trabalho e àmetáfora utilizada neste espaço.

3.4 Como

A próxima questão sobre percepção é "como", eindica como as informações são apresentadas aosusuários, como é sua interface. A interface com ousuário é a responsável pelo fornecimento dasinformações de awareness, devendo apresentá−las de forma resumida, a fim de evitar asobrecarga dos membros e permitir uma rápidaassimilação. Os usuários não podem se sentirsoterrados pelas informações de percepção, nemtê−las omitidas. Estas informações também devemter uma natureza passiva, surgindo direto dasatividades de cada pessoa, ao invés de sergerenciada ou procurada explicitamente [10]. Umainterface mal projetada pode causar tanto asobrecarga, quanto a omissão, por ser inadequadaao tipo de informação apresentada.

Portanto, para fazer o projeto de uma interfacebalanceada, deve−se procurar por elementos deinterface adequados. Estes elementos podem serícones ou cores associados a informaçõesespecíficas, como papéis e participantes, ougráficos representativos do progresso do trabalho,ou ainda uma combinação de elementos comoestes. O importante é que estes elementosapresentem as informações de percepção deforma resumida, sem sobrecarga, nem perda deconteúdo significativo. Para tanto, estes elementosdeverão fazer uma filtragem ou um agrupamentodas informações, mostrando apenas aquilo que formais útil e interessante a cada participante. Estesprocessos de filtragem e agrupamento podemutilizar vários critérios desde o papel atépreferências pessoais de cada membro, como são,por exemplo, os awareness profiles utilizados peloPOLITeam. Estes profiles fazem uma seleçãosobre os eventos ocorridos, fazendo com quesomente aqueles que estiverem no conjunto deprofiles assinados pelo usuário sejamapresentados. O POLITeam também faz uso decores e ícones sobrepostos para agrupar asinformações e apresentar perifericamente aousuário as atividades realizadas sobre um objeto eo tempo transcorrido.

Além disto, há a questão da apresentação dosobjetos e do espaço de trabalho compartilhado. Setodos os membros vêem os objetos e o workspaceda mesma forma ou se há diferenças nas visõesde cada um, isto afeta a percepção do grupo, poismanter uma mesma visão para todos significa queos membros vão ter disponíveis as mesmasinformações (quando a representação diverge, ocontexto pode se perder [13]). Forma−se, então,uma disputa entre as necessidades do grupo e dosindivíduos. Segundo Gutwin e Greenberg [13],diferentes representações do espaço de trabalho eseus objetos podem tornar as tarefas individuaismais fáceis, mas também podem restringir acomunicação sobre os objetos, sendo mais fácil

Tabela 3 A questão "onde"para a percepção

AmbientesSíncronos

AmbientesAssíncronos

Onde Espaço Workspaceawareness

Objetoscompartilhados

Metáfora Escritório Sistema

manter a percepção quando uma mesmarepresentação é mantida. Assim, o projetista deum groupware deve decidir entre beneficiaratividades individuais ou priorizar a percepção dasatividades coletivas. Em sistemas síncronos, otrabalho é feito pelo grupo simultaneamente,fazendo com que uma percepção uniforme doworkspace e dos objetos seja mais importante doque a flexibilidade para o usuário isolado, sendoimportante ter a oportunidade de ver onde seucolega está trabalhando agora e o que estáfazendo em detalhes. Assim, costuma−se usar,nestes casos, interfaces com maior acoplamento,como interfaces WYSIWIS (What You See Is WhatI See), e WYSIWIS relaxadas, ou ainda recursoscomo múltiplas visões.

Nas interfaces WYSIWIS, todos os membrosativos têm a mesma imagem do workspace e seusobjetos, o que garante o contexto das atividades.Entretanto, estas são interfaces muito restritivas epodem prejudicar o andamento do trabalho portolher demais os indivíduos. Para estes casos,uma alternativa são as interfaces WYSIWISrelaxadas, que garantem maior liberdade aosindivíduos, como, por exemplo, a livre navegaçãono workspace, ao custo de uma possível perda deinformações, especialmente em grandesworkspaces. O GroupKit é um exemplo de toolkitque permite a construção de ferramentas degroupware com interface WYSIWIS, e oCUTE/COPSE, um exemplo de groupware cominterface WYSIWIS relaxada.

Além das interfaces WYSIWIS, os sistemassíncronos podem ainda contar com o recurso demúltiplas visões, onde os participantes podemoptar em visualizar o workspace e seus objetos devárias maneiras, permitindo, por exemplo, que umparticipantes mantenha uma visão completa doworkspace e outra visão adequada as suasatividades individuais.

Em ambientes assíncronos, não há sentido em seutilizar interfaces WYSIWIS puras, que enfocam asações dos colegas presentes, pois não hágarantias de que eles estarão trabalhando aomesmo tempo. Todavia, a presença de mais de umusuário no sistema é uma boa oportunidade paracooperação e deve ser explorada. Para estescasos, o mais adequado são interfaces WYSIWISrelaxadas, que mantém a liberdade de ação decada participante, sem deixar de mostrar o que os

colegas ativos estão fazendo no momento. Outrapossibilidade é unir interfaces WYSIWIS relaxadacom a idéia de múltiplas visões, fornecendo aosparticipantes a oportunidade de escolher entre umavisão mais adequada a sua atividade individual eoutra que favoreça sua colaboração. O Alliance éum exemplo de groupware que oferece o recursode múltiplas visões a seus usuários.

Uma última possibilidade é a utilização deinterfaces desacopladas, que não são acopladasàs interfaces dos colegas. Estas permitem a cadamembro adaptar a interface às suas necessidadesindividuais, sem que os demais sejam notificadosdisto, mas não impedindo a interface de incluirelementos para percepção. Um exemplo disso é oSISCO, onde a interface de um usuário nãomantém ligação com a dos demais, mais aindaassim mantém indicadores para awareness.

A Tabela 4 resume a questão "como".

3.5 Quem

A penúltima questão a ser feita é “quem”: quemestá trabalhando e quem está atento no momento.Este é um conhecimento importante para o bomandamento das atividades no grupo, pois agecomo facilitador da cooperação, à medida queestimula a interação e a comunicação informalentre os membros. Segundo Smith [21], boa partedo trabalho em um ambiente de escritório ébaseada na comunicação informal, a qual, emmuitos casos, permite às pessoas ficaremconscientes das atividades dos colegas e fornecetambém um contexto para as atividadesrelacionadas ao trabalho.

A noção de presença dos outros participantes évital em ambientes síncronos, pois é inviávelrealizar uma tarefa simultaneamente com umgrupo de pessoas sem saber quem são estas

Figura 3 Informações detalhadas sobre um participante [11]

Tabela 4 Percepção de "Como"

Ambientes Síncronos Ambientes Assíncronos

Como Interface WYSIWIS WYSIWIS relaxado

WYSIWIS relaxado Múltiplas Visões

Múltiplas Visões Desacopladas

Balanceamento Filtragem

Agrupamento

pessoas. Nestes ambientes, os participantesprecisam (obrigatoriedade) estar conscientes dapresença dos demais para que o trabalho prossigae obtenha resultados satisfatórios. Já emambientes assíncronos, a noção de presençacomporta−se como uma oportunidade para acooperação a ser explorada, e não umanecessidade, porque a presença de todos não éobrigatória para que o trabalho prossiga.Explorando estas oportunidades, os membrosativos podem trocar idéias, experiências e dúvidas,aproveitando a situação para enriquecer oconhecimento do grupo, a própria cooperação e otrabalho como um todo.

A Figura 3, mostra um exemplo widget do GroupKit[18], [19], que apresenta uma lista com osparticipantes presentes e permite a consulta demaiores informações sobre os colegas, como foto,telefone, email. Fornecer informações sobre oscolegas é importante para o fortalecimento danoção de grupo, tanto em ambientes síncronosquanto assíncronos. Esse conhecimento cria umsenso maior de comunidade, à medida que osmembros vão conhecendo melhor seus colegas, eo uso de mecanismos de comunicação reforçam acoesão entre estes membros.

A noção da presença envolve também saber sealguém está ou não atento ao sistema, poisestando os membros geograficamente distantes, amera presença não garante que o colega estejarealmente atento. De posse deste conhecimento, épossível a um membro conversar, trocar idéias,pedir auxílio ou mesmo resolver possíveis conflitosatravés de ferramentas de comunicação,permitindo tornar as relações entre os participantesmais pessoais e interativas, menos formais. Estasferramentas de comunicação devem ser adaptadasao tipo de sistema onde estão inseridas. Emsistemas síncronos, elas devem priorizar acomunicação síncrona, incluindo ferramentas noestilo conferência, como o CUTE que inclui umaferramenta de chat. Já em ambientes assíncronos,destaca−se o uso de ferramentas assíncronas,como email, quadro de avisos e notas, quegarantem aos membros a oportunidade de manteruma comunicação informal com seus colegas. Ouso de ferramentas síncronas, como chats, ficasujeito à eventual presença de mais de ummembro, agindo somente como um recurso extrapara a comunicação.

A Tabela 5 resume a questão “quem”, com ascaracterísticas da percepção expostas acima.

3.6 Quanto

A última das questões a se fazer sobre percepçãoé “quanto” e destaca uma característica essencialque deve ser observada no suporte à percepção:qual a quantidade ideal de informações que deveser apresentada ao usuário, a fim de lhe proverpercepção sobre o grupo e suas atividades.

Esta preocupação é uma constante nodesenvolvimento de um suporte eficaz àpercepção, afetando todas as questõesanteriormente discutidas. O ponto chave destapreocupação é fornecer a quantidade certa deinformações para a percepção, sem causar nem ainsuficiência, que poderia deixar os usuários semum contexto para as suas atividades, nem asobrecarga, que pode prejudicar os participantes àmedida que interrompe o seu trabalho e exigeatenção excessiva para filtrar as informações deseu interesse. É necessário buscar um meio termoentre a insuficiência e a sobrecarrega deinformações, extrapolando a idéia de filtragem eagrupamento para além da interface (“como”), paradentro da escolha das informações (“o que”), paraa escolha do local e do momento da geração eapresentação (“onde” e “quando”), e para e comquem apresentar (“quem”) estas informações.

Dessa forma, esta questão afeta a todas asdemais (o que, quando, como, onde e quem),caracterizando−se como uma dimensão paralela,influenciando cada questão de forma isolada, etambém o somatório de todas as informaçõesextraídas das outras cinco questões, o qual nãopode ficar em nenhuma das extremidades do“quanto” (Figura 4), nem na insuficiência, nem nasobrecarga.

Outra forma de visualizar esta questão é comofunção da densidade de informação, como mostraa Figura 5. Imaginando que cada item nasquestões discutidas (como atividades em micro−nível, eventos no passado e interface

Tabela 5 A questão "quem" para percepção

Ambientes Síncronos Ambientes Assíncronos

Quem Presença obrigatoriedade oportunidade

Ferramentas de Comunicação Essencialmente ferramentassíncronas

Essencialmente ferramentas assíncronas

Figura 4 Dimensão "quanto"Insuficiência Sobrecarga

∑ informações

Figura 5 Variação na densidade da informação

WYSIWIS,etc) possa variar entre não fornecerinformação (não ter este suporte), fornecer umpequeno conjunto, e dispinibilizar um grandeconjunto de informações, como indica a variaçãode cor na Figura 5, a dimensão “quanto”representaria o conjunto de todas estasinformações, o qual poderia ser um conjunto maisou menos denso. Esta visão mantém a mesmaidéia central da apresentada na Figura 4, de que aquestão "quanto" é uma dimensão paralela àsdemais, definida por todo o conjunto deinformações indicados pelas outras questões ecujo ideal para um sistema de groupware seriaalcançar um ponto entre um conjunto muito densoe um muito pouco denso de informações. Ou seja,a idéia central permanece a de chegar a um pontointermediário, com informações suficientes paramanter o contexto do grupo, sem que o seutrabalho seja prejudicado, seguindo os interessesdesse grupo e do próprio groupware.

3.7 O Framework

Discutidas as seis questões "o que", "quando","onde", "como", "quem" e "quanto", forma−se, coma união destas questões, o frameworkapresentado na Figura 6. Este framework resumeas características consideradas mais importantespara percepção, apresentadas durante estadiscussão. Com isso, chega−se a umaclassificação para os mecanismos de suporte àpercepção representada pelo próprio framework, oqual também forma uma visão geral do que énecessário observar e optar durante odesenvolvimento deste tipo de suporte. Pode−seobservar que a Figura 6 é formada na verdade pelaunião das Tabelas 1 a 5 com a Figura 4,representando a formação deste framework peloconjunto das 6 questões discutidas.

Figura 6 Framework para suporte à percepção

4 EXEMPLOS CLASSIFICADOS

Para a confecção deste trabalho, vários sistemasde groupware foram estudados, alguns dos quaiscitados no decorrer do artigo. Estes encontram−seclassificados na Tabela 6, de acordo com oframework da Figura 6. Cada um é representadopor uma letra grega acompanhada de um sinal de“−“, se o suporte não for adequado, e suasprincipais caraterísticas encontram−se descritasabaixo. Convém apenas lembrar que para estarápida análise não foi considerada nestaclassificação, mostrada na Tabela 6, a questão“quanto”.� COPSE/CUTE ( α ): O COPSE é um ambiente

para o desenvolvimento cooperativo desoftware e também um framework para aconstrução de aplicações groupware, enquantoo CUTE é um editor UML com suporte aaspectos de cooperação, construído sobre oCOPSE [9]. O CUTE trabalha com eventospresentes, com apresentação imediata, nãohavendo persistência para as informações depercepção. Ele também mantém a noção depresença no workspace, graças ao recurso de“user list”, e mantém ferramentas decomunicação síncronas, através de umsistema de mensagens e de um chat. Alémdisso, ele possui uma interface WYSIWISrelaxada, mantendo informações como oposicionamento e detalhamento (visualizaçãode atributos e métodos) das classes e comuns

a todos os participantes, mas a navegaçãopelo espaço de trabalho é livre, e adota umametáfora de sistema, assemelhando−se a umsistema de diagramação.

� POLITeam ( δδ ):O projeto POLITeam objetivadesenvolver um groupware com que suporteao trabalho cooperativo assíncrono edistribuído, incluindo componentes deworkflow, processamento coordenado dedocumentos e tarefas [22],[17]. O POLITeamusa a metáfora de containers de objetos, comodocumentos, ferramentas e outros containers,assemelhando−se aos desktops padrão,usados em diversos sistemas, podendo serclassificado como metáfora de sistema. Sobreesta metáfora, o workspace compartilhadopode ser visualizado através de três visõesdiferentes, caracterizando o uso de múltiplasvisões, mas todas se mantém desacopladascom relação às visões mantidas pelos colegas.A noção de presença é fornecida pelo sistemano sentido de oferecer uma oportunidade, masnão há um suporte adequado à comunicação.Quanto aos eventos, os usuários doPOLITeam tem acesso a eventos no passadoe no passado contínuo, com apresentaçãoposterior e alta persistência, com asinformações de awareness localizadas juntoaos objetos compartilhados. Já as atividadessão visíveis em um macro−nível, uma vez quesomente é possível saber que foram feitasdeterminadas operações nos objetos como um

Tabela 6 Classificação de alguns sistemas de groupware

Ambientes Síncronos Ambientes Assíncronos

O que Atividades Micro−nível ( α−) ( ε− ) ( η ) Macro−nível (( δδ ) ) ( ε ) ( φ ) (( γγ ) )

Papéis diferenciação das informações de acordo com o papel desempenhado (( δδ−)−) ( φ ) (( γγ−)−)

Quando Eventos Presente ( α ) ( ε ) ( η ) Passado (( δδ ) ( ) ( γγ ) )

Passado Contínuo (( δδ ) ) ( ε ) ( φ ) (( γγ ) ) ( η−)

Futuro

Apresentação Imediata ( α ) ( η ) Posterior (( δδ ) ) ( φ ) (( γγ ) )

Persistência/Utilidade Baixa ( α ) ( η ) Alta (( δδ ) ) ( ε− ) ( φ−) (( γγ ) )

Onde Espaço workspace awareness ( α−) ( ε− ) ( η ) objetos compartilhados (( δδ ) ) ( φ )

Metáfora Escritório ( ε ) Sistema ( α−) (( δδ−)−) ( φ )

Como Interface WYSIWIS ( η ) Desacopladas (( δδ ) ( ) ( γγ ) )

WYSIWIS relaxado ( α ) ( η )

Múltiplas Visões (( δδ−)−) ( ε ) ( φ )

Balanceamento Filtragem (( δδ ) )

Agrupamento (( δδ ) )

Quem Presença Obrigatoriedade ( α ) ( ε ) ( η ) Oportunidade (( δδ−) (−) ( γγ−)−)

Ferramentas deComunicação

Ferramentas síncronas ( α ) ( ε ) (( γγ ) ) (η) Ferramentas assíncronas (( δδ−)−) ( ε ) (( γγ−)−)

todo, e não que parte do documento foialterada.

� DIVA ( ε ): O DIVA é um protótipo de ambientede escritório virtual, com foco no fornecimentointegrado de awareness, tanto em modosíncrono quanto assíncrono. Ele usa umametáfora de escritório, modelando elementoscomo “pessoas”, “salas”, “mesas” e“documentos”. As “mesas” funcionam comolocal para o trabalho dentro das salas,podendo ser usadas para preservar o contextode trabalho [22], permitindo a definição dediferentes modos de acoplamento entre asinterfaces dos usuários, caracterizando apresença de múltiplas visões. O DIVA tambémfornece uma noção sobre a presença e adisponibilidade dos colegas no escritório, aqual, juntamente com as ferramentas decomunicação síncronas, por canais de áudio evídeo, e assíncronas, via notas que podem serdeixadas para os colegas, funcionam comouma obrigatoriedade.

� Alliance ( φ ): O Alliance é um editorcooperativo assíncrono que permite a umgrupo de pessoas geograficamente distribuídase conectadas a Internet editaremconjuntamente documentos estruturados. Seufuncionamento se baseia na fragmentação dodocumento em partes, de acordo com aatribuição de papéis para os autores, definindoseus direitos sobre cada um dos fragmentos[20]. Dessa forma, o Alliance trabalha com oconceito de papéis e atividades em um macro−nível, operando com a atualização defragmentos completos, os quais tambémgarantem a apresentação de eventos nopassado contínuo, com alta persistência eapresentação posterior. o Alliance tambémapresenta uma metáfora de sistema,assemelhando−se a um editor HTMLtradicional, e o recurso de múltiplas visões,permitindo a visualização e a edição dodocumento em várias visões.

� SISCO ( γγ ): O SISCO é um sistema distribuídoe assíncrono para o apoio a preparação dereuniões, através de um ambiente que permitea discussão dos temas a serem tratados nareunião, sem a obrigatoriedade da tomada dedecisão [2],[6]. Sua arquitetura inclui umamemória de grupo que armazena ascontribuições feitas durante a pré−reunião,facilitando o fornecimento de percepção deeventos ocorridos no passado ou no passadocontínuo, com apresentação posterior epersistência alta, implementada através do usodo SGBD para a manutenção desta memória.Quanto à comunicação, o SISCO trata apresença dos colegas como uma oportunidade,apresentando uma ferramenta de comunicação

síncrona, por troca de mensagens rápidas enão armazenadas e a própria memória degrupo como uma forma de comunicaçãoassíncrona, além de uma interface totalmentedesacoplada.

� GroupKit ( η ): O GroupKit é um toolkit para aconstrução de groupware síncronos edistribuídos para a realização de conferências,incluindo também aplicações de conferênciapropriamente ditas e gerentes de sessão, quepermitem aos usuários criarem e gerenciaremsuas conferências [18],[19]. Através de seuswidgets, o GroupKit permite às aplicações deconferências construídas sobre suas basesapresentar informações sobre as atividadesem um micro−nível, com eventos presentes,de apresentação imediata, mas ainda com umrecurso de manter o estado da conferênciadesde a saída de seu último membro até aentrada do próximo, o que pode serconsiderado como um suporte à eventos emum passado contínuo não muito adequado. Jáos últimos desenvolvimentos dentro doGroupKit têm vindo na direção de um suportemais adequado à wokspace awareness, com odesenvolvimento de novos widgets para isto.Atualmente, há um suporte já preparado ainterfaces tanto WYSIWIS puras quantoWYSIWIS relaxadas, embora a escolha por umdestes modelos e da própria metáfora a serseguida depende da aplicação desenvolvida.Quanto a presença, o GroupKit já traz em suadistribuição um widget para isso, oParticipantes, e uma aplicação de conferência,chamada “Post It”, para a troca de mensagenstextuais síncrona entre os participantes.

5 CONCLUSÕES

Este artigo apresentou um framework, resumindoas principais características para o suporte àpercepção dentro de ferramentas de groupware.Estas características podem ser divididas em seisquestões (o que, quando, onde, como, quem equanto), sempre analisadas sob os ponto de vistade sistemas síncronos e assíncronos. A análise devárias ferramentas de groupware a luz desteframework, mostrou que diversos aspectos dosuporte a awareness encontram−se descobertos, emuitas pesquisas ainda podem ser desenvolvidassobre estes aspectos. Dentre estes pontos, pode−se destacar claramente a questão do suporte aeventos no futuro. A Tabela 6 mostrou quenenhuma das ferramentas analisadas apresentoueste tipo de suporte, o qual é importante paramanter a noção dos rumos e prazos do trabalho.Outro aspecto que também não tem recebido adevido atenção é a questao dos eventos nopassado. Estes não foram muito abordados nasferramentas analisadas, apesar da importância que

decisões e atividades passadas podem ter nasatividades presentes e futuras do grupo. Alémdisso, o framework apresentado aqui não chegou aatacar a questão da estruturação do trabalhocooperativo, bastante comum em ferramentas deworkflow.As necessidades de percepção para estetipo de ambiente devem ainda ser alvo de estudos.

Em resumo, a awareness mostrou−se um campoainda fértil para as pesquisas na área de CSCW,sempre na busca por um suporte mais adequadoao trabalho em equipe.

6 REFERÊNCIAS BIBLIOGRÁFICAS

[1] Araújo, R.M.; Dias, M.S.; Borges, M.R.S. Suporte porComputador ao Desenvolvimento Cooperativo deSoftware: Classificação e Propostas. In: XI SimpósioBrasileiro de Engenharia de Software. SBES’97. Anais.Fortaleza, CE, outubro, 1997. P. 299−314

[2] Bellassai, G.; Borges, M.R.S.; Fuller, D.D.; Pino, J.A.;Salgado, A.C. SISCO: A tool for improve meetingsproductivity. In: CRIWG’95. Proceedings. 1995. P. 149−161.

[3] Borges, M. R.S.; Cavalcanti, M.C.R.; Campos, M. L. M.Suporte por computador ao trabalho cooperativo. In: XVCongresso da Sociedade Brasileira de Computação. XVJornada de Atualização em Informática. JAI’95. Anais.Canela, RS. Julho, 1995.

[4] Borges, M.R.S.; Pino, J.A.; Fuller, D.; Salgado, A. Keyissues in the design of an asynchronous system to supportmeeting preparation, To appear In Decision SupportSystems.

[5] Borges, M.R.S.; Pino, J.A. Awareness Mechanisms forCoordination in Asynchronous CSCW. In: 9th Workshop onInformation Technologies and Systems − WITS‘99.Charlotte, North Carolina, dez., 1999. Proceedings...Charlotte,1999.

[6] Cavalcanti, M.C.; Borges, M.R.S., Endo, M.Y. SISCO−RIO:Um sistema Assíncrono para Apoiar a Preparação deReuniões. In: XI Simpósio Brasileiro de Engenharia deSoftware. SBES’97. Anais. Fortaleza, CE, outubro, 1997.P. 475−479.

[7] Decouchant, Dominique; Salcedo, Manuel Romero; Quint,Vincent. Structured Cooperative Authoring on the World−Wide Web. Disponível em: <http://www.w3.org/pub/Conferences/WWW/Papers/91/>. Acesso em: set., 1998.

[8] Decouchant, Dominique; Salcedo, Manuel Romero;Serrano, M. Principes de Conception d’une Applicationd’Édition Coopérative de Documents sur Internet.Disponível em: <ftp://ftp.inrialpes.fr/pub/opera/publications/IHM97.ps.Z>. Acesso em: set., 1998.

[9] Dias, M.S.; Xexéo, G. Editor Cooperativo paraDiagramação de Software OO. In: XI Simpósio Brasileirode Engenharia de Software. SBES’97. Anais. Fortaleza,CE, outubro, 1997. P. 499−502.

[10] Dourish, P. Extending awareness beyond synchronouscollaboration. In: CHI’97 Workshop on Awareness inCollaboration Systems. Position Paper. Proceedings.Atlanta, USA. Março, 1997. Disponível em:<http://www.best.com/~jpd/chi97−awareness.html>.Acesso em: julho, 1999.

[11] Greenberg, Saul; Roseman, Mark. Groupware toolkits forsynchronous work. In: Beaudouin−Lafon, M. (editor).Computer−Supported Cooperative Work: trends insoftware series. cap.6, p. 135−168. John Wiley & Sons,1998. Disponível em: <http://www.cpsc.ucalgary.ca/grouplab/ papers>. Acessp e,: jan., 2000.

[12] Gutwin, C., Roseman, M. A usability study of workspaceawareness. In: CHI’96. Short Paper. EletronicProceedings. Disponível em: <http://www.acm.org/sigchi/chi96/proceedings/shortpap/Gutwin4/cg4txt.html>. Acessoem: outubro, 1999.

[13] Gutwin, C.; Greenberg, S. Design for individuals, design forgroups: tradeoffs between power and workspaceawareness. In: ACM Conference on Computer SupportedCooperative, 1998. Proceedings. Disponível em:<http://www.cpcs.ucalgary.ca/grouplab/papers/>. Acessoem: setembro, 1999.

[14] Gutwin, C.; Greenberg, S. A framework of awareness forsmall groups in shared−workspace groupware.Techinical Report 99−1, Departament of ComputerScience, University of Saskatchewan, Canadá. Disponívelem:<http://www.cpcs.ucalgary.ca/grouplab/papers/1999/99−AwarenessTheory/html/theory−tr99−1.html>. Acesso em:setembro, 1999.

[15] Hudson, S.E.; Smith, I. Techniques for fundamental privacyand fisruption trade−off in awareness support systems. In:ACM Conference on Computer Supported CoopertativeWork − CSCW’96. Boston, Massachusetts, USA, 1996. Proceedings. Novembro, 1996. P. 248 − 257.

[16] Mariani, J.A. SISCO: Providing a cooperation filter for ashared information space. In: ACM SIGGROUPConference on Supporting Groupwork − GROUP’97.Proceedings. Phoenix, Arizona, USA. Novembro, 1997.

[17] Prinz, W. The POLITeam Awareness Client. Disponívelem: <http://orgwis.gmd.de/projects/POLITeam/poliawac/>.Acesso em:outubro, 1999.

[18] Roseman, Mark; Greenberg, Saul. Building real timegroupware with GroupKit, a groupware toolkit. ACMTransactions on Computer Human Interactions. n.3, v.1,p. 66−106, mar., 1996. ACM Press. Disponível via WWWem http://www.cpsc.ucalgary.ca/grouplab/papers(jan.,2000)

[19] Roseman, Mark; Greenberg, Saul. Building groupware withGroupKit. In: Harrison, M. (editor). Tcl/Tk Tool. p. 535−564. O’Reilly Press, 1997. Disponível em:<http://www.cpsc.ucalgary.ca/grouplab/papers>. Acessoem: jan., 2000

[20] Salcedo, Manuel Romero. Alliance sur l’Internet: supportpour l’édition coopérative des documents struturés surun réseau à grande distance. Grenouble, France: INPG,1998.

[21] Smith, I. Toolkits for multimedia awareness. In: CHI’96.Proceedings. Disponível em: <http://www.acm.org/sigchi/chi96/proceedings/doctoral/Smith/ies_txt.html>. Acessoem: julho, 1999.

[22] Sohlenkamp, M. Supporting group awareness in multi−user enviroment through perceptualization.Dissertation. Fachbereich Mathematik−Informatik derUniversität − Gesamthochschule − Paderborn. Fevereiro,1998. Disponível em:<http://orgwis.gmd.edu/projects/POLITeam/ poliawac/ms−diss/>. Acesso em: julho, 1999.