A análise ergonômica do sistema hiperNet foi realizada com base na observação da tarefa "participar num fórum hiperNet, utilizando o eduFórum". Na realização da análise da tarefa, Johnson (1989) recomenda que a representação dos diferentes tipos de conhecimento relacionados com a mesma, deva se dar a partir de três componentes:
A análise efetivada baseou-se de maneira bastante geral numa adaptação do método proposto por Diaper (1989) com aportes conceituais diversos, principalmente aqueles sintetizados por Barthet (1988). O método proposto por Diaper não pode ser utilizado na íntegra pois o mesmo demanda o auxílio de uma ferramenta que automatize algumas de suas etapas, principalmente no caso de ter havido muitas horas de observação direta da realização da tarefa. Diaper (1989) cita um exemplo de um caso simples, onde ele analisa a tarefa "Anotação com lápis sobre um texto impresso por outra pessoa" com o objetivo de projetar um ambiente para a produção cooperativa de textos em rede. Mesmo neste caso simples, em que foram observados apenas 3 sujeitos com um tempo total de observação igual a 2 horas e 45 minutos de fitas gravadas, Diaper já sente a necessidade de auxílio computadorizado, pois, foram consumidas 60 horas de trabalho para a aplicação do seu método, ou seja quase 22 horas de análise para cada hora de observação realizada. É claro que o tempo total de análise não é diretamente proporcional ao tempo de observação da tarefa, mas, na proposta metodológica de Diaper, essa relação é bastante forte. No caso da observação relativa a este trabalho, pode-se dizer que a tarefa era de alto grau de complexidade se comparada à do exemplo citado. Além disso, foram observados 15 sujeitos, que totalizaram 26 horas de observação registrados em fita VHS.
Diaper informa em trabalhos mais recentes (Diaper, 1992 e 1996) e também na página web "http:www.hud.ac.uk/events/hci95" sobre a existência de uma ferramenta que automatiza o seu método. Contudo, a utilização desta ferramenta não se viabilizou, pois devido ao fato de não ter sido ainda publicada uma documentação consistente sobre a mesma, a sua utilização demandaria freqüentes contatos com a equipe de desenvolvimento. Em contato mantido via correio eletrônico, o autor Dan Diaper alegou dificuldades em prestar auxílios neste momento a partir daquela mídia.
As etapas sugeridas por Diaper (1989) foram realizadas de forma adaptada às condições de trabalho existentes. Foram adaptadas, ou simplesmente eliminadas aquelas etapas mais dependentes de auxilio computadorizado e que não eram de fundamental importância para a análise realizada, quais sejam: os cálculos das freqüências nos nodos da hierarquia de ações e a representação desta hierarquia no formato KRG. Isto posto, optou-se por realizar a seguinte metodologia:
Na verdade a cronologia da realização destas etapas não foi exatamente a apresentada: as etapas 3 e 4 foram realizadas em paralelo, na medida em que aquelas duas construções se apóiam mutuamente. O mesmo ocorreu com as etapas 4 e 5. A etapa 2 foi obtida naturalmente a partir da transcrição e da observação dos registros em fita VHS realizados.
A avaliação ergonômica da interface (sétima etapa) foi efetivada com base no conjunto de princípios ergonômicos elaborados por Barthet ( apresentados na seção 6.3.1) e também na síntese de recomendações constante na seção 6.4. Estas recomendações englobam quatro grande eixos de avaliação: a funcionalidade da aplicação, a linguagem de interação utilizada, os sistemas de ajuda implementados à aprendizagem e à própria realização da tarefa.
Quanto à funcionalidade da aplicação avaliada, analisaram-se os seguintes aspectos:
Os indicadores observados com referência à linguagem da interação foram os que seguem:
Quanto ao tipo de tratamento dos erros que o sistema implementa, tanto para erros de execução (distância articulatória) quanto para erros de intenção (distância semântica), foi considerado:
Quanto à ajuda ou facilidades que o sistema oferece no âmbito da sua interface, não sendo portanto relativas ao domínio específico da tarefa, considerou-se:
Quanto à ajuda na aprendizagem da utilização do próprio sistema, observou-se:
Como já foi dito, as sessões de observação foram gravadas em fitas de vídeo. Nestas registrava-se apenas a imagem do monitor e todas as interações verbais do sujeito com os colegas, com os mediadores e com o examinador (a câmera ficava afixada sobre o ombro do sujeito).
Todas as sessões registradas foram transcritas com todos os diálogos mantidos na íntegra. As ações mais freqüentes, normalmente as ações de leitura do repositório e de manipulação das janelas do ambiente Windows, foram identificadas logo no início das transcrições, o que permitiu a definição e associação de esquemas de códigos de forma a facilitar o trabalho. O apêndice I contém os esquemas de códigos utilizados.
Já durante as transcrições foram sendo assinaladas e descritas as situações que já eram identificadas como problemas e que mereceriam portanto atenção durante a fase de análise que seria efetuada no momento posterior. No apêndice I foi inserido um trecho da transcrição de uma sessão registrada, que exemplifica a forma como esta identificação se processava.
Após realizada a transcrição, uma simples leitura da mesma levou a identificar a lista das ações e objetos componentes da tarefa analisada. Estes objetos e ações foram então analisados e agrupados segundo suas diversas propriedades num trabalho de generalização e diferenciação que resultou nas taxionomias que estão descritas na seção seguinte. A construção destas taxionomias se constituiu num estágio fundamental para as etapas subseqüentes da análise.
É importante ainda registrar que juntamente com a observação que foi realizada de forma sistemática e planejada, ocorreu também uma observação acidental e involuntária, que acabou sendo utilizada de forma indireta na análise efetuada. Isto porque, além do próprio examinador ser um usuário freqüente da aplicação, ele acompanhou de perto o trabalho nos NET's, e, também, em muitos momentos, teve contatos com os seus colegas da equipe de pesquisa, que estavam desenvolvendo e utilizando o ambiente analisado. Mas é preciso ressalvar que apesar desta observação acidental ter fornecido alguns elementos importantes para a análise, de forma alguma ela teria substituído a observação que foi realizada de forma sistemática e planejada.
O "eduFórum", na versão analisada, é uma aplicação que integra um cliente Gopher, de nível bastante profissional, um cliente MOO e um administrador de correspondência eletrônica, num sistema multi-janelas que segue o padrão Windows (ver figura 13).
O cliente gopher, chamado "eduGopher", além de permitir acesso a bases de dados tipo "Gopher", inclui uma possibilidade inédita, ele permite a edição remota do servidor gopher hiperNet. Isso é feito a partir de um menu que contém as principais operações para a administração de um sistema de arquivos tradicional (criar diretório, guardar arquivo, ... etc).
O administrador de correspondência é bastante simples, pois todas as mensagens recebidas pelos participantes da rede hiperNet, ou pelas listas de discussão dos fóruns, são guardadas no próprio repositório do servidor gopher, ou seja a leitura da correspondência é feita a partir do próprio cliente gopher. Para tal, cada participante tem uma área pessoal que inclui uma pasta específica, onde é descarregada toda a sua correspondência . O mesmo ocorrendo com os debates dos fóruns, cada qual tem uma área do repositório gopher que está vinculada ao endereço daquela lista de discussão. Já o envio das correspondências é possível a partir da ativação de um editor específico.
O cliente MOO ainda está com o seu desenvolvimento em estágio
bastante inicial. Infelizmente esse cliente não pode ser analisado
a contento, pois o mesmo só ficou disponível nas duas semanas
finais do período de observação.
Figura 13. Visão geral do ambiente eduFórum.
No nível mais genérico, ao tentar construir a estrutura hierárquica das ações presentes numa sessão de trabalho com o eduFórum, os dois principais atributos generalizadores distinguidos foram a natureza da ação executada e o ambiente ou objeto sobre o qual ela era exercida. O diagrama que segue, construído conforme o modelo proposto por Diaper (1989), descreve esta generalização.
Descrição dos objetos e ações genéricos que compõem a tarefa "Participação num fórum hiperNet utilizando o eduFórum".
/
/-------- natureza da ação
/ |-------- conectar/desconectar
/ |-------- configurar
/ |-------- navegar e ler
/ |-------- editar
/
/--------objeto genérico no ambiente eduFórum
|-------- eduMOO
|-------- eduGopher
|-------- eduCorreio
A multiplicação destas duas classes de atributos, gera a hierarquia completa das ações da tarefa, cada ação genérica pode a princípio ser aplicada a todo e qualquer objeto genérico. Algumas classes resultantes da multiplicação (ação genérica)X(objeto genérico), como por exemplo, 'conectar eduCorreio' estão ausentes na tarefa analisada. Donde, a multiplicação gera um conjunto que é maior do que o conjunto das ações ou procedimentos realmente presentes na tarefa. Isto permite identificar, com certa independência da observação direta da tarefa, procedimentos que são necessários e estão ainda ausentes na mesma. Ou seja, o que se quer enfatizar é que, a metodologia de análise dos resultados permite identificar a ausência de procedimentos importantes na tarefa, até em situações em que esta ausência não havia sido diretamente percebida na prática.
A hierarquia das ações ou procedimentos inclusos numa tarefa contém implícita uma outra, qual seja, a hierarquia dos objetos que compõe o ambiente onde a tarefa se realiza. Donde, é recomendável também explicitar esta hierarquia de classes de objetos. A construção da generalização das ações está diretamente relacionada com a generalização dos objetos.
Um dos objetos genéricos da tarefa não pode ser analisado a contento, o eduMOO, pois a sua utilização só foi permitida ao final da realização do experimento. Os nodos das hierarquias construídas serão interrompidos com um sinal de interrogação "?" quando se tratar da dificuldade citada.
Na construção das classes de objetos foi necessário introduzir uma distinção nos tipos de elos da hierarquia. A distinção citada refere-se ao tipo de relação entre os objetos. Foram usados traços simples para as relações do tipo "é componente de" e traço duplo para as relações do tipo "é uma instância de". Essa diferenciação não foi necessária na categorização das ações, pois lá prevalece a relação do tipo "uma instância de".
Já durante a construção destas hierarquias, foi possível incluir aqueles objetos e ações que apesar de ainda ausentes no ambiente analisado foram percebidos como necessários já na situação experimental investigada. Os nodos escritos em itálico referem-se a estes objetos.
Descrição hierárquica dos objetos no ambiente edufórum
|---------conta e senha
|---------editor de textos
| -------- ambiente eduMOO
| |--------------endereço
| | ||----------------servidor eduMOO
| | ||----------------favoritos
| | ||----------------outros
| |---------------??
|
| -------- eduGopher
| |--------------endereço
| | ||----------------servidor hiperNet
| | ||----------------favoritos
| | ||----------------outros
| |
| |--------------Item
| | ||----------------pasta (diretório)
| | || | ||--------comum
| | || | ||--------fórum
| | || | ||--------debate
| | || | ||------caixa de correspondência
| | || | ||--------mensagens
| | || | ||-------enviadas
| | || | ||-------outras
| | || |------------lista de inscritos
| | ||
| | ||----------------arquivo
| | || ||--------texto
| | || ||--------imagem
| | || ||--------som
| | || ||--------executável
| | || ||--------mensagem
| | ||
| | ||----------------conexão
| | || ||-------- com outro item
| | || ||-------- gopher
| | || ||-------- http
| | ||
| | ||----------------pesquisa
| |--------------------------descrição
| |--------------------------Conteúdo
| -------- eduCorreio
|---------- editor de mensagens
| |---ferramentas de edição
| |---ferramentas impressão e gravação em disco
|------------------Mensagem
| ||---------- mensagem recebida
| || ||------------pessoal
| || ||------------debate
| ||---------- mensagem enviada
| ||------------nova
| ||------------resposta
| ||------------repasse
|------------Endereço
| |--------de origem (remetente)
| |--------de destino
|------------Assunto
|------------Conteúdo
A descrição hierárquica dos objetos utilizados na realização da tarefa fornece uma base importante para a concepção da representação conceptual (Barthet, 1988) da ferramenta. Isto ocorre na medida em que tal descrição hierárquica induz naturalmente à necessidade de uma descrição semântica, bem como sistematiza a construção da mesma. Nesta descrição semântica deve ser bem definido o significado de cada um destes objetos, bem como as relações que eles mantém uns com os outros e que não ficam claras na hierarquia construída. Por exemplo é preciso definir o que é um "item pasta do tipo debate", e o que é um "item pasta do tipo comum" e mais, que relações há entre estes dois tipos de itens.
A construção desta descrição semântica, por envolver aspectos conceituais e técnicos, que ultrapassam a representação externa destes objetos, deve ser feita em conjunto com a equipe de desenvolvimento do sistema, após o término da análise ergonômica. O que se enfatiza aqui é que a análise realizada fornece um subsídio importante para construção de uma nova e melhor representação conceptual para a ferramenta.
A hierarquia completa das ações realizadas na tarefa
analisada, é descrita no diagrama que segue. Neste diagrama, é
importante lembrar novamente que os nodos marcados em
itálico representam as ações que foram
identificadas como necessárias e devem, portanto, ser contempladas
em futuras versões do sistema.
Descrição hierárquica das ações que compõem a tarefa "Participação num fórum hiperNet utilizando o eduFórum"
|
| -------- conectar / fechar
| | -------- eduFórum (1)
| | ----------------- MOO
| | |----------------eduMOO (2)
| | |----------------favorito (i)
| | |----------------Outros (ii)
| |-------- eduGopher
| |----------------Home (3)
| |----------------favorito(4)
| |----------------Outros (5)
| -------- configurar
| |-------- senha (xviii)
| |-------- eduMOO
| | |--------- servidor eduMOO - home (iii)
| | |--------- Configurar (endereços favoritos)(iv)
| |-------- eduGopher
| | |--------- servidor hiperNet - home(6)
| | |-----------diretório de trabalho no disco local(7)
| | |--------- Endereços (favoritos)(v)
| | |--------- Aplicações para Visualização do Item
| | |--------Arquivo (8)
| | |--------conexão http(9)
| |-------- eduCorreio
| |---------Endereço do remetente (10)
| |---------distribuidor de correspondência (11)
| |---------receptor de correspondência(12)
| -------- navegar e ler
| |
| |-------- eduMOO
| | |---------------- ?
| |-------- eduGopher
| |----------------Abrir/fechar Item
| | |-------Pasta (13)
| | |-------Arquivo (14)
| | |-------conexão com item(vi)
| | |-------conexão gopher(vii)
| | |-------conexão http(15)
| | |-------pesquisa(25)
| |----------------Recarregar Item
| | |--------Pasta (16)
| | |-----Arquivo(remarcar item) (viii)
| |----------------------Imprimir Item
| |------Pasta (ix)
| |------Arquivo-mensagem(x)
| ---------------- editar
|
|-------- eduMOO ?
|
|-------- eduGopher
| |-----------------------Criar Item
| | |-------Pasta
| | | |----comum (17)
| | | |----debate(xi)
| | |------Arquivo (18)
| | |------Conexão com item(xiii)
| | |------ conexão gopher(xiv)
| | |------Conexão http(xv)
| |----------------Substituir Arquivo (19)
| |----------------Mudar Descrição Item (20)
| |----------------Mudar Ordem Item (21)
| |----------------Mover Item (xvi)
| |----------------Remover Item (22)
|
|-------- eduCorreio
|---------enviar mensagem nova (23)
|--------- enviar mensagem resposta (replay) (24)
|---------Repassar mensagem(forward)(xvii)
|---------Redirecionar mensagem (xix)
Os nodos finais destas hierarquias são os procedimentos ou as unidades de análise da tarefa. Daqui em diante estas unidades serão chamadas de operações. A descrição de cada uma delas será apresentada minuciosamente adiante.
Antes porém, ressalta-se que o objeto central da análise efetuada foi o eduGopher, por isso é importante destacar a categorização das ações aplicáveis sobre o mesmo. As duas categorias de mais alto nível de generalização para objetos e ações no eduGopher são descritas abaixo. Como já foi dito a distinção desses categorias generalizadoras foi fundamental no sentido da identificação de ações necessárias e ainda ausentes da tarefa.
Descrição hierárquica das ações que compõem a tarefa "leitura no eduGopher"
/
/-------- natureza da ação
/ |-------- abrir/fechar
/ |-------- recarregar
/ |-------- imprimir
/
/-------- tipo de item
|-------- pasta
|-------- arquivo
|-------- conexão
Descrição hierárquica das ações que compõem a tarefa "edição no eduGopher"
/
/-------- natureza da ação
/ |-------- criar
/ |-------- mudar descrição
/ |-------- mudar ordem
/ |-------- mover
/ |-------- remover
/
/-------- tipo de item
|-------- pasta
|-------- arquivo
|-------- conexão
As descrições feitas listam e hierarquizam as ações que compõe a tarefa "participar num fórum hiperNet, utilizando o software eduFórum". Neste processo de hierarquização são criadas categorias para os operações possíveis e desejáveis no ambiente. Estas categorias criadas já se constituem na própria estrutura de menus da aplicação.
O menu atual, como pode ser notado na figura 14 e na descrição feita abaixo, contém uma organização inadequada, uma vez que guarda pouca ou nenhuma relação com a hierarquia de ações encontrada na tarefa. Há inclusive uma opção "eduFórum" que tem exatamente o nome do software, isso obviamente é fonte de muita confusão.
Na nova proposta que foi formulada, privilegiou-se a organização hierárquica construída e garantiu-se também a previsão de inclusão no mesmo de todo o rol de ações encontrado na hierarquia, mesmo daquelas ainda ausentes na atual versão implementada (destacadas em itálico na hierarquia). Ou seja, foi possível prever uma organização que pode ser expandida na medida em que novas versões forem incorporando o rol dos procedimentos necessários e ainda não implementados. Ficaram ausentes, nesta estrutura de menus, apenas as operações cujo desencadeamento optou-se por manter restrito à manipulação direta dos objetos da interface. Estas ações correspondem à maioria das ações de navegação.
A nova organização do menu, obedece a lógica da realização da tarefa, ou a lógica da utilização, como diria Barthet, uma vez que a hierarquia foi construída a partir das próprias operações identificadas durante o uso da ferramenta. O menu e a barra de ferramentas anterior refletiam ainda a lógica do funcionamento, ou a perspectiva dos projetistas. Por exemplo: a barra de ferramentas já tem botões de configuração, mas não tem botões de navegação; ora, as ações de configuração são bastante necessárias e freqüentes nos ambientes de desenvolvimento, mas não mantém estas mesmas taxas de utilização e de freqüência em contextos de realização efetiva da tarefa.
Na construção da nova proposta de menu foram também consideradas dificuldades inerentes ao próprio vocabulário que foram percebidas durante a observação realizada (tais dificuldades estarão sendo relatadas de forma mais específica na descrição isolada de cada procedimento). Um exemplo, é a denominação de painel de controle para um dos itens de menu, esta denominação não era compreendida pelos usuários. Por isso, optou-se pelo termo "configuração".
Figura 14. Visão geral do ambiente
eduFórum com destaque para a sua barra de menus
Descrição do Atual Menu do eduFórum
Conexões [Conecta... ;
Conecta Gopher;
Conecta eduMOO]
EduFórum [Cria Diretório;
Guarda Arquivo;
Substitui Arquivo;
Remove Item;
Muda Ordem;
Muda Descrição;
[Envia Mensagem]
[Recarrega Automaticamente]
Item [Informação,
Recarrega]
Painel de Controle [Configura Conexões...,
Configura Aplicações para Visualização...,
Configura Endereço de Resposta ]
Janela [segue o Padrão Windows]
Nova Proposta para o MENU
Conexões [conecta gopher hiperNet;
conecta outros gophers...
conecta eduMOO;
conecta outros MOOs...]
[sai do eduFórum]
Arquivo [salva,
salva como...,
imprime...]
Edição [Cria item tipo[pasta...
arquivo...
conexão com item...
conexão com gopher...
conexão com http...]
Substitui arquivo...
Muda descrição item...
Move item
Remove item]
[desfaz digitação
recorta
copia
cola
localiza...]
Correio [envia mensagem...
responde mensagem...
repassa mensagem...
redireciona mensagem...]
Navegação [informa sobre item
recarrega item
remarca item]
[localiza item no servidor...]
[lista arquivos salvos durante a sessão...]
Configurações [servidor p/ conexão eduFórum...
servidor p/ conexão eduMOO...
distribuidor de correspondência...
receptor de correspondência...
endereço do remetente...
pasta de trabalho temporária...]
Os três pontos ao final de uma opção indicam que a operação correspondente não será deslanchada imediatamente após a seleção, isto porque há ainda a necessidade da definição de parâmetros de entrada. Nestes casos será necessária a apresentação de uma janela preliminar com mensagens complementares, indicando quais os parâmetros ainda devem ser definidos e a forma como fazê-lo.
A nova barra de ferramentas também precisa ser mudada. A decisão de inclusão de um botão relacionado a uma operação, depende da intensidade, ou da freqüência, com que a mesma é utilizada. Esta freqüência pode mudar de um usuário para outro (preferências pessoais, demanda de uso da ferramenta, nível de conhecimento da ferramenta,... ), donde é preciso que tais barras possam ser personalizadas. Mas, há algumas operações que são freqüentes para todos os tipos de usuário, ou pelo menos para aquele usuário mais característico ou típico. Estas devem poder ser disparadas por botões específicos que constariam já de uma barra de ferramentas apresentada como opção inicial.
Não foi feito nenhum cálculo de freqüências
para determinar com precisão quais eram as ações modais.
Este cálculo seria bastante importante, mas demandaria um investimento
de tempo que não se justificou. Isto foi considerado pelo fato de
ter havido um grande número de horas de observação direta
da tarefa, o que permitiu que tais ações modais fossem determinadas
intuitivamente de maneira bastante segura, mesmo na ausência dos resultados
quantitativos.
Descrição da atual barra de ferramenta
Botão de conexão com edufórum - deslancha operação 01/conecta
Botão de acesso à janela de "configuração do eduFórum"
Botão de acesso à janela de "configuração
das aplicações de visualização"
Proposta para a barra de ferramentas padrão:
Propõe-se que a nova barra contenha os seguintes botões, já agrupados de acordo com a natureza da ação que representam:
[conexão eduGopher (OP3); conexão eduMOO(OP2)]
[retorno(OP13/fechar); recarrega item(OP16); remarca item(OPviii); informa sobre item]
[envia mensagem(OP23)]
[editor de textos]
Todos os botões indicados com itálico estão atualmente ausentes da barra de ferramentas
O botão editor de textos deve apenas disparar a abertura de uma janela de um editor de textos simplificado. Esta janela conterá, por sua vez, os botões principais de edição que lhe são correspondentes, quais sejam: refazer edição, recortar, copiar e colar, e ainda, abrir e salvar arquivos.
O botão de envio de mensagens, por sua vez, também dispara a abertura de uma janela contendo um editor de textos específico. Além de conter os botões normais de edição, esta janela deve conter também os campos para definição dos parâmetros do cabeçalho da mensagem (endereços de origem e destino e assunto) e também botões de cancelamento e envio da mesma.
Nesta etapa, cada operação cuja granulosidade foi definida nos nodos terminais da hierarquia de ações construída, deve ser descrita de forma bastante detalhada. Esta descrição demandou que o analista voltasse a realizar uma nova etapa de observação da aplicação, a qual não havia sido anteriormente planejada. Isto porque, depois de identificada cada operação, e, também, os problemas que os usuários tiveram relacionados às mesmas, atingiu-se um novo patamar de percepção sobre o ambiente. Desta forma, a partir da experimentação que o próprio examinador realizou, simulando contextos de disparo para as operações que não haviam sido percebidos diretamente nas observações realizadas com os usuários, foi possível conseguir uma descrição mais pormenorizada dos meandros da realização de cada uma delas.
Isto feito, e atendendo as recomendações e o modelo proposto por Barthet (1988), foram construídas as descrições para cada operação. O conjunto completo das descrições englobando todas as operações é encontrado no apêndice III. Cada uma destas descrições contêm:
- condições de disparo ou desencadeamento da operação;
- evento desencadeador ;
- natureza (interativa ou automática);
- status ou condições de precedência (precondições);
- condições de sincronização (paralelismo);
- parâmetros de entrada;
- sucessão de etapas após o disparo, considerando todas os contextos possíveis no momento do disparo envolvendo condições de concatenamento e de status dos parâmetros de entradas;
- componentes da interface que intervêm na realização do procedimento;
- problemas relacionados com a operação, envolvendo os aspectos de: processo, aparência das janelas e componentes da interface, ajuda ao aprendizado e à realização da tarefa.
A inclusão da descrição para a operação "Abrir Arquivo e Conexão http", é feita neste local apenas a título explanatório.
Tabela 26. Características genéricas da operação "Abrir item tipo arquivo e conexões http"
As janelas no ambiente eduFórum que são utilizadas durante a realização da operação são apresentadas a seguir. É preciso ressalvar que a operação "abrir arquivo e conexão http" pode disparar a comunicação com outros aplicativos, tais como navegadores de rede e editores de textos. Desta forma, outras janelas podem indiretamente vir a participar da realização da operação.
Figura 15. Janela de conexão com servidor
gopher
Figura 16. Janela de aviso da transferência
do arquivo
Figura 17. Janela de leitura de mensagem
Descrição das etapas da operação - Processo
Aqui, primeiro se descreve aquelas etapas que seriam observadas numa realização bem sucedida da operação, ou seja, num contexto em que todas as condições de precedência tenham sido satisfeitas e a operação atinge o seu objetivo. Em seguida são descritas as etapas que seriam observadas para o caso em que uma ou mais condições de precedência não tenha sido atendida. Neste caso, são consideradas todas as possibilidades dentre as observadas e previsíveis.
Estando todas as condições satisfeitas, após a seleção do item com um clique sobre a descrição do mesmo na janela de conexão, e após o disparo da operação com o duplo clique, as etapas que caracterizam a operação são:
1. Abertura da janela de aviso da transferência do arquivo com área de sinalização em vermelho;
2.Texto na linha de aviso da janela de transferência:
"Conectando servidor [rota _do_servidor]";
3.Texto na linha de aviso da janela:
"Enviando pedido para servidor [rota do servidor]";
4.Cor da área de sinalização transferida para amarelo.
5.Texto na linha de aviso da janela: "Esperando resposta."
6.O progresso da transferência começa a ser mostrado no interior da janela;
7.Ao final da transferência a cor da área de sinalização transferida para verde;
8.Texto na linha de aviso da janela:
9. A aplicação configurada para visualização é disparada e o conteúdo do arquivo é mostrado, quando for o caso.
No caso de alguma condição de precedência não ter sido satisfeita, ou quando há alguma situação adversa ou peculiar durante a realização tem-se:
Problemas com a OP13/Abrir
Com relação à seqüência ou ao processo da realização da operação
Problemas com as mensagens de erro e de auxílio à aprendizagem.
Problemas com auxílio na realização da tarefa
- a descrição da própria janela de conexão na sua parte superior, que informa sobre o nome da pasta cujo conteúdo está sendo visualizado no momento; e
- a opção item(informação) do menu que abre uma janela contendo: o tipo do item (um código numérico); o seletor (a rota ou ramo do item na estrutura hierárquica); o servidor ao qual se tem acesso e que contém o item); e, a porta que ativa a conexão.
Propõe-se que tal serviço de informações, seja acionável via botão direito do mouse, além do menu, e que inclua também:
-tipo do item - categorizado de acordo com a hierarquia de objetos identificada para a tarefa (eliminando-se o tal código numérico);
-nome do item;
-descrição comentada do item;
-conta do responsável pela criação do item;
-data da criação do item;
-data da última modificação de conteúdo realizada (considerando também as sub-pastas no caso de o item ser uma pasta);
-no caso de itens do tipo arquivo incluir o tamanho do arquivo;
-rota do item (ao invés de seletor) com base nos nomes dos itens.
Dentre as informações que devem ser postas disponíveis uma das mais importantes é a data da última modificação do item. Essa informação sozinha, eliminaria grande parte das operações de navegação realizadas por usuários rotineiros. Por exemplo, ao invés de navegar até a sua caixa de correspondência para saber se alguma correspondência nova foi enviada, o usuário poderia simplesmente solicitar o serviço de informação de uma pasta de nível superior à sua caixa de correspondência. Se ficasse sabendo que nenhuma modificação ocorreu naquele diretório (pasta) desde a última visita feita ao repositório, ele poderia simplesmente suspender a visita, isso diminuiria muito a solicitação de serviços ao servidor, o que poderia inclusive ter um efeito muito importante sobre o desempenho do mesmo.
Na granulosidade julgada adequada para hierarquia que descreve as ações da tarefa analisada, foram identificadas um total de 43 ações. Destas, 25 já estão implementadas na atual versão do eduFórum, e foram descritas e analisadas nos mesmos moldes do exemplo descrito acima. As outras 18 operações ainda estão ausentes na versão implementada e foram identificadas como necessárias durante o processo de análise.
Para estas, apresenta-se a seguir uma descrição breve juntamente com a justificativa ou a razão pela qual a sua necessidade foi detectada.
Ações de conexão e configuração
OPi e OPii - Conexão com outros servidores MOO - Na atual versão o cliente MOO permite conexão apenas com o servidor eduMOO (o servidor do projeto hiperNet). Aqui o que se indica é a necessidade de permitir que o usuário possa usar o mesmo software cliente para conexão com outros servidores MOO.
OPxvii - Configuração da senha - O usuário não tem permissão para mudar autonomamente a sua senha da conta hiperNet. Se quiser fazer isso ele precisa se comunicar com o administrador da rede.
OPiii, OPiv e OPv - Configuração dos endereços do servidor eduMOO e dos servidores favoritos de gopher e MOO - Estas operações só são disponíveis hoje via edição (em editor compatível com DOS ) do arquivo eduforum.ini. É preciso trazê-las para o nível da interface.
Ações de leitura e navegação
OPviii - Recarregar item tipo arquivo - Na atual versão o reload implementado só atua sobre itens do tipo pasta, pois é sempre o conteúdo da janela de conexão já aberta que é recarregado (de uma pasta portanto). Como os itens tipo arquivo quando abertos acabam remetendo para um contexto externo ao do ambiente ( contexto da aplicação de visualização do arquivo), uma vez carregados durante uma sessão não podem mais ter o seu conteúdo recarregado.
OPix e OPx - Impressão de itens tipo pasta e mensagens - Tais itens têm a visualização do seu conteúdo interna ao contexto do eduFórum, e não há nenhuma ferramenta de impressão no ambiente.
Ações de Edição
OPxi - Criação de item pasta tipo debate - O eduFórum permite a edição remota e cooperativa de um repositório gopher a partir da criação de pastas comuns(diretórios) e da inclusão, modificação e remoção de arquivos nas mesmas. Mas, para promover real liberdade de organização e autonomia, é preciso ainda, fornecer ao usuário a possibilidade de ele mesmo organizar grupos de discussão sobre temas que lhe interessem. Isso pode ser possível permitindo-lhe criar também itens do tipo debate.
O item debate já existe no ambiente, mas sua criação não é ainda possível pelos usuários (apenas pelos administradores da rede). Ele se configura numa pasta (ou diretório) que funciona como uma caixa de correspondência coletiva. Os participantes do debate enviam mensagens sobre o tema proposto para esta caixa., estas mensagens ficam, então, todas disponíveis no servidor gopher hiperNet. Ao criar um item deste tipo será preciso definir o endereço do debate e a lista dos participantes inscritos no mesmo.
OPxiii - Criar item tipo conexão com item - Muitas vezes é importante permitir a visualização de um mesmo conteúdo a partir de dois pontos diferentes da hierarquia Gopher (quando um conteúdo interessa aos participantes de dois fóruns temáticos diferentes). Na versão atual ao usuário só resta incluir duas vezes o mesmo conteúdo na hierarquia (nos dois lugares em que ele deve ser visível). O problema pode ser facilmente eliminado permitindo-se ao usuário que ele mesmo faça a inclusão de uma conexão entre dois itens.
OPxiv e OPxv - Criar itens tipo conexão com gopher e conexão com http - Esses tipos de itens já estão presentes na estrutura gopher disponível, mas sua criação ainda não é permitida a partir do cliente eduFórum.
OPxvi - Mover Item - só é possível na atual versão mudar a ordem de apresentação de um item dentro de uma mesma pasta, é preciso permitir que um item possa ser movido de uma pasta para outra.
OPxvii e OPxix - Repassar e redirecionar mensagens - Estas são operações comuns nos sistemas de correio eletrônico que estão ausentes no eduFórum.
As descrições hierárquicas das ações e objetos já feitas apenas abstraem e classificam estes objetos e ações segundo os atributos percebidos como importantes na realização da tarefa. É preciso contudo descrever e analisar a realização da tarefa como um processo que ocorre no tempo. Tal descrição deve incluir as condições precedência, concatenamento, paralelismo, e obrigatoriedade da execução de uma ação.
Na verdade tal descrição já está presente de forma implícita na descrição isolada de cada operação, apresentada no apêndice III. Ao torná-la explícita quer-se apenas ter uma visão mais diretamente focalizada sobre esta característica da tarefa.
Este pode ser um aspecto bastante importante e mesmo fundamental nalgumas tarefas. Inclusive, a maioria das metodologias de análise da tarefa apontam para este aspecto como central. Com o eduFórum, contudo, não é este o caso, pois o mesmo não apresenta grandes dificuldades neste aspecto. Isto se deve à utilização do modelo multi-janelas que permite bastante liberdade no encadeamento ou na seqüência da realização das ações, uma vez que a maioria delas pode ser disparada em paralelo, a partir de janelas independentes. Este é um aspecto muito positivo na tarefa analisada.
As condições de precedência são as encontradas na maioria das aplicações deste tipo. A seqüência mais genérica de ações está descrita a seguir:
Neste diagrama a precedência obrigatória está indicada da esquerda para a direita, e o paralelismo na dimensão vertical. É importante ressalvar que as ações de configuração uma vez realizadas, mantém o seu efeito válido de forma permanente, não precisando ser novamente realizadas a cada sessão. Isto está indicado no diagrama com o uso do tracejamento descontínuo. Outra ressalva diz respeito ao fato de que tais operações de configuração podem ser desencadeadas a qualquer momento durante uma sessão, ou seja, podem ser executadas em paralelo com qualquer outra operação.
As derivações desta seqüência genérica, são, na denominação de Diaper (1989), as seqüências específicas de ações . Um exemplo de seqüência especifica seria:
Combinando diferentes ações de configuração, conexão, leitura e edição relativas a um mesmo objeto genérico (eduGopher, eduMOO e eduCorreio) poderiam ser definidos vários tipos de seqüências específicas. As particularidades destes encadeamentos de ações foram examinadas de forma bem detalhada na descrição de cada operação constante no apêndice III. Note que mesmo várias ações de leitura podem ser desencadeadas em paralelo, o mesmo valendo para as ações de edição. Quando isso ocorre, automaticamente uma nova janela de conexão é aberta para apresentar o resultado da operação.
Por outro lado, é preciso salientar que múltiplas seqüências específicas podem também ser desencadeadas em paralelo.
A simplicidade desta seqüência genérica de ações, e a possibilidade do desencadeamento em paralelo de múltiplas seqüências específicas, demonstra a grande flexibilidade e autonomia que os usuários tem no estabelecimento dos procedimentos efetivos para a realização da tarefa. Ou seja, o nível de repartição da pilotagem entre o usuário e a máquina está muito bem dosado. De outra forma, o que se quer dizer é que o conjunto de ações cujo disparo é feito de forma automática está muito bem definido na aplicação.
Parte da avaliação ergonômica já veio sendo descrita na medida em que a análise da tarefa o foi. No apêndice III foi incluída juntamente com a descrição de cada operação, sua avaliação ergonômica detalhada. Cabe ainda, de todo modo, apresentar aqui um parecer geral sobre a avaliação realizada.
No tocante à funcionalidade da aplicação analisada, como já foi visto, há ainda muito a ser feito, com relação à implementação de operações necessárias e ainda ausentes no sistema.
Na organização dos menus e da barra de ferramentas, ficou bastante clara a importância da realização da análise ergonômica., ali prevalecia a perspectiva do desenvolvimento ou do funcionamento da ferramenta, e não a da sua utilização.
Um aspecto positivo muito importante, relativo a funcionalidade do sistema, que já foi mencionado, diz respeito ao fato de haver uma adequada repartição da pilotagem entre o usuário e o mesmo, ou seja, a definição da obrigatoriedade ou não, dos disparos das operações está razoavelmente bem definida. Na concepção destes desencadeamentos minimais ou genéricos de operações pode-se dizer que a lógica de utilização foi preservada. Há apenas alguns casos de menor importância, de ausência ou presença inadequada de disparos das operações, como no caso da conexão automática com o servidor MOO, quando da abertura do ambiente, ou da ausência do disparo indicativo das operações de configuração quando necessário.
Por outro lado, a grande simplicidade da seqüência genérica de ações existente, ou do procedimento minimal, conforme a denominação proposta por Barthet(1989), e a possibilidade do desenvolvimento de multi-tarefa no ambiente, permite muita flexibilidade na derivação de procedimentos efetivos. Isto dá ao sistema a possibilidade de adaptar a sua funcionalidade aos vários tipos de usuários encontrados.
Ainda com relação a funcionalidade do sistema, há que se destacar que mesmo no caso das operações já implementadas, é preciso ainda de forma geral, implementar outras operações de apoio ou ajuda na realização das mesmas, tais como: mapas de navegação, histórico das atualizações de cada item, possibilidade de repetir e anular as operações realizadas, possibilidade de interrupções, facilidade na transferência de dados entre aplicações e possibilidades de evolução da interface. É importante também fornecer mais informações sobre cada item presente no repositório. As informações disponíveis atualmente refletem sem sombra de dúvida a lógica do funcionamento e são significativas apenas para os projetistas e executores da mesma. É preciso informar na perspectiva do usuário.
As operações de apoio acima citadas já foram detalhadas no apêndice III. Mas, há ainda um outro aspecto geral relativo às operações de edição e navegação no eduGopher, que não foi mencionado e que poderia ser bastante melhorado. O eduGopher permite editar e visualizar remotamente o conteúdo de um repositório de informações, que é organizado segundo o mesmo padrão hierárquico encontrado em sistemas do tipo do DOS (Disk Operational System). A atual versão do eduGopher limita que cada janela de conexão visualize apenas o conteúdo de uma pasta ou diretório de cada vez. A partir de uma janela é possível retornar para a página anterior ou descer mais um nível abrindo uma sub-pasta ou um arquivo da pasta corrente. Seria importante aqui permitir uma visualização mais flexível desta estrutura hierárquica, dando acesso a visualização de mais de um nível da hierarquia num mesmo momento. Para conseguir isso, atualmente o usuário precisa servir-se de alguns ardis e artimanhas, como por exemplo, visualizando várias janelas de conexão ao mesmo tempo, cada uma delas conectando um dos níveis da estrutura hierárquica que se quer analisar.
No caso descrito acima, o que se está salientando é a necessidade de implantar facilidades do tipo das encontradas no "File Manager" do ambiente Windows ( ou Windows Explorer, na versão 95). Um ambiente deste tipo seria de extrema importância, não só pela facilidade de utilização mas principalmente pelo fato de que o mesmo auxiliaria muito os usuários na construção da modelo de organização hierárquica das informações no gopher. Muitos pessoas tem dificuldades para compreender tais estruturas, o que fica evidente na dificuldade que elas apresentam quando precisam realizar uma busca sistemática sobre a hierarquia.
Já as operações de edição no eduGopher são realizadas sempre através da seleção de uma opção num menu que permite a aplicação da operação sobre um item de cada vez. Aqui também sente-se a ausência de visualização da estrutura que se está manipulando, além de ser preciso permitir que tais ações possam ser desencadeadas de forma simultânea sobre vários itens, ou mesmo sobre uma ramificação completa da estrutura. Como por exemplo, remover ou mover vários itens de uma só vez, ou uma pasta com todo o seu conteúdo, incluindo sub-pastas (novamente, como já ocorre em ferramentas do tipo Windows Explorer).
Um outro aspecto importante para usuários iniciantes é a necessidade de ajuda para a compreensão do modelo multi-tarefas implementado através da manipulação do sistema de multi-janelas. Para muitos usuários a construção deste modelo não é simples. A sobreposição de janelas, o acesso a janelas minimizadas, etc, não são situações facilmente dominadas pelos iniciantes. A barra de tarefas, implementada no Windows95, parece ser uma solução interessante para ser transportada para o interior do ambiente eduFórum.
Com relação à linguagem da interação utilizada na organização dos menus, em alguns momentos se privilegiou os termos usados nos ambientes de desenvolvimento. Estes casos foram identificados e corrigidos. Em muitas situações estava preservada, a compatibilidade com a linguagem normalmente usada em domínios similares da tarefa.
Já a linguagem usada para as mensagens de progresso das operações, bem como para a sinalização dos erros, em geral está inadequada. Ocorre com freqüência que sejam utilizados códigos que nada informam, existem mensagens em inglês, etc. Outro detalhe é a necessidade de diferenciar as zonas do monitor que são utilizadas para as mensagens de progresso normal da operação e as mensagens de erros. Em geral as mensagens de erros são apresentadas na linha inferior da janela onde a operação é executada, ou seja, no mesmo lugar em que é comunicado o progresso normal e bem sucedido da operação. Isto confunde o usuário na identificação da existência de problemas e também se configura numa falha grave de homogeneidade com outros ambientes, uma vez que nestes, em geral, mensagens de erro são apresentadas em janelas específicas.
Outro problema grave encontrado na aplicação, relativo a linguagem de interação, diz respeito aos tempos de resposta que o sistema apresenta. Esses tempos são altamente dependentes de processos externos ao próprio sistema e mesmo à configuração da estação de trabalho utilizada. Os mesmos dependem da configuração geral de rede na qual o sistema está operando. Não é possível, portanto, controlá-los a partir da própria aplicação. Apesar disso, é preciso sinalizar melhor ao usuário sobre o estado em que o sistema se encontra na execução da operação, e principalmente quando se tratar de problemas com a conexão em rede que impeçam o desenvolvimento da operação. Esse foi um dos principais problemas percebidos na análise feita, pois ele está relacionado a praticamente todas as operações do ambiente. As soluções percebidas foram indicadas juntamente com as descrições individuais das operações inseridas no apêndice III.
Nenhum sistema de ajuda foi ainda implementado, tanto para o auxílio à aprendizagem quanto para o tratamento dos erros. No segundo caso, o sistema ainda apresenta um nível bastante primário: os erros são apenas mal sinalizados e em geral, nenhuma ajuda é oferecida para a superação dos mesmos. Os sistemas de ajuda estão ainda por serem projetados. Neste caso já se vislumbra a necessidade de sistemas inteligentes e sensíveis ao contexto de trabalho dos usuários, pois a grande flexibilidade e autonomia que o sistema oferece torna difícil a identificação de quando a ação do usuário se configura num erro, isto porque os erros cometidos são em geral erros de intenção e estão associados à distância semântica (conforme Norman apud Coutaz, 1990:47). Os erros de intenção são de identificação muito mais sofisticada do que aqueles erros chamados de execução, que são associados à distância articulatória. Apenas um sistema inteligente, capaz de perceber as sutilezas no contexto do trabalho do usuário seria capaz de detectá-los.
Como já foi dito, a análise efetivada baseou-se de maneira bastante geral numa adaptação do método proposto por Diaper (1989) com aportes conceituais sintetizados principalmente a partir do modelo proposto por Barthet (1988).
Johnson (1989), recomenda considerar na análise da tarefa a necessidade da representação do conhecimento referente: (i)à estrutura taxonômica para as ações e objetos genéricos da tarefa; (ii) a descrição dos procedimentos ou operações da tarefa; e, (iii)à subestrutura orientada à metas ou ao plano para executar a tarefa. A metodologia proposta por Diaper dá conta, com consistência e completitude das representações referentes ao primeiro e terceiro itens mencionados por Johnson. Já com relação à descrição dos procedimentos ou operações constantes da tarefa, a metodologia de Diaper é omissa, e para tal, o apoio conceitual fornecido por Barthet foi fundamental.
Por outro lado, pode-se dizer que a metodologia proposta por Diaper preenche uma lacuna importante percebida no modelo proposto por Barthet no tocante a identificação dos procedimentos minimais e efetivos, conceitos que são fundamentais naquela abordagem. Tais procedimentos correspondem na proposta metodológica de Diaper às seqüências genéricas e específicas de ações.
Mas há uma outra lacuna, que não é apontada por nenhum dos autores citados e que foi percebida durante a experiência prática realizada. Na análise de uma tarefa, a descrição da ação exercida pela pessoa que a realiza deve ser sem dúvida o centro das atenções. Contudo, a ação é exercida sobre um objeto, e este deve ser contemplado como uma das dimensões importantes do conhecimento sobre a tarefa descrita. A representação do objeto precisa merecer mais atenção nas metodologias de análise na ergonomia de software, principalmente porque as aplicações computacionais interativas, são objetos bastante complexos.
Para descrever a hierarquia de classes de objetos componentes de um ambiente interativo, os diagramas e a gramática KRG propostas por Diaper parecem ser uma boa alternativa, desde que se crie a diferenciação entre elos "é uma instância de" e elos "é um componente de". No entanto, a representação completa do conhecimento sobre o objeto, comporta também uma descrição semântica sobre cada instância e classe de objetos. Esta ficou por ser feita, na análise realizada.
Outro ponto que merece ser considerado diz respeito à adaptação realizada sobre a metodologia proposta por Diaper. As modificações consistiram de inclusões e de exclusões. Houve a inclusão da descrição dos procedimentos segundo o modelo proposto por Barthet e da descrição da hierarquia de classes de objetos. As exclusões consistiram:
Apesar de justificadas no contexto em que se realizaram, estas exclusões não seriam desejáveis numa situação idealizada. No caso da representação das hierarquias e seqüências de ações no formato KRG, a mesma não foi realizada pois tal etapa demandaria suporte computadorizado ainda não disponível. No entanto, o uso daquela representação permitiria manipular com muito mais facilidade as seqüências e hierarquias de ações dando mais segurança e facilidade ao processo de determinação das classes genéricas de ações, de objetos e de seqüências de ações.
O cálculo das freqüências das ações, nos vários níveis ou nós da hierarquia de ações, forneceria um subsídio importante para decisões cruciais nas próximas etapas do projeto. Dentre elas: o desenho da barra de ferramentas e dos menus e a definição entre alternativas de implementação, visando otimizar os tempos dos processos empregados. Neste caso a supressão também se justificou pela demanda excessiva de tempo que esta etapa acarretaria. O suporte computadorizado é novamente desejado neste caso.
A importância da utilização desta metodologia foi percebida pelo analista a partir até da sua própria experiência prática. Apesar de já ser um usuário freqüente da aplicação, e de poder ser qualificado como um usuário especialista da mesma, a realização desta metodologia, permitiu ao mesmo um grande salto qualitativo na descrição da aplicação computadorizada e na compreensão tida sobre a mesma. A documentação produzida passou a ter um papel fundamental nas próximas etapas de desenvolvimento da aplicação, principalmente no que concerne a construção dos sistemas de auxílio ao tratamento dos erros e à realização da tarefa.