ÐÏࡱá>þÿ ,.þÿÿÿ)*+ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿì¥Á9 ø¿z¤bjbjýÏýÏ-àŸ¥Ÿ¥z ÿÿÿÿÿÿl.......Bt&t&t&t&, &„B0:ú0'‚²'²'²'²'²'²'²'¯9±9±9±9±9±9±9$*; J=ÜÕ9.²'²'²'²'²'Õ9â2..²'²'ê9â2â2â2²' .²'.²'¯9â2²'¯9â2â2ú889[..£9²'$' `Ñ¿!ÀB2$t&À2“9£9 :00:›9&>À2"&>£9â2BB....ÙERGONOMIA DE SOFTWARE Edla Maria Faust Ramos Introdução A forma como se processa a interação homem-computador é um dos gargalos principais à utilização das ferramentas que o homem vem construindo na área da informática. O acesso simples e não mitificado ao manejo de tais ferramentas é condição básica para a disseminação do seu uso, donde pesquisas nesta área, revestem-se de uma grande importância social e econômica. Key (1990:204), enfaticamente, afirmou que o projeto de interfaces com o usuário ainda está muito longe de tornar simples a comunicação com estas máquinas. O homem lida com ferramentas já há milhares de anos e, é claro, o design de suas interfaces não é um assunto novo, mas até a poucos anos atrás esta não era ainda considerada uma área de pesquisa. Mesmo atualmente, o projeto de interfaces ainda tem muito de arte. Na verdade, um bom projeto de interfaces exige aportes de múltiplas áreas de conhecimento, "não é mais província exclusiva dos analistas, artistas gráficos, pesquisadores em inteligência artificial, ou mesmo dos aficionados em multimídia" (Laurel, 1990:364). Coutaz (1990) define uma interface como um dispositivo que serve de limite comum a duas entidades comunicantes que se exprimem numa linguagem específica (sinal elétrico, movimento, língua natural). Alem de assegurar a conexão física o dispositivo deve permitir a tradução de uma linguagem (formalismo) para outra(o). No caso da interface homem-computador trata-se de fazer a conexão entre a imagem externa do sistema e o sistema sensório-motor do homem. A fabricação da interface pressupõe portanto o conhecimento preciso de cada uma das entidades a conectar, a complexidade do sujeito homem torna esta uma tarefa difícil. O computador não é uma ferramenta comum: "em razão do seu potencial funcional, ele pode ser visto, não como uma simples ferramenta e sim como um colaborador" (Coutaz, 1990:2). Uma ferramenta é um instrumento sem poder decisório, ela é concebida para ser manipulada, o colaborador, ao contrário, participa ativamente da realização do trabalho comum, a sua eficácia depende muito do conhecimento que ele tenha das estratégias do seu parceiro. Essa afirmação de Coutaz, confere um certo nível de antropomorfização ao computador, pois o eleva ao nível de um parceiro na realização da tarefa. "Nessas condições, aquele que concebe um sistema interativo deve elaborar uma descrição o mais precisa possível do problema e dos processos cognitivos do usuário" (Coutaz, 1990:3), para em seguida concretizar o mais fielmente possível esta representação no software. Dessa forma, o sistema pode ser considerado como a extensão eletrônica das faculdades cognitivas do usuário, da mesma forma que uma ferramenta é uma extensão mecânica das suas faculdades musculares e sensório motrizes. Kay (1990), comentando o conceito de agentes da interface, concorda que estas devem buscar formas mais eficazes de cooperação com o usuário. Ele salienta que, como comunicação é a palavra chave nesta área, então, além de analisar como? e o que? o homem comunica, cabe analisar com quem ele se comunica? O homem se comunica em primeiro lugar com ele mesmo e com as suas ferramentas, e em segundo lugar, com seus companheiros e seus agentes. Os computadores pessoais têm, até agora, somente se concentrado na primeira dimensão citada acima. As redes de computadores têm facilitado a comunicação dos homens entre si, mas, nos computadores, com exceção de alguns poucos dispositivos, não existe nada atuando eficientemente como agentes a serviço dos usuários. Kay defende sua proposta alegando que na verdade os homens sempre usaram uns aos outros como agentes prestadores de serviço. Aplicações de computadores que incluam tais agentes, deixam a categoria de ferramentas manipuláveis e passam à classe das ferramentas manejáveis ou administráveis. A metáfora dos agentes também é analisada por Laurel (1990:360), que a considera como o que há de melhor no projeto de interface centrado no usuário: estes agentes devem ser capazes de executar tarefas que exijam especialização, habilidades, recursos e trabalho que o usuário não tenha ou não queira dispor; devem também, ser sensíveis a ponto de poder perceber e interpretar corretamente quais são as necessidades, preferências e dificuldades do usuário; espera-se ainda destes agentes que sejam competentes, ou seja eles devem possuir um meta-conhecimento do seu domínio de atuação e devem ser capazes de representar este conhecimento através de múltiplas formas; por último, na opinião de Laurel estes agentes e seus atributos devem ser facilmente acessíveis aos usuários, um agente seria acessível se o usuário pudesse predizer o que é que ele vai fazer numa dada situação a partir das suas características. Essa metáfora designa que as aplicações interativas devam ser habitadas por serviçais inteligentes, sensíveis e prontos a cooperar de forma efetiva com o usuário. Na visão de Norman (1990) o foco do projeto de interfaces deve se desviar da interface para a tarefa que o usuário quer desempenhar, a interface deve ser centrada no usuário e nas suas metas e objetivos. Centrar o foco na interface, segundo Norman, significa estar preso ao uso das interfaces atualmente existentes, significa pensar em projeto de interfaces, em melhorar as interfaces já existentes. É claro que elas precisam ser melhoradas, mas essa melhora ocorreria naturalmente se o foco do projeto passa-se a ser a tarefa a ser desenvolvida e as necessidades da pessoa que a desenvolverá. . Segundo Norman, as interfaces nesses casos passariam a ser quase imperceptíveis, pois estariam harmoniosamente integradas à tarefa. Para Normam mesmo os computadores deveriam ser imperceptíveis, é o que acontece com os video-games, por exemplo. Norman recomenda como prioridades do projeto: O usuário - o que ele realmente quer fazer? A tarefa - a análise da tarefa. Como o trabalho pode ser feito melhor? tendo em conta todo o cenário no qual a tarefa é construída, incluindo outras tarefas, o ambiente social, as pessoas e a organização. Tanto quanto possível, fazer a tarefa dominar e fazer a ferramenta invisível. Aperfeiçoar a interação, fazendo as coisas certas ficarem visíveis, fornecendo os modelos mentais corretos, ou seja, seguir as regras do bom projeto para o usuário, escritas já um milhão de vezes em muitos lugares. No panorama desenhado até aqui fica clara a importância do aporte de muitas áreas de conhecimento, dentre elas destaca-se a ergonomia que se interessa de maneira geral pelo melhoramento das condições de trabalho. No final da última década começou-se a falar em ergonomia de software, esta disciplina vem concentrando os seus esforços particularmente nas condições de utilização de um software por seus usuários. Para tal, é preciso conhecer o usuário sob várias perspectivas. Destaca-se também a psicologia cognitiva que aborda os fenômenos da aprendizagem, percepção, memória, representação de conhecimento, etc. A psicologia cognitiva permite uma compreensão maior do comportamento do usuário e das conseqüências das suas reações sobre a concepção de aplicações interativas. Para os ergônomos e os psicólogos, a interação homem computador designa o conjunto dos fenômenos físicos e cognitivos que intervém na realização da tarefa informatizada. Um outro argumento muito forte a favor da análise da tarefa na concepção de aplicações interativas vem do fato de que é impossível isolar a concepção da interface das funcionalidades do sistema, pois, para que uma aplicação seja realmente interativa o disparo das operações deve ser dividido de forma cooperativa entre o homem e a máquina. Por outro lado, uma boa roupagem e apresentação do sistema não é suficiente para torná-lo "fácil de aprender e utilizar". Se as funções do sistema não são de natureza a completar as faculdades do usuário, se a sua organização não corresponde a estrutura mental que o usuário tem para a resolução do problema, nenhum efeito de apresentação poderá ser bem sucedido. Kay (1990) sugere que uma interface sofisticada numa aplicação com funcionalidade inadequada, tem o sabor de um molho francês sofisticado com cachorro quente de baixa qualidade. Mas, segundo Coutaz (1990), o terreno em que pisa a área de interfaces ainda está longe de oferecer segurança. As ciências cognitivas apresentam teorias sedutoras mas ainda muito restritivas para permitir boas modelagens dos conjuntos de processos psicológicos. Os modelos quantitativos formais ainda são muito restritivos, e os modelos qualitativos ainda são muito informais, para guiar escolhas por uma via científica segura. Há uma variedade de recomendações praticas que conduzem a situações contraditórias. As hipóteses e as demonstrações experimentais são abundantes e ainda há muito o que ser feito. No contexto descrito acima, este texto dará ênfase aos métodos e modelos existentes nas áreas de confluência da ergonomia e de interfaces, para o que será fundamental a descrição das técnicas de análise da tarefa existentes. Buscar-se-á fazer uma síntese dos principais modelos de aplicações interativas formulados, bem como analisar o seu potencial na avaliação das aplicações interativas, mais especificamente no que concerne à possibilidade da promoção da facilidade de uso e do aprendizado autônomo. O texto descreverá também as principais técnicas existentes para a observação das tarefas informatizadas. A análise hierárquica da tarefa A principal técnica de análise da tarefa existente é chamada de "análise hierárquica da tarefa". Tal técnica foi desenvolvida inicialmente por Annett e Duncan, em 1967 (apud Johnson, 1994:162) , no contexto da ergonomia aplicada às tarefas subjacentes aos processos industriais. Esse método tem sua ênfase na parte pragmática da técnica, ou seja, é uma maneira de fornecer um modelo explícito e legível para o trabalho do operador, apesar disso sua estrutura está baseada num modelo teórico sobre a forma como o homem processa informação. De maneira geral, pode-se dizer que "uma tarefa é uma atividade que é realizada por um ou mais agentes para produzir alguma mudança de estado num dado domínio." (Johnson, 1994:164) Tais agentes podem ser homens, animais ou máquinas. Na realização de uma tarefa as atividades não ocorrem independentemente umas das outras, ou seja, há uma estrutura na tarefa. Algumas atividades são executadas em paralelo, e podem causar, ou mesmo habilitar, a ocorrência de outras. Por atividade aqui entenda-se, a unidade essencial do comportamento juntamente com as demais propriedades do ambiente que incluem determinadas ferramentas ou contextos específicos. O comportamento é, portanto, estruturado, e essa estruturação decorre dos próprios objetos sobre os quais, ou com os quais a ação é realizada, ela é determinada em parte por esses objetos, o agente que realiza a ação deve se acomodar às efetivas condições que o objeto lhe dá. "Todo comportamento intencional humano requer conhecimento de alguma forma, daí segue que, se o comportamento é estruturado então esta estrutura é determinada, ou pelo menos refletida, na forma pela qual o conhecimento que suporta a tarefa é ele mesmo estruturado." (Johnson, 1994 :165). Se essa representação existe na memória das pessoas, então ela poderia ser descrita e incorporada às ferramentas que apóiam a execução da tarefa. Num mundo ideal poder-se-ia imaginar que uma tarefa após completamente conhecida e descrita permitiria, a partir da aplicação de regras lógicas, uma tradução que transformasse esta descrição na especificação detalhada de um sistema. Na verdade os requisitos do usuário e das tarefas são alvos móveis, novos sistemas fornecem novas oportunidades para a tarefa o que gera um novo conjunto adicional de requisitos, ou seja a forma de realizar uma tarefa, e mesmo os objetivos as quais ela se destina, ou os seus critérios de eficácia dependem muito da tecnologia disponível para realizá-la. Um sistema de conhecimento sobre uma tarefa deve então fornecer uma representação sumária dos conhecimentos que foram adquiridos a partir do aprendizado e da execução da mesma. Contidas num tal sistema estão subestruturas taxonômicas orientadas aos objetivos, estas representam o conhecimento de uma pessoa sobre, metas e estados atingíveis, sub-objetivos, planos e procedimentos. Representam também o conhecimento sobre as propriedades dos objetos usados na tarefa e as ações associadas aos mesmos. Dessa forma Johnson(1994) recomenda que a representação das diferentes dimensões em um sistema de conhecimentos da tarefa, dá-se a partir de três componentes: Uma subestrutura orientada à metas, pode ser pensada como um plano para executar a tarefa, esta estrutura determina os objetivos e sub-objetivos e incluem ainda estados condicionais e os estados verossímeis que devem prevalecer quando um destes objetivos é atingido. A consideração que a grande maioria do trabalho humano pode ter o seu objetivo descrito em termos de sub-objetivos, até um nível de detalhamento que assegurem a competência da operação, é um princípio básico assumido na área da ergonomia que orienta a análise da tarefa. Por exemplo, para decorar uma sala temos que 'aplicar o papel de parede', 'aplicar o carpete' e 'pintar o forro'. Para aplicar o carpete ... etc... etc.... Ou seja, assume-se a hipótese de que a resolução de uma tarefa é organizada segundo o modelo de planificação hierárquica. A palavra planificação é adequada pois, a competência operacional nos sub-objetivos não garante a competência do objetivo: é preciso saber quando cada um dos sub-objetivos deve ser atingido (é preciso pintar o teto antes de aplicar o papel de parede), ou seja há a necessidade de uma competência específica que concerne ao estabelecimento de um plano ou estratégia. É preciso saber, também, quando parar de redefinir objetivos em planos e sub-operações, seja por irrelevância destas descrições seja por impossibilidade (tarefas com muitas componentes procedurais/motoras tais como, trocar a marcha do carro ou equilibrar-se numa bicicleta, por exemplo). No último caso, é necessário fazer uma hipótese sobre o processo psicológico da pessoa que desenvolve a tarefa através de uma simulação cognitiva. Procedimentos da tarefa - são unidades simples, ou atômicas, desenvolvidas à medida em que a tarefa é praticada - pode existir mais de um procedimento diferente para atingir o mesmo objetivo ou sub-objetivo - donde há conhecimento condicional e de contexto relacionado aos procedimentos, constitui-se este em regras de seleção do método ou procedimento a ser utilizado - ele está relacionado aos objetos e ações que combinados constituirão uma unidade procedural; Uma estrutura taxonômica para as ações e objetos genéricos da tarefa - os objetos e ações relacionados aos procedimentos são categorizados de acordo com suas propriedades, com os procedimentos onde são utilizados, com suas relações com outros objetos e ações e, ainda, com referência às propriedades de representatividade e/ou centralidade associada com o objeto em uma tarefa dada num dado contexto - é importante também considerar que esta estrutura não é estática, ela muda de indivíduo para indivíduo como também muda para o mesmo indivíduo à medida que aumenta a sua experiência na realização da tarefa. Quanto à forma como deve ser realizada a análise da tarefa, há, em geral, muita bruma. Na verdade, o que se encontra na bibliografia é apenas um conjunto de recomendações do tipo: iniciar com a especificação das razões pela qual a análise deverá ser feita; identificar o objetivo geral da tarefa; identificar os sub-objetivos; identificar as listas de ações/operações e objetos utilizados na realização da tarefa; identificar os planos de ação que englobam a seqüência das operações, envolvendo condições de disparo de uma ação, concatenação, paralelismo, loops, etc.; As recomendações acima são apenas uma descrição das grandes etapas da tarefa de analisar o homem realizando uma tarefa. Na verdade, cada etapa descrita tem dificuldades específicas. É mesmo arriscado afirmar que tais etapas devam ocorrer na ordem cronológica em que foram apresentadas. A primeira questão que surge é como realizar a observação da tarefa, neste campo há unanimidade quanto a importância da observação direta, devendo esta ser realizada junto a vários operadores em diferentes níveis de especialidade e interesse. Sheperd (1990) propõe também a discussão com especialistas e a análise da documentação já existente ( manuais de operação, descrição de rotinas, procedimentos de emergência e segurança, manutenção de arquivos, etc.). Essa observação direta não é tarefa fácil, principalmente quando a tarefa é executada com o auxílio de ferramentas complexas, como é o caso das aplicações computacionais. Técnicas específicas para este tipo de observação foram desenvolvidas e serão apresentadas neste texto aquelas concernentes à observação da tarefa informatizada. Em seguida surge a questão de como representar estas observações, ou seja como representar um sistema de conhecimentos sobre uma tarefa. Nesta área ainda muito precisa ser feito, os resultados obtidos nas áreas de engenharia do conhecimento: inteligência artificial, sistemas especialistas, sistemas de representação do conhecimento podem ser uma fonte interessante de soluções. Alguns autores, limitam-se a sugerir, como Sheperd (1989) a utilização de tabelas ou diagramas hierárquicos. Payne e Green (1989) desenvolveram uma gramática especial a TAG (Task-Action Grammar) para o caso das tarefas informatizadas, esta gramática está baseada na BNF (Backus-Naur Form). Diaper (1989) desenvolveu uma gramática associada a um tipo especial de diagramas, a qual será descrita em detalhes na seção 6.2.1. A importância da análise hierárquica da tarefa no projeto de aplicações computacionais interativas é defendida por vários autores. Barthet (1988) desenvolveu um modelo de projeto destas aplicações que é totalmente baseado na análise hierárquica da tarefa. Este modelo será descrito na seção 6.3.1. Sheperd (1989) analisa de forma mais específica a importância da análise hierárquica da tarefa para o projeto de software interativo. Ele destaca a sua importância segundo os tópicos seguintes. No projeto de manuais para usuários, ou helps on-line, a análise hierárquica da tarefa fornece uma linguagem operacional que facilita a localização de informações e, ainda, estrutura o conteúdo numa forma que é idealmente conveniente à construção de hipertextos (a característica hierárquica da análise pode ser preservada apresentando-a em diferentes páginas com diferentes níveis de descrição). No planejamento de treinamentos, a análise hierárquica da tarefa possibilita a distinção entre procedimentos e conceitos e a sua estrutura fornece um desenvolvimento controlado do treinamento, já que partes da tarefa podem ser consolidadas e praticadas separadamente, livres da complexidade da tarefa toda. Isto pode ser muito útil em vários contextos incluindo até o treinamento baseado em computadores. Um importante aspecto é o do treinamento adaptável, de forma que a expansão da tarefa pode estar relacionada ao próprio progresso do indivíduo. Na redefinição do trabalho, a mesma estrutura da análise hierárquica da tarefa pode ser usada para a sua redefinição gerando um novo agrupamento que seja mais sensível e adequado. Ainda a informação necessária aos planos de tomada de decisão pode ser melhor apresentadas nos dispositivos de monitoramento de processo. É nesse respeito que análise hierárquica da tarefa pode ser usada para o desenho dos conteúdos das telas nas tarefas que envolvem interação homem-computador. Em suma, as técnicas de análise da tarefa são um excelente suporte para o projeto, desenvolvimento e testes de sistemas computacionais interativos. Elas auxiliam desde o momento inicial da análise de requisitos, auxiliam a construção do modelo inicial, a avaliação na fase de prototipação e o desenvolvimento de documentação de suporte para o uso. A proposta de DIAPER: TAKD (Task analysis for knowledge descriptions). Este método está sendo aqui apresentado em detalhes, pois, na bibliografia pesquisada, esta foi a proposta mais completa encontrada, relativamente à construção de uma descrição da análise da tarefa. Percebe-se também a possibilidade de que o mesmo venha a preencher a lacuna observada, na proposta de Barthet, no que concerne à definição do procedimento minimal, que permitirá a construção do modelo conceptual da aplicação computacional "O papel da TAKD (Task analysis for knowledge descriptions) é analisar os dados oriundos da observação de tarefas relevantes e descrevê-los numa forma representacional única e consistente que especifique o conhecimento que os operadores têm sobre a tarefa que desempenham e os objetos (tecnologia) que usam. Na sua forma atual TAKD consiste de um método que gera uma descrição hierárquica da tarefa e de uma gramática de representação de conhecimento (KRG- knowledge representacional grammar)." (Diaper, 1989:109). A TAKD não é restrita às tarefas que tenham componentes fortemente baseados em ferramentas. Neste sentido como toda técnica de análise da tarefa a TAKD pode ser usada em dois estágios distintos do ciclo de vida de desenvolvimento de sistemas computacionais. Ela pode ser usada como uma parte da produção da especificação de requisitos e também com propósitos de avaliação, quando um protótipo tenha sido construído. A metodologia TAKD No coração da metodologia TAKD está uma hierarquia descritiva da tarefa que envolve decisões subjetivas do analista de conseqüência e extensão variadas. Estas decisões são geralmente difíceis pois são indutivas ao mesmo tempo que envolvem uma lógica dedutiva. Os elementos de entrada Os elementos de entrada de TAKD, são as descrições de mais baixo nível da tarefa, estas envolvem dois tipos de listas de entidades: uma lista de objetos específicos e uma lista de ações específicas. Há ainda a necessidade de um terceiro tipo de entrada de baixo nível, são as seqüências específicas ( que serão melhor exploradas adiante). A lista de objetos específicos contém todos os objetos que são relevantes para a performance da tarefa. A definição de um objeto é meio problemática, pois um objeto específico pode ser parte de outro maior. Contudo este problema dos sub-relacionamentos e super-relacionamentos entre objetos é tratado automaticamente na descrição hierárquica da tarefa, isto porque o mesmo objeto pode ser tratado por formas semanticamente diferentes em momentos distintos da realização da tarefa. Existem também objetos que apesar de irrelevantes (pois os executores não aplicam sobre eles ações específicas) não deixam de ser importantes (como a cadeira onde o usuário senta). Em caso de dúvidas sobre incluir ou não um objeto ou incluir dois objetos similares como o mesmo ou diferentes, deve ser aplicado uma heurística conservativa. Esta heurística propõe que: na dúvida inclua-os separadamente pois redundâncias serão tratadas mais tarde e omissões são desastrosas. Contudo, a inclusão de um objeto na lista tem um custo, donde uma heurística secundária deve ser aplicada: Objetos específicos devem ser descritos no mais alto nível possível de consistência com o seu uso pretendido. Ações específicas são os comportamentos executados por uma pessoa e direcionadas a um objeto específico ( não são as ações executadas pelos objetos - computadores ou software). As mesmas heurísticas são aqui aplicadas. A lista de ações é quase sempre bem menor que a lista de objetos, pois as mesmas ações podem ser aplicadas a muitos objetos diferentes. Mas, apesar de menor, a lista e ações específicas é de muito mais difícil identificação, e neste caso a gravação em vídeo e a técnica de post-task walthrough (que serão descritas na seção 6.2.2) são de grande ajuda, principalmente nos casos em que a ação não contém um componente motor visível. Idealizando a descrição hierárquica da tarefa A formalização do processo de construção de uma descrição hierárquica da tarefa tem como base permitir um leque de decisões subjetivas que o analista deve tornar explícitas, informando quando tais decisões devem ser tomadas e permitindo a exploração de diferentes versões da hierarquia, com diferentes níveis de descrição. Uma descrição hierárquica da tarefa deve ser realmente hierárquica e não uma rede ( sem loops). Alguns níveis podem ser repetidos e omitidos. Em qualquer nível existem três tipos de relacionamentos mutuamente exclusivos que podem ser usados: relações XOR - representadas nos diagrama por uma linha vertical "|" - quando um objeto/ação de menor nível puder ser descrito por um ou outro tipo (exclusivamente ) de entidade de maior nível ( este é o mais comum); relações AND - representadas nos diagrama por uma barra "/" - permite que um objeto/ação possua várias propriedades ao mesmo tempo'; é usada apenas nos altos níveis de uma hierarquia: relações OR - representadas nos diagrama por uma chave "{" - quando pelo menos uma dentre um conjunto de propriedades pode ser possuída por um objeto/ação. Não está ainda determinado se uma descrição hierárquica da tarefa deve permitir apenas uma única rota na hierarquia para cada objeto/ação específico. Construindo a descrição hierárquica da tarefa. Notou-se que a construção cooperativa produz melhores descrições. Primeiro é preciso ter muito claro o propósito da construção da TAKD e ainda é preciso que o analista seja bastante familiar com a lista de ações e objetos específicos, que ele irá descrever. O primeiro passo é construir uma descrição de muito alto nível para estas ações e objetos (como no exemplo: novas publicações nas bancas que é apresentado na figura 1). Isto permite ao analista usar uma lógica dedutiva e tomar decisões do tipo 'quais são os nodos de alto nível mais importantes?'. Uma decisão como esta envolve alto nível de subjetividade, pois os nodos de uma hierarquia podem aparecer de muitas formas diferentes e o analista precisa decidir qual é o mais adequado para a análise que ele deseja realizar. Uma descrição hierárquica da tarefa não é construída numa única vez, pois seções inteiras as vezes precisam ser mudadas para reorganização de nodos e níveis, uma vez que o processo é ao mesmo tempo bottom-up (indutivo) e top-down (dedutivo). Na verdade, uma boa dose de intuição e bom senso são necessárias, pois o analista deve sentir quando chegou ao fim da construção desta primeira etapa da descrição hierárquica da tarefa. A próxima etapa é a construção da KRG (knowledge representation grammar), a qual fornece a descrição da rota para os objetos específicos de cada etapa da tarefa, resultando numa lista de sentenças em KRG. Nesse estágio o analista retorna aos dados originais representando-os como uma seqüência de etapas da tarefa que incluirão objetos e ações específicas ou descrições que possam ser recorrentemente representadas sobre estas entidades específicas. A KRG é uma ferramenta analiticamente poderosa para os estágios subseqüentes da TAKD. Uma sentença em KRG consiste de um único objeto/ação genérico que opera com outras GOP's - generic object phrases. As seguintes sentenças em KRG (apesar de não expressarem ações genéricas) re-descrevem os quatro jornais representados na figura 1. Os componentes das mesmas são representados como na descrição hierárquica da tarefa com os seguintes sinais, barras "/..../" para a relação AND, parênteses "(.....)" para a relação XOR e chaves "{.....}" para a relação OR. HYPERLINK "fig1.htm"Figura 1. Uma descrição hierárquica da tarefa permitindo a especificação das novas publicações disponíveis nas bancas. Nota: o exemplo não expressa nenhuma ação relacionada aos objetos classificados K1. The Times NOVAS PUBLICAÇÕES/STATUS(QUALIDADE((GERAL)))/FORMATO (JORNAL(DIÁRIO{COLORIDO}))/ K2. The Observer NOVAS PUBLICAÇÕES/STATUS(QUALIDADE((GERAL)))/FORMATO (JORNAL(SEMANAL{COLORIDO}))/ K3. The Sun NOVAS PUBLICAÇÕES/STATUS(POPULAR((GERAL)))/FORMATO (JORNAL(DIÁRIO{COLORIDO}{MONOCROMÁTICO}))/ K4 The Kensington Post NOVAS PUBLICAÇÕES/STATUS(POPULAR((GERAL)))/FORMATO (JORNAL(SEMANAL{COLORIDO}))/ Fica fácil de ler se separadas em diferentes linhas, da seguinte forma: K1. The Times NOVAS PUBLICAÇÕES /STATUS(QUALIDADE((GERAL))) /FORMATO(JORNAL(DIÁRIO{COLORIDO}))/ No exemplo acima, que é muito simples, todas as sentenças são diferentes. Não é este o caso quando há muitas sentenças e nesse caso uma única sentença poderá representar várias etapas da tarefa (no exemplo: publicações) que são as mesmas. Se duas etapas da tarefa que pareçam ser muito diferentes têm a mesma sentença KRG associada, então a descrição hierárquica está inadequada, ou seja, estão ausentes categorias importantes de classificação (isto tende a ser raro). A KRG permite à TAKD atingir o seu principal objetivo que é a identificação geral de similaridade entre as etapas da tarefa. Esse processo de generalização envolve uma nova representação das etapas da tarefa em um nível mais alto. A generalização é um processo simples de remoção dos níveis inferiores da TDH. Tais cortes devem ser tentados em vários níveis. No exemplo dos quatro jornais, um corte de um nível resultaria em: K1. The Times NOVAS PUBLICAÇÕES/STATUS(QUALIDADE)/FORMATO (JORNAL(DIÁRIO))/ K2. The Observer NOVAS PUBLICAÇÕES/STATUS(QUALIDADE)/FORMATO (JORNAL(SEMANA))/ K3. The Sun NOVAS PUBLICAÇÕES/STATUS(POPULAR)/FORMATO (JORNAL(DIÁRIO))/ K4 The Kensington Post NOVAS PUBLICAÇÕES/STATUS(POPULAR)/FORMATO (JORNAL(SEMANAL))/ Nenhuma generalização foi possível ainda, com o corte de mais um nível tem-se: K1. The Observer and The Times NOVAS PUBLICAÇÕES/STATUS(QUALIDADE)/FORMATO (JORNAL)/ K2. The Sun and The Kensigton Post NOVAS PUBLICAÇÕES/STATUS(POPULAR)/FORMATO (JORNAL)/ Neste nível, as outras publicações citadas podem ser descritas como: K3. Vogue e Country Life NOVAS PUBLICAÇÕES/STATUS(QUALIDADE)/FORMATO (REVISTA)/ K4. Time Out e The Beano NOVAS PUBLICAÇÕES/STATUS(POPULAR)/FORMATO (REVISTA)/ As aplicações de TAKD usaram listas de sentenças genéricas de KRG para uma ou mais tarefas como o produto primário de análise. Elas foram listadas em termos de sua freqüência de ocorrência. Estas sentenças são capazes de informar ao analista quais são as classes de atividades mais comuns na tarefa e, portanto, no caso do projeto de sistemas computacionais e de sua interfaces, elas definem as funcionalidades fundamentais do mesmo, donde elas precisam estar disponíveis com facilidade e segurança. Desta forma "a TAKD fornece um método analítico bem estruturado e empiricamente direcionado para a identificação do que é comum, sendo assim bastante adequado à este papel nos estágios iniciais do projeto de sistemas computacionais." (Diaper, 1989:126) No caso de avaliação de sistemas já existentes (prototipação) a freqüência de ocorrência das sentenças de KRG precisa se comparada com o esforço em efetivá-las. Donde uma TAKD fornece aos projetistas do sistema uma medida de quanto irracional está sendo o esforço dos usuários na operação do sistema. Análise de seqüências KRG A idéia aqui é analisar a repetição de seqüências de sentenças KRG. Seqüências similares poderiam ser representadas por uma Gramática de Representação da Seqüência (SRG), que da mesma forma que a KRG, poderiam reconhecer relacionamentos lógicos entre as sentenças K, particularmente aquelas que são opcionais numa seqüência. Com efeito, a SRG representaria na forma de sentenças o fluxo de um diagrama que descreveria as seqüências mais comuns no comportamento do usuário. A vantagem estaria no fato de que estaria aberto um processo de generalização similar ao usado com as sentenças KRG. Sumário do método TAKD. O método TAKD pode ser sumariado nas dez etapas abaixo, que devem ser efetivadas após ter sido estabelecido o propósito e a destinação da análise: Passo1. A partir dos dados oriundos da observação da tarefa, liste todos os objetos e ações específicas ; Passo2. Construa uma descrição de mais alto nível para a tarefa representando-a no formato genérico de KRG; Passo3. Construa a primeira linhagem da descrição hierárquica da tarefa, usando exemplos de objetos específicos e de ações genéricas e específicas, se apropriado; Passo4. Construa a versão final da descrição hierárquica da tarefa relacionando os objetos específicos aos níveis mais baixos da mesma; Passo5. Calcular a freqüência da ocorrência de objetos específicos em todos os nodos da descrição hierárquica da tarefa; Passo6. Re-descrever cada etapa da tarefa observada no formato de sentenças KRG; Passo7. Gerar as sentenças KRG genéricas removendo os níveis inferiores dos nodos de descrição, após o alinhamento do níveis de TDH até que o número de sentenças genéricas geradas seja adequado e manejável; Passo8. Calcule a freqüência das sentenças genéricas de KRG; Passo9. Interprete as sentenças genéricas de KRG com respeito ao domínio de interesse; Passo10. Repita o passo 6 com as sentenças genéricas de KRG; Passo11. Extraia repetições de seqüências genéricas de KRG e as represente com SRG e finalmente como genéricas SRG. Comentários finais sobre o método TAKD O método chamado TAKD que foi aqui brevemente descrito, ainda está em desenvolvimento, "muitas se não todas as questões discutidas aqui estão correntemente sendo trabalhadas..."(Diaper, 1989:156). Apesar disso, dentre os vários métodos encontrados este parece ser o que mereceu um desenvolvimento mais cuidadoso e abrangente. O processo de identificação das GOP's (generic object phrases) é bastante simples e parece ser uma ferramenta segura para identificar os objetos e ações genéricas dentro de uma descrição hierárquica da tarefa. As zonas nebulosas do método se concentram na etapa da determinação da hierarquia da descrição dos objetos e ações, resta apenas o bom senso para resolver qual a ordem da hierarquia e qual os níveis a serem incluídos, ainda mais que a inserção de mais um nível pode ter um custo alto. Observando o exemplo apresentado, é possível notar que os objetos são hierarquizados a partir de vários atributos e não se percebe qual a importância do uso ou não de um determinado atributo nesta hierarquização. Para complicar, a escolha de tais atributos é fundamental na determinação das GOP's. Quanto a geração das SRG (Sequence Representation Grammar) praticamente nada foi dito, e o próprio autor do método assume que esta ausência é uma das principais fraquezas do. Contudo ele já sugere que deverá propor algo similar à KRG. Uma outra falta que é evidenciada pelo autor, é a de uma ferramenta computacional adequada ao desenvolvimento da TAKD, pois no exemplo citado pelo autor foram consumidas mais ou menos 60 horas para a produção da descrição hierárquica da tarefa, e a maior parte deste tempo na correção de erros que poderiam ser automaticamente controlados. O processo de generalização também é longo e custoso e poderia ser automaticamente efetivado. A observação da interação homem-computador Introdução A análise da tarefa, como já foi várias vezes dito, pode e deve acompanhar todo o ciclo do desenvolvimento de um software, bem como deve abranger não somente os atuais mas também os potenciais usuários do sistema. Este capítulo aborda a questão da observação da tarefa realizada com o suporte de uma aplicação computacional interativa, ou seja, serão descritas as técnicas mais usuais de observação da interação homem-computador. A relevância desse capítulo reside no fato de que a análise da tarefa, da mesma forma que auxilia na modelagem das aplicações computacionais, é um instrumento valioso na avaliação das aplicações já existentes. Observação não é, em geral, uma tarefa fácil. Do ponto de vista psicológico, o mundo sensorial é resultante de um vasto e complexo processo mental que opera sobre a evidência fornecida pelos sentidos, daí tem-se que o mundo sensório e o mundo real são diferentes. "A natureza construtiva da percepção leva os observadores a registrar eventos que são consistentes com suas crenças e expectativas e a efetivamente ignorar ou distorcer aqueles que são contrários a estas mesmas crenças e expectativas..." (Diaper, 1989:212). O mito da objetividade é um indicador da falta de base filosófica que permeia a atividade técnica. Uma frase do tipo "um ponto de vista objetivo" usada tão freqüentemente nesses meios é totalmente contraditória pois 'objetivo' significa 'externo à mente, real' ou 'sem colorações de sentimentos ou opiniões' e qualquer definição de 'visão' evolve uma componente psicológica. "Mesmo ignorando a fascinante mas irrelevante questão filosófica sobre o mundo real existir ou não, é inquestionável o fato de que toda observação pode somente ser subjetiva." (Diaper, 1989:213). Aliado a todos os fatores já mencionados está o fato de que toda observação transposta para uma formalização qualquer (verbal, escrita, diagramática) passa a ser apenas uma sombra pobre da riqueza perceptiva do observador. Há que se considerar também o fato citado como efeito de reatividade, ou efeito de Heisenberg, de que o próprio ato de observar que envolve um ato de introspecção mental transforma aquilo que foi percebido, pois exige do observador um plano sobre o que será percebido. Da mesma forma o ato de observar transforma aquilo que está sendo observado, na maioria das vezes: basta uma pessoa saber que está sendo observada para que o seu comportamento se altere, não importa o quanto desobstrutivo é o observador e o seu equipamento e não há nenhuma solução elegante para este problema. Todos os observadores devem estar dele conscientes no sentido de tentarem minimizar a perda de fidelidade entre uma performance observada e uma não observada. "A rejeição da noção de objetividade é crucial para o entendimento e a apreciação de ambos os componentes, o da observação e o analítico, da análise da tarefa. Ambos envolvem numerosas decisões subjetivas e é preciso estar claro para aqueles que iniciam na área que não há decisões corretas, somente julgamento subjetivos, os quais quando feitos são úteis para um propósito particular." (Diaper, 1989:213). Um outro problema importante de ser tratado nesta introdução é aquele da definição da tarefa, parece que não há muita concordância sobre o que uma tarefa realmente é. A princípio tenta-se fazer uma distinção entre trabalho e tarefa: trabalho seria mais uma implicação contratual e teria uma orientação mais pessoal. Um conjunto de tarefas designado a uma pessoa seria o seu trabalho. Por outro lado, é comum dizer-se que uma tarefa pode envolver uma ou várias atividades. Fica claro que este é um problema de granulosidade, qual dentre as ações listadas a seguir seria uma tarefa? mover o mouse? escrever um texto? administrar uma empresa? A determinação do que é uma tarefa é arbitrária e dependerá da abordagem da análise. Diaper (1989) propõe que uma tarefa não seja uma ação instantânea nem muito duradoura, por exemplo, produzir um documento de 40 páginas é mais do que uma tarefa, é um projeto; enquanto que apagar uma palavra num processador de texto é apenas uma atividade ou ação simples. De forma geral o autor propõe o uso dos termos projeto, tarefa, sub-tarefa e atividade. Outra zona nebulosa é a noção de objetivo da tarefa, note-se que a determinação de tais objetivos é necessária na maioria das metodologias de análise da tarefa. Mas objetivos não são entidades observáveis e precisam ser inferidas dos comportamentos observáveis e das descrições verbais dos executores da tarefa. Mas o mais importante para o sucesso da observação não é definir os objetivos da tarefa é sim definir o propósito da própria observação, e, portanto, a decisão sobre o que observar e o que é irrelevante no contexto da observação. Essa decisão irá orientar a escolha dos meios de observação . Tecnologia de registro da observação da tarefa. As pessoas são sensíveis ao contexto, e tarefas realizadas em ambientes diferentes são diferentemente executadas. Há basicamente dois tipos de ambientes ou formas de registro: a observação se dá no próprio local de trabalho e o único fator estranho é o próprio observador ou ela ocorre em um ambiente simulado e laboratorial. É preciso estar atento, neste segundo caso, para garantir a fidelidade do ambiente. Papel e caneta. Apesar da aparência 'low tech' a utilidade dos métodos que usam papel e caneta não deve ser subestimada, pois eles permitem a observação no mundo real, ou seja permitem a observação de tarefas genuínas. Mas eles podem ser muito intrusos se a pessoa observada quiser saber o que o observador está anotando, além disso podem causar um considerável stress no observador. Outras desvantagens são: eles exigem muita habilidade do observador; fornecem apenas uma descrição de alto nível da tarefa; são muitos trabalhosos e não permitem o 'post task walthrough'. Nos protocolos concorrentes é possível o registro com papel e caneta pois esta técnica retarda a realização da tarefa e fornece o tempo precioso que o observador precisa para registrar suas observações. Outra técnica que permite o uso do registro em papel é o manuseio de esquemas de codificação. Os códigos quando existentes habilitam o observador a um olhar mais aguçado sobre a tarefa, dado que os registros podem ser rapidamente realizados. O uso desta técnica exige um trabalho criterioso de preparação da observação e muita segurança sobre a decisão do que observar. Registro em vídeo. Esta é mais usual forma de registro. É preciso contudo diferenciá-la da observação em si, pois nesse caso faz-se um registro do evento e não uma observação. O uso do vídeo meramente permite a extensão da observação a momentos posteriores ao da ocorrência do evento registrado. O registro pode ser feito no próprio local de trabalho ou em um laboratório especial que deve conter duas salas, uma delas para o equipamento de registro que pode estar equipada com um divisória de vidro que permita visão unilateral. No caso da interação homem-máquina, recomenda-se o uso de três câmaras com saída sincronizada de forma que as três imagens possam ser mixadas numa única fita. Uma destas três câmaras forneceria uma visão geral do operador e do computador, com uma lente grande angular, uma segunda câmara focaria diretamente o vídeo do computador e uma terceira teria foco no teclado e nos dispositivos de entrada. Se o uso de um laboratório nas condições acima não é financeiramente viável, pode-se usar apenas uma câmara focando o vídeo e o teclado. Nesse caso a melhor opção é posicioná-la por sobre o ombro do operador e bastante próxima do mesmo. Dependendo do caso pode-se optar por focar apenas a tela, já que são possíveis inferências sobre todas as entradas efetuadas pelo teclado e mouse. Também é importante acrescentar como parte da imagem gravada um temporizador (relógio digital). Acabada a sessão de observação direta da tarefa, costuma-se dar início a uma sessão de post task walkthrough, esta deve ser também gravada, a câmara deve focar nesse caso a pessoa observada e também a televisão onde estará sendo rodada a fita gravada sobre a tarefa.. Uma recomendação importante aqui, diz respeito ao tempo de duração da tarefa registrada, sempre que uma sessão de walkthrough for realizada: é preciso lembrar que uma sessão de walkthrough normalmente toma o dobro do tempo da tarefa correspondente donde para prevenir fadigas a sessão de observação da tarefa não deve ultrapassar muito o tempo de 20 minutos. Comportamento verbal Entrevistas e outros métodos. A revisão proposta por Cordingley (apud Diaper, 1989), para as técnicas de entrevistas em elucidação de conhecimento, é igualmente apropriada para o caso de interação homem-computador e será aqui , portanto, sumariada nos seus pontos principais: As propriedades principais de uma entrevista são: foco (grau de detalhe associado), estrutura (extensão em que um formato predefinido é utilizado) e sistematização (exaustão pela qual um tópico é coberto). As questões podem ter diferentes formatos (La France apud Diaper, 1989): tipo grand tour, categóricas, definição de atributos, determinação de interconexões, busca de recomendações e checagem cruzada. Outra classificação: abertas e fechadas. Ou ainda: estruturada, semi-estruturada e não-estruturada. Protocolos verbais concorrentes. Esta técnica de análise da tarefa, teoricamente, envolve o usuário explanando o que ele está fazendo enquanto ele faz. Na prática, contudo o que acontece não é bem isto. É uma técnica muito importante para identificar as expectativas que o usuário tem para as conseqüências de suas próprias ações. Esta técnica é o meio ideal para identificar os planos e objetivos dos usuários. A grande desvantagem reside no fato de que o esforço cognitivo exigido para que uma pessoa fale interfere e muito no desempenho da pessoa em realizar a tarefa. Post-task walkthrough - Protocolo verbais consecutivos Envolve o usuário na geração de um protocolo após ter completado a tarefa, de preferência imediatamente após. Para tal é necessário algum registro da tarefa. A grande vantagem é que estes protocolos não interferem na realização da tarefa. O problema é que comentar uma ação após conhecer o seu resultado pode interferir na descrição das suas causas, mas, a grande desvantagem é mesmo o tempo que ela toma. Técnicas de registro da observação da tarefa. O produto final da observação da tarefa e a entrada para a análise é geralmente uma lista de atividades. Esta lista de atividades é geralmente uma descrição em prosa da seqüência de eventos que ocorre na realização de uma tarefa. As duas sessões seguintes descrevem duas abordagens sobre como tal lista de atividades pode ser gerada após a observação da tarefa. Transcrição. Esta transcrição só não é necessária quando a única forma de registro da tarefa foi o papel e a caneta. Caso contrário é necessário produzir de forma escrita a lista de atividades. É um serviço chato e muitos solicitam o concurso de agências especializadas, mas tal não é possível nos casos de registro em vídeo, por falta de pessoal especializado. A transcrição é normalmente uma tarefa muito demorada, e pode ser evitada, já que outras formas de produção da lista de atividades podem ser utilizadas, como o descrito a seguir. Esquemas de códigos. Estes esquemas fornecem uma forma manual consistente, coerente e rápida para registrar a observação da tarefa. Podem ser usados para observação direta com papel e caneta ou para dados registrados em vídeo. O que é crítico no desenvolvimento de um esquema de códigos é a decisão sobre quais eventos devem ser registrados, e, portanto, codificados, o que implica em decidir qual o nível de detalhes a ser ignorado. A produção de algumas transcrições pilotos e amostrais podem ser de grande ajuda no desenvolvimento do esquema a ser posteriormente utilizado. É crucial que tais esquemas sejam abertos e que novas categorias de comportamento possam ser incluídas. Os aportes da psicologia e da ergonomia na modelagem das aplicações computacionais interativas O computador pode ser entendido como mais uma ferramenta disponível à ação humana. A relação existente entre a funcionalidade do sistema computacional e as tarefas que os usuários pretendem efetivar não é simples, uma vez que o sistema tanto deve se acomodar ao trabalho prático num domínio externo ao mesmo, quanto introduz funções adicionais e opções que expandem e amplificam os objetivos das tarefas a serem realizadas. O uso de um sistema computacional envolve o usuário num mapeamento dos seus objetivos na estrutura e funcionalidade do sistema. A complexidade dessa tarefa de mapeamento depende parcialmente dos esforços do projetista em entender e considerar no seu projeto as necessidades inerentes à tarefa. Como já foi dito, a ergonomia se interessa de maneira geral pelo melhoramento das condições de trabalho. Já a ergonomia de software, concentra-se particularmente nas condições de utilização de um software por seus usuários. A psicologia cognitiva permite uma compreensão maior do comportamento do usuário e das conseqüências das suas reações sobre a concepção de aplicações interativas. Mais especificamente, Barthet (1988:20) salienta que a psicologia cognitiva leva a considerar que: existem diferentes tipos de usuário, que por razões variadas, não utilizam a mesma lógica da mesma forma; que existe uma diferença fundamental entre a lógica de funcionamento do computador e a lógica de utilização do computador pelo homem; que se deve distinguir as tarefas previstas das tarefas efetivamente executadas pelo usuário; que as características da memória de curto tempo têm para o homem um impacto direto no dialogo homem-máquina e que uma parte da aprendizagem passa pela formação de automatismos. Além disso, a psicologia cognitiva contribuiu com a criação da hipótese de que a resolução de uma tarefa é organizada segundo o modelo de planificação hierárquica. Nesse mesmo contexto da utilização de um software interativo o ergônomo preocupa-se em estudar a interação homem-máquina externamente, observando (conforme Barthet, 1988:20): a sucessão das operações que é autorizado pelo software; a linguagem da interação, concernente aos dados e comandos trocados entre o homem e máquina aos níveis léxico e sintático; os dispositivos de entrada e saída, juntamente com os de respostas percebidos pelo usuário, bem como, o tratamento dos erros e a ajuda para utilização e aprendizagem. Barthet (1988) apresenta um modelo de aplicações interativas que integra os pontos de vista do usuário, do ergônomo e do analista. Nesse modelo, a perspectiva do analista será considerada na Representação Conceptual do software, esta descreve a lógica geral do novo sistema. No mesmo modelo, a Representação Externa incorpora o ponto de vista do usuário, ou seja corresponde à visão externa e às possibilidades de manipulação do software. A implementação das duas representações anteriores dá-se na Representação Interna que corresponde ao ponto de vista do programador. As interações entre a representação conceptual e externa e os aportes de conceitos vindos da psicologia cognitiva e da ergonomia são apresentadas no diagrama a seguir: HYPERLINK "fig2.htm"Figura 2. Aportes da ergonomia e da psicologia cognitiva à concepção de aplicações interativas, conforme Barthet (1988:21). Outros autores como Coutaz (1990) também destacam essa diferenciação existente entre as várias visões de um mesmo software. Coutaz expressa essas diferenças construindo os conceitos de modelo de concepção e modelo do usuário. Ele recomenda: aquele que concebe a ferramenta tem por tarefa definir uma imagem para a mesma que conduza o usuário a construir no curso da interação um modelo compatível com o modelo de concepção. No caso dos computadores pode ainda intervir um terceiro tipo de modelo, o modelo do próprio usuário, que a ferramenta é capaz de construir, com o auxílio de um programa inteligente. Tais modelos permitem a interface evoluir dinamicamente em função do seu usuário. Carey (et alli, 1989) também aborda a questão da modelagem das aplicações interativas. Para estes autores o modelo conceptual do projetista de um sistema computacional está logicamente organizado sobre estrutura de dados e processos que operam sobre estas estruturas. Ações sobre a interface desencadeiam estes processos e produzem modificações sobre a estrutura interna dos dados, estas poderão ser visíveis, ou não, na tela. . Num certo sentido o modelo do projetista está no nível da máquina (em termos de bits, strings, etc.), mas o projetista também desenvolve um modelo de nível de abstração mais alto em termos dos objetos manipulados pelo sistema e perceptíveis pelos seus usuários (mails, parágrafos, diagramas, etc.). A combinação e a inter-relação destas duas visões conceituais formam o modelo conceptual que o projetista tem do sistema. Na percepção dos autores citados, o modelo conceptual que o usuário tem do sistema também pode ser visto segundo diferentes níveis: Nível procedural do conhecimento do usuário - é o menos sofisticado e está relacionado com o aprendizado estrito de seqüências de comandos com objetivos imediatos (o sistema é tratado pelo usuário como uma caixa preta). Ele sabe o que quer e o que fazer para obter tais resultados, mas não tem nenhuma idéia sobre os estados internos do sistema. Sem construir um modelo mental sobre o funcionamento do sistema, a maioria dos usuários não conseguirá sucesso em operá-lo. Sem instrução e ajuda tais modelos geralmente são simplistas, superficiais e cheios de erros. "Em alguns casos tais modelos podem envolver antropomorfização do sistema, atribuindo ao mesmo características humanas e motivações" (Carey et alli, 1989: 58). Estes modelos tem natureza explanatória e não descritiva pois só permitem ao usuário observar a causa das ações ocorrerem não lhe dando base para construir novas composições de comandos. Nível sintático do conhecimento do usuário - À medida que aumenta a percepção sobre a estrutura interna da linguagem de comandos do sistema, o usuário tem a possibilidade de construir novas complexas combinações de comandos, bem como tem uma maior capacidade de diagnose de erros. Num certo sentido o conhecimento agora passa a ser preditivo, já que os princípios de agrupamentos de comandos passam a ser percebidos e utilizados. Nível semântico do conhecimento do usuário - agora o usuário está consciente a respeito da estrutura conceptual interna do sistema computacional, envolvendo os objetos conceituais, seus atributos e estados possíveis bem como a forma pela qual os comandos alteram esses atributos e estados. Agora o usuário é capaz de raciocinar sobre o sistema diagnosticando problemas que ocorrem durante o seu uso e planejando operações complexas. Barthet (1988) destaca que os principais conceitos que a ergonomia e a psicologia cognitiva fornecem no sentido de orientar o analista na concepção de aplicações computacionais são os conceitos de imagem operativa, de planificação hierárquica, as diferenciações entre usuários novatos e experientes e, ainda, as noções de tarefa prevista e tarefa efetivas. Imagens operativas são as imagens mentais que acompanham a ação no trabalho. Sempre que uma pessoa se confronta com um objeto com o qual ela deva interagir, ela faz uma representação mental desse objeto. A imagem operativa é sempre um subconjunto da estrutura integral do objeto que retém apenas aquelas relações presentes na estrutura integral que são necessárias ao desenrolar da ação. Dois são os aspectos principais desta representação: o laconismo - a imagem é apenas um recurso da ação, ela não retém do objeto nada além das propriedades necessárias à ação; a deformação funcional - a imagem operacional é uma réplica deformada do objeto, a deformação constitui-se num artifício para acentuar o que é funcionalmente importante para uma dada tarefa. Do conceito de imagem operativa, podem ser retiradas três idéias para as aplicações interativas: A noção de laconismo é muito importante para a concepção do vocabulário e da sintaxe dos diálogos. Para os usuários não especializados ou ocasionais, certamente, a solução do problema do diálogo passa pelo estudo e compreensão da linguagem natural. Já os especialistas usam um vocabulário especializado, operativo, não ambíguo que seja funcional e adaptado ao tipo de tarefa. O analista de sistemas e o usuário tem uma pequena chance de possuir a mesma imagem operativa para determinada tarefa. O analista tem uma visão global e abstrata dos procedimentos para tratamento de informação, ao passo que o usuário tem uma imagem local e concreta da mesma tarefa. A imagem operativa e o processo de decisão variam segundo o grau de experiência dos usuários. De fato pode-se prever apresentações diferentes do mesmo software dependendo do nível de experiência do usuário. Já a planificação hierárquica diz respeito a forma pela qual o usuário representa o trabalho ou a ação que irá executar para atingir o seu objetivo. A imagem operativa é, de certa forma, estática e corresponde as estruturas de dados, já a planificação hierárquica é dinâmica e corresponde a estrutura dos procedimentos. A planificação hierárquica tem como hipótese o fato de que o usuário irá elaborar um plano de ação a partir do objetivo que ele espera atingir. A análise destes planos de ações explicita a lógica de utilização do usuário, por outro lado, a invariância de sub-objetivos entre vários planos de ação pode servir de elemento construtivo da representação conceptual do software. A análise hierárquica envolve uma hierarquia descritiva da tarefa, esta por sua vez, envolve decisões subjetivas do analista de conseqüência e extensão variadas. Estas decisões são geralmente difíceis pois são indutivas ao mesmo tempo que envolvem uma lógica dedutiva. E a indução não é um processo bem conhecido nem filosoficamente, nem heuristicamente. A planificação hierárquica corresponde a uma descrição da trabalho orientado a um objetivo. O ponto de partida é o resultado da ação (top-down). Isso não é usual na concepção dos sistemas de informação a qual é baseada nas descrições dos procedimentos, partindo, portanto, dos eventos de entrada (bottom-up). Ainda, uma abordagem não é simplesmente a inversa da outra. pois: "...na descrição orientada pelo objetivo, se obtém um conjunto de operações necessárias a realização do mesmo, procedimentos diferentes serão re-agrupados quando se referirem ao mesmo objetivo. Esta descrição permite descrever facilmente todos os paralelismos e corresponde a lógica de utilização; -na descrição orientada a eventos, se obtém um encadeamento de operações deslanchadas por um dos eventos iniciais; esta descrição corresponde a lógica de funcionamento do sistema de informação; os diferentes procedimentos são descritos independentemente de sua utilização." (Barthet, 1988:37) Para a concepção das aplicações interativas, a distinção entre lógica de funcionamento e a lógica de utilização é muito importante. Com efeito, as várias formas de software interativo são elaboradas e apresentadas ao usuário segundo uma lógica de funcionamento. As lógicas de utilização só podem ser percebidas através de observação direta em postos de trabalho existentes e eventualmente podem ser completadas por experimentação de um protótipo. Quanto à diferenciação entre usuários novatos e veteranos é preciso explicitar quais são exatamente as diferenças entre estas duas categorias e como ocorre a aprendizagem, ou como acontece a passagem de uma fase para a outra. Já foi dito que existem diferenças significativas no nível da construção de imagens operativas e de deformação funcional entre usuários mais experimentados e novatos. Pode também ser notada uma diferença entre procedimentos escolhidos e resultados obtidos na realização de um mesmo objetivo. Como exemplo pode-se considerar um grupo de controladores de torres de aeroporto, uns mais experientes e outros menos. Quando ocorre uma situação de conflito de rotas, os mais experientes se mostram muito mais prudentes nas decisões que tomam, do que o novatos. Quanto a aprendizagem do uso de um computador Barthet (1988) remete-se à questão da diferença entre a lógica de funcionamento e de utilização, estudada por Richard (1983). Na perspectiva da lógica do funcionamento o usuário aprende o funcionamento da máquina e os efeitos que os comandos da linguagem provocam (Se P então Q). Já da perspectiva da lógica de utilização, aprende-se como fazer para se chegar a um determinado resultado (Se o objetivo é Q então P). É em geral muito difícil a visualização da passagem de uma lógica de funcionamento para uma lógica de utilização, pois o procedimento a ser elaborado para se atender um objetivo, não pode ser deduzido diretamente do conhecimento das regras de funcionamento, é necessário modificar a representação do problema decompondo-o em sub-objetivos compatíveis com o funcionamento da máquina. Neste sentido é preciso implementar ajudas que especifiquem as ações possíveis e os procedimentos relacionados. A modelagem proposta por Carey (1989) também aponta como fundamental a análise do modelo mental que os usuários têm do sistema (ou dos objetos) com os quais operam, e a diferença, neste caso, dos usuários novatos para os veteranos pode ser analisada nos três níveis de modelos conceituais que os usuários elaboram sobre o sistema. Carey e Barthet, concordam, portanto, a respeito do fato do usuário novato não conseguir fazer o mapeamento entre as lógicas de funcionamento e a lógica de utilização. Ele as percebe separadamente, ou seja, não consegue decompor os objetivos da tarefa em sub-objetivos expressáveis através das operações conhecidas do sistema. A variabilidade da execução de uma tarefa e o seu impacto no projeto de aplicações interativas também é considerada no modelo de Barthet. A tarefa prevista é a tarefa concebida por aquele que comanda a sua execução e sua descrição está completa quando permite a sua execução imediata, não requerendo do sujeito nada mais do que a sua execução. Já a tarefa efetiva corresponde ao que o usuário faz efetivamente, ela não é somente um decalque da parte observável da atividade . A atividade é o resultado de se executar uma tarefa. A noção de tarefa inclui a definição de um objetivo (etapa final ou desejada) e o conjunto de etapas que devem ser percorridas para atendê-lo (sub-objetivos). Nesse contexto chamar-se-á procedimentos a um conjunto de operações que permitem percorrer de tais etapas. O mesmo pode então ser descrito a partir da lista destas operações e da lista dos pré-requisitos que exprimem quais condições que devem ser realizadas para cada operação possa ser efetuada. A noção de procedimento permite aclarar o peso que a variabilidade da execução de uma dada tarefa tem na construção da representação conceptual de um software interativo. Basta notar que uma tarefa com idêntico objetivo pode ser realizada a partir de vários procedimentos. Donde cabe descrever: O procedimento previsto - correspondente ao procedimento padrão ou recomendado que é na maioria das vezes aquele que é reconhecido espontaneamente pelo analista. O procedimento efetivo - é aquele efetivamente executado pelo usuário é que somente pode ser reconhecido através de observação. O procedimento minimal - é a seqüência mínima de operações e de encadeamentos necessários para que o objetivo da tarefa possa ser considerado como atendido. Para uma mesma tarefa dada existe, portanto, um procedimento minimal, um procedimento previsto e vários procedimentos efetivos. Os procedimentos efetivos e os procedimentos previstos devem ser compatíveis com o procedimento minimal. HYPERLINK "fig3.htm"Figura 3. Os vários procedimentos na realização de uma tarefa (Barthet, 1988:49) O modelo de BARTHET O modelo proposto por Barthet leva em conta os pontos de vista do ergônomo, do usuário e do projetista que já foram explicitados. Esta proposta considera que ao se modelar uma aplicação interativa é necessária a construção de três representações diferentes. O ponto de vista do analista será, nesse modelo, considerado na Representação Conceptual do software. A representação conceptual descreve a lógica geral do novo sistema e em seguida a lógica dos tratamentos relativos a um posto de trabalho, nesta segunda fase devem ser incorporados os elementos de psicologia cognitiva ligados ao usuário. A Representação Externa incorpora o ponto de vista do usuário, ou seja corresponde à visão externa e as possibilidades de manipulação do software. Esta compreende duas partes, a primeira é a tradução dos elementos da representação conceptual que interferem na interação homem-máquina e a segunda compreende a definição de todos os elementos específicos à mesma (que correspondem à noção de interface). Nesta representação são integrados todos os elementos da ergonomia A implementação das duas representações anteriores dá-se na Representação Interna. Esta corresponde ao ponto de vista do programador e não se faz acompanhar de nenhuma especificação nova concernente ao usuário, nem integra, portanto, elementos suplementares de ergonomia. A ordem da apresentação corresponde à ordem usual da concepção como o indicado no esquema que segue: HYPERLINK "fig4.htm"Figura 4. As três representações na concepção de uma aplicação interativa (Barthet, 1988:19) Barthet apresenta juntamente com o seu modelo de aplicações interativas um conjunto bastante consistente de recomendações ergonômicas. Estas recomendações serão também apresentadas neste texto, juntamente com complementos importantes que foram encontrados na bibliografia pesquisada. A Representação Conceptual O conceito de representação conceptual é central na modelagem proposta por Barthet. Os aportes da psicologia cognitiva a esta representação dizem respeito à forma do processamento da informação e à sua variabilidade. Quanto à representação dos processos de tratamento de informação dos usuários é importante relembrar que: o conceito de planificação hierárquica permite descrever o trabalho do usuário a partir dos objetivos que ele mesmo fixa, remontando uma seqüência de operações e de pré-requisitos necessários a realização dos mesmos; a diferença entre a lógica de utilização e a de funcionamento permite a estruturação de menus segundo uma lógica de utilização aliada a lógica de funcionamento. Já a variabilidade destes processos de tratamento está ligada a dois fatores: a deformação funcional da tarefa proveniente dos diferentes objetivos dos diversos usuários e também do nível de experiência profissional dos mesmos; a diferença entre a tarefa prevista e as tarefas efetivas; A Representação Conceptual é formada em parte pelas descrições dos dados dos tratamentos, que são uma porção da interface ( o resto é definido no nível de Representação Externa), e de outra parte pela representação dos processos de tratamento da informação do usuário e pela variabilidade destes processos de tratamento. Na Representação Conceptual é necessário distinguir os parâmetros variáveis, provenientes das características particulares de uma aplicação, dos parâmetros constantes que estão presentes em todas as aplicações interativas. Os parâmetros variáveis são oriundos da análise do trabalho, trata-se, por exemplo, dos objetivos ou da lógica de utilização. Os parâmetros constantes são definidos pelas características gerais dos usuários; trata-se, por exemplo, das possibilidades de interrupção ou de transferência de dados . Nas aplicações interativas, uma das principais decisões diz respeito à divisão do controle (pilotagem) da execução das operações entre o usuário e o computador. Essa "pilotagem" envolve desde a decisão do disparo até a regulação das condições de execução da mesma. Barthet (1988), trata esta questão estratégica, com o conceito de latitude decisória, correspondente à parte de pilotagem que é de responsabilidade do usuário. Este conceito sintetiza as várias noções apresentadas que são básicas na construção de representação conceptual. O controle da execução de uma aplicação interativa é dividido implicitamente entre o homem e o computador segundo proporções muito variáveis que podem evoluir entre duas situações extremas que vão desde a pilotagem completamente automatizada até a pilotagem completamente assumida pelo usuário. Quando a pilotagem, é deixada inteiramente nas mãos do usuário, nenhuma seqüência de telas é imposta ao usuário, que pode ativar os procedimentos dentro de uma ordem completamente livre. Isto resulta em que: nenhum controle será efetuado para que haja coerência entre as atitudes e o objetivo fixado; e mais, o computador não poderá utilizar o máximo de suas possibilidades já que será privado, por exemplo, da possibilidade de fazer encadeamentos automáticos ou inferências. O contrário acontece quando a pilotagem é completamente deixada a cargo do computador. Nesse caso, haverá uma garantia máxima de coerência nas ações do sistema de informação, em detrimento da flexibilidade e da criatividade que cada usuário pode imprimir ao sistema e da facilidade de integrar de incorporar os acontecimentos aleatórios. Daí a necessidade da criação de um modelo que explicite claramente o que deve ser controlado pelo usuário e o que deve ser controlado pelo computador. É exatamente o conceito de procedimento minimal que define, para uma dada tarefa, o nível de controle que deverá ser dado à máquina, pois estão implícitos no mesmo os limites da faixa de decisão do usuário. Com efeito, tudo o que não estiver explicitamente definido ao nível do sucessão e do desencadeamento das operações dentro do procedimento minimal, será considerado como exposto à decisão do usuário não sendo objeto de nenhum controle sistemático da máquina. "A partir do procedimento minimal, o usuário pode definir um procedimento previsto (ou padrão) e um ou mais procedimentos efetivos que ele utilizará a sua conveniência e que serão descarregadas dentro de casos comuns aos repertórios do controle de execução do procedimento. Mas ele poderá a todo momento retomar a "direção" a fim de impor seu próprio controle (dentro dos limites de sua latitude decisória) face a uma situação não prevista." (Barthet, 1988:51) O procedimento minimal pode então ser definido a partir do procedimento previsto do qual serão retiradas as regras de coerência correspondentes ao controle que será deixado ao computador. Estas se constituem em: de um lado, as regras de gestão indispensáveis para assegurar coerência e a sobrevida do sistema; por outro lado, as regras de comodidade de uso, ditas de bom senso, que podem ser transgredidas sem pôr em caos o sistema. Para poder melhor entender como deve se dar a divisão de controle entre o homem e o computador torna-se necessário definir com mais precisão as propriedades das operações e dos pré-requisitos que fazem a ligação entre a estrutura dos tratamentos e dos dados. Propriedades das operações Uma operação será, então, definida como uma seqüência de transações que podem ser executadas consecutivamente. Será descrita por suas entradas, sua natureza, a sua condição de disparo, seu status e suas saídas: As entradas, são a lista de eventos que podem permitir seu desencadeamento. A natureza será interativa ou automática. Uma operação é interativa se desencadeia uma conjunto de ações que podem ser divididas entre o usuário e o computador. Uma operação é automática se desencadeia apenas ações realizadas pelo computador. O status ou a possibilidade de execução traduz-se no fato de poder ser ativada ou não: uma operação é ativada se todas as condições dos pré-requisitos são realizadas. As saídas são os eventos que podem desencadear outras operações. Propriedades usuais dos pré-requisitos Aqui cumpre explicitar duas noções distintas: a noção de sincronização, e a noção de precondição. A sincronização pode ser definida a partir de proposições lógicas (booleana) que comportarão as condições de entrada de uma determinada operação Oi. Por exemplo (A .e. B) .ou. C constitui uma regra de sincronização, ou seja o evento Oi só deve ser ativado se os eventos A e B forem realizados ou se o evento C for realizado. A sincronização é também associada à noção de delay correspondendo a uma regra de tempos relacionados ao desencadeamento de uma operação Oi se esta puder ser ativada. Tem-se então: delay livre - A execução de Oi pode acontecer não importa o momento que acontece a ativação. delay com limite - A execução de Oi é desencadeada depois de uma data Di e antes de uma data Do. As pré-condições exprimem uma condição sobre o valor do dados contidos dentro do evento, condições que devem ser validadas para que o evento seja considerado como realizado. Os pré-requisitos expressam a noção de precedência entre operações numa linha de prioridade de execução das mesmas. Se P(Oi,Oj) for satisfeita tem-se que Oi deve ser executado antes de Oj. Propriedades ligadas à pilotagem Finalmente é possível definir melhor a questão da divisão da pilotagem (ou controle) entre o homem e a máquina: Uma operação é obrigatória ou facultativa. Ela é obrigatória se sua execução, quando está ativada, é necessária para atender ao objetivo, no outro caso, ela é dita facultativa. A operação obrigatória é controlada pelo computador e a facultativa é pilotada pelo usuário que controla, então a sua execução. Quanto ao desencadeamento de uma operação, ele é opcional ou sistemático. É opcional se depender do usuário. É sistemático se depender do computador. A precedência é permanente se ela existe dentro de todas as descrições procedurais da tarefa (procedimento minimal, previsto e efetivo). Ela será indicativa se existir dentro de um ou vários procedimentos efetivos ou previstos mas não no procedimento minimal. As precedências permanentes são todas controladas pelo computador enquanto que as indicativas o são pelos usuários. As noções que nós vamos definir são válidas para todos os procedimentos sem distinção de procedimento minimal, previsto ou efetivo. O procedimento minimal exprime o controle minimal sobre o usuário: ele atrela uma pilotagem máxima de seu trabalho ao usuário. Os procedimentos previstos e efetivos são variantes possíveis do procedimento minimal que de uma parte restringem a pilotagem do usuário e de outra parte facilitam seu trabalho ( encadeamentos automáticos, tutoriais...). As operações facultativas tem o seu desencadeamento necessariamente opcional já que será o usuário quem dirá se a operação será ou não desencadeada. Donde a seguinte implicação: Facultativo Opcional, que é equivalente a Sistemático Obrigatório Note-se que o desencadeamento sistemático não pode ser concluído se uma operação é obrigatória. Quanto a natureza, interativa ou automática, de uma operação, ocorre que tanto umas quanto outras podem ter o seu desencadeamento opcional ou sistemático, donde natureza e desencadeamento independentes. São também independentes do caráter obrigatório ou facultativo Correspondências entre procedimentos previstos, minimais e efetivos É preciso verificar a compatibilidade entre o procedimento previsto e o procedimento minimal e também entre um procedimento efetivo e o procedimento minimal. Um procedimento previsto para um posto de trabalho e um dado objetivo, é descrito por uma lista de operações e uma lista de pré-requisitos. O mesmo corresponde a um procedimento padrão que é executado dentro de um caso normal ou por um guia de um usuário novato. Ele contém os mesmos elementos que o procedimento minimal, os quais têm a seguinte interferência na pilotagem: suprimem desencadeamentos opcionais; acrescentam precedências indicativas; aumentam as operações obrigatórias ou as precedências permanentes. Um procedimento minimal e um procedimento previsto são compatíveis para um mesmo objetivo se todas as operações obrigatórias, todas as precedências permanentes e todos os disparos sistemáticos presentes no procedimento previsto forem incluídos no procedimento minimal. Esta inclusão é fundamental porque ela permite ao analista ter segurança sobre o fato de que o procedimento minimal que ele irá definir lhe permitirá a execução do procedimento previsto correspondente. Os procedimentos efetivos tem a mesma definição de compatibilidade em relação ao procedimento minimal. A distinção entre um procedimento previsto e um procedimento efetivo é de ordem metodológica, apenas, já que o procedimento previsto corresponde geralmente a primeira observação da tarefa e os efetivos às variantes possíveis, que serão definidas à medida das necessidades. Os Parâmetros Constantes da Representação Conceptual Os parâmetros constantes constituem a ajuda ao usuário. A característica geral destes parâmetros faz com que eles não necessitem ser especificados para cada aplicação. A ajuda na realização de atividades será distinguida da ajuda na aprendizagem e na possibilidades de evolução do software. Ajuda ao Trabalho Esta noção, é particularmente importante, para todas as operações de consulta que vão necessitar que uma outra operação esteja ativa. A hipótese é a de que num sistema mono-posto todas as operações são possíveis a todo o momento. Para os sistemas time-sharing é necessário que o sistema gerencie "conflitos" devido a abertura múltipla de arquivos. Transferência de Dados - é dada ao usuário a possibilidade de transferir um dado de uma aplicação a uma outra sem precisar reescrevê-lo. Esta função permite minimizar os embargos e evitar os erros de digitação. Interrupção - a interrupção permite ao usuário sair, não importa qual a operação esteja em curso de execução, para ir executar uma outra operação e retomar a primeira do ponto de interrupção. Pode-se prever vários níveis sucessivos de interrupções, apesar de que concretamente, os usuários não ultrapassem o terceiro ou quarto nível. Saída (Quitter) - o usuário pode precisar abandonar seu trabalho a qualquer momento ou ir para um outro item do menu. O software deve sinalizar as conseqüências desta atitude, conforme o lugar onde o usuário se encontre. Retardar - o usuário pode querer retardar não importa qual operação dentro do tempo. Retardar se distingue da saída porque dentro da ação de retardar existe a memorização da tarefa não terminada, e isto, não acontece na ação de saída. Anular - o usuário pode anular a última ação que foi realizada, esta possibilidade é particularmente útil para que se possa corrigir erros cometidos pelo usuário ou assinalados pelo software. Memorização da Atividade - este modelo de interface não impõe um quadro rígido ao operador. São vários os tipos de memorização que serão então propostos: entre as sessões, o registro, por um usuário das operações retardadas no tempo, este registro vai permitir a todo o momento conhecer o conjunto de operações que estão em curso e que vão terminar uma jornada; entre as sessões a memorização dos parâmetros próprios do usuário: identificação, vocabulário próprio, procedimentos efetivos...; numa sessão, o registro das interrupções sucessivas e não terminadas, isto permite principalmente que o usuário não se perca dentro do software, em particular se este for interrompido por um evento externo; durante uma sessão pode-se ter uma trajetória do trabalho total ou pelo menos das duas ou três últimas operações realizadas, afim, de poder retomar facilmente a etapa precedente do sistema. Ajuda na Aprendizagem Aqui trata-se do auxílio à aprendizagem de manuseio do software interativo e não do trabalho em si. Barthet recomenda a existência de dois guias: Guia Funcional - um comando do tipo S.O.S. deve permitir ao usuário conhecer a todo o momento seja a lista de operações possíveis dentro do estágio atual do trabalho, seja uma explicação das funções e efeitos de um dado comando. Este tipo de possibilidade é clássica e possui grande popularidade. Guia de utilização - a todo momento, o usuário deve poder ter acesso a um modo guia, elaborado segundo a lógica de utilização, onde os encadeamentos de operações correspondentes às precedências permanentes ou indicativos, lhe serão propostos em função do objetivo que ele tenha fixado. Este tipo de guia pode permitir responder a questões do tipo "Como fazer para....?". A elaboração de tal guia é possível, graças a estruturação do sistema em objetivos, sub-objetivos, operações e precedências. Sellen e Nicol (1990) abordam a questão dos guias de utilização de uma forma um pouco mais detalhada. Os autores afirmam que o tempo de busca nos helps poderia ser bastante reduzido se a forma do tópico do help correspondesse ao tipo de questão que o usuário faz. Acontece que o tipo de questão feita, freqüentemente determina o tipo de informação requerida. A tabela 7 lista os tipos de questões citadas pelos autores: HYPERLINK "tab1.htm"Tabela 1. Forma canônica para os tipos de questão mais comum feito pelos usuários. Donde o tipo de informação enviada deveria ser diferente para cada tipo de questão formulada, ou a forma pela qual a informação é alcançada e apresentada deveria depender do tipo de questão feita. Definindo melhor: O que eu posso fazer com este programa? Deve introduzir informação facilmente acessível e visível para o usuário iniciante e deve prover informações sobre todo o espectro de capacidade do software, especialmente apontando usos e funções que o usuário não iria normalmente descobrir. O que é isso? Para que é isso? Elas ocorrem no modo operatório, quando o usuário aponta para um objeto na tela e pede uma descrição. O segundo ocorre no modo de execução de tarefa, e um termo específico precisa ser definido. Como é que eu faço isto? Este é o tipo mais freqüente de questão, pois é quando o usuário está diretamente envolvido em um tipo específico de tarefa. Ele já sabe o que quer, e as respostas a todas as outras questões, são na verdade fundamentais para que ele possa desenvolver a sua tarefa, ou seja esta questão é fundamental. Barthet já salientava este fato quando associava este tipo de questão à lógica da utilização do software. Aqui o que se recomenda é um help procedural que seja expresso na "linguagem" e no vocabulário do usuário (linguagem orientada à tarefa) e que não desative o contexto de trabalho em que a questão foi feita. Por que isto aconteceu? Perguntas deste tipo ocorrem quando o sistema responde de forma inesperada, seja esta resposta uma mensagem de erro ou não. Nesse caso, para poder prover o usuário das ferramentas necessárias, o sistema precisaria poder descobrir qual era a intenção do usuário que foi frustrada. Ora, esta não é uma tarefa fácil, ela é dependente da capacidade de "inteligência" e de rastreamento embutidas no computador, pois: mesmo que o computador seja capaz de rastrear a atividade do usuário e registrar os padrões de procedimentos de um usuário típico, muitas tarefas podem ser desenvolvidas de muitas maneiras diferentes; o usuário pode estar desenvolvendo múltiplas atividades que se sobrepõem; os usuários podem ter intenções muito diferentes do que as suas ações sugerem; ainda, os próprios usuários podem não estar totalmente conscientes das suas intenções. O computador poderia oferecer para a crítica do usuário uma interpretação das suas intenções, isto ajudaria no diagnóstico do problema e o próprio usuário participaria deste diagnóstico se isso lhe fosse permitido e facilitado (com helps adicionais, por exemplo com acesso a história das suas ações passadas, ou, com a apresentação de uma lista com os erros mais comuns naquela situação). Onde é que eu estou? Este tipo de questão é dependente da aplicação - hipertextos - por exemplo, onde os usuários usam metáforas espaciais. Sellen e Nicol (1990) ainda recomendam que: o sistema de help use adequadamente os recursos das mídias disponíveis - helps on line podem ser interativos, dependentes do contexto relativo à ação e ao nível de habilidade do usuário; podem ainda ser dinâmicos, com animação do seu uso, inclusive através de voz; podem também incorporar o uso de palavras chaves e cortar informações do texto do help para levá-lo à sessão de trabalho; a distinção entre a interface e o help não precisa ser explícita, na medida em que a interface facilita ou restringe a ação do usuário, pois todo o tipo de feed-back que possa ser dado ao usuário (prompt para a próxima ação numa série de ações ou uma mensagem de erro) pode ser considerado como um help on-line; boas interfaces talvez não necessitassem de helps on-line, pois as mesmas poderiam ser auto explicativas, a questão é: "não seriam os sistemas de helps desculpas para interfaces ruins?" Parece que por enquanto a resposta ainda é não, considerando-se o poder e a flexibilidade do software interativo e o estágio atual do desenvolvimento de interfaces inteligentes. O help pode também incluir perguntas ao invés de respostas. Perguntas do tipo: você sabia que...? ajudariam o usuário a melhorar a sua performance de utilização (uso de teclas de atalhos e também uso de todo o espectro de oportunidades que a interface oferece), a partir de pequenos pedaços de informação que são oferecidas ao usuário. Como direções a serem seguidas na área de interação homem-máquina Sellen e Nicol (1990) sugerem o desenvolvimento de interfaces adaptáveis e tolerantes, estas devem reduzir a necessidade de helps on- line. Quanto mais sensitivos ao contexto forem os helps desenvolvidos mais eles deixarão de ser obtusos. Mas um conhecimento superficial do contexto não é suficiente para tal, pois o sujeito poderá estar num contexto não relacionado com a ajuda que precisa, e um help sensível ao contexto nesta situação só trará mais confusão. Helps mais inteligentes não precisariam esperar o pedido de ajuda do usuário, pois isso exige que ele saiba fazê-lo. Sistemas mais avançados poderiam completar comando ou prompts para a próxima ação, poderiam mesmo fazer a tarefa para o usuário ao invés de lhe explicar como fazê-lo. É preciso contudo cuidar pois helps não solicitados podem ser irritantes e ainda, quando o computador exerce excessivo controle sobre a ação do usuário este pode sentir-se como um espectador. Isto exige que o computador conheça a intenção do usuário. Uma outra dica muito importante de Sellen e Nicol é a seguinte: sistemas de ajuda não devem necessitar de ajuda para serem utilizados. As Possibilidades de Evolução A evolução que se quer aqui abordar não corresponde ao desenvolvimento da própria ferramenta, em termos de programação ou projeto, ela diz respeito ao tipo de evolução que é levada a efeito pelo próprio usuário, na sua forma de usar o software. O que é passível de mudanças consiste em: A criação de novos procedimentos efetivos adaptados aos modos de trabalho dos diferentes usuários; A repartição da pilotagem entre homem-máquina, ou seja, as noções de desencadeamento, de operações obrigatórias ou facultativas, e de precedências permanentes ou indicativas. O nível das operações intermediárias que não são inicialmente previstas mas que utilizam operações já conhecidas da máquina. Isto vai permitir ao usuário que crie suas próprias seqüências padrão ou macro-operações próprias. Se forem necessários novos tratamentos que não podem ser compostos a partir das operações já disponíveis na máquina, será necessário a programação de novos módulos. Representação Externa A Representação Externa corresponde, como já foi dito, a visão que o usuário faz da aplicação interativa. Ela se define a partir de conceitos oriundos da própria Representação Conceptual, e também da psicologia cognitiva e da ergonomia. Os suportes da psicologia cognitiva para a representação externa dizem respeito principalmente à percepção e ao registro de uma informação. No ser humano podem ser identificados três tipos de memória: um registro da informação sensorial, que é capaz de conter a totalidade de uma imagem por um período de tempo muito curto (de 0,1 à 0,5 segundos); uma memória de curto alcance, que interpreta as informações contidas dentro do registro de informação sensorial afim de extrair os elementos significativos; uma memória de longo alcance. HYPERLINK "fig5.htm"Figura 5. Estrutura esquemática da memória humana (Barthet, 1988:73) A memória de curto alcance se constitui em uma limitação enorme, pode-se reter até 7 itens (na verdade, entre 5 e 9) durante um tempo que varia em torno de 2 segundos. Um item corresponde a uma unidade de informação significativa para um indivíduo, por exemplo: as letras c, h, a, t e o correspondem a cinco itens, já a palavra chato corresponde a um item (para uma pessoa que conhece o português). Só a auto-repetição permite que uma informação seja mantida por mais de dois segundos pela memória de curto termo. Os mecanismos de memorização e de pesquisa dentro da memória de longo alcance não são conhecidos com a mesma precisão que a memória de curto alcance. Mas, sabe-se que o esforço de memorização dentro da memória de longo alcance requer uma concentração que torna a pessoa relativamente indisponível para outras tarefas. A memória de longo alcance é facilitada pela compreensão, ou seja pela atribuição de um significado ao elemento sensorial percebido, o que presume a incorporação de tais elementos à estruturas cognitivas já formadas ou em formação (assimilação). As conseqüências das estruturas de memória sobre as interfaces são múltiplas, conforme registra Barthet (1988): Uma simples interrupção (telefone, cliente...) cria um esvaziamento da memória de curto tempo; para remediar esta limitação, é necessário memorizar a atividade do usuário de maneira a poder relacionar as últimas ações, seja para assinalar erros, seja para assinalar as conseqüências destas ações; a degradação rápida da informação da memória de curto tempo deve ser levada em conta dentro da concepção do parâmetro << tempo de resposta>>; os limites de capacidade da quantidade de informação da memória de curto tempo necessitando de concisão e do emprego de conceitos os quais devem ser agregados o máximo possível de forma a serem identificáveis (após a aprendizagem) como correspondentes a um único item; a memorização na memória de longo alcance é facilitada pela compatibilidade entre os mais antigos e os novos procedimentos ou pela analogia entre os sistemas já conhecidos. As especificidades da memória humana remetem à criação dos automatismos que surgem com a experiência quando uma mesma tarefa é repetida muitas vezes. Os automatismos permitem que tais tarefas sejam rapidamente executadas com uma mobilização mínima dos processos conscientes, o que traz muito mais eficiência ao trabalho. Pode-se citar como exemplo a aprendizagem do uso do teclado. Donde, tem-se como conseqüência, que a concepção da interface deve favorecer a criação destes automatismos. A criação de tais automatismos está intimamente ligada com a homogeneidade presente nos parâmetros de uma interface, pois a criação dos mesmos só pode ocorrer quando para situações idênticas a ação do usuário é a mesma. Por exemplo, a tecla que permite validar a entrada de dados deve ser a mesma para todas as aplicações informatizadas. Sendo assim a busca da homogeneidade tem um impacto sobre quase todos os parâmetros da interface, dentre os quais Barthet (1988) destaca: na entrada: teclas, funções ou mouse; na ordem: disposição espacial; erros: apresentação e retificação; linguagem: sintaxe e vocabulário; seqüência: processo de encadeamento; guias: apresentação e conceitos. Comentários sobre a proposta de Barthet O principal conceito apresentado por Barthet é o conceito de procedimento minimal. A partir do mesmo é possível ter mais clareza quanto ao perfil da divisão de tarefas entre homem e máquina. A consistência que Barthet atinge nessa conceituação deve-se ao fato de o modelo ter uma abrangência multidisciplinar integrando resultados provenientes das áreas de ergonomia e psicologia cognitiva. Uma questão que Barthet não esclarece, diz respeito a como se deve proceder para a identificação do procedimento minimal. Obviamente há que se partir da análise da tarefa, mas permanece ainda uma lacuna metodológica quanto a que representação dos resultados da análise da tarefa seriam adequados para identificar os procedimentos minimais. Recomendações Ergonômicas para os Parâmetros de Interface Barthet faz acompanhar a sua proposta de uma gama bastante abrangente de recomendações ergonômicas para a interface das aplicações interativas. As recomendações feitas por Barthet são sintetizadas a seguir e são complementadas com a fundamentação feita por outros autores, quando se achou que isso era conveniente. Sucessão de operações O problema focado aqui é o de adequação entre a ordem das operações fixadas pela máquina e aquela necessária ao operador para efetuar sua tarefa não importa o ambiente. A maior parte das características de sucessão tem como fonte a estrutura profunda do software que nesta etapa já está determinada na representação conceptual e é determinada pela análise da tarefa. Trata-se neste caso de observar: do tipo de encadeamento (livre, guiado, automático); a possibilidade do encadeamento variar segundo o grau de experiência e do tipo do usuário; a possibilidade de acesso a todas as informações a todo momento; de poder sair, anular ou interromper (com retorno ao mesmo ponto) uma transação a todo momento; de fazer uma chamada a uma operação qualquer que seja a partir de uma outra e voltar a primeira; de transferir as informações de uma aplicação para outra; A nível da interface tais recomendações concernem aos dispositivos de entrada e ordenação, ao vocabulário e sintaxe e às mensagens de erros e guias de utilização. Linguagem de interação A linguagem de interação é quem vai permitir que o usuário expresse, a partir de um vocabulário e de uma sintaxe, as operações que ele deseja que a máquina efetue; da mesma forma; que permite que o usuário interprete as respostas que lhe são fornecidas após a execução das operações solicitadas. Quanto ao vocabulário, os ergônomos privilegiam de forma unânime o emprego, sempre que possível, da linguagem dos especialistas da tarefa ao invés da linguagem do analista Esta recomendação não é facilmente seguida, principalmente há que se considerar que a diferenciação que a informatização introduz na realização da tarefa leva à criação de um novo vocabulário. Nestes casos é necessário escolher novos vocábulos, e testar o seu uso com cuidado. Recomenda-se que esta escolha evite a utilização de códigos numéricos, pode-se utilizar códigos mnemônicos mas dá-se preferência à língua natural, com algumas ressalvas, conforme indicam o estudo realizado por Scapin (apud Barthet, 1988). Scapin recomenda cuidado com termos que tem significados diferentes na aplicação informatizada e na língua corrente, nesse caso é melhor usar um termo novo, mesmo que se trate de uma língua estrangeira. De modo geral os pictogramas, ou ícones, podem se revelar muito interessantes quando não apresentam ambigüidade; eles permitem exprimir um conceito a partir de um único item facilmente registrável na memória a curto tempo, a partir de analogias com um caso manual conhecido, levando a uma memorização de longo termo facilitada. A sintaxe de uma linguagem de interação é formada pelo conjunto de regras que permitem expressar comandos mais complexos a partir de combinações entre os mesmos. As recomendações básicas aqui referem-se a simplicidade, por razões de memorização e à homogeneidade para evitar riscos de erros e favorecer a formação de automatismos. A presença de exceções será fatalmente fonte de erros. A homogeneidade é desejável não somente dentro de uma aplicação mas também entre uma aplicação e outra. Payne e Green (1989) chegam a definir um formalismo para modelar a representação mental das linguagens de interface permitindo a especificação formal da mesma conforme a sua percepção pelo usuário. Estes autores citam uma tentativa anterior de formalização destas linguagens feita por Reiner em 1977, que tentou transportar as virtudes do formalismo BNF (Backus-Naur Form) para este terreno, com a vantagem adicional de poder predizer a complexidade psicológica da linguagem. Formalizações deste tipo possibilitariam a construção de métricas simples sobre a gramática (tais como o número de regras, por exemplo),que permitiriam predizer aspectos da complexidade psicológica. " Tais aspectos incluem tempo despendido para o aprendizado, erros intrusos durante o aprendizado, e a habilidade para gerar extensões da linguagem. Um objetivo secundário de tais gramáticas é ajudar o analista a perceber a estrutura da linguagem da tarefa." (Payne e Green, 1989:80) A principal predição empírica de uma tal gramática é a seguinte: dentre duas linguagens similares, a que será melhor lembrada e mais facilmente aprendida será aquela com menor número de regras. Na verdade, linguagens consistentes têm um pequeno numero de regras gramaticais, enquanto, nas linguagens inconsistentes, as construções sintáticas têm pouco em comum entre si, não permitindo a sua redução para um pequeno número de regras. A base cognitiva para a construção e análise destas gramáticas está, segundo Payne e Green naquelas tarefas simples que o usuário pode rotineiramente executar e que não demandam nenhuma estrutura de controle. Estas tarefas simples são psicologicamente importantes para o aprendizado. Por exemplo, um usuário que tenha aprendido a apagar palavras, irá, sem muito problemas, induzir o método iterativo para apagar sentenças. O foco destes autores sobre a predição do esforço de aprendizado ressalta uma distinção crucial "tarefas simples são um conjunto de tarefas para as quais distintas seqüências de ações precisam ser aprendidas, ou induzidas, da estrutura particular da linguagem de interação." (Payne e Green 1989:95). No caso do software interativo estas tarefas simples estão mais relacionadas aos dispositivos e objetos da interface estando, portanto, fora do domínio da tarefa propriamente. No entender de Barthet (1988) estas tarefas simples seriam aquelas que deveriam promover a formação de automatismos. Norman (apud Coutaz, 1990:47) também aborda a questão da linguagem da interação como uma instância do mapeamento da lógica de utilização para a lógica do funcionamento. Os principais conceitos que Norman utiliza são de 'distância de avaliação' e 'distância de execução'. Norman indica que a realização de uma tarefa reúne pelo menos sete atividades: o estabelecimento de um objetivo, que é resultante da percepção de uma diferença entre o estado percebido do sistema e o estado a atingir; a formação de uma intenção - é a percepção da necessidade de agir para atingir o objetivo; a especificação de uma seqüência de ações; a execução dessas ações; a percepção do estado do sistema; a interpretação do estado do sistema; a avaliação do estado do sistema em relação ao objetivo. Estas sete fases não são necessariamente seguidas na ordem apresentada (as três primeiras são recursivas, já as três últimas conduzem a uma recorrência da primeira fase numa etapa mais avançada) e há que se ressaltar o distanciamento entre as variáveis físicas e as psicológicas, que Norman chama de distância de execução e distância de avaliação. É preciso lembrar ainda que do ponto de vista lingüístico a imagem é uma linguagem de interface formada por dois dialetos: um para especificar as expressões de entrada e outro para apresentar os conceitos do sistema nas expressões de saída. Esses dialetos podem ser estudados segundo seus componentes semânticos ou formais. Hutchins e seus co-autores (apud Coutaz, 1990:51) integram esta nova perspectiva e as chamam de distância semântica e distância articulatória: Distância semântica exprime as relações entre os objetivos fixados e a significação das expressões da linguagem da interface e traduz o esforço de por em correspondência o conhecimento que o usuário tem do domínio da tarefa e o conhecimento semântico que ele possui sobre o sistema. Esta distância pode ser percorrida em duplo sentido, o da execução (entrada) ou da avaliação (saída) A distância articulatória reflete as relações entre a significação de uma expressão da linguagem e sua forma. Ela traduz o esforço de tradução entre o conhecimento que o usuário tem do sistema e o conhecimento sintático dos elementos de apresentação do sistema. Esta distância também pode ser percorrida em duplo sentido. HYPERLINK "fig6.htm"Figura 6. Modelo representando as etapas na realização de uma tarefa e as distâncias a serem percorridas em cada uma delas (Coutaz, 1990:22). O diagrama apresentado na figura 6, representa as diversas atividades na realização de uma tarefa informatizada e as distâncias que devem ser percorridas em cada uma delas. A distância de execução correspondente à fase entre a definição do objetivo e a execução da ação esta representada pela seta indicada por DEx. Esta distância pode ser subdividida em distância semântica de entrada (DSE) e distância articulatória de entrada (DAE). A distância de avaliação (DAv) tem como extremos os momentos da percepção de um estado do sistema e o da definição de um objetivo, esta dividi-se em distância semântica de saída (DSS) e distância articulatória de saída (DAS). A modelagem apresentada esquematicamente na figura 6, tem apenas a ambição de explicar os processos cognitivos subjacentes à realização de uma tarefa computadorizada. Este modelo mantém a decomposição hierárquica da tarefa, mas a noção de objetivo é ampliada com a introdução da noção de estado, distinguindo-se o estado efetivo do estado perseguido. O erro nesse caso passa a ser uma necessidade insatisfeita na tradução do mundo físico para o mundo mental, podendo ocorrer seja porque a imagem mental não explicita corretamente o estado efetivo, seja porque a correspondência entre as variáveis físicas e psicológicas é complexa, ou ainda porque os dispositivos de controle físico das variáveis não são adaptados à tarefa. O modelo mental que é forjado pelo usuário é utilizado nos modos leitura e escrita. Estes dois modos traduzem bem o princípio de adaptação que é revestido dos dois aspectos complementares: acomodação e assimilação. O usuário assimila enquanto atravessa a distância de avaliação: durante as fases de percepção e interpretação, ele traduz uma representação do estado do ambiente em uma representação mental que pode eventualmente modificar o modelo conceptual. O usuário acomoda sempre que percorre a distância de execução. Os tempos de resposta A questão que se põe aqui é a seguinte: qual é o tempo de resposta ideal? Os especialistas não entram em acordo totalmente sobre a resposta a esta questão. Alguns defendem uma resposta imediata, outros uma resposta compatível com a velocidade do processo cognitivo do ser humano. Para tentar responder mais precisamente esta questão, devem ser relembrados os resultados da psicologia concernentes ao tempo de resposta que é da ordem de dois segundos numa conversação entre duas pessoas e à retenção dos dados na memória de curto termo (de dois a seis segundos no máximo). Tais resultados levam a concluir: perto de dois segundos: tempo de resposta ideal; de 2 a 4 segundos: impressão de espera, pode ser gerado pela memória de curto tempo; mais de 4 segundos: muito longo se o dialogo necessitar uma memorização a curto tempo e se não existem mensagens fixadas no vídeo. O tratamento de erros Cabe neste caso distinguir dois tipos de erros: os erros de execução, facilmente detectáveis e retificáveis, provenientes do fato de se apertar inadvertidamente em outra tecla que não aquela desejada; os erros de intenção que correspondem a uma má interpretação do sentido dos comandos ou da significação dos procedimentos; estes erros podem não ser detectados e sua retificação pode exigir um esforço de aprendizagem de parte do usuário. Para o assinalamento de erros, há unanimidade sobre os seguintes elementos sobre o fato de que os erros devem ser assinalados imediatamente ou o mais rapidamente possível por causa da volatilidade da memória de curto tempo; Para a correção de erros, o usuário deve poder rever facilmente a operação ou a linha onde se situa o erro e deve poder anular eventualmente na totalidade ou em parte o trabalho que foi feito depois deste. Conclusão As técnicas de análise da tarefa desenvolvidas tradicionalmente pela ergonomia são anunciadas como adequadas à modelagem e à concepção de aplicações interativas. De fato, foram inúmeras as vantagens apontadas pelas diversas fontes consultadas. Dentre os autores consultados Barthet (1988) traduziu de forma bastante proveitosa as várias recomendações ergonômicas para a área de modelagem do software interativo e Diaper apresentou uma alternativa promissora para a representação dos resultados da análise da tarefa. A proposta de Diaper já se encontra em um tal nível de formalização que já enseja a construção de ambientes computacionais de apoio à sua implementação. Cabe ressaltar nesta conclusão, que as mesmas técnicas de análise da tarefa que permitem a modelagem das aplicações computacionais, permitem avaliar aquelas já existentes, uma vez que, trata-se neste caso, de analisar a tarefa informatizada. Quanto aos atributos que permitiriam o desenvolvimento de atitudes de aprendizado autônomo, praticamente nada é explicitamente mencionado. Dois autores, Key e Coutaz, falam em cooperação, mas não se referem explicitamente a autonomia que adviria destas relações cooperativas (Piaget salienta que as relações de cooperação e a autonomia são um único processo). O conceito de agentes que a proposta de Alan Key integra parece ser a melhor metáfora de relação cooperativa homem-máquina. Note-se que esse agente que "habita" as aplicações computacionais e que deve ser capaz de cooperar é um "ser" que deve ser dotado de um alto nível de inteligência, esta inteligência o capacitaria a decidir "sozinho", e a agir sem esperar que o seu "chefe", o usuário, comandasse as suas ações. Neste sentido ele é dotado de autonomia. A sua autonomia só seria restringida num nível macro, pois ele seria obrigado a adotar, em primeira instância, a escala de valores do seu "chefe", o usuário. Dois conceitos desenvolvidos na área de ergonomia de interfaces são importantes para o desenvolvimento de posturas autônomas no uso de aplicações computacionais, sem deixar de considerar que a maioria das recomendações feitas também o sejam. Um deles é o conceito de latitude decisória, desenvolvido por Barthet. Estabelecer o que deve ficar sob responsabilidade da máquina e o que deve ficar sob responsabilidade do homem não é tarefa fácil, ainda mais quando se considera que esta latitude decisória deve mudar com o uso da aplicação, e deve ser dada ao usuário a capacidade de decidir sobre a própria latitude decisória que ele deseja ter. Outro conceito é o de que um software precisa ser sensível ao contexto da sua utilização. Ser sensível ao contexto significa ser capaz de perceber as intenções do usuário, e portanto adiantar-se a ele oferecendo-lhe ajuda e orientação ou mesmo operando no seu lugar. Isto pressupõe, a capacidade de reversibilidade operatória, que segundo Piaget é o nível de estrutura cognitiva atingida pelos humanos, na sua maioria, entre a adolescência e a fase adulta. Um tal nível de inteligência na máquina, além da capacidade de percepção que lhe seriam necessárias, dão uma idéia da complexidade de tal empreitada. Em todo caso, trata-se de conseguir tal 'sensibilidade' em contextos bastante limitados. .:…‹¦7è Z ¬ OXåî¾À¹!Ä!À(ã(Œ)‘)%++ž.¤/WHkH¸HÈHfKsK*R,RsR+TVÏWáWèXÿXÙ`í`xa¥ad"dðdód¨e«e¥fÓfDh`h.k4k¹kÙknnƒo„o˜o™ošo¢o£ogpppÉpÕp/q6q˜q›q®qýýùýùýùýùýùýùýõýõýõýýùýùýùýùýùýùýðýùýõýõýùýõýõýõýõýõýùýùýùýùýéýßéÚéýùýùýùýÓË6CJmH sH  CJmH sH 0JCJjCJU jCJUmH sH 5CJ6CJCJP.:CN¾ òç =†µâ°ÿ×ጠÿ#_&Â(ã(ÿ*é+.úõðõõõõõõõõõõèèèèõõõõæðõõõ$ & Fa$$a$$a$$a$z¤þ.P02’415ƒ;T=¶?k@¹@â@AYAõAC.FPI{J>KÌLòNÏP,RsR*T.VÏWãWúúúúòòòúòòòòòúúúúúòòòúíúúúú$a$$ & Fa$$a$ãWèXY†YªYËYXZí^xa§aëbÞc¸dqef¥fÕfØgåi’kUmnƒocprp¨pÅp×p qúúúòòúúúúúúòòòúúúúúúúúúúúúúú$ & Fa$$a$ q+q8qlq˜q°qäqrKrZrmrŠr¯r…t0v?vlvv‘v¾vÑvÞv ww4w_wswÃwãwxúúúúúúúúúúúúúúúúúúúúúúúúúúúúú$a$®q°qOrXr4v=vƒvvÕvÜv ww2w4wÃwÇwáwãwxx=x?x»x¿xÓxÕxyy&y(y`{:|}˜}退…¦…†U†‡+‡#ŠBŠÔŒÞŒßŒjR‘ä’“m—옒¡›¡×¢Ý¢’£–£—£›£œ£¦£‚¨‰¨Â«×«é¬ô¬(­3­6®:®°°'°1°[³|³y»Û»ÆÆhÆ}Æ5ÇùöòöòöòöòöùêùöùêùöùêùöùêùöùêùöòöæöæöæöòöòöòöæÞöòöòöòöòöòöòöòöòöòöòöòöòöòöòöòö×ööæöæö CJOJQJ5CJOJQJ5CJ6CJmH sH 6CJCJ CJmH sH Uxx?xjxux»xÕxyy(ySy_yQ|}š}逖€n‚›‚ƒgƒ7„u„Í„ …€…úúúúúúúúúúúúúúúúúòòòòòòòòòòò$ & Fa$$a$€…¨…Á‡ ŠõŠ¨ŒÔŒàŒal‘¨“ˆ”l—™C|žÑŸk¡l¡}¡ª£ç¥è¥ü¥§‹©Þ­ß­®úúúúúõúúúúúúúúúúúúúúúúúúúúúú$a$$a$® ¯Ù¯±)±¥²E³F³~³µµDµ®¶¯¶½¶¸Î¸Ï¸å¸´¹{»Û»„½«¾/À7ÃBÅ~Çúòòúúúúúúúúúúúúúúúúúíúúúúúú$a$$ & Fa$$a$5ÇJÇ'È(È<È=È>ÈFÈGÈuË|Ë{ÑýÑÒ Òóãåå)æGìTìÂìÛìNöeöùù&ù'ù(ù0ù1ùÓúÔúáúâúêûëûøûùûúýûýþ þ5ÿ6ÿJÿKÿLÿTÿUÿí£JPdl°¸¤ªMS%¨©¬Z‹01qv“ûøñøçñâñøÞøÞøÞøÞøÞøÞøÞø×øñøÍñâñøûøûøûøûøûøûøñøÃñâñøÞøÞøÞøÞøÞøÞøÞøÞøÞøÞøÞøÞøÞøjÈCJUj0CJU CJmH sH 6CJ0JCJj˜CJU jCJUCJ5CJM~Ç'ȼÈnËÁÎFÏÖÒ…Ô7Ö×WÙÓÙ“ÚõÚnÜŠÝZÞ›ß,àáwâïãå@æèãèêë¼ëúúúúúòòòúúòòúòòòúúúúúúúúúúúú$ & Fa$$a$¼ëßìÏîbñtó=õeö÷‰÷'øù{ùù“úèû¾ýÏþ5ÿ«ÿã'£ò‰Åúúúúúúòòòúúíúúúúúúúúòòúòòúú$a$$ & Fa$$a$* R / ‚éìºòna®¢J³¬]qÓ`Ñš!˜!úúúúúúúúòòúúúúúúúúúúòòúúòòòú$ & Fa$$a$“”¸¹ÏÐÖãûüþÿ;<àëïú4<@Kª´, 6 ÷-.‡0Ž0·9È9à:å:; ;ó;ô;< < <<<7=^=T>s>7?O?A A¹AÐAFF²FÆFzG~G¶G»GÈHÌHIII–I¶I¼IJ'JVJ[J\JcJ¼JÁJ™KK¥M´MâMçM·N»NøNýNûøûøûøûøûøûøûøûøûøûøûøûøûøûøûøûøûøûøûøñøçñâñøÞøÞøÞøûøÞøûøÞøûøûøûøûøûøûøûøûøûøûøûøûøûøûøû5CJ0JCJj`CJU jCJUCJ6CJX˜!"ö"©#ì#M$œ%;&²'Ø'ÿ'C(Q)*Ê+-].1/€0^1J2 3¦3w4ú4Ê5‰6 637úúúúúúúúòòòúúúúúòòòòòòòòòòúú$ & Fa$$a$37]8N:ó;_<7=`=T>t>7?Q?é@¹AÒAoC9D„DÔD,E²FÈF@GmGñH*J—KèLPQ÷÷òòòòòòòòòòòòò÷÷÷òòòò÷÷÷òòò$a$$ & Fa$ýN£OªO3P8PrU‡U’X“X§X¨X©X±X²XZ Z ZZ8Z=Z”oŸo&r*rs#sRtZtsxtxÝxÞxàxßy·}f~°´v…z…®ˆ¯ˆÈĈň͈Έš”«”3•D•Í—Ú—=Ÿz¤ýùýùýõýîýäîßîýùýùýùýùýùýùýùýùýùýùýùýùýùýîýÕîßîýùýùýýjCJU0JCJjøCJU jCJU5CJ6CJCJ6Q·Q­RØR*B*>P`B> Corpo de texto 2$a$CJ>V@¢Q> HyperlinkVisitado >*B* ph€€z àÿÿÿÿ.:CN¾ ò ç =†µâ°ÿ×áŒÿ_"Â$ã$ÿ&é'*P,.’011ƒ7T9¶;k<¹<â<=Y=õ=?.BPE{F>GÌHòJÏL,NsN*P.RÏSãSèTU†UªUËUXVíZx]§]ë^Þ_¸`qab¥bÕbØcåe’gUijƒkclrl¨lÅl×l m+m8mlm˜m°mämnKnZnmnŠn¯n…p0r?rlrr‘r¾rÑrÞr ss4s_sssÃsãstt?tjtut»tÕtuu(uSu_uQxyšyé{|–|}n}~›~g7€u€Í€ €¨Áƒ †õ†¨ˆÔˆàˆa‹l¨ˆl“•C™|šÑ›kl}ªŸç¡è¡ü¡£‹¥Þ©ß©ª «Ù«­)­¥®E¯F¯~¯±±D±®²¯²½²´Î´Ï´å´´µ{·Û·„¹«º/¼7¿BÁ~Ã'ļÄnÇÁÊFËÖÎ…Ð7ÒÓWÕÓÕ“ÖõÖnØŠÙZÚ›Û,ÜÝwÞïßá@âäãäæç¼çßèÏêbítï=ñeòó‰ó'ôõ{õõ“öè÷¾ùÏú5û«ûãü'þÿ£ÿòÿ‰Å*R/ ‚ é ì ºòna®¢J³¬]qÓ`Ñš˜ö©ìM œ!;"²#Ø#ÿ#C$Q%&Ê')]*1+€,^-J. /¦/w0ú0Ê1‰2 233]4N6ó7_879`9T:t:7;Q;é<¹=Ò=o?9@„@Ô@,A²BÈB@CmCñD*F—GèHLM·M­NØN€{õ˜ ?€{õ˜ @€{õ˜ A€{õ˜ B€{õ˜ C€{õ˜€{õ˜€{õ˜ D€{õ˜ E€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜ F€{õ˜ G€{õ˜ H€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜ I€{õ˜ J€{õ˜ K€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜ L€{õ˜ M€{õ˜ N€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜ O€{õ˜ P€{õ˜ Q€{õ˜€{õ˜€{õ˜€{õ˜€{õ˜ R€{õ˜ S€{õ˜ T€{õ˜ U€{õ˜€{õ˜€{õ˜€{õ˜ V€{õ˜ W€{õ˜ X€{õ˜ Y€{õ˜ Z€{õ˜ [€{õ˜€{õ8€{·˜€®a˜€®a(€˜€´d8€´d˜€*f˜€*f˜ \€*f˜ ]€*f˜ ^€*f˜ _€*f˜ `€*f˜ a€*f˜€*f8€´d˜€Ij˜€Ij˜€Ij˜€Ij˜€Ij˜€Ij˜€Ij˜€Ij˜€Ij˜€Ij˜ b€Ij˜ c€Ij˜ d€Ij˜ e€Ij˜ f€Ij˜ g€Ij˜ h€Ij˜€Ij˜€Ij˜ i€Ij˜ j€Ij˜€Ij˜€Ij˜€Ij˜€Ij8€´d˜€ÌŒ˜€ÌŒ˜€ÌŒ˜ k€ÌŒ˜ l€ÌŒ˜ m€ÌŒ8€´d˜€P˜€P˜€P(€˜€Ï“˜€Ï“˜€Ï“˜€Ï“˜0€Ï“®q5Ç“ýNz¤Úàäèë.ãW qx€…®~Ǽë˜!37Qee¯{—z¤ÛÝÞßáâãåæçéêìíîïz¤܃k™k¢k'Ä=ÄFÄõ'õ0õ5ûKûTûó7 88’T¨T±T®„Ä„Í„z X”ÿ•„X”ÿ•„X”ÿ•„X”ÿ•„X”ÿ•„X”ÿ•„X”ÿ•„"'¦©NT]c‰«¼¯ µ ò õ ç ê  lwéòLO  r%x%{%%ˆ6“6G9Q9ç=ì=@@ÔCÛCD#DWDbDcDjD¸DÃDÄDÈDËDÑDÓEÚE{F‚FfGkGãMïM.N6N O§OÕOÜOxDxxxZ‚`‚ƒƒƒ#ƒ$ƒ+ƒ#†+†,†:†;†B†X^”šð”ö”Ù—ß—’•–š’Ÿ–Ÿ—Ÿ›ŸœŸ¦Ÿ‚¤‰¤Â§Æ§Ç§Ë§Ì§×§é¨ô¨(©3©*ª4ª;ªAª¬ ¬¬¬'¬,¬-¬1¬F¯O¯P¯[¯E¼L¼v¿~¿Ó¿Ú¿BÁIÁ­ÁµÁ¨Ä¯ÄÐÄÖÄ8Å>ÅnÇsÇxÇ|ÇqÉxÉ!Ê&ÊLËV˧͸ÍÎÎ Î Î"Ð+Ð7Ò>ÒýÞß ß©ß-â4â=çDçèêíêìì"ì)ìãíêíNòeò˜óŸódôkôõõhõoõ¦õ­õÒõÚõ˜ûŸû«û²û.ý5ýA H s z   §®ÉÐYa‹qv·¹ýÿ:<áì •œy€§®ÂÉfm‡!!ñ!ø!1"8"t#{#S$Z$G%N%½%Ä%z&&‡,Ž,3 3N6T6W6\6à6å67 7~<…<= = ==BB@CFCICNCzC~C¶C»C¼C¾C¿CÃCÈDÌDEEE–E¶E¼EFFVF[F¼FÁF™GG*I0I3I8I¦I«I¬I®I°I´IâIçI·J»JøJýJ£KªK3L8L4M:M=MBMÝTäTˆYY¾`Å`ÎaÕaüab!b(b©b°bocvcÐc×c©d±dîdõdše¡e¤k­kn$n+n2n;nAnCrHrXs^sžs©sªs®sëuðux xrzwzA{H{µ{»{Zb{B…H…‹†Ž†"‡%‡ì”ó”w•}•ì•ò•˜˜ ˜˜™™mœtœ| F¯~¯¯²½²| ÿÿHelio Lemes Costa?C:\WINDOWS\TEMP\Salvamento de AutoRecuperação de Documento1.asdHelio Lemes Costa0C:\Meus documentos\ihm\ergonomia de software.docHelio Lemes Costa0C:\Meus documentos\ihm\ergonomia de software.docHelio Lemes Costa0C:\Meus documentos\ihm\ergonomia de software.docHelio Lemes CostaeC:\WINDOWS\Application Data\Microsoft\Word\Salvamento de AutoRecuperação de ergonomia de software.asdHelio Lemes CostaeC:\WINDOWS\Application Data\Microsoft\Word\Salvamento de AutoRecuperação de ergonomia de software.asdHelio Lemes CostaeC:\WINDOWS\Application Data\Microsoft\Word\Salvamento de AutoRecuperação de ergonomia de software.asdHelio Lemes Costa0C:\Meus documentos\ihm\ergonomia de software.docHelio Lemes Costa0C:\Meus documentos\ihm\ergonomia de software.docþÿÿÿÿÿÿÿÿ*þÿÿÿÿÿÿÿx @@h „Є˜þ^„Ð`„˜þOJQJo(·ðÿÿÿÿ| ÿ@´µ‚¶ŒødW´µ´µz €@ÿÿUnknownÿÿÿÿÿÿÿÿÿÿÿÿG‡:ÿTimes New Roman5€Symbol3& ‡:ÿArialCLucida Casual"qˆðÄ©v­EñI›?<iW¯ÜÁ"ð¥À´´€0»¥z ðßÿÿ7FUNDAMENTAÇÃO TEÓRICA - PARTE 3: ERGONOMIA DE SOFTWARE Helio Lemes CostaHelio Lemes Costaþÿ à…ŸòùOh«‘+'³Ù0 ˆÐÜø 4@ \ h t€ˆ˜ä8FUNDAMENTAÇÃO TEÓRICA - PARTE 3: ERGONOMIA DE SOFTWARE UNDHelio Lemes CostaICeli Normal.dot Helio Lemes CostaIC5liMicrosoft Word 9.0C@bj9@„F7ˆÃ¿@6'ÿ!À?<iWþÿ ÕÍÕœ.“—+,ù®DÕÍÕœ.“—+,ù®t0 hpŒ”œ¤ ¬´¼Ä Ì äHelio Lemes Costaܯ»¥ü 8FUNDAMENTAÇÃO TEÓRICA - PARTE 3: ERGONOMIA DE SOFTWARE TítuloD 8@ _PID_HLINKSäAü*[Z fig6.htm[Y fig5.htmLU  tab1.htm[X  fig4.htm[_ fig3.htm[^ fig2.htm[] fig1.htm  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ ¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðþÿÿÿòóôõö÷øþÿÿÿúûüýþÿ     þÿÿÿ þÿÿÿ"#$%&'(þÿÿÿýÿÿÿýÿÿÿýÿÿÿ-þÿÿÿþÿÿÿþÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿRoot Entryÿÿÿÿÿÿÿÿ ÀF@šÐ!À/€Data ÿÿÿÿÿÿÿÿÿÿÿÿñ1Tableÿÿÿÿÿÿÿÿù&>WordDocumentÿÿÿÿ-àSummaryInformation(ÿÿÿÿÿÿÿÿÿÿÿÿDocumentSummaryInformation8ÿÿÿÿÿÿÿÿ!CompObjÿÿÿÿoObjectPoolÿÿÿÿÿÿÿÿÿÿÿÿ@šÐ!À@šÐ!Àþÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿþÿ ÿÿÿÿ ÀFDocumento do Microsoft Word MSWordDocWord.Document.8ô9²q