ENGENHARIA DE USABILIDADE: UMA ABORDAGEM ERGONMICA

Walter de Abreu Cybis Laboratrio de Utilizabilidade de Informtica

Florianpolis, Maio de 2003

Engenharia de usabilidade: uma abordagem ergonmica

ENGENHARIA DE USABILIDADE: UMA ABORDAGEM ERGONMICA SUMRIO

INTRODUO................................................................................................................................... 1 USABILIDADE E A ERGONOMIA .............................................................................................................. 2 ENGENHARIA DE USABILIDADE ............................................................................................................. 4 INTERFACE COM O USURIO .................................................................................................................. 5 ESTA APOSTILA...................................................................................................................................... 5 PRIMEIRA PARTE : FUNDAMENTOS TERICOS DA ENGENHARIA DA USABILIDADE................................................................................................................................... 7 1. 1.1 1.2 1.3 1.4 2. O TRABALHO E SUAS PERSPECTIVAS ............................................................................. 7 FUNCIONAMENTO E UTILIZAO ............................................................................................... 7 TAREFA E ATIVIDADE ................................................................................................................ 8 A DINMICA DO TRABALHO ...................................................................................................... 9 O CONTEDO DO TRABALHO ................................................................................................... 10 A PSICOLOGIA COGNITIVA............................................................................................... 13

2.1 OS MODELOS MENTAIS............................................................................................................. 13 2.2 A PERCEPO.......................................................................................................................... 15 2.2.1 A percepo visual ....................................................................................................... 16 2.2.2 A percepo auditiva.................................................................................................... 16 2.2.3 A percepo da fala...................................................................................................... 16 2.2.4 Ateno e Vigilncia .................................................................................................... 17 2.3 A MEMRIA ............................................................................................................................. 18 2.3.1 Modelos cognitivos para a memria ............................................................................ 19 2.4 O RACIOCNIO E O APRENDIZADO ........................................................................................... 20 2.5 O CURSO DAS AES .............................................................................................................. 21 2.5.1 A anlise de uma situao............................................................................................ 21 2.5.2 A planificao das aes.............................................................................................. 22 2.5.3 O Controle das aes ................................................................................................... 23 3. A COMUNICAO E A SEMITICA ................................................................................. 24 3.1 A TEORIA DE COMUNICAO .................................................................................................. 24 3.1.1 Indicao e Significao .............................................................................................. 25 3.2 A SEMITICA ........................................................................................................................... 26 3.3 OS COMPONENTES DE UM SINAL .............................................................................................. 26 3.4 A FORMAO DE UM SINAL ..................................................................................................... 27 3.5 A SEMITICA COMPUTACIONAL ............................................................................................... 28 3.5.1 Sinais Computacionais................................................................................................. 29 SEGUNDA PARTE: FERRAMENTAS PARA A ENGENHARIA DE USABILIDADE ......... 31 4. QUALIDADES ERGONMICAS PARA IHC ..................................................................... 31

4.1 A CONDUO .......................................................................................................................... 31 4.1.1 Presteza ........................................................................................................................ 31 4.1.2 Feedback Imediato ....................................................................................................... 32 4.1.3 Legibilidade.................................................................................................................. 32 4.1.4 Agrupamento/Distino de Itens .................................................................................. 32
4.1.4.1 4.1.4.2 Agrupamento/Distino por Localizao ............................................................................. 33 Agrupamento/Distino por Formato................................................................................... 33

4.2

A CARGA DE TRABALHO ......................................................................................................... 33

ii

Engenharia de usabilidade: uma abordagem ergonmica 4.2.1

4.2.1.1 4.2.1.2

Brevidade ..................................................................................................................... 34
Conciso............................................................................................................................... 34 Aes Mnimas..................................................................................................................... 34

4.2.2 Densidade Informacional ............................................................................................. 34 4.3 O CONTROLE EXPLCITO ......................................................................................................... 35 4.3.1 Aes Explcitas do Usurio ........................................................................................ 35 4.3.2 Controle do Usurio..................................................................................................... 35 4.4 A ADAPTABILIDADE ................................................................................................................ 35 4.4.1 Flexibilidade ................................................................................................................ 36 4.4.2 Considerao da experincia do usurio..................................................................... 36 4.5 A GESTO DE ERROS ............................................................................................................... 36 4.5.1 Proteo contra os erros.............................................................................................. 37 4.5.2 Qualidade das mensagens de erro ............................................................................... 37 4.5.3 Correo dos erros....................................................................................................... 37 4.6 A HOMOGENEIDADE/COERNCIA ............................................................................................ 37 4.7 O SIGNIFICADO DOS CDIGOS E DENOMINAES.................................................................... 38 4.8 A COMPATIBILIDADE............................................................................................................... 38 5. MODELO DE COMPONENTES DE IHC............................................................................. 39 5.1 INTRODUO AO MODELO LINGSTICO ................................................................................. 39 5.2 OS COMPONENTES DA INTERAO HUMANO-COMPUTADOR .................................................. 40 5.2.1 Os dilogos................................................................................................................... 43
5.2.1.1 5.2.1.2 5.2.1.3 5.2.1.4 Aes.................................................................................................................................... 43 As Tarefas ............................................................................................................................ 43 Os Estilos dos Dilogos........................................................................................................ 44 Estruturas de interaes........................................................................................................ 45

5.2.2
5.2.2.1 5.2.2.2 5.2.2.3 5.2.2.4 5.2.2.5 5.2.2.6 5.2.2.7 5.2.2.8

Os Objetos de Interao............................................................................................... 46
Os Painis de Controle ......................................................................................................... 47 Os controles compostos........................................................................................................ 51 Os grupos de controles ......................................................................................................... 58 Os controles simples............................................................................................................. 59 Os campos de entrada........................................................................................................... 61 Os mostradores estruturados ................................................................................................ 63 Os Mostradores Simples....................................................................................................... 68 As Orientaes ..................................................................................................................... 68

5.2.3 5.2.4
5.2.4.1 5.2.4.2

Os Sistemas de Significado........................................................................................... 71 As Primitivas ................................................................................................................ 76

As formas visuais ................................................................................................................. 76 Formas sonoras..................................................................................................................... 78

TERCEIRA PARTE: O CICLO DA ENGENHARIA DE USABILIDADE ............................... 79 6. ABORDAGEM PARA A ENGENHARIA DE USABILIDADE .......................................... 79

6.1 O ENVOLVIMENTO DO USURIO NO PROJETO ........................................................................... 80 6.1.1 As formas de envolvimento........................................................................................... 81 6.1.2 Organizao para o envolvimento do usurio ............................................................. 82 6.2 O CICLO DA ENGENHARIA DA USABILIDADE ........................................................................... 82 7. A PERSPECTIVA DA ANLISE ........................................................................................... 85 7.1 DEFINIO DO ESCOPO DO SISTEMA........................................................................................ 85 7.2 ANLISE DO USURIO ............................................................................................................. 85 7.3 ANLISE DO TRABALHO .......................................................................................................... 86 7.3.1 Anlise das Tarefas ...................................................................................................... 87
7.3.1.1 7.3.1.2 7.3.1.3 Entrevistas com gerentes ...................................................................................................... 87 Entrevistas com usurios ...................................................................................................... 88 Descrio das tarefas............................................................................................................ 88

7.3.2 7.3.3
7.3.3.1 7.3.3.2 7.3.3.3

Anlise do Ambiente..................................................................................................... 88 Anlise das atividades.................................................................................................. 89

Anlise de situaes de normalidade.................................................................................... 89 Anlise de Situaes Crticas ............................................................................................... 90 Anlise de situaes de Erros e Incidentes ........................................................................... 90

7.3.4

A elaborao do Relatrio de Anlise.......................................................................... 90

iii

Engenharia de usabilidade: uma abordagem ergonmica 7.4 8. ANLISE DAS POSSIBILIDADES E RESTRIES TECNOLGICAS ................................................. 91 A PERSPECTIVA DA SNTESE............................................................................................ 92 8.1.1 8.1.2 8.1.3 8.1.4
8.1.4.1 8.1.4.2

Especificao do Contexto de Uso ............................................................................... 92 Definio da nova estrutura do trabalho ..................................................................... 92 Especificao da usabilidade esperada ....................................................................... 93 O Projeto da Interface.................................................................................................. 94
The Bridge - Projeto de IHC orientado objetos. ................................................................ 94 Usage-Centered Design (Constantine, 1999) ...................................................................... 98

8.2 9.

CONSIDERAES SOBRE O PROJETO DE IHC.......................................................................... 104 A PERSPECTIVA DA AVALIAO .................................................................................. 106

9.1 PROBLEMA DE USABILIDADE ................................................................................................. 106 9.1.1 Contexto de um problema de usabilidade .................................................................. 106 9.1.2 Efeitos de um problema de usabilidade...................................................................... 107 9.1.3 A descrio de um problema de usabilidade.............................................................. 107 9.1.4 Tipos de problemas de usabilidade ............................................................................ 108 9.2 OBJETIVOS DE UMA AVALIAO DE USABILIDADE ................................................................. 109 9.3 TCNICAS PROSPECTIVAS ...................................................................................................... 110 9.4 TCNICAS PREDITIVAS OU DIAGNSTICAS ............................................................................ 111 9.4.1 Avaliaes Analticas ................................................................................................. 111 9.4.2 Avaliaes Heursticas ............................................................................................... 112
9.4.2.1 9.4.2.2 9.4.2.3 Avaliaes Heursticas de Usabilidade............................................................................... 112 Inspeo Cognitiva da Intuitividade ................................................................................... 114 Inspees preventivas de erros ........................................................................................... 115

9.4.3 Inspees Ergonmicas via Checklists....................................................................... 115 9.5 TCNICAS OBJETIVAS ............................................................................................................ 117 9.5.1 Ensaios de interao .................................................................................................. 117
9.5.1.1 9.5.1.2 As caractersticas dos ensaios............................................................................................. 117 Montagem de um ensaio de interao ................................................................................ 121

9.5.2 Os sistemas de monitoramento................................................................................... 126 9.6 COMPROMISSO ENTRE TCNICAS DE AVALIAO................................................................... 127 9.7 PROJETO DE AVALIAO ....................................................................................................... 128 9.8 PLANO DE TESTES.................................................................................................................. 129 10. 10.1 11. A NORMA ISO 9241 .......................................................................................................... 131 VERIFICANDO AS QUALIDADES ERGONMICAS ATRAVS DA ISO-9241................................. 134 REFERNCIAS BIBLIOGRFICAS .............................................................................. 136

iv

ENGENHARIA DE USABILIDADE: UMA ABORDAGEM ERGONMICA Introduo

No incio, os usurios de programas de software eram os seus prprios desenvolvedores. Mais tarde estes programas passaram a ser destinados a um pequeno pblico de usurios externos, que recebiam treinamento pesado. At a, tudo ia relativamente bem com as interfaces humano-computador, mas quando os programas de computadores passaram a ser destinados a um pblico mais amplo e menos treinado, e os sistemas passaram a ser propostos como produtos, destinados ao mercado consumidor, a coisa comeou a no dar certo. A falta de interesse pela lgica de utilizao, fazia com que as interfaces com os usurios fossem sempre deixadas como ltima coisa no desenvolvimento. Interfaces difceis, feitas as pressas, contribuiram para a famosa "barreira da informtica", que nos anos 80, fez com que a disseminao dos computadores e de produtos de software ficasse s como uma promessa. Muita coisa evoluiu de l para c, mas mesmo nos nossos dias, so frequentes casos de interfaces que se colocam como barreiras. Veja um exemplo de uma interface engessada, pois inadequada para quem tenha trocado de endereo e ainda no tenha decorado o novo CEP.

Este exemplo mostra que quando um novo dispositivo, sistema interativo ou ferramenta informatizada introduzido em um sistema de trabalho, ele causa um forte impacto na maneira como os usurios desenvolvem as estratgias que iro utilizar em suas atividades.

As consequncias de experincias negativas variam desde pequenos aborrecimentos e frustraes. No exemplo apresentado, o usurio pode sentir-se diminuido perante os outros e se culpar por no conseguir interagir ou no entender o que todo mundo usa. Em outras interfaces, de uso mais frequente e profissional, os aborrecimentos e frustraes podem levar a ansiedade e ao estresse, devido a sequncia de experincias negativas, da presso pela obrigao do uso imposta pela chefia. Em casos mais agudos, o estresse no liberado pode levar a psicopatologias, em um processo pelo qual o usurio apresenta-se inicialmente irritado, deprimido, estpido com os colegas, mais tarde sente-se perseguido, apresenta dores de cabea constantes, clicas abdominais. Em casos extremos, ele pode desenvolver ansiedade generalizada, comportamento compulsivo, crises de pnico... Pelo lado da empresa, interfaces difceis, que aumentam a carga de trabalho do usurio, trazem conseqncias negativas que vo desde a resistncia ao uso, passando pela subutilizao, chegando ao abandono do sistema. Dependendo da escala em que o software empregado os prejuzos para a empresa podem ser expressivos. As causas de fatos negativos como estes continuam a o desconhecimento da atividade, o desconhecimento cognitivo humano, o desinteresse pela lgica de utilizao falta de ferramentas lgicas para o desenvolvimento usabilidade. ser: do e a da

O desenvolvimento de sistemas com boa usabilidade ir impactar a tarefa no sentido da eficincia, eficcia, produtividade da interao. O usurio ir atingir plenamente seus objetivos com menos esforo e mais satisfao. Eventualmente, uma interface poder ter fins teraputicos e contribuir para aliviar as frustraes e o stress do dia a dia. (Picard, 2002) A usabilidade ir impactar positivamente o retorno do investimento para a empresa. Ela ser argumento de vendas, passar uma imagem de qualidade, evitar prejuzos para os clientes, ligados ao trabalho adicional e ao retrabalho de correes freqentes, por exemplo. A empresa desenvolvedora ir certamente economizar custos de manuteno e de revises nos produtos, como mostra o texto sobre Engenharia de Usabilidade (Nielsen, 1993).

Usabilidade e a Ergonomia
Usabilidade definida como a capacidade que um sistema interativo oferece a seu usurio, em um determinado contexto de operao, para a realizao de tarefas, de maneira eficaz, eficiente e agradvel (ISO 9241). A intuitividade, a facilidade e a eficincia de uso em um dispositivo informatizado contribuem para sua usabilidade, e a Ergonomia tm muito em comum com isso tudo. Afinal, esta disciplina visa a adaptao do trabalho ao

homem, por meio de sistemas e dispositivos que estejam adaptados a maneira como o usurio pensa e trabalha. Para a construo de interfaces amigveis ou ergonmicas, o engenheiro de usabilidade deve, entre outras coisas, conhecer muito bem o usurio e o seu trabalho. Primeiro, porque as pessoas tm formas particulares de pensar e trabalhar, que em geral so muito mais elaboradas do que as imaginadas por projetistas de interfaces, que no consideram estratgias de aprendizado, de erros e de economia, por exemplo. Segundo, porque a maneira de pensar e trabalhar conseqncia direta das caractersticas do dispositivo que introduzido no local de trabalho do usurio. A atividade tem que ser pensada como uma evoluo, na medida em que ao perceberem completamente o dispositivo, as pessoas passam a us-lo de forma diferente. Terceiro porque o computador e sua interface representam uma ferramenta cognitiva, uma extenso da memria, uma prtese cognitiva que permite tratar melhor a informao. importante que se conhea como os processos cognitivos humanos se desenvolvem para a concepo de prteses cognitivas compatveis com eles. A usabilidade uma qualidade de uso, ou seja, ela se define quando do uso do sistema. Isto quer dizer que ela definida ou medida para um contexto em que um sistema operado. Assim, um sistema pode proporcionar boa usabilidade para um usurio experiente, mas pssima para novatos, ou vice e versa. Pode ser fcil de operar se o sistema for usado esporadicamente, mas difcil, se for utilizado freqentemente, no dia a dia. Uma interface bonita pode dar prazer se o site for acessado por conexes rpidas, mas causar ansiedade insuportvel se ele for acessado de casa, via modem. Mas como conceber algo amigvel em tantas situaes diferentes? A adaptabilidade uma, entre as qualidades de uma interface com o usurio. Um interface adaptvel permitir que diferentes usurios, em diferentes estgios de competncia, em diferentes tarefas e em diferentes ambientes fsicos, tecnolgicos e organizacionais, possam alcanar seus objetivos com eficcia, eficincia e satisfao. evidente, a construo da usabilidade vai deixar o sistema mais caro. As empresas precisam implementar um esforo sistemtico para garantir esse desenvolvimento. Jacob Nielsen, o guru da usabilidade mundial, fala, em seu primeiro livro sobre o assunto, do retorno extremamente lucrativo de investimentos no desenvolvimento de boas interfaces com o usurio (economia de custos, facilidade nas vendas, imagem da empresa, etc...). Isso pode ser feito a partir de uma perspectiva de engenharia, ligada a idia da otimizao (maximizar os resultados e minimizar os recursos necessrios). A Engenharia de Usabilidade surge como esforo sistemtico das empresas e

organizaes para o desenvolvimento da usabilidade dos sistemas interativo.

Engenharia de Usabilidade
Os sistemas interativos podem ser decompostos segundo dois subsistemas bsicos: Ncleo funcional ; Interface com o usurio O ncleo funcional formado por programas aplicativos, algortmos e base de dados, principalmente. A interface com o usurio formada por apresentaes, de informaes, de dados, de controles e de comandos. esta interface tambm que solicita e recepciona as entradas de dados, de controles e de comandos. Finalmente, ela controla o dilogo entre as apresentaes e as entradas. Uma interface tanto define as estratgias para a realizao da tarefa, como conduz, orienta, recepciona, alerta, ajuda e responde ao usurio durante as interaes. At a algum tempo atrs, o desenvolvedor tinha muito mais chances de sucesso ao construir programas de aplicao, do que interfaces com o usurio. De fato, ele recebia treinamento sobre mtodos e tcnicas e possua ferramentas que o auxiliavam na construo de um cdigo eficaz. Ele j no possua as mesmas facilidades em relao ao desenvolvimento de uma interface com o usurio, tarefa que exige abordagens, mtodos, conhecimentos e treinamento que os engenheiros de software no recebiam nos bancos da faculdade. No incio do processo eles desconsideravam o usurio (que s atrapalhava) e o trabalho que estes efetivamente realizavam e baseavam-se em informaes passadas por gerentes e responsveis pelos sistemas. Pela falta de apoio, deixavam para ltima hora a definio da lgica de operao e a construo das interfaces com o usurio. Fundamentalmente, deixavam de envolver o usurio (que s atrapalhava), na concepo e teste de prottipos. A partir do final dos anos 80 e sobretudo nos anos 90, foram desenvolvidos as primeiras abordagens, mtodos, tcnicas e ferramentas destinadas a apoiar a construo de interfaces intuitivas, fceis de usar e produtivas. A Engenharia de Usabilidade, saa dos laboratrios das universidades e institutos de pesquisa e comeava a ser implementada, como funo nas empresas desenvolvedoras de software interativo. Hoje so numerosos os livros, revistas, normas e relatrios tcnicos que nos apresentam mtodos, tcnicas e ferramentas para a montagem de uma capacidade em termos de engenharia de usabilidade nas empresas.

Existem publicaes que orientam a como especificar, construir e testar a usabilidade, como qualidade de uso e qualidade externa de um sistema de software interativo. Especialmente as normas ISO da srie 9241. Outras nos informam de centenas de tcnicas participativas ou documentais, para o projeto e a avaliao da usabilidade de interfaces. Livros e normas orientam a montagem de um processo de desenvolvimento centrado no usurio, como a norma ISO 13407. No momento atual, trata-se da engenharia de usabilidade como uma rea de processo (modelo CMMI) no qual as empresas de software capacitam-se difcil tarefa de produzir interfaces humano-computador com usabilidade.

Interface com o Usurio

A dificuldade no desenvolvimento de interfaces com usabilidade se deve ao fato delas constiturem fundamentalmente, sistemas abertos, probabilsticos, no determinsticos, sujeitos as influncias do ambiente e as interpretaes dos usurios. Suas entradas e sadas podem significar coisas diferentes para pessoas diferentes, em funo de seu conhecimento, do momento, do ambiente que as cercam. Se, por um lado, os programas das aplicaes so construdos por meio de linguagens de programao inequvocas, uma interface humano-computador, construda por meio de um conjunto aberto de smbolos ambguos, que devem podem ser interpretados de diferentes formas pelos usurios, em funo de seu contexto dinmico. Assim, pode-se afirmar que a experincia da interao humano-computador individual e nica, no sentido de que cada pessoa nica em sua bagagem de conhecimento e experincia. Dificilmente uma mesma interface v significar a mesma coisa para dois usurios distintos. Menor ainda, a chance dela ter um significado compartilhado entre usurios o seus projetistas.

Esta apostila
Esta apostila tem o objetivo de ajudar na mudana de uma realidade que no Brasil, que coloca o desenvolvimento de interfaces humano-computador mais prximo da arte do que da engenharia. Ele vem disponibilizar os conhecimentos e as ferramentas lgicas que caracterizam a abordagem ergonmica para Interfaces Humano-Computador desenvolvida pelo LabIUtil desde sua criao em 1995. A primeira parte se refere aos fundamentos da abordagem ergonmica para engenharia de usabilidade de IHC. So assim apresentadas, nos captulos 1, 2 e 3 suas bases tericas, advindas das perspectivas sobre o trabalho, a psicologia cognitiva e da semitica. A segunda parte se refere ao ferramental da abordagem, apresentando nos captulos 4 e 5 duas ferramentas lgicas para o projeto e avaliao de sistemas
5

interativos: os critrios de qualidade das IHC ergonmicas e um modelo de componentes de IHC. Os captulos 6, 7 e 8 referemse ao ciclo da engenharia de usabilidade, abordado a partir das perspectivas de anlise, sntese e avaliao. A abordagem ergonmica para a engenharia da usabilidade de Interfaces Humano-Computador caracterizada pela considerao dos conhecimentos disponveis sobre habilidades e capacidades cognitivas humanas e dos aspectos ligados ao trabalho como ele , efetivamente realizado. Os dispositivos de software interativo assim realizados, centrados nos usurios e sua tarefas, tm chances reais de serem adaptados aos usurios e adequados a suas tarefas. Seguindo os preceitos da abordagem ergonmica, estes aplicativos forneceriam conduo e feedback nas interaes sempre falando a lngua do usurio. As taxas de erros na realizao da tarefa cairiam em funo destas qualidades, mas tambm devido a apresentaes e dilogos consistentes entre si e pela garantia do controle da interao ao usurio. A carga de trabalho diminuiria por meio de dilogos e telas compatveis com as necessidades dos usurios em suas tarefas e por uma maior flexibilidade na interao.

Primeira parte : FUNDAMENTOS TERICOS DA ENGENHARIA DA USABILIDADE

1. O TRABALHO E SUAS PERSPECTIVAS

A anlise do trabalho inevitvel para uma interveno ergonmica, seja para a especificao, construo ou avaliao da usabilidade. Uma interface com o usurio, segundo a perspectiva ergonmica, deve proporcionar a realizao de tarefas de modo eficaz, eficiente e agradvel a seu operador. Na anlise de uma situao de trabalho, o ergonomista ou o engenheiro de usabilidade, deve considerar os seguintes aspectos:. O Contedo do Trabalho: caracterizado por objetivos, estratgias, informaes, ferramentas, etc que podem ser analisados segundo as seguintes linhas de corte: Linhas de Corte: Funcionamento e Utilizao : a que separa lgica de funcionamento e lgica de operao do sistema; Tarefa e Atividade : a que distingue o que deve ser realizado do que efetivamente realizado; A Dinmica do Trabalho : a que diferencia o que do que ser...

1.1 Funcionamento e Utilizao

Qualquer sistema ou dispositivo informatizado pode ser descrito segundo duas lgicas: a de seu funcionamento e a de sua operao ou utilizao. A lgica de funcionamento descreve as inter-relaes entre os componentes internos ao sistema, uma vez que as funes dos sistemas tenham sido acionadas ou solicitadas pelo usurio. A lgica de operao se refere ao uso do sistema pelo usurio para realizar suas atividades. Ela descreve os relacionamentos existentes entre objetivos dos usurios em suas tarefas e as entradas e sadas do sistema. A lgica de utilizao a desenvolvida atravs do conhecimento da interao com o sistema. Essa ltima baseada na chamada imagem operativa; representao que se tem da realidade do

ambiente de trabalho, modificada e simplificada pelo que funcionalmente significativo. A imagem operativa amplia os elementos pertinentes e elimina os secundrios. Enquanto a lgica de funcionamento baseia-se no conhecimento das funes e de seus mecanismos internos, a de utilizao baseia-se nas repercusses visveis do sistema. Os conflitos entre as duas lgicas evidenciam os pontos problemticos, onde as pessoas desenvolvem mecanismos de regulao que podem ser custosos, tanto para elas como para a empresa. Uma preocupao importante no projeto da interface de um sistema interativo a mostrar claramente ao usurio os elementos da lgica de operao definida para o sistema. Por exemplo, apresentar corretamente na interface, o estado habilitado e desabilitado de opes de comando ou mostrar a necessidade do usurio criar pacotes (Zips) para guardar arquivos antes de compacta-los..

1.2 Tarefa e atividade

Uma outra distino importante a que divide o trabalho entre tarefa e atividade. Tarefa o trabalho prescrito, e refere-se quilo que a pessoa deve realizar, segundo sua chefia, seus colegas ou segundo ela mesmo. A atividade trabalho como efetivamente realizado e refere-se ao modo como a pessoa realmente realiza sua tarefa. O contedo da anlise da tarefa descrito em termos de metas e objetivos, procedimentos, regras e restries, etc.. A coleta de informaes feita atravs de entrevistas, anlise da circulao e tratamento da documentao, anlise da organizao do trabalho, das ligaes entre os servios, das caractersticas dos postos de trabalho, etc.. Em suma, busca-se compreender como o dispositivo funciona e como ele deve ser operado. A anlise da atividade visa entender como o sistema efetivamente operado, e feita atravs das observaes "in loco" de sesses de trabalho real. As observaes das interaes estabelecidas entre operadores reais e o sistema podem ser organizadas de modo a cobrir situaes de normalidade (i), de aprendizado (ii) e de incidentes (iii). A anlise destas situaes vai revelar aspectos importantes como as operaes efetuadas, seu encadeamento, suas dificuldades, alm dos tipos, freqncias, causas e condies de aparecimento dos incidentes. uma viso geral da utilizao da informao, isto , conhecer as informaes realmente utilizadas e sua ordem, as informaes que faltam, as inteis e as que induzem a erros.

 as denominaes dadas pelos usurios para as informaes e operaes por ele realizadas (linguagem operativa). As diferenas existentes entre o que previsto e o que se verifica na prtica, tanto no que se refere ao funcionamento, como a operao do sistema, est certamente na origem de erros e incidentes ou de custosas estratgias de acomodao (jeitinho) desenvolvidas pelos operadores.

1.3 A Dinmica do trabalho

Um dos princpios bsicos da abordagem ergonmica para o desenvolvimento de sistemas de trabalho, sejam eles informatizados ou no, o de "conhecer para modificar". importante salientar que esta mxima se refere tanto aos usurios como a seu trabalho. Uma nova ferramenta vai implicar em novas formas de realizar o trabalho e em novas exigncias sobre o usurio e sobre seu ambiente. As novas exigncias sobre o usurio se referem em geral a mais formao e mais experincia na tarefa, na operao do sistema e da informtica em geral. Elas podem representar tambm a necessidade de ampliao de suas habilidades motoras (velocidade de digitao, preciso de movimentos manuais), perceptivas (acuidade visual e sonora), cognitivas (memorizao e recuperao) e psicolgicas (sociabilidade e motivao para aprender). Sob o ponto de vista da tarefa, um novo sistema representa freqentemente uma nova repartio de trabalho, uma nova arquitetura de objetivos, novas possibilidades ou limitaes tcnicas. Sob o ponto de vista do ambiente, a introduo de um novo sistema representa freqentemente novas instalaes, nova infra-estrutura, novos equipamentos, novos dispositivos, etc. preciso conhecer as exigncias atuais e futuras, de modo a tornar tranqila a transio entre os contextos de operao do velho para o novo sistema, e em conseqncia, evitar problemas de usabilidade.. A introduo de uma nova ferramenta ter um impacto maior ou menor, dependendo da compatibilidade entre as novas e as velhas exigncias sobre o usurio e suas formas de realizar o trabalho. A anlise e especificao de sistemas inovadores dificultada pela aparente inexistncia de um quadro de comparao entre o que e o que ser o contexto de realizao da tarefa. Freqentemente, este fato citado como justificativa para a no realizao de uma boa anlise do existente. Entretanto, e antes de negar a pertinncia da anlise do trabalho, prope-se que se busque analisar a tarefa com sistemas relacionados ao sistema pretendido (estado-da-arte), que na maioria dos casos existem efetivamente. Por traz desta

proposta esta a constatao de que em geral a inovao se d pela evoluo, e no pela revoluo face o existente. Assim possvel aplicar o princpio de "conhecer para modificar" sobre uma tarefa futura, apoiada por um sistema ou interface anloga ao que se pretende desenvolver. De fato, entrevistar, observar e analisar, usurios de sistemas representando o estado-da-arte do projeto uma estratgia vlida para conhecer, com uma aprecivel antecedncia, as vantagens e inconvenientes de lgicas de operao que poderia ser adotadas no novo sistema. Esta atividade pode ser vista como o primeiro ciclo de prototipagem & teste do desenvolvimento de um sistema. Com efeito, a anlise do estado da arte assume no desenvolvimento da usabilidade, uma pertinncia bem maior do que a usual em engenharia de software.

1.4 O contedo do trabalho

Alm de conhecer sobre a natureza das lgicas, perspectivas e dinmica de um sistema de trabalho, fundamental conhecer o seu contedo em termos de objetivos, mtodos, condies, estruturas, etc.. Para sistematizar as anlises, o engenheiro de usabilidade pode adotar alguma ferramenta, como o formalismo M.A.D. (Scapin, 1993), que permitir recolher de forma sistemtica os elementos que descrevem ou especificam o trabalho em diversas situaes de anlise, nas quais tanto uma tarefa, como uma atividade, podem ser descritos por meio dos seguintes elementos : Objetivo ltimo a alcanar (o que o operador deve realizar); Decomposio em sub-tarefas/sub-objetivos; Relaes entre as sub-tarefas (sequenciais, paralelas, alternativas, facultativas, etc); Nomes, denominaes e definies das sub-tarefas; Objetivos a alcanar nas sub-tarefas; Mtodos ou a sequncia de aes que o operador utiliza em cada sub-tarefa para alcanar seus objetivos (como o operador realiza sua tarefa); Estados inicial e final do sistema para cada sub-tarefa (quais informaes so utilizadas e quais as informaes que so produzidas em cada etapa); Pr- e ps-condies das sub-tarefas, que se referem a atributos dos elementos pertencentes aos estados inicial e final do sistema, que devem ser satisfeitos para autorizar o incio de determinada ao. Alm desses elementos, apresentam atributos: as tarefas individualmente

10

 FAC (facultativa) : a tarefa no obrigatoriamente executada, mas que ela pode ser observada em certas condies. Ela no indispensvel para a tarefa mas, assim mesmo, merece ser anotada, sobretudo numa perspectiva de concepo. @ (repetitiva) : a tarefa pode-se repetir vrias vezes. PRIOR (prioritria) : tarefa que pode interromper outras. Permite atribuir nveis de prioridade entre as tarefas e saber que tarefas podem interromper a tarefa em curso. INTER (interruptvel) : a tarefa ou no interruptvel. Este atributo permite exprimir que uma tarefa pode ser interrompida ou no pelos eventos externos. Assim que a tarefa termina, a tarefa interrompida repetida nas condies explicitadas pelo valor do atributo. Por outro lado, as tarefas e as atividades compostas apresentam componentes inter relacionadas logicamente, formando uma estrutura hierarquizada. Os construtores das estruturas de tarefas segundo M.A.D. so os seguintes: -SEQ (estrutura seqencial): subtarefas so executadas em seqncia, i.e., uma aps a outra, numa dada ordem. Enquanto a primeira tarefa no esteja determinada, fica certo de que a segunda no ser feita. As subtarefas de uma seqncia no podem interromper uma s outras. -PAR (estrutura paralela): exprime que a ordem das subtarefas no foi imposta priori e que podem existir tarefas de interrupo. Cada subtarefa tem um nvel de prioridade. As pr-condies das subtarefas de mais alta prioridade so testadas. A ordem de execuo de vrias subtarefas de mesma prioridade determinada ao acaso. Enquanto uma tarefa interruptvel executada as tarefas de prioridade superior so ditas de interrupo -ALT (estrutura alternativa): estrutura que permite indicar uma tarefa que se pode executar de vrias maneiras, mas apenas uma das subtarefas efetuada. Para determinar qual subtarefa se efetua, as prcondies detonadoras de cada uma delas sero testadas. -SIM (estrutura simultnea): uma estrutura em que que um ou mais operadores possam executar duas ou mais tarefas ao mesmo tempo. O funcionamento o mesmo que o de PAR com a diferena de que vrias tarefas podem ser executadas ao mesmo tempo. Uma tarefa SIM termina quando todas as subtarefas no facultativas foram executadas ao menos uma vez ou ento quando as ps-condies fim de tarefa esto verificadas.

11

Um passo importante da anlise do contedo do trabalho refere-se validao das descries e informaes que foram coletadas e que compem as representaes sobre o trabalho. Para tanto esta etapa deve prever a realizao de observaes in-loco do trabalho do usurio. especialmente recomendado que seja solicitado aos operadores que verbalizem sobre quais os objetivos, critrios, diagnsticos e razes das decises tomadas. Pode-se prever meios de registro em vdeo, audio e um bloco de anotaes para capturar os aspectos citados em trs tipos de situaes; situao de normalidade, situaes consideradas crticas e situaes de erros e incidentes. Situao de Normalidade: A anlise de atividades normais feita atravs de observaes contnuas procurando abranger toda a durao do trabalho.Em especial deve-se confrontar a descrio da tarefa realizada na etapa anterior de anlise com o que realmente realizado pelo usurio em termos de objetivo ltimo a alcanar, decomposio da atividade em subatividades/sub-objetivos, relaes entre as sub-atividades (sequenciais, paralelas, alternativas, facultativas, etc). Deve-se verificar em particular, os graus de dificuldades na realizao das atividades. Situaes crticas A partir do que foi levantado na etapa de anlise da tarefa, algumas situaes podem ser consideradas problemticas ou crticas e devem ser observadas com maior ateno. A observao destas situaes se faz ento por amostragem de perodos escolhidos.Nelas deve-se confrontar a descrio da tarefa prescrita com a atividade realizada pelo usurio em termos de mtodos empregados e do fluxo de informao nesta parte do sistema. Situaes de Erros e Incidentes As situaes de erros e incidentes so de difcil observao, tanto pela dificuldade de prever sua ocorrncia como pela dificuldade de seguir seu processo. Recomenda-se ento que sejam preparadas simulaes, in-loco (no local de trabalho) ou em laboratrio. Dependendo do sistema, as do primeiro tipo podem ser dispendiosas para empresa, operador e analista. Portanto sua realizao deve ser alvo de uma estudo custo X benefcio cuidadoso. Um outro tipo de simulao poder ser realizado em um cenrio fora da situao de trabalho. Uma situao hipottica deve ser apresentada verbalmente ao usurio que dever descrever os procedimentos para a recuperao da situao de normalidade. Assim, a viso geral da tarefa, complementada por um levantamento em termos das informaes envolvidas com a sua realizao efetiva. Desta forma pode-se conhecer quais so;

12

 as informaes necessrias e a ordem em que tornam-se disponveis; as informaes que so difceis de obter; as informaes que so inteis (no so utilizadas); as informaes que so impertinentes (que atrapalham e induzem a erros de interpretao). Tambm pode-se obter informao complementar sobre as tarefas e sub-tarefas; quais so as mais frequentes quais so os horrios (durao) e modo de utilizao quais as deficincias, problemas e incidentes encontrados. Em particular deve-se identificar suas causas, condies de aparecimento, frequncia e os procedimentos para a sua recuperao.

2. A PSICOLOGIA COGNITIVA
Assim como os conhecimentos sobre a fisiologia da mo e do brao so importantes no projeto de uma ferramenta manual, tambm os conhecimentos sobre as caractersticas humanas no tratamento da informao so importantes no projeto de um software interativo. Considerar o usurio significa conhecer, alm das informaes provenientes da anlise ergonmica do trabalho (idade, sexo, formao especfica, conhecimentos, estratgias, etc...), tambm aquelas ligadas as suas habilidades e capacidades em termos cognitivos. Na medida em que se pretende o computador como uma extenso do crebro humano, fundamental conhecer como se processam os tratamentos cognitivos na realizao de uma tarefa informatizada. Nos ltimos anos, vrios estudos tm sido realizados em psicologia sobre o tratamento da informao. A descrio das leis gerais sobre o comportamento (behaviorismo) complementada, no sem controvrsias, pela descrio dos mecanismos que explicam o seu funcionamento (cognitivismo). Em suas intervenes para a concepo e avaliao de interfaces humano-computador, os ergonomistas devem valer-se dos resultados de ambos os tipos de estudos; os enfocando comportamentos humanos e os centrados nas estruturas cognitivas humanas

2.1 Os modelos mentais

O sistema cognitivo humano caracterizado pelo tratamento de informaes simblicas. Isso significa dizer que as pessoas elaboram e trabalham sobre a realidade atravs de modelos mentais ou representaes que montam a partir de uma realidade. Esses modelos, que condicionam totalmente o comportamento do indivduo, constituem a sua viso da

13

realidade, que modificada e simplificada pelo que funcionalmente significativo para ele. O sujeito amplia os elementos pertinentes e elimina os secundrios estando apresentao resultante intimamente ligada aos conhecimentos j adquiridos e a compreenso que o indivduo tem de um problema. Os modelos mentais relativos a um sistema interativo, por exemplo, variam de indivduo para indivduo, em funo de suas experincias passadas, e evoluem no mesmo indivduo, em funo de sua aprendizagem. Neste sentido, pode-se distinguir, numa determinada situao de trabalho informatizada, as seguintes conseqncias clssicas: os modelos mentais relativos a uma interface correspondem a um conjunto de conhecimentos semnticos (conceitos) e procedurais (procedimentos) que particular a cada usurio. os modelos mentais desenvolvidos por projetistas e por usurios se diferenciam grandemente; os modelos mentais desenvolvidos por indivduos, que exercem diferentes funes com o sistema, gesto ou de operao, por exemplo, se diferenciam grandemente. Neste caso so evidentes as diferenas nas representaes mentais de quem opera um sistema assdua e freqentemente, de quem o faz de maneira espordica ou intermitente; os modelos mentais desenvolvidos por usurios novatos e por experientes se diferenciam grandemente; A interface humano-computador deste sistema, deve ser flexvel o suficiente, para adequar-se aos diferentes tipos de usurios, ao mesmo tempo em que possa adaptar-se evoluo das caractersticas de um usurio especfico durante seu processo de aprendizagem com o sistema. As teorias cognitivas descrevem dois tipos bsicos de modelos mentais, os que representam procedimentos e os que representam conceitos. Ambos se organizam em redes hierrquicas de conhecimentos, semnticos e procedurais sobre, por exemplo, os significados das funes do sistema interativo e sobre como se operam estas funes. As lgicas de funcionamento (conceitos) e de operao (procedimentos) de um dispositivo esto associadas natureza destes dois tipos de representaes mentais e contribuem igualmente para o seu entendimento. Da a necessidade dos textos de ajuda explorarem estas duas perspectivas de um software interativo; como funcionam e como se operam suas funes. Para o projeto de interfaces humano-computador, alm da variabilidade, nos indivduos e no tempo, importante saber o que favorece ou limita a elaborao, armazenagem e a recuperao destas representaes em estruturas de memria e

14

por meio da percepo da realidade. Isto ser tratado nos tpicos sobre a memria.

2.2 A Percepo
O homem toma conhecimento do mundo atravs do tratamento da informao sensorial. De fato, o homem, como todos os seres vivos, coleta no meio ambiente as informaes necessrias a sua adaptao e a sua sobrevivncia. A percepo est delimitada pelo conjunto de estruturas e tratamentos pelos quais o organismo impe um significado as sensaes produzidas pelos rgos perceptivos. Gagn (1962) distingue, na atividade de percepo trs nveis distintos de processos: processos de deteco ou neuro-fisiolgico: constatar a existncia de um sinal; processos de discriminao (de identificao) ou perceptivo: classificar as informaes em categorias. Esta funo s possvel se anteriormente houve a deteco e se j existirem categorias memorizadas; processos de interpretao (tratamento das informaes) ou cognitivo: dar um significado s informaes. Esta funo s possvel se anteriormente houve a deteco, a discriminao e se j existirem conhecimentos memorizados. Inicialmente, pode-se distinguir sensao da percepo que, nas atuais obras de psicologia, so tratadas como dois nveis de um mesmo processo cognitivo. Na verdade, sensao a resposta especfica um estmulo sensorial, enquanto percepo o conjunto dos mecanismos de codificao e de coordenao, das diferentes sensaes elementares, visando lhes dar um significado. O estudo da percepo situa-se num nvel menos sensorial e mais cognitivo do que o estudo da sensao. De fato, interessa menos as condies do estmulo que permitem a percepo, e mais o significado correspondente um certo estmulo, isto , o conhecimento do objeto, tal como ele percebido. A cognio caracteriza-se por um processo ou um caminho de duas vias : de baixo para cima (botton-up) e de cima para baixo (Up-down). Com efeito, o percebido no uma fotografia fiel do ocorrido, pois a informao que resulta do processo de deteco muitas vezes incompleta, e integrada com uma informao 'parecida' que desce da memria. Assim, possvel uma atribuio de significado rapidamente, ainda que de forma equivocada. De fato, uma informao "parecida" guardada na memria nem sempre corresponde a realidade. Assim, no processo da percepo humana, ganha-se em rapidez, mas perde-se em preciso.

15

Estes processos se verificam, com maior ou menor variao no conjunto de sistemas autnomos que caracterizam a percepo, e que so apresentados a seguir.

2.2.1 A percepo visual

O sistema visual humano organizado segundo os nveis neuro-sensorial, perceptivo e cognitivo. O nvel neuro-sensorial envolve a transformao dos traos elementares da estimulao visual em primitivas visuais. A nvel perceptivo, esta primitivas so estruturadas seguindo diversos mecanismos conhecidos como Leis da Gestalt. Estas leis descrevem as condies de aparecimento de grupamentos e incluem os princpios bsicos de: proximidade, similaridade, continuidade e conectividade. A percepo de contornos, a segregao figura-fundo e a ocorrncia de iluses ptico-geomtricas so fenmenos da estruturao prsemntica. Mesmo que possam corresponder aparncia de um objeto, elas ainda no permitem sua identificao. Para tanto necessrio montar uma representao espacial (3D) e recuperar os conhecimentos prvios sobre o significado do objeto.

2.2.2 A percepo auditiva

O sistema auditivo humano recebe as informaes de fontes sonoras simultneas de maneira seletiva. As representaes acusticamente coerentes, denominados objetos ou "imagens" auditivas, so organizadas em processos perceptivos (organizadores) paralelos e seqenciais. Os processos paralelos organizam os eventos sonoros segundo sua amplitude, freqncia, forma espectral e posio. Os processos seqenciais lidam com sucesses de eventos acsticos percebidos na forma de um fluxo. Os componentes de um fluxo sonoro apresentam continuidade, como em uma melodia, e so classificados por relaes de freqncia, cadncia, intensidade, contedo espectrais, etc.

2.2.3 A percepo da fala

A percepo da linguagem falada est organizada na forma de uma srie de sucessivos processos de codificao. A nvel neuro-sensorial ocorre a codificao neuronal dos estmulos fonticos. A informao sobre a estrutura espectral destes ndices extrada e estocada numa memria sensorial de curtssimo termo. Isto permite a anlise dos ndices acsticos pertinentes que so confrontados com os traos fonticos caractersticos de uma linguagem especfica. Ocorre ento a filtragem das variaes
16

fonticas que no so caractersticas, de maneira a isolar as unidades silbicas pertencentes aos idiomas dominados pelos indivduos. A nvel lexical se do os tratamentos de acesso ao lxico e de identificao das palavras. nvel sinttico ocorre a integrao das informaes lexicais e sintticas com a interpretao da mensagem recebida, nvel semntico.

2.2.4 Ateno e Vigilncia

Na realidade do trabalho, a deteco responde a um objetivo, mais ou menos explcito, por parte do sujeito, o qual ir organizar a coleta das informaes consideradas pertinentes em relao este objetivo. A ateno e a vigilncia desempenham um importante papel de regulao de todas as entradas de informaes, tanto para as deteces dirigidas pelo sujeito (voluntrias e conscientes), como para as recepes impostas pelas estimulaes externas. O meio ambiente analisado e explorado, de forma seletiva. A explorao dirigida por esquemas antecipatrios, que determinam a disponibilidade frente a diferentes tipos de configuraes (ticas, sonoras, etc.) e a planificao da ao perceptiva. Esses esquemas so desenvolvidos a partir da histria pessoal e profissional de cada indivduo. O resultado da explorao perceptiva modifica o esquema inicial que, por sua vez, modifica a explorao e, assim, sucessivamente. A orientao perceptiva se traduz por uma filtragem considervel dos sinais, sobre os quais a percepo no focalizada. Ela est ligada ao curso da ao no qual o sujeito encontra-se engajado, num determinado momento e, em particular, aos objetivos que ele persegue. Da mesma forma, ela depende da competncia do sujeito, a qual permite um conhecimento da probabilidade do aparecimento de certos sinais, e do significado de uma srie de eventos. Por exemplo, a representao que um usurio de um provedor de acesso Internet tem sobre o processo de conexo por linha telefnica comporta um conhecimento sobre os objetivos desta fase, uma previso sobre a evoluo esperada com os rudos produzidos pela linha telefnica e pelo modem, a antecipao dos sinais e mensagens apresentados na interface e a preparao para o curso da ao seguinte (efetuar o login, por exemplo). Os processos de ateno e vigilncia podem acarretar na ocorrncia de sinais que, por no serem esperados, no so percebidos, mesmo que estejam dentro do campo perceptivo. Por outro lado, pode ocorrer a percepo de sinais esperados, mesmo que no sejam extamente eles, os dectetados. Para

17

evitar estes fatos, preciso que estes sinais se imponham ao que est sendo esperado, atravs de caractersticas fsicas diferenciadas (nvel ou freqncia sonora, luminosidade, cor, etc.). O projetista de uma interface, consciente deste fato, deve diferenciar sinais ligados a situaes de anormalidade para que escapem dos processos antecipatrios da ateno e vigilncia.

2.3 A memria
Os modelos e representaes mentais so armazenados e recuperados atravs de um conjunto de fenmenos que tm em comum o fato de restiturem a informao, com maior ou menor transformao, aps um certo tempo, quando a fonte desta informao no est mais presente. A capacidade de memorizao humana pode encadear os seguintes processos: Reconhecimento: a capacidade humana de reencontrar no seu campo perceptivo elementos anteriormente memorizados (reconhecer o nome de uma opo de menu aps algum tempo sem v-la). Reconstruo: a capacidade humana de recolocar os elementos memorizados na sua organizao anterior (qual o caminho na estrutura de menus e as aes nas caixas de dilogo para a configurao de uma tabulao de pargrafo definida?). Esta capacidade representa um misto entre reconhecimento, de uma parcela do modelo metal considerada vlida e a lembrana de novos elementos para complementar o todo. Lembrana: a capacidade humana de recuperar, de forma integral, uma situao anteriormente vivenciada, sem a presena de nenhum dos elementos dessa situao (lembrar-se da sintaxe correta de comandos a serem entrados em uma linha de comando). Os conhecimentos cientficos atuais no permitem definir, de forma exata, os custos fisiolgicos associados a estes processos. Entretanto, no que se refere a uma pessoa que se vale de um aplicativo de produtividade, como um editor de textos ou planilha, de forma intermitente, possvel considerar que a lembrana do nome exato de um comando, para entrada em uma linha, seja mnemonicamente mais custosa em relao a seu reconhecimento em um painel de menu. O armazenamento e a recuperao da informao podem ser explicados a partir de fenmenos em dois nveis de atividades: as neuro-fisiolgicos e as cognitivas (tratamento da informao).

18

2.3.1 Modelos cognitivos para a memria

Os modelos cognitivos descrevem a memria humana a semelhana da memria de um computador. Este modelo, distingue trs sistemas de estocagem, que correspondem, provavelmente a sistemas neuro-fisiolgicos tambm distintos: o registro sensorial das informaes (RS), a memria de curto tempo (MCT) e a memria de longo tempo (MLT). Em sua verso original, a informao que liberada pelo sistema perceptivo, armazenada em um registro sensorial de capacidade limitada e altamente voltil. O registro sensorial da informao conservado apenas por alguns dcimos de segundos, sem nenhuma possibilidade de prolongamento. A parte do registro sensorial que pertinente face o curso das aes dos usurios selecionada para um tratamento mais elaborado, sendo armazenada em uma estrutura de memria denominada memria de curto termo -MCT- ou memria de trabalho MT-. A capacidade da MCT de 6 a 7 itens e seu esquecimento ocorre em poucos segundos. Esta declarao define a MCT como um registro de armazenamento voltil e limitado, indiferente ao formato da informao e passivo em relao ao nvel de evocabilidade exigido. J o modelo de memria de trabalho MT define esta memria intermediria como um centro de tratamentos, composta de dois sub-sistemas especializados, um nos tratamentos auditivos e outro nos tratamentos visuais-espaciais, com capacidade, volatilidade e acessibilidade diferentes, variando para tipos de indivduos. Para muitos indivduos a memria de trabalho visual maior e menos voltil ao contrrio da memria de trabalho sonora, mais voltil e com menor capacidade. Um executor central capaz de manter certas informaes em um alto nvel de evocabilidade. A partir da memria de trabalho, a informao pertinente armazenada em registros permanentes, os esquemas, que representam a base de conhecimentos do indivduo. A permanncia da informao na memria de longo termo MLT no est sujeita limitaes de ordem temporal, o que no implica em uma acessibilidade permanente. O esquecimento, nesta memria descrito como incapacidade de recuperao e causado pelo aumento em nmero e semelhana dos conhecimentos declarativos (conceitos), e pela incompatibilidade entre os contextos de codificao e de recuperao dos conhecimentos procedurais (procedimentos). Para favorecer estes processos, os projetistas de IHC devem investir na organizao, categorizao, diferenciao e discriminao das informaes apresentadas sobre estas interfaces.

19

Na correlao com os modelos mentais, existem dois tipos de esquemas de memria (de trabalho e permanente); os episdicos e os semnticos. A memria episdica guarda o conhecimento de ordem procedural, essencialmente dinmico e automatizvel, como seqncia de dilogo, ou caminhos em uma interface. O efeito do contexto (intrnseco, interativo, psicolgico) o fator determinante da recuperao da episdios. Um bom desempenho depende da compatibilidade entre as situaes no momento do registro e no momento da recuperao da informao. A memria semntica armazena conhecimentos declarativos organizados, segundo redes de proposies conceituais. O acesso informao independe do contexto, e acontece pela ativao de um de seus ns, e pela propagao desta ativao aos ns vizinhos. Aqui, a organizao, classificao e diferenciao das informaes apresentadas nas IHC garantem um bom desempenho humano.

2.4 O Raciocnio e o Aprendizado

O raciocnio definido como uma inferncia ou atividade mental de produo de novas informaes, a partir das existentes. Essas atividades possuem duas finalidades no exclusivas; a de buscar uma coerncia entre as diferentes informaes, e a de decidir sobre escolhas de aes. A chegada de novos dados suscitam conceitos e hipteses que estimulam o tratamento. A produo de conhecimentos pode ser feita partir de regras gerais, cuja validade definida pela lgica formal ou, a partir de regras heursticas, que podem produzir resultados nem sempre eficazes. A inferncia dedutiva, quando partindo de uma ou mais premissas verdadeiras, chega-se a uma concluso seguramente correta. A inferncia dedutiva, como o tratamento do tipo algortmico dirigido por programas e corresponde a procedimentos pr-determinados, mais ou menos automatizados. A inferncia indutiva quando se parte de premissas verdadeiras, chegando-se uma concluso mais geral, no necessariamente verdadeira (generalizao). A analogia uma forma de raciocnio indutivo que baseia-se em conhecimentos estocados na memria para compreenso de uma situao desconhecida. Trata-se de um tipo de raciocnio que visa a estabelecer uma relao de similaridade entre dois objetos ou situaes diferentes. Na repartio homem-mquina, os projetistas de IHC devem considerar que os humanos tm dificuldades para o raciocnio algortmico, dedutivo, tendo melhores possibilidades em analogias e dedues.

20

Segundo uma abordagem cognitivista, a aprendizagem pode ser entendida como o processo de modificao das representaes acumuladas nos esquemas declarativos e procedurais, fruto das inferncias internas ou de atividade perceptiva. A nvel de conhecimentos, a aprendizagem define a competncia (saber), e nvel de comportamento, ela define o desempenho (saber-fazer). O progresso na aprendizagem no acontece exclusivamente pela acumulao de conhecimentos (mudanas quantitativas), mas tambm pela eliminao de hipteses falsas, de restries inoportunas e pela substituio de procedimentos (mudanas qualitativas). De maneira geral, a aprendizagem pode se dar pela ao ou por um tutorial. A descoberta e a explorao caracterizam a aprendizagem pela ao. Nestas situaes, os fatores importantes so o feedback, a identificao dos pontos crticos da situao, e dos ndices que permitem evocar situaes anteriores. A aprendizagem por tutorial refere-se s diversas formas de transmisso do saber de um instrutor. Neste caso, importante o papel que assumem os conhecimentos anteriores, como um quadro assimilador do novo conhecimento.

2.5 O Curso das Aes

O curso das aes dos indivduos para a realizao de uma tarefa encadeia processos ou atividades cognitivas em trs etapas principais: anlise da situao, planificao e controle das aes.

2.5.1 A anlise de uma situao

A fase de anlise inicia-se pela percepo orientada, sendo composta das seguintes etapas: ativao: um sinal chama a ateno do indivduo, levando-o orientar seus sentidos na direo da fonte desta informao, o que provoca um estado de alerta; observao: a partir do estado de alerta, o indivduo coleta dados sobre o ambiente, sistema de produo e meios de trabalho; categorizao: o indivduo dispe agora de um conjunto de dados que pode ser decodificado e coordenado no sentido de elaborar uma representao do estado do sistema; interpretao: nesta etapa, o indivduo determina as causas e as conseqncias do estado do sistema sobre a evoluo da situao de trabalho.

21

2.5.2 A planificao das aes

Tendo sido montada uma representao da situao, as prximas etapas de tratamentos cognitivos se referem a avaliao de quais so as possibilidades de aes, selecionar uma e planejar a sua realizao: avaliao das possibilidades: a partir das caractersticas tcnicas, organizacionais e humanas, o indivduo avalia as diferentes solues possveis e escolhe a estratgia tima, aquela que melhor lhe permite satisfazer um conjunto de critrios contraditrios, como custo para o sistema de produo e custo para ele prprio; definio da tarefa: o indivduo, segundo esta estratgia, fixa os objetivos e determina os meios necessrios para ating-los; definio de procedimentos: consiste na definio de numa seqncia ordenada de operaes a serem efetuadas; A definio ou seleo de uma tarefa a ser realizada garante a alocao dos recursos cognitivos necessrios para a sua planificao e para o seu controle. Este processo de seleo guiado por mecanismos motivacionais (motivao), envolvendo o produto de trs fatores: a importncia da tarefa do ponto de vista das motivaes do indivduo, a esperana de sucesso nesta tarefa e o custo cognitivo para a sua realizao. A importncia um parmetro que evolui no tempo e depende tambm da urgncia da tarefa. A esperana de sucesso depende no somente da freqncia de sucessos anteriores, mas tambm da crena que tem o indivduo de que o sucesso est sob o seu controle. A tarefa escolhida a de custo cognitivo mais baixo, para a qual a fora de inteno a mais forte. Assim, se pode identificar tarefas e situaes custosas: quando o nmero de informaes a serem detectadas e tratadas elevado; quando a redundncia ou semelhana entre as informaes a serem memorizadas ou recuperadas for elevada; quando o tempo de apresentao das informaes for reduzido; quando os prazos para elaborao de respostas motoras em relao percepo das informaes forem diminutos, etc.. A planificao das atividades se refere a fixao de objetivos e elaborao de planos e se baseia em uma representao hierrquica de espaos abstratos. A estrutura
22

geral do problema representada, mas os detalhes menores so abstrados. Resolve-se o problema por refinamentos sucessivos, introduzindo-se os detalhes dos espaos abstratos dos nveis inferiores. A planificao no passa de uma hiptese de trabalho, pois ela necessita de avaliaes e de ajustes constantes.

2.5.3 O Controle das aes

A fase de planificao termina com a execuo dos procedimentos, isto , na realizao da tarefa. Uma vez executadas, as aes so controladas e avaliadas em termos dos resultados obtidos. A partir das entradas e sadas possveis na realizao e controle das aes Rasmussen (1981) prope uma formalizao de trs diferentes tipos de comportamentos humanos; os baseados em habilidades, os baseados em regras; os baseados em conhecimentos. Os comportamentos baseados em habilidades (skills) so essencialmente sensrio-motor, acionados automaticamente por situaes rotineiras e que se desenvolvem segundo um modelo interno, no consciente, adquirido anteriormente. As habilidades so pouco sensveis s condicionantes ambientais e organizacionais, permitindo reaes muito rpidas e podendo se desenvolver em paralelo com outras atividades. Um exemplo de um encadeamento sensrio-motor complexo o digitar. Dentro de certos limites, as variaes do estado do teclado, ou as mudanas de velocidade, so tratadas sem interveno da conscincia para assegurar a continuidade da progresso da tarefa. Os comportamentos baseados em regras (rules) so sequncias de aes controladas por regras memorizadas por aprendizagem. Ao contrrio das habilidades, estes comportamentos exigem o disparo de regras e uma coordenao entre elas, tendo em vista a variabilidade das situaes encontradas. As atividades conscientes de um usurio experiente na realizao de tarefas rotineiras com um software editor de textos pertencem a este tipo de tratamento. Os comportamentos baseados em conhecimentos (knowledge) aparecem em situaes novas, de resoluo de problemas, para os quais no existem regras pr-construdas. De fato, este tipo de comportamento est mais ligado ao indivduo do que a prpria tarefa. Uma tarefa pode ser familiar para um indivduo, mas totalmente nova para outro. A avaliao dos resultados da ao um componente fundamental na modificao da representao que se tem do problema. Ela necessita uma atitude geral de reflexo sobre a ao, que leva, mais do que ao sucesso, compreender uma situao, e melhoria do processo de soluo.

23

3. A COMUNICAO E A SEMITICA
" A civilizao humana depende dos sinais e dos sistemas de sinais; a inteligncia humana inseparvel do funcionamento dos sinais." Morris, C. -Fundamentals of the theory of signs. A comunicao interao humano-computador pode ser vista como um processo de comunicao entre dois sistemas cognitivos que fazem tratamento de informao simblica. De um lado, o ser humano, cujas estruturas cognitivas examinadas no captulo anterior, tratam representaes, portanto simblicas, da realidade. De outro, o computador, visto como uma mquina simblica que realiza tratamentos de sinais produzidos pelos programadores para produzir os sinais que os usurios interpretam e manipulam em suas interfaces. Para poder apoiar as decises de projeto da interao humano-computador, o ergonomista deve conhecer as bases de funcionamentos destes dois sistemas de tratamentos simblicos e a forma como eles se comunicam. Neste tpico so apresentadas as bases da comunicao humana e das estruturas dos sistemas de sinais, a semitica.

3.1 A Teoria de Comunicao

Os componentes da teoria da comunicao so um emissor, uma mensagem, um contexto de referncia, um cdigo e um receptor. Algumas funes se estabelecem a partir das relaes entre estes componentes. Uma mensagem carrega um significado, mas tambm a atitude do emissor frente ao objeto. Assim, uma mensagem muitas vezes ambgua e so as relaes entre mensagem e seu contexto de referncia que podem estabelecer uma comunicao lgica e objetiva. Relaes objetivas e afetivas, so as bases, ao mesmo tempo complementares e concorrentes da comunicao.

Fig. 3.1 O Modelo de Comunicao de Prieto

24

Um cdigo define convenes entre significantes e significados. Ele resulta de um acordo entre os usurios de um sistema de sinais que reconhecem esta relao e a respeitam no emprego do sinal. Este acordo pode ser mais ou menos explcito, o que separa dois grandes tipos de relaes: as motivadas (implcitas) e as arbitrrias (explcitas). Os cdigos motivados se verificam quando existe uma relao natural entre mensagem e referncia. o caso das analogias que emprestam aos smbolos e cones (imagens), de um modo mais ou menos abstrato, a aparncia dos objetos ou das funcionalidades que eles representam. Nos formalismos das cincias exatas os cdigos so geralmente arbitrrios e funcionam por pura conveno estabelecida que conhecida pelos usurios do sistema de cdigo. Alm disto sua eficcia garantida por uma correspondncia unvoca entre mensagem e referncia (monosemia). Nos chamados cdigos estticos ou poticos verifica-se em geral uma conveno enfraquecida por uma polisemia uma expresso ligada diversos contedos. Cabendo ao receptor escolher um sentido entre os diversos possveis. A ambigidade do sinal polismico geralmente desaparece quando se considera o contexto da mensagem. Uma outra categoria de cdigos, os sensoriais (Ware, 1992), esto ligados s primeiras etapas do processamento sensorial da informao. Eles tendem a ser estveis frente indivduos e culturas. Os elementos bsicos da gramtica sensorial esto baseados em estruturas fisicamente presentes no mundo. As leis da Gestalt, derivadas dos prprios mecanismos da percepo de objetos, fornecem exemplos de sinais cujo significado definido nas primeiras etapas da cognio. Os fatos dos objetos possurem superfcies, estarem sujeitos lei da gravidade e da luz se propagar em linha reta independem de uma cultura especfica. O interesse na identificao de uma gramtica sensorial envolve a naturalidade e a facilidade de utilizao de um esquema representacional que seja vlido em uma grande variedade de contextos.

3.1.1 Indicao e Significao

Os atos simblicos so de dois tipos: notificativos e significativos. Um ato notificativo simplesmente indica ao receptor que o emissor se prope a emitir um sinal. Um ato significativo informa ao receptor que a classe qual pertence a mensagem que chega uma classe familiar, isto , capaz de ser tratada. A operao final consiste na seleo de uma entre todas as mensagens que compem a classe de significados para a sua interpretao. Para Prieto cada ato comunicativo carrega em si uma intenso por parte do emissor. Sem intenso no haveria comunicao. J para Eco, o critrio da intencionalidade irrelevante.

25

3.2 A semitica
Os sistemas de sinais comearam a ser estudados no incio do sculo XX, quando Peirce e Saussure lanaram as bases de duas disciplinas dedicadas aos sinais; respectivamente, semitica e semiologia. Peirce enfocou a lgica da funo chamada sinal e Saussure enfocou sua funo social. Este captulo, dedicado semitica, a cincia que estuda a lgica dos sistemas de sinais: linguagens, cdigos, sinalizao, etc.

3.3 Os componentes de um sinal

Fig.3.2 A trade de Pierce A trade de Peirce mostrada na figura 3.2, uma representao dos componentes dos sinais e de suas interrelaes. Ele envolve um sinal (ou expresso) S, um objeto de referncia (ou contedo) R, e uma pessoa que o interpreta (interpretando) I.

Fig. 3.3 - As relaes semiticas

26

Segundo este esquema, um sinal ocorre somente quando ele for interpretado na mente de uma pessoa. As relaes envolvendo os trs fatores de um sinal definem as dimenses pragmtica, semntica e sinttica da semitica (fig. 3.3) . A relao entre sinais (expresso) define a sintaxe de um sistema, que descrita por um conjunto de regras do tipo; tal sinal "determina" ou " determinado" por outro, ou independente em relao a outro. A semntica associa sinais (expresses) aos objetos (contedos) que eles representam, e descrita por um conjunto de regras (arbitrrias ou naturais) do tipo; um sinal "designa" ou "denota" um objeto. A relao pragmtica relaciona sinais e objetos com seus interpretandos e descrita em termos de; um sinal "exprime" ou significa um objeto para mim. quando uma pessoa conhece as regras que permitem entender as relaes entre os sinais (sintaxe) e destes com seus objetos (semntica). Uma palavra pode ter diversos designaes previstas, mas apenas uma a que se encaixa em um determinado contexto (ex. Capital cidade sede de um governo, quantia em dinheiro, algo importante,....)

3.4 A formao de um sinal

Hjelmslev estudou o sinal como uma relao ou uma funo, que associa um contedo uma expresso na mente da pessoa que o interpreta (fig. 3.4).

Fig. 3.4 A Semiosis ou formao de um sinal A expresso a dimenso manifesta de um ato simblico. Ela pode envolver diversas substncias, por exemplo: gestos, movimentos, sons, pontos no papel, pixels na tela, etc. O contedo de um sinal se realiza na mente da pessoa que o interpreta e corresponde um conhecimento sobre um objeto ou
27

propriedade do mundo. As dimenses contedo e expresso so interdependentes, o que significa que um sinal no existe sem uma delas. Contedo e expresso apresentam forma e substncia. A substncia representa uma caracterstica do contnuo que instanciada por uma forma. A forma surge no momento do ato simblico quando a substncia instanciada passa a ser diferencivel em relao a uma outra instncia e pertinente em relao ao contedo ou a expresso. Desta forma, os fatores decisivos em um sinal so suas formas. O significado de um sinal denota uma classe formada por todas as mensagens que um sinal admite. Inversamente, por significante entende-se a classe formada por todas os sinais que uma mensagem admite. Mensagem e sinal so instncias de significado e significante (fig. 2.5). O procedimento de anlise denominado "teste de comutao" permite a identificao destas duas classes de variantes. Por outro lado, as formas de sinais podem ser articuladas. A primeira articulao se verifica quando existe uma correspondncia simblica entre os fatores (partes) da forma da expresso e os fatores (partes) da forma do contedo de um sinal. Estes fatores so denominados signos. Por exemplo, o numero 201 indica um apartamento localizado no segundo andar (2), de frente e direita da fachada (01). A segunda articulao se verifica em um sinal j articulado cujos signos no so formados por outros signos. Neste caso estes fatores so denominados de figuras. As figuras ocorrem quando no existe uma correspondncia entre os fatores da forma de expresso e de contedo de um sinal ou de um signo. Os sinais da linguagem escrita ou falada apresentam dupla articulao, na medida em que grafemas ou fonemas, os componentes elementares das palavras, constituem figuras.

3.5 A semitica computacional

A semitica computacional proposta por Andersen (1991) a utilizao de sinais computacionais na sociedade atual. Suas propostas so baseadas em duas das interpretaes do esquema semitico apresentadas no tpico anterior: o esquema estruturalista elaborado por Hjelmslev e a trade de Peirce. No centro de sua perspectiva est o indivduo, considerado como o criador, o intrprete e a referncia dos sinais. Ele usa a produo semitica de outros para (re)produzir conhecimento comum. Um sinal uma relao entre formas de expresso e de contedo que s ocorre quando ele interpretado. Assim, o sistema informatizado visto como um sistema de expresses "vazias", pois dependem do usurio para se realizarem como sinais. Os projetistas podem influenciar fortemente estas interpretaes ao conceberem seus candidatos sinais computacionais. Assim, sua atividade possui o carter de criao de proposio de
28

significados. No se pode dizer que um projetista conceba sinais, ele prope sinais, que em algumas circunstncias se realizam, mas que em muitas outras nunca atingem a realizao prevista. Programar, no sentido semitico do termo , segundo Andersen (Andersen, 1993) usar o computador para tentar dizer algo s pessoas. Deste modo, os sinais computacionais so definidos como sinais candidatos. Eles dependem do usurio para se realizarem como sinais. Entretanto o projetista, e este o seu papel, deve poder influenciar sua interpretao. Desta forma, o computador visto essencialmente, como um meio para a comunicao. Em um sistema informatizado o projetista quem define os limites da comunicao criando os sinais que o usurio pode manipular. Para Andersen, o computador no possui as faculdades de um emissor ou de um receptor, ao contrrio de pessoas, que articulam uma linguagem mesmo sem conhecer seu "programa" ou gramtica. As pessoas, ao contrrio de um computador, possuem a capacidade de modificar uma linguagem naturalmente, pois as linguagens humanas no foram construdas por um grupo de projetistas, mas evoluram naturalmente com o uso.

3.5.1 Sinais Computacionais

A interface humano-computador vista como uma coleo de sinais computacionais, isto , toda a parte do processo do sistema que detectada, utilizada e interpretada por uma comunidade de usurios. Ela deixa de ser vista como componente e passa a ser entendida como processo de um sistema. Segundo esta definio pode-se afirmar que um sistema informatizado possui inmeras interfaces, uma vez que cada usurio entra em contato com uma coleo diferente de sinais os quais ele interpreta de uma maneira particular. A relao que se estabelece entre o usurio e as partes perceptveis do sistema faz com que uma nova interface emerga do sistema informatizado cada vez ele utilizado. Os sinais computacionais so definidos como um tipo especial de sinais cujo plano de expresso se manifesta no processo de mudana da substncia dos dispositivos de entrada e de sada do sistema informatizado. Seu contedo est no sistema de referncia. Os sinais computacionais formam estruturas de propriedades manipulveis, permanentes e transitrias que podem realizar aes sobre os outros sinais do sistema. As propriedades manipulveis so produzidas pelo usurio com o objetivo de articular suas aes e incluem o pressionar de uma tecla, os movimentos do "mouse", etc. As propriedades permanentes, geradas pelo computador, so aquelas que permanecem constantes durante o ciclo de vida ativa do sinal e que servem para diferenci-lo de outros sinais. As transitrias, tambm geradas pelo computador, so as que se

29

modificam durante a vida do sinal. Elas simbolizam os diferentes estados que sua referncia pode assumir. Em um sistema interativo os sinais podem aparecer juntos ou se seguirem no tempo. O primeiro tipo de situao define uma cadeia concorrente que representa o ambiente esttico de trabalho. Este formado pelo elenco de objetos de trabalho, mquinas, ferramentas, controles, etc. A cadeia seqencial, definida pelo segundo tipo de relao, representa o aspecto dinmico do sistema. Elas representam as possibilidades e os padres em termos de aes. O principal sinal composto concorrente refere-se a "cena". As cenas correspondem a noo teatral do termo, que define um local com os objetos e os atores necessrios para a realizao de aes. Leia-se o conjunto de objetos e ferramentas necessrios para a execuo de um grupo de tarefas concorrentes. Andersen sugere que a descrio de um sistema interativo baseada em cenas deve ser feita em dois nveis. O primeiro descreve cenas genricas, como por exemplo aquelas ligadas ao gerenciamento do sistema de janelas, da manipulao de arquivos, dos dispositivos de entrada e sada, etc. Num segundo nvel ocorre a descrio das cenas associadas s tarefas especficas de um aplicativo. Assim a concepo de um sistema interativo pode se realizar como um processo de insero de novas cenas em um livro j escrito e comercializado, como aquelas definidas nos sistemas MS-Windows, X-Windows, MacApp, etc. Os sinais compostos seqenciais so as "aes e tarefas simblicas que resultam da manipulao de sinais.

30

SEGUNDA PARTE: FERRAMENTAS PARA A ENGENHARIA DE USABILIDADE

4. QUALIDADES ERGONMICAS PARA IHC

O sucesso de qualquer atividade de concepo ou de avaliao depende do emprego de critrios bem definidos. A abordagem ergonmica proposta neste livro est baseada em um conjunto de critrios definidos por Scapin e Bastien, pesquisadores do INRIA (Institut National de Recherche en Informatique et en Automatique da Frana) em sua verso de 1993. Trata-se de um conjunto de 8 critrios principais que se subdividem de modo a minimizar a ambigidade na identificao e classificao das qualidades e problemas ergonmicos do software interativo.

4.1 A Conduo
O software ergonmico aconselha, orienta, informa, e conduz o usurio na interao com o computador (mensagens, alarmes, rtulos, etc.), possibilitando: - a localizao do usurio, ou seja, que saiba, a qualquer hora, onde se encontra, numa seqncia de interaes ou na execuo de uma tarefa; -conhecimento das aes permitidas, bem como suas conseqncias; -obteno de informaes suplementares (eventualmente por demanda). O software prestativo proporciona aprendizado rpido e fcil utilizao permitindo que o usurio melhore seu desempenho e diminua o nmero de erros na operao do sistema. Esta qualidade pode ser analisada a partir de duas dimenses: a presteza e o feedback imediato.

4.1.1 Presteza
A presteza diz respeito as informaes que permitem ao usurio identificar o estado ou contexto no qual se encontra, bem como as ferramentas de ajuda e o modo de acesso, incluindo todos os mecanismos ou meios que permitam ao usurio conhecer as alternativas, em termos de aes, conforme o estado ou contexto no qual ele se encontra. Esta qualidade elementar engloba os meios utilizados para levar o usurio a realizar determinadas aes.

31

O software prestativo guia o usurio e poupa, do aprendizado de uma srie de comandos, permitindo ao usurio saber o modo ou o estado e onde se encontra no dilogo, bem como o que fez para se encontrar nessa situao. Uma boa presteza facilita a navegao no aplicativo e diminui a ocorrncia de erros.

4.1.2 Feedback Imediato

Feedback imediato diz respeito s respostas do sistema s aes do usurio. Estas entradas podem ir do simples pressionar de uma tecla, at uma lista de comandos. As respostas do computador devem ser fornecidas, de forma rpida, com um tempo de resposta apropriado e consistente para cada tipo de transao. Uma resposta rpida deve ser fornecida com informao sobre a transao solicitada e seu resultado. A qualidade e rapidez do feedback so dois fatores importantes para o estabelecimento de satisfao e confiana do usurio, assim como para o entendimento do dilogo. Estes fatores possibilitam que o usurio tenha um melhor entendimento do funcionamento do sistema. A ausncia de feedback ou sua demora podem ser desconcertantes para o usurio. Os usurios podem suspeitar de uma falha no sistema, e podem tomar atitudes prejudiciais para os processos em andamento.

4.1.3 Legibilidade
A performance melhora quando a apresentao da informao leva em conta as caractersticas cognitivas e perceptivas dos usurios. Uma boa legibilidade facilita a leitura da informao apresentada. Por exemplo, letras escuras em um fundo claro so mais fceis de ler que letras claras em um fundo escuro; texto apresentado com letras maisculas e minsculas lido mais rapidamente do que texto escrito somente com maisculas. Legibilidade diz respeito s caractersticas lexicais das informaes apresentadas na tela que possam dificultar ou facilitar a leitura desta informao (brilho do caracter, contraste letra/fundo, tamanho da fonte, espaamento entre palavras, espaamento entre linhas, espaamento de pargrafos, comprimento da linha, etc.).

4.1.4 Agrupamento/Distino de Itens

A compreenso de uma tela pelo usurio depende, entre outras coisas, da ordenao, do posicionamento, e da distino dos objetos (imagens, textos, comandos, etc.) que so apresentados. Os usurios vo detectar os diferentes itens ou grupos de itens, e aprender suas relaes mais facilmente, se,
32

por um lado, eles forem apresentados de uma maneira organizada (e.g., ordem alfabtica, freqncia de uso, etc.), e por outro lado, os itens ou grupos de itens forem apresentados em formatos, ou codificados de maneira a indicar suas similaridades ou diferenas. Alm disso, a aprendizagem e a recuperao de itens ou de grupos de itens ser melhorada. Esta qualidade diz respeito organizao visual dos itens de informao, relacionados uns com os outros, levando em conta a topologia (localizao) e algumas caractersticas grficas (formato) para indicar as relaes entre os vrios itens mostrados, apontando se pertencem ou no, a uma dada classe, ou indicando diferenas entre classes. Esta qualidade tambm diz respeito organizao dos itens de uma classe. O critrio agrupamento/distino de itens est subdividido em dois critrios elementares: agrupamento/distino por localizao e agrupamento/distino por formato.

4.1.4.1 Agrupamento/Distino por Localizao

A qualidade de agrupamento/distino por localizao diz respeito ao posicionamento relativo dos itens, estabelecido para indicar se eles pertencem ou no a uma dada classe, ou, ainda, para indicar diferenas entre classes, e o posicionamento relativo dos itens dentro de uma classe.

4.1.4.2 Agrupamento/Distino por Formato

Ser mais fcil para o usurio perceber relacionamento(s) entre itens ou classes de itens, se diferentes formatos ou diferentes cdigos ilustrarem suas similaridades ou diferenas. Tais relacionamentos sero mais fceis de aprender e de lembrar. A qualidade de agrupamento/distino por formato diz respeito mais especificamente s caractersticas grficas (formato, cor, etc.) que indicam se itens pertencem ou no a uma dada classe, ou que indicam distines entre classes diferentes, ou ainda distines entre itens de uma dada classe.

4.2 A Carga de Trabalho

Quanto maior for a carga de trabalho cognitivo para o usurio, maior ser a probabilidade de cometer erros, alm disso, quanto menos o usurio for distrado por informao desnecessria, mais ser capaz de desempenhar suas tarefas eficientemente, pois quanto menos aes so necessrias, mais rpidas as interaes. O critrio Carga de Trabalho, que define o software econmico, diz respeito a todos elementos da interface que tm um papel importante na reduo da carga cognitiva e perceptiva do usurio, e no aumento da eficincia do dilogo.

33

O critrio Carga de Trabalho est subdividido em dois critrios: Brevidade (que inclui Conciso e Aes Mnimas) e Densidade Informacional.

4.2.1 Brevidade
A capacidade da memria de curto termo limitada. Conseqentemente, quanto menos entradas, menor a probabilidade de cometer erros. Alm disso, quanto mais sucintos forem os itens, menor ser o tempo de leitura, e quanto mais numerosas e complexas forem as aes necessrias para se chegar a uma meta, maior ser a carga de trabalho e a probabilidade de ocorrncia de erros. O software Breve respeita a capacidade de trabalho perceptivo e cognitivo do usurio, tanto para entradas e sadas individuais, quanto para conjuntos de entradas (i.e., conjuntos de aes necessrias para se alcanar uma meta). Brevidade corresponde ao objetivo de limitar a carga de trabalho de leitura e entradas, e o nmero de passos. O critrio Brevidade se divide em duas qualidades elementares: Conciso e Aes Mnimas.

4.2.1.1 Conciso
O critrio conciso diz respeito carga perceptiva e cognitiva de sadas e entradas individuais.

4.2.1.2 Aes Mnimas

Quanto mais numerosas e complexas forem as aes necessrias para se chegar a uma meta, maior ser a carga de trabalho e a probabilidade de ocorrncia de erros. A qualidade Aes Mnimas diz respeito carga de trabalho em relao ao nmero de aes necessrias realizao de uma tarefa. Trata-se de limitar, tanto quanto possvel, o nmero de passos pelos quais o usurio deve passar.

4.2.2 Densidade Informacional

A carga de memorizao do usurio deve ser minimizada. Usurios no devem ter que memorizar listas de dados ou procedimentos complicados. Eles no devem, tambm, precisar executar tarefas cognitivas complexas quando estas no esto relacionadas com a tarefa em questo. Na maioria das tarefas, a performance dos usurios diminuda quando a densidade da informao muito alta ou muito baixa, nestes casos, a ocorrncia de erros mais provvel. Itens que no esto relacionados tarefa devem ser removidos. A qualidade Densidade Informacional diz respeito carga de trabalho do usurio, de um ponto de vista perceptivo e cognitivo, com relao ao conjunto total de itens de informao

34

apresentados aos usurios, e no a cada elemento ou item individual.

4.3 O Controle Explcito

Com um software obediente o usurio tem o controle explcito sobre os processamentos do sistema. Quando os usurios definem explicitamente suas entradas, e quando estas entradas esto sob controle, os erros e as ambigidades so limitados. Alm disso, o sistema ser melhor aceito pelos usurios se eles tiverem controle sobre o dilogo. O software obediente se define em dois critrios elementares: Aes Explcitas do Usurio e Controle do Usurio.

4.3.1 Aes Explcitas do Usurio

O critrio Aes Explcitas do Usurio se refere s relaes entre o processamento pelo computador e as aes do usurio. Esta relao deve ser explcita, i.e., o computador deve processar somente aquelas aes solicitadas pelo usurio e somente quando solicitado a faz-lo. Quando o processamento pelo computador resulta de aes explcitas dos usurios, estes aprendem e entendem melhor o funcionamento da aplicao, e menos erros so observados.

4.3.2 Controle do Usurio

O critrio Controle do Usurio se refere ao fato de que os usurios deveriam estar sempre no controle do processamento do sistema (e.g., interromper, cancelar, suspender e continuar). Cada ao possvel do usurio deve ser antecipada e opes apropriadas devem ser oferecidas. O controle sobre as interaes favorece a aprendizagem e assim diminui a probabilidade de erros. Como conseqncia, o computador se torna mais previsvel.

4.4

A Adaptabilidade
A adaptabilidade de um sistema diz respeito a sua capacidade de reagir conforme o contexto, e conforme as necessidades e preferncias do usurio. Dois sub-critrios participam da adaptabilidade: a flexibilidade e a considerao da experincia do usurio. Uma interface no pode atender ao mesmo tempo a todos os seus usurios em potencial. Para que no tenha efeitos negativos sobre o usurio, a interface deve, conforme o contexto, se adaptar a ele. Por outro lado, quanto mais variadas so as maneiras de realizar uma tarefa, maiores so as chances do usurio de escolher e dominar uma delas no curso de seu

35

aprendizado. Deve-se portando fornecer ao usurio procedimentos, opes, comandos diferentes permitindo alcanar um mesmo objetivo.

4.4.1 Flexibilidade
A flexibilidade se refere aos meios colocados disposio do usurio que permite personalizar a interface a fim de levar em conta as exigncias da tarefa, de suas estratgias ou seus hbitos de trabalho. Corresponde tambm ao nmero de diferentes maneiras disposio do usurio para alcanar um certo objetivo, e portanto, da capacidade da interface se adaptar as variadas aes do usurio. Quanto mais formas de efetuar uma tarefa existirem, maiores sero as chances de que o usurio possa escolher e dominar uma delas no curso de sua aprendizagem.

4.4.2 Considerao da experincia do usurio

A considerao da experincia do usurio diz respeito aos meios implementados que permitem que o sistema respeite o nvel de experincia do usurio. O grau de experincia dos usurios pode variar, pois podem se tornar especialistas, devido a utilizao continuada, bem como menos especialistas, depois de longos perodos de no utilizao. A interface deve tambm ser concebida para lidar com as variaes dos nveis de experincia. Usurios experientes no tm as mesmas necessidades informativas que novatos. Todos os comandos ou opes no precisam ser visveis o tempo todo. Os dilogos de iniciativa somente do computador, entediam e diminuem o rendimento do usurio experiente. Os atalhos, ao contrrio, podem permitir rpido acesso as funes do sistema. Pode-se fornecer aos usurios inexperientes dilogos bem conduzidos, ou mesmo passo passo. Portanto, meios diferenciados devem ser previstos para lidar com diferenas de experincia, permitindo que o usurio delegue ou se aproprie da iniciativa do dilogo.

4.5 A Gesto de Erros

A gesto de erros diz respeito a todos os mecanismos que permitem evitar ou reduzir a ocorrncia de erros, e quando eles ocorrem, que favoream sua correo. Os erros so aqui considerados como entrada de dados incorretas, entradas com formatos inadequados, entradas de comandos com sintaxes incorretas, etc. Trs sub-critrios participam da manuteno dos erros: a proteo contra os erros, a qualidade das mensagens de erro e a correo dos erros. As interrupes provocadas pelos erros tm conseqncias negativas sobre a atividade do usurio. Geralmente, elas
36

prolongam as transaes e perturbam o planejamento. Quanto menor a possibilidade de erros, menos interrupes ocorrem e melhor o desempenho.

4.5.1 Proteo contra os erros

A proteo contra os erros diz respeito aos mecanismos empregados para detectar e prevenir os erros de entradas de dados ou comandos, ou possveis aes de conseqncias desastrosas e/ou no recuperveis. prefervel detectar os erros no momento da digitao do que no momento da validao. Isto pode evitar perturbaes no planejamento da tarefa.

4.5.2 Qualidade das mensagens de erro

A qualidade das mensagens refere-se a pertinncia, a legibilidade e a exatido da informao dada ao usurio sobre a natureza do erro cometido (sintaxe, formato, etc.), e sobre as aes a executar para corrigi-lo. A qualidade das mensagens favorece o aprendizado do sistema indicando ao usurio a razo ou a natureza do erro cometido, o que ele fez de errado, o que ele deveria ter feito e o que ele deve fazer.

4.5.3 Correo dos erros

O critrio correo dos erros diz respeito aos meios colocados a disposio do usurio com o objetivo de permitir a correo de seus erros. Os erros so bem menos perturbadores quando eles so fceis de corrigir.

4.6 A Homogeneidade/Coerncia
O critrio homogeneidade/coerncia refere-se forma na qual as escolhas na concepo da interface (cdigos, denominaes, formatos, procedimentos, etc.) so conservadas idnticas em contextos idnticos, e diferentes para contextos diferentes. Os procedimentos, rtulos, comandos, etc., so melhor reconhecidos, localizados e utilizados, quando seu formato, localizao, ou sintaxe so estveis de uma tela para outra, de uma seo para outra. Nestas condies o sistema mais previsvel e a aprendizagem mais generalizvel; os erros so diminudos. necessrio escolher opes similares de cdigos, procedimentos, denominaes para contextos idnticos, e utilizar os mesmos meios para obter os mesmos resultados. conveniente padronizar tanto quanto possvel todos os objetos quanto ao seu formato e sua denominao, e padronizar a
37

sintaxe dos procedimentos. A falta de homogeneidade nos menus por exemplo, pode aumentar consideravelmente os tempos de procura. A falta de homogeneidade tambm uma razo importante da recusa na utilizao.

4.7 O Significado dos Cdigos e Denominaes

O critrio significado dos cdigos e denominaes diz respeito a adequao entre o objeto ou a informao apresentada ou pedida, e sua referncia. Cdigos e denominaes significativas possuem uma forte relao semntica com seu referente. Termos pouco expressivos para o usurio podem ocasionar problemas de conduo onde ele pode ser levado a selecionar uma opo errada. Quando a codificao significativa, a recordao e o reconhecimento so melhores. Cdigos e denominaes no significativos para os usurios podem lhes sugerir operaes inadequadas para o contexto, lhes conduzindo a cometer erros.

4.8 A Compatibilidade
O critrio compatibilidade refere-se ao acordo que possa existir entre as caractersticas do usurio (memria, percepo, hbitos, competncias, idade, expectativas, etc.) e das tarefas, de uma parte, e a organizao das sadas, das entradas e do dilogo de uma dada aplicao, de outra. Diz respeito tambm, ao grau de similaridade entre diferentes ambientes e aplicaes. A transferncia de informaes de um contexto outro mais tanto mais rpida e eficaz quanto menor o volume de informao que deve ser recodificada. A eficincia aumentada quando: os procedimentos necessrios ao cumprimento da tarefa so compatveis com as caractersticas psicolgicas do usurio; os procedimentos e as tarefas so organizadas de maneira a respeitar as expectativas ou costumes do usurio; quando as tradues, as transposies, as interpretaes, ou referncias a documentao so minimizadas. Os desempenhos so melhores quando a informao apresentada de uma forma diretamente utilizvel (telas compatveis com o suporte tipogrfico, denominaes de comandos compatveis com o vocabulrio do usurio, etc.).

38

5. MODELO DE COMPONENTES DE IHC

5.1 Introduo ao Modelo Lingstico
A interface humano-computador entendida como um subsistema do software interativo que como tal, possui estrutura e processos. A estrutura representada por seus componentes, e os processos se estabelecem na interao entre estes componentes e os usurios do sistema. Assim um nico sistema de interface humano-computador permite inmeras interaes humano-computador, cada uma associada aos diferentes percursos (processos) realizados pelos diferentes usurios. Sob outro ponto de vista, a interface humano-computador vista como uma linguagem (sistema de sinais) cuja estrutura lexical e sinttica conhecida pelo usurio e pelo sistema informatizado. Durante o dilogo, esses agentes articulam os elementos do lxico atravs de regras de sintaxe para montar e interpretar as mensagens trocadas. A analogia entre interfaces com o usurio e um sistema de linguagem detalhada no modelo de camadas de abstrao proposto por Nielsen (Nielsen, 1984 - citado em Bodart & Vaderdonck, 1993 ) Nvel de Objetivos: refere-se aos objetivos dos usurios independentemente do sistema informatizado; Nvel Pragmtico: refere-se as funes e estruturas de dados, associados aos conceitos do mundo real, como implementados no sistema; Nvel Semntico: refere-se aos significados que o usurio desenvolve sobre a operao das funes e estruturas de dados do sistema em associao com o mundo real; Nvel Sintxico: refere-se tanto aos dilogos como as telas, janelas e caixas de dilogo individuais. Trata das relaes entre os objetos de interao apresentados numa seqncia de telas, e de modo concorrente, em uma nica tela; Nvel Lexical: refere-se aos nomes dos comandos e desenhos de cones. Trata dos significados das unidades veiculando os itens de informaes; Nvel de Primitivas: refere-se as fontes, linhas, texturas, cores e sons, que representam o conjunto de unidades construtivas dos itens de informao; Nvel Fsico: trata dos dispositivos de entrada e sada do sistema.

39

Esse modelo lingstico proporciona a diretriz mais utilizada para a organizao dos elementos das interfaces humanocomputador e do raciocnio ergonmico para sua seleo, configurao e avaliao.

5.2 Os Componentes da Interao HumanoComputador

Os Critrios Ergonmicos de Scapin e Bastien (1993) apresentados no captulo anterior referem-se as qualidades de diferentes tipos de componentes de interfaces humanocomputador como mensagens de erro, cdigos, denominaes, aes do usurio, itens, localizaes, formatos, etc. O modelo de componentes das interfaces humano-computador que apresentado nesse livro, representa uma maneira de organizar a estrutura dessas interfaces e os conhecimentos para selecionar, configurar e avaliar/inspecionar os elementos apresentados na tabela 5.1. Eles foram definidos a partir do exame de recomendaes ergonmicas1 e se referem aos nveis Sinttico, Lexical e de Primitivas do modelo lingstico de Nielsen. O modelo prope classes de elementos organizados a partir de dilogos (sintaxe seqencial), objetos de interao (sintaxe concorrente), sistemas de significados (lxico) e primitivas. Os dilogos, vistos como seqncias de interaes entre o homem e o sistema podem ser analisados segundo perspectivas de funo, forma e estrutura. As funes dos dilogos definem as classes de tarefas, e representam o nvel pragmtico das interaes homem-sistema. Elas esto associadas s maneiras de apoiar os objetivos prticos dos usurios nas interaes com o sistema. Assim por exemplo, para um editor de texto existem funcionalidades que apiam tarefas especficas do tipo procurar/substituir cadeias de caracteres ou para realizar a reviso ortogrfica e gramatical do texto. As aplicaes com planilhas proporcionam facilidades de definir relaes matemticas entre as clulas. O modelo de caractersticas de interfaces humano-computador prope alguns tipos de tarefas genricas definidas nas relaes com diversos tipos de programas aplicativos. A componente elementar de classes de tarefa uma ao. Os estilos de dilogo representam a sintaxe seqencial do modelo, que prope as classes de; preenchimento de formulrios, dilogo por menu, dilogos de manipulao direta e dilogos de questo x resposta.
A Base de Recomendaes Ergonmicas LabIUtil, foi implementada em Microsoft Access verso 2.00 e formada por cerca de 200 recomendaes selecionadas de diversas fontes (Smith & Mosier, 1986; Bodart & Vanderdonckt, 1993; Brown, 1988; ISO 9241-10,14 e 17, 1995). Cada recomendao apresenta uma estrutura de informao com enunciados, justificativas, excees, exemplos positivos e negativos, glossrio e referncias bibliogrficas. 40
1

As estruturas dos dilogos determinam as dinmicas possveis de um dilogo. Entre os exemplares possveis dessas classes constam as estruturas do dilogo, estrutura do menu, estrutura da linguagem de comando, estrutura das teclas de funes. As classes de objetos de interao representam as relaes estticas que se estabelecem nas telas, janelas, caixas de dilogo, etc. Elas foram agrupadas segundo uma perspectiva funcional-estrutural, definindo as classes de painis de controles, controles complexos, grupos de controles, controles simples, campos de entrada, dados complexos, dados simples e as informaes.

41

TABELA 2 - Modelo de Componentes de Interfaces Humano-computador Organizao das Componentes Classes de Componentes Aes Aes de Entrada Entrada de dados e comandos Interaes Tarefas Tarefa de Diagnstico, Tarefa Corretiva Tarefa Destrutiva Estilos Dilogo por Menu Dilogo por Preenchimento de Formulrio Dilogo por Linguagem de Comando Dilogo por Manipulao Direta Estruturas Estrutura Seqencial (Passo passo) Estrutura Paralela Estrutura Repetitiva Objetos de Painis de Controles Tela, Janela, Caixa de Dilogo, Caixa de Interao Ao/Tarefa, Tela de Consulta, Formulrio, Caixa de Mensagem Controles Barra de Menu, Painel de Menu, Compostos Pgina de Menu, Barra de Ferramentas, Lista de Seleo, Lista de Combinao Grupos de Grupo de Botes de Comando, Controles Grupo de Botes de Rdio, Grupo de Caixas de Atribuio Grupo de campos/mostradores de dados Controles Simples Boto de Comando, Caixa de Atribuio, Cursor do Dispositivo de Apontamento, Escala, Dial Campos de Entrada Campo de Texto, Campo de Dado, Campo Grfico, Linha de Comando Mostradores Lista de Dados, Tabela de Dados, Texto, Estruturados Grfico, Diagrama de figura, Diagrama de Texto, Mapa Mostrador simples Mostrador de Dados Mostrador de Rtulo, Mensagem de Orientao, de Informaes Ajuda, de Alerta, Aviso, Mensagem de Erro, Indicador de Progresso, Efeito Sonoro, Motivo Meldico, Locuo, Fala Sistemas de Motivados Denominao, Abreviatura, cone Significado Arbitrrios Cdigo Alfanumrico, Cdigo de Cores, Cdigo de Textura, Cdigo de Intermitncia, Cdigo de Vdeo-Reverso Primitivas Visuais Cor, Fonte, Linha, Arranjo Sonoras Som O lxico da interface definido pelos sistemas de significados, sendo ainda possvel definir as primitivas grficas empregadas na construo das apresentaes dos objetos. O

42

modelo de caractersticas das interfaces humano-computador poderia ainda abrigar as classes de mdias se estivesse relacionado com recomendaes ergonmicas sobre os aspectos fsicos dos dispositivos de entrada e sada. importante salientar que o modelo proposto no tem a finalidade de descrever em sua totalidade as caractersticas das interfaces homem - computador. Ele visa especificamente apoiar a aplicao do conhecimento ergonmico sobre essas interfaces nas atividades de projeto e avaliao. Sua abrangncia limitada ao alcance da base de recomendaes ergonmicas que est em sua origem, sendo inevitvel que hajam ausncias de classes. Sobre elas no existem conhecimentos ergonmicos explicitados na base de conhecimento.

5.2.1 Os dilogos 5.2.1.1 Aes

A ao corresponde uma interao elementar. Ela compreende a menor entrada significativa do usurio acompanhada de uma resposta tambm significativa do sistema.
5.2.1.1.1 Ao de entrada de dados ou comandos

Em uma ao o sistema deve sempre aguardar pelo trmino da entrada e fornecer feedback imediato e significativo para ela. Se necessrio, o sistema deve considerar como equivalentes as letras maisculas e minsculas, alm de preencher automaticamente zeros decimais e vrgulas. O sistema deve tambm avisar o usurio sobre os erros nas entradas atravs de um sinal sonoro. No caso de entrada de dados codificados, o sistema deve sempre fornecer a lista dos cdigos definidos. Nas aes de entrada que envolvem tratamento demorado pelo sistema, deve ser dada ateno redobrada s questes de feedback, informando ao usurio sobre: a indisponibilidade do sistema; o tempo esperado do tratamento; o estado atual do sistema; o resultado (sucesso ou fracasso) alcanado. Uma opo para a interrupo do tratamento deve estar disponvel ao usurio.

5.2.1.2 As Tarefas
Uma tarefa vista como uma seqncia de aes ou interaes elementares.

43

5.2.1.2.1

Tarefa de diagnstico

Nesse tipo de interao, o objetivo do usurio de elaborar um diagnstico visando a recuperao de incidentes a nvel de sistema de produo. O sistema de controle informatizado deve apoiar o usurio apresentando-lhe os dados crticos de modo diferenciado e lhe propondo um tipo de ajuda on-line, de obteno direta e com orientaes redigidas em linguagem simples, objetiva e contextualizada.
5.2.1.2.2 Tarefa corretiva

Nas tarefas corretivas, a qualidade das mensagens de erro um requisito importante. Recomenda-se que as mensagens tenham um nvel de detalhe configurvel, de modo a que sejam adaptadas ao tipo de usurio, e que tenham um contedo dinmico, variando no caso da reincidncia de erros. As funcionalidades de ajuda, de desfazer e de refazer devem sempre estar habilitadas. No que se refere a essas ltimas, elas no devem ser mescladas em uma nica opo.
5.2.1.2.3 Tarefa destrutiva

Na tarefa destrutiva o sistema deve proporcionar uma adequada proteo aos dados do usurio, atravs: da definio de opes de comando default no destrutivas, da apresentao antecipada de avisos sobre as repercusses das aes do usurio e da solicitao de confirmao das aes destrutivas.

5.2.1.3 Os Estilos dos Dilogos

5.2.1.3.1 Dilogo por menu

A estrutura de menu proporciona um estilo de dilogo adequado para entrada de comandos por usurios intermitentes com o sistema, que no tenham possibilidades de memorizar um grande nmero de opes de comando e cujas habilidades de datilgrafos sejam moderadas. Estas opes de comando podem ser agrupadas logicamente segundo critrios como ordem cronolgica da tarefa ou freqncia de uso. Recomenda-se este estilo tambm quando a tarefa principal for fortemente baseada no mouse como dispositivo de interao. Este estilo deve proporcionar a minimizao das aes do usurio atravs do balano entre a largura (nmero de opes existentes) e a profundidade (nmero de passos necessrios para disparar as opes). No dilogo de entrada de comandos a partir de um menu o usurio deve poder primeiro indicar a opo desejada e, em um segundo momento, comandar sua ativao. O feedback dessas aes deve ser adequado.

44

5.2.1.3.2

Dilogo por linguagem de comando

A linguagem de comando proporciona um estilo de dilogo adequado para entrada de comandos por um usurio que utiliza o sistema freqentemente e recebe treinamento assduo. Em sua tarefa, a seqncia lgica dos comandos imprevisvel. Quanto a suas caractersticas, uma linguagem de comando deve manter acessvel a lista de comandos de base da linguagem, bem como o histrico dos comandos entrados pelo usurio. Deve considerar a experincia do usurio ao permitir processar mltiplas entradas e interpretar sinnimos de comandos. A estrutura da linguagem de comandos deve tambm permitir o reaproveitamento de entradas equivocadas e mais ainda, aceit-las no caso de erros de digitao mais comuns
5.2.1.3.3 Dilogo por preenchimento de formulrio

Este estilo de dilogo se aplica quando as entradas da tarefa forem predominantemente de dados, tiverem uma estrutura rgida e com poucos comandos. Os usurios, por seu lado, no precisam ter treinamento especfico e suas habilidades de datilgrafo podem ser moderadas. Para reduzir a carga de trabalho e conduzir o usurio no dilogo de preenchimento de formulrio o sistema deve, alm do previsto para entradas de dados simples, propor uma posio adequada para o incio do dilogo, propor facilidades de navegao entre os campos (que no automatizem a tarefa), realar o campo com o foco atual das aes e propor valores defaults adequados. O tratamento de um formulrio pelo sistema deve ser comandado explicitamente pelo usurio.
5.2.1.3.4 Dilogo por manipulao direta

O dilogo por manipulao se aplica quando direta as entradas so de difcil elaborao e existe a possibilidade de construir metforas a partir de objetos e entidades do mundo real, na forma de objetos de uma interface grfica interativa. Neste estilo de dilogo a questo de feedback assume importncia particular. Assim, o sistema deve fornecer uma indicao clara sobre o tipo de ao que est sendo executada e qual objeto o foco das aes ou o selecionado pelo usurio. As repercusses dessas aes, sejam em termos de mudana de atributos do objeto ou de sua movimentao tambm devem ser claramente indicadas.

5.2.1.4 Estruturas de interaes

5.2.1.4.1 Estruturas seqenciais (passo passo)

Em interaes seqenciais, como as implementadas em dilogos questo x resposta e passo passo, s tarefas atribuda uma seqncia rgida de execuo. Um passo s pode

45

ser realizado aps o anterior ter sido concludo. Esta uma estrutura especialmente indicada no caso em que usurios novatos na tarefa sejam confrontados a tarefas complicadas. Nestas situaes, o melhor a fazer conduzi-lo seqencialmente, porm mantendo-os no controle sobre a interao. Isto significa que lhe deve ser possvel interromper, finalizar e retomar a tarefa a qualquer instante.
5.2.1.4.2 Estruturas Paralela

Diferentemente das interaes seqenciais, em interaes com estrutura paralela as tarefas podem ser realizadas em qualquer ordem. Neste caso, imprimi-se uma flexibilidade tarefa, pois supe-se que o usurio saiba a melhor maneira de realiza-la, em funo dos dados que possui, ou que tenham de ser informados. Estruturas de menus (no caso de aes de comando) ou de estruturas de formulrios (no caso de entrada de dados) devem manter sempre ativas as opes que do acesso s diversas interaes da estrutura.
5.2.1.4.3 Estruturas Repetitiva

Interaes pertencentes a uma estrutura repetitiva so aquelas que os usurios realizam repetidas vezes, como para a entrada de diversos dados de mesmo tipo ou para a edio de diversos objetos de mesmo tipo, etc. Para apoiar estas situaes, as interfaces devem oferecer comandos de atalho, valores default, facilidades de seleo mltipla, entre outros servios.

5.2.2 Os Objetos de Interao

Um objeto de interao definido como um objeto de software cujo processamento gera uma imagem que apresentada ao usurio e com a qual ele pode interagir. Eles preenchem as telas das interfaces com o usurio e podem se basear em metforas de objetos do mundo no informatizado, representando botes, janelas, menus, interruptores, etc. So construdos a partir dos recursos das caixas de ferramentas ou toolboxes dos sistemas gerenciadores de janelas, dos quais herdam um estilo particular de apresentao e de comportamento imediato. Assim, verifica-se uma padronizao em termos de lxico e parte da sintaxe das interfaces de aplicativos construdos sobre uma mesma plataforma de desenvolvimento (Microsoft Windows, Macintosh Sistema 7, OS/2, OpenWindows, etc.). Do ponto de vista ergonmico, o objeto de interao possui um atributo genrico, que se refere ao tipo de ateno que ele possa exigir em um determinado momento na tela. Isso porque,

46

o enfoque no projeto de uma determinada tela deve ser centrado sobre como salientar, agrupar e discriminar objetos de interao. Alm da demanda de ateno, o projeto de um elemento prope a configurao dos recursos relativos a noo de partes. As partes de um objeto elementar variam de ambiente para ambiente, mas via de regra, so definidos como primeiro plano, um plano de fundo e bordas. Enquanto o primeiro plano recebe as palavras e cones, o plano de fundo recebe os motivos e sombras. Uma composio de objetos de interao apresenta como atributo genrico o controle de uma "lista de componentes" e de um "layout". Os objetos desta classe desempenham o papel de containers ao garantirem a coeso espacial na apresentao, deslocamentos e eliminao da tela de componentes. Via de regra, estes componentes tm os valores default para seus atributos definidos a nvel da composio. Assim, na ausncia de uma declarao explcita, todo componente ter as mesmas caractersticas de estilo definidas para a composio da qual fazem parte.

5.2.2.1 Os Painis de Controle

Os "Painis de Controle" so objetos compostos que fornecem ao usurio um cenrio adequado, em termos dos diferentes tipos de mostradores, de controles e de comandos necessrios para a realizao de sua ao ou tarefa. Eles esto divididos em Telas, Janelas e Caixas de Dilogo. As janelas correspondem a expresso global de aplicativos e de documentos. As Caixas de dilogo fornecem informao e apiam as tarefas e aes individuais. As telas representam a reunio de janelas e caixas de dilogo de diversos programas aplicativos.
5.2.2.1.1 Janela

Toda a janela deve possuir um ttulo nico, curto e significativo localizado em sua barra superior, centrado ou alinhado pela esquerda. A posio do ttulo deve ser mantida inalterada para todas as janelas do sistema. Seu layout deve ser padronizado, propondo uma diagramao equilibrada no que se refere a distribuio das reas livres, evitando ao mximo problemas de alinhamentos e diferenciando claramente as diferentes zonais funcionais. Nesse particular, o contedo de informao deve ser pertinente e oportuno, sendo que os objetos principais devem estar localizados de maneira que estejam bem vista do usurio.

47

A janela do aplicativo corresponde a uma rea do terminal fsico alocada para um programa aplicativo ou para o programa gerente de janelas (Finder, Presentation Manager, ). Estes aplicativos podem criar diversas outras janelas de documentos que vo coexistir na tela. Em vista dessa possibilidade, esse tipo de janela deve possuir uma opo de menu para o controle da disposio das janelas secundrias. Aconselha-se estabelecer um limite para a quantidade de janelas abertas, que no deve ultrapassar de 7 janelas.

A janela do documento subordinada a janela do aplicativo com a qual ela reparte o foco das aes do usurio. Este pode ento agir sobre o documento em questo com as ferramentas disponibilizadas na janela do aplicativo.

48

5.2.2.1.2

Caixa de dilogo

A caixa de dilogo corresponde a uma janela especialmente destinada a apresentao de mensagens e/ou de controles para aes que lhe so especficas. As caixas de dilogo podem ser modais ou no modais. So modais quando exigem uma resposta do usurio, que fica impedido de qualquer outra ao, at que isto acontea. As no modais permitem que o usurio trabalhe sobre outros objetos de uma outra janela ou caixa de dilogo, enquanto que aguardam em segundo plano, uma ao sua. As dimenses de uma caixa de dilogo devem ser definidas em funo de seus componentes, de modo que a relao entre o comprimento e altura se aproxime do chamado nmero de ouro; 1/1,613. Assim como para as janelas, recomenda-se que os ttulos das caixas devam ser centrados na margem superior ou alinhados pela esquerda e a distribuio de seus integrantes deva seguir uma diagramao adequada. A densidade final de uma caixa de dilogo no pode exceder os 40 %. Sua apario na tela pode ser padronizada em um mesmo local, determinada pelo objeto a que se refere ou alinhada com o ttulo da caixa de dilogo que lhe superior.
5.2.2.1.3 Caixa de Ao/Tarefa

A caixa de ao/tarefa proporciona os controles e comandos especficos para a introduo de parmetros e para o acionamento da ao ou da tarefa que a define. Este tipo de caixa deve abrigar os botes de comando para validar, para aplicar imediatamente e para cancelar uma ao. Um deles deve ser definido "por default" e diferenciado apropriadamente. No caso de aes destrutivas, a opo "por default" deve recair sobre sua anulao e no sobre a prpria ao. Tambm devem ser previstos botes de ajuda e de fechamento da caixa. A definio do layout destes botes deve minimizar os movimentos do mouse.
5.2.2.1.4 Formulrio e a tela de consulta

A tela de consulta e o formulrio so painis de controle destinados especificamente s aes de consulta e entrada de conjunto de dados. Eles devem apresentar um ttulo significativo e um layout agrupando, diferenciando e ordenando logicamente as diversas categorias de dados apresentadas. Alm disso, o layout deve ser compatvel com os documentos fsicos, manuseados pelo usurio em sua tarefa. O mesmo ocorre em relao aos formatos dos dados apresentados e introduzidos.

49

O incio das aes de entrada em um formulrio deve se dar a partir do campo localizado, mais ao alto e a esquerda do painel. Esta posio inicial deve ser mantida de forma consistente durante a interao. Os campos devem estar adequadamente identificados, sendo que seus rtulos devem ser visualmente diferenciados dos dados e devem conter informao sobre as unidades, valores aceitveis e os formatos dos dados a entrar. O alinhamento dos rtulos deve ser feito pela esquerda ou pela direita, no caso deles apresentem comprimentos muito diferentes. Deve ser previsto um mecanismo de simples operao para a navegao entre os campos, geralmente atravs da tecla TAB. Os campos de preenchimento obrigatrio devem ser diferenciados visualmente e aqueles contendo dados crticos para o sistema devem ser identificados e protegidos contra acidentes de operao. Um efeito sonoro pode ser empregado para informar sobre a proteo de um campo e/ou, sobre o seu preenchimento total. Os controles e mostradores de informaes sobre o estado do sistema devem estar localizados na parte inferior do formulrio. Esta mesma regio deve ser reservada para a apresentao caixas de mensagens de erro. O registro dos dados entrados em um formulrio no deve ser acionado como efeito colateral da ao de entrada de algum dado. O usurio deve explicitamente solicitar este registro atravs de um boto de comando, com uma denominao coerente. Aconselha-se que o rtulo desse boto contenha a palavra "Entre". Da mesma forma, deve ser previsto um boto para cancelar este comando. Aps o registro das entradas, o sistema deve preencher com traos "----" os campos desconsiderados pelo usurio.
5.2.2.1.5 Caixa de mensagem

As caixas de mensagem fornecem informaes e instrues ligadas a conduo, a ajuda, as advertncias, aos alarmes e aos

50

erros na interao. Elas so do tipo modais, exigindo que o usurio tome seu conhecimento para permitir a seqncia da interao. O boto "ok" deve ser previsto em toda a caixa de mensagem como meio de receber a confirmao do usurio. Quando a situao for de alarme as caixas devem estar destacadas atravs de uma localizao central da tela, do emprego da cor vermelho, da intermitncia ou do acionamento de um efeito sonoro. Numa situao de advertncia elas devem explorar o estereotipo do amarelo. As caixas de mensagens de erro devem propor sempre um boto "Ajuda".

5.2.2.2 Os controles compostos

Os controles so objetos de interao sensveis s aes do usurio, lhe proporcionando facilidades em termos de edio, seleo e manipulao direta. Tratam-se de campos, botes de comando, painis de menus, listas de seleo e barras de ferramentas que possibilitam ao usurio tanto a entrada de dados, como o comando de acionamento de uma funcionalidade da aplicao. Os controles complexos correspondem a objetos de interao de estrutura composta com algum tipo de navegao interna e que destinam-se especialmente seleo de controles e comandos
5.2.2.2.1 Painel de menu

Um painel de menu destina-se a seleo de opes que acionam os comandos do programa aplicativo. Existe a possibilidade desse acionamento ser precedido da apresentao de caixas de dilogo e/ou de outros menus. Em um menu as escolhas s podem ser simples. Todas as opes de um menu devem ser apresentadas simultaneamente, no sendo recomendados a navegao por barra de rolagem.

51

As opes de um menu devem refletir as necessidades do usurio em sua tarefa, de modo a formar grupos e sub-grupos a partir de costumes ou convenes dos usurios (carnes, frutas, legumes, etc.), de categorias lgicas (objetos, aes) ou arbitrrias. Nesse sentido, apenas as opes pertinentes devem ser apresentadas e devem ser ordenadas segundo algum critrio lgico; como seqncia da tarefa, seqncia lgica, freqncia de uso ou ordem alfabtica. Os menus muito numerosos devem ser organizados em grupos de at 7 elementos interrelacionados logicamente e separados um dos outros por um trao simples. As opes inativas devem ser apresentadas de modo dissimulado. De modo a preservar a leveza dos painis e a legibilidade das opes, as bordas devem ser definidas por linhas simples suficientemente afastadas dos nomes das opes.

A opo de menu corresponde a uma rea de seleo preenchida com o nome correto de um comando do sistema, que enviado para a interpretao do programa aplicativo assim que a opo seja selecionada pelo usurio. Os diferentes estados que as opes de menu podem assumir, "inativo", "ativo", em "foco", e "selecionado", devendo ser visualmente diferenciados. No estado ativo, a opo se encontra sensvel a uma ao de seleo. No estado inativo, a seleo no possvel. O estado "em foco" corresponde ao momento anterior a uma seleo, quando o usurio posiciona o cursor sobre a opo e prepara-se para selecion-la. A desativao pode ser representada atravs da dissimulao do item (cor cinza dos caracteres). Para os itens em foco de seleo, o padro o vdeo reverso. O feedback que informa que uma seleo acaba de ocorrer dado pelo desaparecimento do painel de menu e pelas repercusses da ao escolhida. Em painis com mltiplas escolhas, uma opo j selecionada indicada ao usurio atravs de pequenos smbolos ( , * ou flechas). As opes podem ser classificadas como; opo de comando, opo de dilogo e opo de sub-menu. As opes do primeiro tipo acionam um comando da aplicao. As de dilogo acionam a apresentao de uma caixa de dilogo para a entrada de parmetros de um comando. As opes de sub-menu fazem a apresentao de outro menu, permitindo ao usurio afinar a sua
52

escolha em termos de opes de comandos. Estes diferentes tipos de opes devem ser apresentados diferentemente. As opes que acionam caixas de dilogo devem ser seguidas de indicadores de continuao de dilogo "...". Aquelas associadas a sub-menus devem apresentar um marcador em forma de flecha. Ambos indicadores devem ser adequadamente alinhados pela margem direita do menu. A seleo e acionamento de uma opo de um painel pode ser feita atravs do teclado e de um dispositivo de apontamento (mouse, caneta tica, ou o dedo em uma tela ttil). Na interao atravs de dispositivos de apontamento, a reas de seleo devem ser suficientemente amplas. No caso de menus em telas tteis ela deve ter uma altura mnima de aproximadamente 2,0 cm. A interao por teclado possibilita dois tipos de atalhos; os aceleradores e os mnemnicos. Um acelerador um dispositivo que permite acionar uma opo de menu, a partir de uma tecla de funo ou de combinaes de teclas. Isto ocorre independentemente da opo estar ou no visvel na tela. Neste caso, a indicao das teclas aceleradoras associadas a uma opo deve aparecer direita de seu nome. J os mnemnicos s acionam opes de menu que estejam visveis na tela. Eles so definidos a partir de uma das letras do nome da opo, que aparece sublinhada. Essa letra pode ser a inicial do nome ou uma outra que lhe seja associada. Estando o painel de menu visvel na tela, o acionamento de uma opo atravs de seu mnemnico ocorre pela simples digitao da letra sublinhada. Os nomes das opes devem ser concisos, significativos e familiares aos usurios e no devem ser abreviados. Sua tipografia deve ser normal, com somente a primeira letra do nome da opo em maiscula. Se uma enumerao das opes for necessria ela deve ser numrica. Sob o ponto de vista da tarefa, os painis de menus podem ser principais e secundrios. O menu principal representa o ponto de partida para a tarefa. Suas opes devem cobrir todas as alternativas em termos de aes bsicas. Os menus secundrios so acionados atravs de uma opo de menu, permitindo ao usurio afinar a escolha de um comando. Quanto a dinmica da apresentao, os painis de menu podem ser permanentes (sempre visveis em uma posio fixa da tela) ou transitrios (aparecerem somente quando solicitado pelo usurio). Esses ltimos caracterizam os menus "de desdobrar" (pull-down), em cascata" (cascading) e os de "sobreapresentao" (pop-up). O menu de desdobrar apresentado na tela atravs do acionamento de uma opo de menu principal. O menu em cascata designa uma estrutura na qual um painel de menu secundrio apresentado a partir do

53

acionamento de uma opo de um outro painel menu tambm secundrio.

O surgimento na tela de um menu em sobre-apresentao (pop-up) se d atravs do acionamento do boto direito do mouse. As opes de um menu pop-up variam conforme a zona funcional da tela sobre a qual o cursor do mouse se encontra no momento em que ocorre o acionamento. O painel de menu popup deve ser apresentado prximo do local onde seu acionamento ocorreu.

Quanto a sua forma, os painis de menus constituem as pginas de menu, as barras de menu e os menus imbricados (hipertexto).
5.2.2.2.2 Pgina de Menu

As pginas de menu so telas nas quais o elemento principal um painel de menu permanente. As pginas de menu
54

encontram-se encadeadas de modo arborescente. Os aspectos principais destas estruturas de menus correspondem a largura (nmero de alternativas por pgina) e a profundidade (nmero de pginas por busca). Uma pgina de menu deve possuir um ttulo significativo, um elemento de convite interao (prompt) e um sistema de enumerao das opes.

Na seleo por teclado, as opes da pgina de menu devem ser enumeradas com nmeros e no com letras, alinhados pela direita e separados do nome da opo atravs de um ou dois espaos. A numerao de partir sempre do nmero 1 e nunca do zero. No caso das letras serem definidas para a seleo por teclado, a enumerao deve ser alinhada pela esquerda.
5.2.2.2.3 Barra de Menu

A barra menu um painel de orientao horizontal. Ela deve ser posicionada no alto da tela ou da janela do programa aplicativo, apresentando os comandos de base de um sistema (no mais de oito opes). As barras no comportam qualquer tipo de navegao, e sua retirada da tela s se justifica para sistemas destinados ao grande pblico, ou se expressamente comandada pelo usurio. Os nomes de suas opes devem ser palavras curtas e separadas por ao menos trs espaos em branco. Se a ordem relativa a tarefa ou a freqncia de uso no podem ser definidas, um ordenamento alfabtico deve ser empregado.
5.2.2.2.4 Hipertexto (Menu Imbricado)

O menu imbricado em um texto permite a construo de dilogos do tipo hipertexto, destinado a navegao entre pginas de textos relacionados. Esse tipo de menu deve respeitar as recomendaes quanto a uma estrutura equilibrada, organizando
55

as opes de navegao por nvel segundo os limites da memria de curto termo humana e as categorias lgicas e conceituais das tarefas. A profundidade da estrutura deve ser limitada no sentido de evitar dilogos muito compridos.

5.2.2.2.5

Barra de ferramentas

A barra de ferramentas constituda de um grupo de controles, campos e de botes de comando, que so apresentados em um pequeno painel amodal. Esses elementos permitem a seleo, a parametrizao e o acionamento das ferramentas de que dispe o usurio para realizar tarefas diversas no sistema.
5.2.2.2.6 Lista de seleo

Uma lista de seleo um tipo de menu que empregada para a entrada de dados cujos valores possveis sejam conhecidos de ante-mo. O comprimento recomendado de uma lista deve permitir a visualizao imediata de apenas 7 (+- 2) itens. O projetista deve especificar a ativao de mecanismos de navegao internos (barras de rolamento) quando o nmero de escolhas possveis se torne elevado. O limite mximo de algo como 50 itens que devem ser ordenados logicamente, segundo a freqncia de uso e/ou uma ordem alfabtica. Separadores devem ser empregados para marcar a organizao dos itens segundo grupos lgicos. Se qualquer organizao no for

56

possvel, os separadores (um trao simples) devem ser dispostos a cada 6 linhas de alternativas.

No caso de restries de espao as listas podem ser configuradas como desdobrveis. Desta forma somente a primeira linha da lista apresentada inicialmente. Para visualizar as outras alternativas o usurio deve acionar o boto de desdobramento ( direita da primeira linha) que ir apresentar o restante da lista para baixo ou para acima e no primeiro plano da tela (tapando outros elementos). A largura da lista pode ser determinada pelo item mais longo se ele for menor do que 20 caracteres. Caso contrrio ela deve ser definida a partir da mdia dos comprimentos de cada item. A lista de seleo composta de itens que, a semelhana com as opes de um menu, podem assumir os estados "inativo", "ativo", em "foco" e "selecionado", com representaes visualmente diferenciadas.
5.2.2.2.7 Caixa de combinao

A caixa de combinao combina em um s objeto uma lista de seleo de desdobrar associada a um campo de dados. Ela proporciona mais facilidade ao usurio ao selecionar um item da lista a partir dos caracteres digitados no campo de dados.

57

5.2.2.3 Os grupos de controles

5.2.2.3.1 Grupo de botes de comando

O grupo de botes de comando deve ser definido nas situaes em que as opes de comandos possveis forem em nmero reduzido. Seu arranjo pode seguir duas regras. Eles podem ser alinhados verticalmente e a direita do objeto a que fazem referncia, ou horizontalmente e abaixo deste objeto. Um boto "por default" deve ser definido, visualmente diferenciado e posicionado ao alto, se a orientao for vertical , ou a esquerda, no caso de uma orientao horizontal.
5.2.2.3.2 Grupo de botes de rdio

Um grupo de botes utilizado para a entrada de dados deve prever botes de rdio (radio-button), quando o conjunto de valores possveis para um dado forem conhecidos, no excederem sete alternativas, e forem mutuamente exclusivos.

O grupo de botes rdio rene um mximo de sete itens de seleo que devem estar distribudos eqidistantemente. Grupos maiores devem ser subdivididos logicamente e visualmente separados por uma linha simples ou um retngulo de linhas simples (caixa de grupamento)

58

5.2.2.3.3

Grupo de caixas de atribuio

Se os valores possveis para uma entrada no forem mutuamente exclusivos, estando envolvidos em uma escolha mltipla, deve-se prever um grupo de caixas de atribuio (check-box).

O layout de um grupo de caixas de atribuio (check-box) est sujeito s mesmas recomendaes propostas para um grupo de botes de rdio.
5.2.2.3.4 Grupo de campos/mostradores de dados

Os grupamentos de campos e mostradores de dados devem ser definidos segundo critrios lgicos de formao e de ordenamento. Assim os dados devem ser reunidos segundo critrios tradicionalmente empregados pelos usurios ou segundo as funcionalidades definidas ou ainda segundo critrios arbitrrios. Em todos os casos a ordem de apresentao deve seguir critrios de seqencialidade, importncia ou freqncia de uso. O destaque de um campo de dados pode se dar pelo seu posicionamento ou pelo emprego das cores.

5.2.2.4 Os controles simples

5.2.2.4.1 Boto de comando

Em relao aos comandos editveis, botes de comando facilitam consideravelmente a tarefa do usurio, que realiza uma atividade mental de reconhecimento e no de recuperao. Nesta ltima o seu rendimento humano superior. Outro aspecto importante dos comandos selecionveis est ligado a abstrao dos detalhes da sintaxe dos comandos. O usurio conduzido na entrada de parmetros de acordo com a opo de comando selecionada e os parmetros j entrados. Este fato proporciona uma reduo importante de erros de sintaxe.

59

Os estados possveis para um boto de comando incluem "ativo", "inativo", "default" e "ativado" que devem ser visualmente diferenciados. O boto definido por default tem o foco das aes do usurio. Dessa forma, seu acionamento facilitado ao usurio que pode tanto usar o dispositivo de apontamento como as teclas "Enter" ou "Return". Os nomes de botes de comando devem ser concisos, significativos e familiares e quando eles acionam caixas de dilogo, devem ser seguidos de indicao de continuidade "...".
5.2.2.4.2 Boto de seleo

O boto de seleo utilizado quando uma entrada de dados corresponder a ativao e desativao de um atributo ou entidade (on-off). Eles correspondem aos check-boxes, interruptores, radio buttons e outros interadores similares. Em grupos, os check-boxes e radio-buttons tem um comportamento estabelecido por conveno. Os primeiros permitem escolhas mltiplas enquanto que os radio-buttons trabalham com escolhas simples e mutuamente exclusivas. Segundo essa conveno a utilizao de botes de rdio isolados no tem sentido e deve ser evitada.
5.2.2.4.3 Cursor do dispositivo de apontamento

Os cursores representam a classe de controles verdadeiramente manipulveis pelo usurio. Seu objetivo de permitir a designao ou a indicao de uma posio na tela. atravs do cursor do dispositivo de apontamento que o usurio seleciona e aciona parmetros e funcionalidades dos diferentes objetos. Sua forma deve ser diferencivel, ao mesmo tempo em que no prejudique a visualizao dos objetos que encobre. O cursor

60

do mouse oferece a possibilidade de definio de diversas formas que se alternam em funo de seu posicionamento ou do tipo de tarefa. Neste caso elas devem ser significativas e ao mesmo tempo fornecer um apoio ao usurio. Por exemplo, quando a tarefa exigir preciso na indicao, a forma definida pode incluir um crculo. O projetista deve definir valores para a taxa de deslocamento levando em considerao um compromisso entre a velocidade e a preciso no posicionamento.
5.2.2.4.4 Escala

A escala um controle que permite ao usurio a introduo de um valor numrico pelo ajuste de um cursor em uma determinada posio sobre uma linha graduada. A barra de rolamento um exemplo deste tipo de objeto.
5.2.2.4.5 Dial

O dial se apresenta como um objeto circular graduado numericamente entre dois limites a intervalos regulares. Da mesma forma que na escala, o usurio interage com o dial atravs do cursor.

5.2.2.5 Os campos de entrada

As possibilidades em termos de controles editveis incluem os campos para a edio de textos e de objetos grficos.
5.2.2.5.1 Linha e rea de comando

As reas e linhas de comando correspondem a campos de edio uni e multi-lineares, cujo contedo, introduzido pelo usurio, enviado ao programa aplicativo visando acionar uma ou mais de suas funcionalidades. Neste sentido, esses comandos editveis proporcionam grande flexibilidade ao usurio, que pode se valer de forma imediata e direta de todas as opes de comandos previstas na linguagem. A rea de

61

comando em especial fornece recursos de histrico, para que o usurio possa avaliar e retomar estratgias de interao. Os comandos deste tipo devem ter sua localizados padronizada, de preferncia na parte inferior da tela e a rea de comando no deve ser inferior a quatro linhas.
5.2.2.5.2 Campo de dados

Um campo de dado por definio uni-linear. Eles recebem dados cujos valores no podem de ante mo, ser previstos pelo projetista e cujos comprimentos no excedam os 40 ou 50 caracteres. Todo o campo de dado deve apresentar um rtulo identificativo e convidativo (prompt), para apoiar o usurio na entrada de um dado. Isso pode ser feito atravs da explicitao do formato (mm/dd/aa) do dado, de sua unidade (cm, pol) e dos valores possveis (1 a 10). Um smbolo padronizado, em geral : deve ser empregado como explicitao do convite entrada. O rtulo do campo de dado deve ser conciso, significativo e familiar para o usurio e ser escrito de tipografia normal (somente a inicial em maisculo). Em geral, o rtulo deve ser consistentemente colocado ao lado esquerdo do campo ou acima desse e alinhado pela esquerda. Com o objetivo de minimizar as aes do usurio o projetista pode especificar um valor a ser proposto "por default" ao usurio. Na escolha de um modo de edio "inserir entre" deve ter a preferncia sobre o modo "escrever sobre". Nesse particular, seja qual for a definio ela deve ser mantida consistente durante o projeto da interface. Os mtodos para o tratamento dos valores entrados podem considerar equivalentes as letras maisculas e minsculas. O preenchimento dos zeros e dos pontos decimais desprezados pelo usurio tambm deve ser considerado. Em entradas de valores codificados com mais de 10 letras ou 5 dgitos sem significado para o usurio, um esquema de pontuao com espaos, vrgulas, hfens ou barras pode ser
62

definido. O objetivo nesse caso de dividir essas entradas em grupos de 3 a 4 caracteres, para evitar os erros e facilitar a leitura. Os dados entrados devem ser checados quanto a sua conformidade de tipo, cabendo ao projetista declarar uma expresso de destaque como um bip sonoro, para alertar ao usurio quando os erros acontecerem.
5.2.2.5.3 Campo de Texto

O campo de texto por definio multi-linear. Seu tamanho em termos do nmero e do comprimento de linhas deve ser adequado para proporcionar um desempenho eficiente na tarefa de entrada de textos. Para a facilidade de leitura o comprimento das linhas no deve exceder os 40 caracteres e a altura do campo deve proporcionar a apresentao de um mnimo de 4 linhas.
5.2.2.5.4 Campo grfico

O campo grfico se define nos recursos de edio grfica que proporciona ao usurio. As recomendaes ergonmicas so econmicas em relao a essa classe de objetos. Elas se referem as diferentes formas do cursor face aos diferentes tipos de tarefa.

5.2.2.6 Os mostradores estruturados

Os dados e informaes interligadas a uma srie de variveis do contexto do sistema devem ser apresentados atravs de grficos, tabelas ou listas, textos, mapas, diagramas, etc.. Essas formas de apresentao facilitam o exame de dados numerosos permitindo, em maior ou menor grau, a identificao das inter-relaes e tendncias. O critrio de agrupamento dos dados que participam dessa estruturas deve ser lgico. A discriminao de um grupo de dados nas telas pode ser feita atravs de seu posicionamento, pelo emprego de cores ou pela definio de uma caixa de grupamento.

63

5.2.2.6.1

Lista/Coluna de Dados

Toda lista/coluna de dados deve possuir um cabealho conciso, e representativo dos dados apresentados, dos quais deve estar visualmente diferenciado. O alinhamento dos dados na lista deve dispensar cuidado especial e sua enumerao deve ser feita a partir de nmeros, evitando as letras e suficientemente afastada do texto. No caso da lista se estender alm dos limites de espao de tela, o projetista pode optar entre dois tipos de navegao possveis: por paginao ou por rolamento. A paginao se aplica no caso de usurios inexperientes ou quando a tarefa envolver a busca de uma informao isolada. Este recurso demanda a definio referente a mensagem de continuao. Quando o objetivo da tarefa for a busca de relaes entre dados, a tcnica de rolamento preferencial. O formato da coluna pode ser normal ou identado, prevendo assim a possibilidade de hierarquias de itens e sub-itens.
5.2.2.6.2 Tabela de Dados

tabela de dados aplicam-se as recomendaes da lista. Deve-se ter cuidado especial na definio de cabealhos para linhas e colunas (se necessrios), que devem ser diferenciados entre si. Alm disso, uma tabela pode apresentar blocos de dados e informaes interligadas. Os blocos devem ser definidos logicamente e separados fisicamente, por uma linha em branco ou por um trao simples, do resto da tabela.
5.2.2.6.3 Texto

A classe "Texto" apresenta informaes na forma de uma cadeia de frases e perodos. Sua dimenses devem ser definidas de modo a apoiar a tarefa de leitura. Nesse particular, o formato do texto pode ser normal ou em colunas. Em formato normal o alinhamento deve ser definido pela margem esquerda. Em formato coluna, ele deve ser justificado. O espaamento entre colunas pode ser de 3 caracteres se elas forem justificadas pela direita. Em caso contrrio este valor passa para 8 caracteres. O comprimento das linhas no pode exceder os 50 a 60 caracteres em formato normal e os 35, em formato coluna. Os pargrafos devem, em ambos formatos, ser espaados de aproximadamente uma linha em branco. Sob hiptese alguma um texto que deva ser lido pode aparecer piscando (blinking) ao usurio.

64

O projetista deve explorar adequadamente os recursos de estilo para realar as informaes importantes de um texto, sem no entanto, exagerar no negrito ou sublinhado. Ele deve evitar de apresentar textos exclusivamente em letras maisculas. Para facilitar a leitura, as fontes para devem ser proporcionais e devese evitar a hifenizao. O enquadramento por bordas pode ser til para destacar o texto na tela.
5.2.2.6.4 Grfico

Os grficos apresentam espacialmente dados ou variveis correlacionadas. Seus diferentes formatos se aplicam para; multi-linha -> anlise de tendncias, grfico de superfcies -> exame de valores cumulativos, grficos de barra -> exame de amostras a intervalos discretos, grficos de setor -> anlise de valores que representam partes de um todo.

65

O ttulo de um grfico deve ser descritivo das correlaes apresentadas. As curvas podem ser diferenciadas atravs do uso de traos pontilhados, smbolos geomtricos, espessuras e cores. Na configurao das escalas, merecem ateno as definies relativas ao rtulo geral, ao tamanho das letras, marcao inicial (0), ao intervalo de rotulao (a cada 1,2,5 e 10 marcaes), ao nmero de sub-divises (<9) e s progresses horizontal (esquerda->direita) e vertical (baixo->cima).
5.2.2.6.5 Diagrama de figura

Um diagrama uma representao grfica, que pode ser um desenho ou uma fotografia de um objeto ou de uma estrutura, realizados com o objetivo de mostrar as relaes espaciais entre os componentes de um todo. No caso de limitao de espao eles podem ser organizados em sees, devendo ento ser previstos botes de comando para a visualizao das diversas sees. Uma lupa mvel ou zoom deve estar disponvel para auxiliar na visualizao dos detalhes do diagrama, que pode tambm contar com o apoio de uma funo de rotao. As partes importantes podem ser destacadas atravs caixas de enquadramento ou de flechas intermitentes.
5.2.2.6.6 Diagrama de fluxo

Os diagramas de fluxo so representaes grficas elaboradas para a apresentao esquemtica de dados logicamente relacionados em um processo seqencial. Elas se aplicam especialmente para tarefas de resoluo de problemas e de gesto de projetos. Seus elementos devem ser apresentados segundo uma ordem lgica, respeitando as convenes estabelecidas em termos de esquerda para a direita, do alto para baixo e no sentido dos ponteiros dos relgios. As trajetrias mais provveis devem ser minimizadas, o que pode ser conseguido

66

atravs da antecipao de pontos de decises com o menor nmero de alternativas. Economizar espao a partir da combinao de decises, pode confundir o usurio e algo a ser evitado. A disposio de alternativas em um bloco deve respeitar algum tipo de lgica e ser coerente. Por exemplo o "sim" deve sempre estar a esquerda e o "no" a direita ou abaixo. Finalmente, a escolha dos formatos dos blocos e dos conectores deve ser consistente com o tipo de ao e de relao representados.
5.2.2.6.7 Mapa

Um mapa uma representao reduzida de uma regio que utilizada para a apresentao de dados fsicos e geogrficos. Sua apresentao pode assumir, segundo as necessidades do projetista, a forma de um mapa poltico ou de uma carta geogrfica. Os mapas so apropriados para a apresentao de dados relativamente estveis como populao, atividade econmica, etc. As cartas se aplicam especialmente na apresentao de dados variveis como a progresso de massas de ar. Mapas e cartas devem apresentar uma orientao consistente em termos de norte-sul alm de uma escala precisa e compatvel com os dados a serem apresentados. Um efeito de curvatura pode ser definido quando da apresentao de superfcies vastas. Os rtulos descritivos devem ser posicionados cuidadosamente, de modo que no se afastem de sua referncia, que no encubram outras informaes e que no venham a causar um congestionamento visual importante. Uma legenda deve ser definida para cdigos de textura, cores e de intensidade de cores.

67

Alguns autores (Norman, 1991) entretanto consideram que o uso frequente de legendas pode atrapalhar o usurio, podendo ser uma indicao da falta de adequao nas escolhas feitas em termos dos tipos de representaes a adotar. As cores podem representar dados substitutivos como alinhamentos polticos, tipos de reservas minerais, de florestas, de lavouras, etc. J a intensidade de cores e texturas, constituem escalas aditivas e se aplicam na representao de dados numricos como altitudes, demografias, indicadores econmicos, etc. . Funes de zoom e de navegao devem estar disponveis aos usurios. Um cursor de localizao e um indicador de distncias devem ser previstos nos casos de deslocamentos possveis. Isto com o objetivo de informar, grfica e numericamente, a posio do usurio sobre a carta.

5.2.2.7 Os Mostradores Simples

5.2.2.7.1 Mostrador de Dados

Os mostradores de dados devem possuir rtulos identificativos e descritivos para explicitar a unidade e o formato dos valores apresentados. Sempre que for possvel o projetista deve adotar formatos padronizados e coerentes com as convenes de usurio. Uma forma digital (dgitos) deve ser definida quando houver uma necessidade de preciso de leitura do dado. No caso de valores que variem rapidamente, uma forma grfica analgica deve ser definida. Se o dado a apresentar for demasiadamente longo ele deve ser divido em grupos lgicos. No que se refere as formas auxiliares, as cores, em especial o amarelo, pode ser empregado para agrupar dados espalhados na tela. Cores mais saturadas (contraste) ou mais intensas (brilho) podem ser utilizadas para o destaque de dados crticos. O emprego da intermitncia visual (pisca-pisca) para destacar um dado deve ser feito com bastante cuidado. De modo a preservar sua legibilidade, sugere-se a adoo de um elemento extra, como um indicador ao lado do dado, ao qual seria atribuda a intermitncia visual. O tamanho dos caracteres tambm pode ser utilizado como forma de destacar dados urgentes.

5.2.2.8 As Orientaes
Uma orientao definida como uma mensagem do projetista ao usurio. Ela desempenha uma funo fundamental para as manipulaes cognitivas dos usurios envolvendo dados, controles e comandos. A ausncia de informao inviabiliza a operao de um sistema por usurios leigos. As classes de orientao distinguem os rtulos, as mensagens (de orientao, de ajuda, de alerta, de aviso e de

68

erro), os indicadores de estado e de progresso, e os efeitos e motivos sonoros.

5.2.2.8.1 Rtulo

Um rtulo pode assumir a forma de um cone, de um sinal geomtrico, de uma palavra ou de um texto.

Os rtulos textuais devem empregar palavras distintas e significativas, alm de concisas. Caso demandem uma ateno particular as formas auxiliares podem ser empregadas como expresso discriminativa. O tamanho dos caracteres deve estar definido segundo o critrio da legibilidade. O posicionamento relativo ideal acima ou a esquerda do objeto a que fazem referncia. Neste particular eles devem estar suficientemente isolados ao mesmo tempo em que permanecem prximos do objeto. Em suas relaes com outros objetos, esta classe desempenha diferentes tipos de funes, incluindo: a identificao, a descrio, a incitao, a indicao e a separao. Face a estas funes e as relaes com diferentes objetos possvel definir algumas das instncias de um rtulo. O ttulo um rtulo identificativo forosamente textual, empregado como funo de identificao em textos, grficos, tabelas, janelas, caixas de dilogo, etc. Um cabealho o rtulo de uma lista ou tabela, devendo ser destacado ou discriminado atravs do tamanho ou do estilo de caracteres sublinhados, coloridos, etc.. Da mesma forma que o cabealho se define na relao com listas, um prompt se define na relao com campos de dados. Um prompt o rtulo de convite interao que deve ser destacado ou diferenciado atravs de um posicionamento adequado na tela. O marcador tem a forma de um pequeno sinal que colocado ao lado de objetos como itens de seleo e opes de menu principalmente, para indicar seu estado j selecionado. O separador tem a forma de uma linha simples que define uma separao entre os itens ou opes de um menu ou lista de seleo.
69

5.2.2.8.2

Mensagem

As mensagens incluem as orientaes, as ajudas, os alertas, os avisos e os avisos de erro. Dependendo do ambiente operacional do sistema, elas podem ser apresentadas dentro de caixas de mensagens ou diretamente nas telas. As mensagens podem ser permanentes ou transitrias, modais ou amodais, e sua apresentao pode ser solicitada pelo usurio ou comandada pelo sistema em resposta a uma ao do usurio ou de uma mudana do contexto do sistema. Elas so apresentadas geralmente na forma textual, que especialmente adequada para lidar com noes abstratas e expressar dedues lgicas, podendo ser complementadas atravs de algum elemento grfico (cone ou figura). As frases devem ser afirmativas e diretas, na voz ativa, evitando pontuaes desnecessrias e apresentando os argumentos segundo uma ordem lgica. Assim como os rtulos, as orientaes so elementos permanentes das telas. So frases, que colocadas vista do usurio tentam orient-lo em sua tarefa, atravs de um vocabulrio simples, significativo e familiar. As ajudas so solicitadas explicitamente pelo usurio e podem permanecer na tela enquanto ele completa sua tarefa (amodais). Seu contedo deve ser contextual, isto , deve se referir ao contexto da tarefa que o usurio est realizando. A apresentao de avisos e alertas comandada pelo sistema em resposta a uma ao do usurio ou a uma mudana no contexto exterior (rede, dispositivos, etc.) Ambas so modais, exigindo uma resposta do usurio antes de lhe devolverem o controle. Avisos e alertas se diferenciam atravs da importncia que lhes atribuda. Assim sendo, os alertas devem ter uma apresentao diferenciada e nica. As mensagens de erro so modais e so apresentadas pelo sistema em resposta a uma ao equivocada do usurio. Elas devem ser polidas, neutras e contextuais. Devem ser concisas evitando porm os cdigos ou abreviaturas. Devem apresentar a informao principal no incio deixando os elementos a memorizar para o final. A tipografia deve ser a de uma frase normal (somente a inicial em maisculo).
5.2.2.8.3 Indicador de Progresso

O indicador de progresso um mostrador especializado na apresentao da sucesso de estados de um processo linear e finito. Tipicamente, tm a forma de uma barra, cujo preenchimento d uma indicao do que j foi feito e do que falta a ser realizado no processo.

70

5.2.2.8.4

Efeito Sonoro

Os efeitos sonoros so estruturas sonoras simples que atuam como cones sonoros para chamar a ateno do usurio e fornecer feedback. Eles devem ser consistentes com a situao a assinalar, pouco numerosos e suficientemente diferenciveis. Como cones sonoros, os efeitos sonoros podem apresentar formas concretas e abstratas. As concretas imitam sons como o fechamento de uma porta metlica para representar o fechamento de um arquivo de dados. As abstratas se baseiam em convenes sociais como aplausos para representar uma aprovao.
5.2.2.8.5 Motivo Meldico

Motivo meldico denota uma breve sucesso de tons combinados de maneira a produzir um padro de ritmo suficientemente distinto para que ele funcione como uma entidade individual e reconhecvel (Loshe, Walker, Biolsi, & Rueter, 1991). A seqncia de tom e o ritmo definem a partitura de um "motivo sonoro". As caractersticas dinmicas de "crescendo" e "decrescendo" podem ser utilizadas para indicar aes de iconificao, movimentao e mudanas de tamanho de janelas, por exemplo. Ritmos e de timbres so bastante eficazes para efeitos de diferenciao.
5.2.2.8.6 Locuo e Fala

Estas classes representam uma forma alternativa de transmisso de dados e mensagens ao usurio, aplicando-se aos ambientes de trabalho silenciosos, onde o operador tenha necessidades de pequenos deslocamentos e podem ser de "fonte" sintetizada ou registrada. A classe "locuo a verbalizao de palavras simples ou compostas, enquanto que a Fala a verbalizao de textos de mensagens. A locuo pode ser usada para demonstraes, simulaes ou instrues e devem envolver somente as informaes, crticas ou necessrias, que tenham um carter de domnio pblico. Se o conjunto de frases for em pequeno nmero elas devem ser registradas. Se elas foram sintetizadas, deve-se tomar cuidado em definir um ritmo adequado. O timbre de voz pode ser usado para destacar ou discriminar a expresso falada que no deve ser muito longa. Um meio adequado de permitir a interrupo da locuo deve estar disponvel ao usurio.

5.2.3 Os Sistemas de Significado

Os sistemas de significado referem-se as relaes simblicas estabelecidas na transmisso de um contedo de informao por meio de uma expresso perceptvel e tratvel

71

pelo sistema cognitivo humano. Essas relaes referem-se a entidades como smbolos e sinais. Considera-se que em um sinal (Chevalier, 1980) a relao entre a forma de contedo e forma de expresso seja arbitrria, ou seja depende do conhecimento mtuo das regras de codificao. Os sinais usados tanto em uma linguagem natural como na lgebra ou na matemtica tem assim uma capacidade de transmitir um conhecimento mais ou menos objetivo. Em um smbolo, a homogeneidade entre expresso e contedo estabelece uma representao motivada ou concreta, onde o carter espontneo da interpretao essencial. A citao de Chevalier (pg. XV) oportuna para concluir este entendimento: "o smbolo carregado de realidades concretas. A abstrao esvazia o smbolo e da vida ao sinal".
5.2.3.1.1 cones

Um cone pode corresponder a diferentes tipos de representaes. Chevalier, em seu Dicionrio dos Smbolos esclarece sobre variaes simblicas pertinentes ao projeto representaes grficas: Smbolo - representaes grficas motivadas ou concretas; um desenho de uma impressora para designar o dispositivo fsico. Neste grupo se incluem as miniaturas. Emblema - uma figura adotada convencionalmente para representar uma idia, um ser fsico ou moral; bandeiras nacionais e logomarcas. Atributo - um acessrio caracterstico para designar o todo; garfo e da faca para representar um restaurante, asas para companhias areas, rodas para o transporte rodovirio, etc. Arqutipo - exemplares de classe para representar o conjunto; um exemplar de histograma para representar as escolhas possveis em termos de grfico de dados. Analogia - relao entre seres ou noes essencialmente diferentes, mas semelhantes sob um determinado aspecto; taa de vinho usada como smbolo de fragilidade. Se possvel, use cones prontos respeitando seus significados (esteritipos para cones). Se for desenh-los siga as seguintes recomendaes: Desenhe cones simples, com poucos elementos, mas com apelo visual. Use metforas de objetos em vez de abstraes sobre idias ou conceitos Amplie os elementos significativos dos cones (que os distinguem)

72

 Evite grossos contornos Use poucas cores Empregue um grid para o desenho de cones Desenhe cones consistentes em seu conjunto Use efeitos de sombra (fonte luminosa no canto superior esquerdo) e perspectiva Respeite a escala dos outros objetos da tela. No os faa nem muito grandes, nem muito pequenos Os cones devem ser significativos, apropriados, coerentes, consistentes, claros, simples e definidos em pequeno nmero (no mais do que 20). Seu tamanho deve ser econmico em relao ao espao de tela. Dependendo de sua utilizao aconselha-se a adoo de bordas bem definidas. Diversos autores indicam a necessidade de um rtulo identificativo centrado na margem inferior, ou de bolhas de ajuda (tool-tips), uma pequena descrio de um objeto que aparece na tela ao se posicionar o cursor do dispositivo de apontamento sobre ele.
5.2.3.1.2 Cdigos de formas

Os cdigos de forma envolvem os sinais geomtricos construdos a partir de primitivas grficas (linha, arco, retngulo, etc.). Eles correspondem a uma da classe de sinais abstratos que para o sucesso na comunicao dependem do conhecimento mtuo das regras de codificao. Os crculos, quadrados, tringulos e retngulos so utilizados por exemplo, para codificar classes de eventos em grficos estatsticos. Aconselha-se no utilizar mais do que 15 opes de sinais geomtricos.
5.2.3.1.3 Denominaes

As denominaes utilizadas em uma interface humanocomputador constituem cdigos de expresso textual cujos os termos (sinais arbitrrios) so retirados da linguagem articulada pela populao de usurios em sua tarefa com o sistema. As regras de codificao desses termos so definidas, de modo mais ou menos formal, no ambiente de trabalho dos usurios. Assim, a linguagem textual da interface deve ser constituda de termos empregados no contexto de trabalho, portanto significativos e familiares para o usurio (linguagem operativa), alm de concisos.
5.2.3.1.4 Abreviaturas

As abreviaturas so diminutivos de denominaes que devem ser utilizadas somente quando absolutamente necessrio. Alm de suficientemente distintas entre si, elas devem ser curtas, claras e significativas.

73

5.2.3.1.5

Cdigos alfanumricos

Os cdigos alfanumricos so cdigos de expresso textual que constituem sinais arbitrrios cujas possibilidades tanto em termos de contedo como de expresso so definidas por regras de codificao. As consideraes sobre os valores a adotar para cdigos alfanumricos arbitrrios indicam no utilizar valores maiores do que 4 ou 5 caracteres. Se isto for inevitvel deve-se recorrer a pontuaes e sub-grupamentos. O limite para cdigos alfabticos arbitrrios de 7 a 10 letras. No caso de cdigos alfanumricos deve-se procurar arranjar letras e nmeros em grupos separados, como forma de evitar combinaes perigosas entre caracteres semelhantes.
5.2.3.1.6 Cdigos de cores

O emprego das cores na concepo de interfaces humanocomputador tem sido alvo de numerosas recomendaes ergonmicas. Elas aconselham o uso de cores para transmitir informaes, chamar a ateno, contrastar e associar objetos de interao. O uso puramente decorativo desaconselhado. Para que sua utilizao seja eficaz, deve-se tomar cuidado com trs aspectos: (i) a legibilidade final da informao; (ii) com os efeitos das cores sobre a performance cognitiva do usurio e; (iii) com as possibilidades dos dispositivos fsicos. Estas precaues visam conter a confuso visual resultante do emprego arbitrrio e exagerado de cores no pertinentes. O cdigo de cores deve prever na medida do possvel motivado e composto de um elenco reduzido e equilibrado de opes (no mais do que 10 ou 11 cores). Estas no devem estar associadas a mais do que um significado e deve respeitar os seguintes esteretipos naturais: o vermelho deve ser utilizado para perigo, alarme, ateno, alerta, calor e comandos de interrupo. o amarelo para advertncias, teste e lentido. o verde para passagem livre, normalidade, vegetao e segurana. o laranja para valor limite e radiao. o azul para frio, gua, cu e calma; o cinza para inatividade, neutralidade; o branco uma cor neutra. Cdigos arbitrrios expressos a partir de cores devem ser claramente indicados aos usurios atravs de uma legenda.

74

As variaes de cores, definidas a partir da luminosidade e do contraste no podem ser mais do que trs e devem respeitar os significados da cor principal. Altos nveis de contraste e de iluminao podem ser definidos para as cores utilizadas no destaque de dados importantes. Devido a coabitao de dispositivos fsicos coloridos e monocromticos, a cor no deve ser utilizada como nica forma de uma expresso. Assim, os projetista devem fazer a definio de uma forma alternativa e redundante para o significado corrente.
5.2.3.1.7 Cdigos de fontes

O estilo complementa as capacidades em termos de transmisso de informao das formas textuais. Os recursos desta classe incluem fontes, estilos e tamanhos. A utilizao do estilo como cdigo auxilia na compreenso dos elementos de um texto e deve ser empregado de maneira consistente. Segue abaixo alguns objetivos definidos para os tipos de fontes: Arial -> ttulos e cabealhos de documentos Avant Garde -> grandes ttulos Courrier -> documentos impressos, cartas padronizadas, correspondncia Helvtica -> relatrios, ttulos de captulos, de sees, cdigo de programas Letter Gothic -> texto que deve ser simples e claro Romano -> correio padronizado Times-> documentos diversos, de mltiplo uso, comentrios em programas Ultrablack -> etiquetas de embalagens Os recursos em termos de estilo devem ser usados com cautela, para discriminar ou destacar uma informao textual, incluindo caixa, negrito, itlico e sublinhado. O tamanho dos caracteres deve ser apropriado (18 a 24 para transparncias e 10 a 12 para trabalho normal) e permanecer inalterado na mudana de fontes.
5.2.3.1.8 Cdigos de Textura

A textura utilizada como codificao arbitrria na apresentao de grficos e mapas. As diferentes opes de textura podem ser empregadas tanto como escalas aditivas como substitutivas. Se utilizadas juntamente com palavras elas devem ser escolhidas de modo a no prejudicar a leitura.
5.2.3.1.9 Cdigos de vdeo reverso

O vdeo reverso uma codificao binria utilizada para o destaque de objetos, itens e opes selecionadas pelo usurio. Deve ser dada ateno especial na rea total de inverso, que
75

deve incluir os espaos vizinhos ao objeto, principalmente se tratando de palavras. As de inverses de textos coloridos em fundo colorido devem ter seu resultado final testado em termos do contraste entra letra e fundo.
5.2.3.1.10 Cdigos de intermitncia visual (pisca-pisca)

A intermitncia pode ser aplicada para o destaque em situaes excepcionais, em que o perigo de acidentes imponha um carter de urgncia. Esta codificao, essencialmente binria no deve ser aplicada a mais de um elemento de cada vez. A taxa de intermitncia pode variar entre 2 e 5 Hz. Na configurao de um objeto intermitente, o projetista deve prever um meio, associado a uma tecla, que permita ao usurio desativar a intermitncia.

5.2.4 As Primitivas
As formas para a expresso de um objeto de interao resultam da articulao de substncias de um contnuo perceptvel ao sistema cognitivo humano.

5.2.4.1 As formas visuais

As formas de expresses "visuais" incluem as formas grficas e textuais. A forma grfica envolvida com questes ergonmicas principalmente a cor, a fonte e o arranjo.
5.2.4.1.1 Cores

A Cor como forma uma forma empregada na expresso grfica de objetos de interao. Recomenda-se cuidado com o uso indiscriminado da cor. Primeiro faa o projeto em P&B e depois o colora com cuidado, usando cores neutras. Assim, use poucas cores, use cores com mesma luminncia (brilho) e use cores brilhantes com cautela. As cores podem causar sensaes sobre as pessoas. Sabe-se, por exemplo que o verde descansa, o vermelho: atrai a ateno e pode causar irritao, o azul d sono e o amarelo, ao contrrio, desperta as pessoas. Use cores de forma consistente e evite usar cores opostas no espectro em reas muito prximas Espectro/Arco ris:

76

5.2.4.1.2

Fontes

As consideraes sobre o emprego de fontes como forma esto envolvidas com o uso da serifa e o espaamento entre os caracteres. A serifa caracterizada por uma terminao saliente dos caracteres conforme ilustrada na primeira letra da figura abaixo. Fontes sem serifa so de percepo leve, mas de difcil leitura. Assim, nos ttulo e rtulos curtos deve-se empregar fontes sem serifa. Emprega-se fontes com serifa nos textos como forma de facilitar o reconhecimento rpido dos caracteres.

SS
No use serifa para vdeos de baixa resoluo. No use fontes menores do que 12 pontos para telas e 10 pontos para impressos. Limite o uso de fontes diferentes para textos (at dois tipos). Evite fontes muito grandes, que gritam com o usurio. Evite textos s com maisculas, e no exagere com o sublinhado, negrito e itlico
5.2.4.1.3 Bordas

A maior parte dos objetos de interao so delimitados por bordas, que desempenham papel importante na leveza desses objetos. Essa caracterstica pode ser assegurada atravs da natureza simples de seus traos e da distncia segura entre as bordas e textos em geral (denominaes, ttulos, cabealhos, rtulos, etc. )
5.2.4.1.4 Arranjo ou Layout

O arranjo a forma pela qual os itens de informao esto dispostos em uma janela, caixa de dilogo ou de mensagem. As recomendaes principais para um arranjo adequado so as seguintes: Defina um grid para o layout das telas. Defina alinhamentos para os elementos conforme as linhas e colunas do grid
77

 Defina focos de ateno (zonas de trabalho) agrupando os elementos interrelacionados. Monte uma estrutura, a partir das relaes (conexes) entre os elementos e coloque em evidncia o que for mais importante no grupo... (mais a esquerda, colorido,...) Distribua da esquerda para a direita em funo da importncia, da cronologia,.. D equilbrio as telas distribuindo os elementos de forma balanceada. Evite reas vazias ou altamente carregada de componentes Mantenha consistncia entre os layouts das telas.
5.2.4.1.5 Fundos ou Background

Os fundos de telas, janelas, caixas de dilogo ou de mensagens devem ser definidos com cores neutras (acromticas), que garantam um contraste adequado com os textos e rtulos em primeiro plano. recomendvel no carregar o fundo da tela com elementos grficos (para reas de trabalho e leitura). As cores e padres para os fundos podem ser usados para diferenciar tipos de telas/reas.

5.2.4.2 Formas sonoras

A classe "Forma Sonora" apresenta os atributos de expresso "timbre", e "freqncia", utilizados para destaque ou diferenciao do sinal sonoro. O timbre est ligado a natureza da entidade fsica que gera um som. A mesma nota musical em um piano ou em clarinete soam diferente devido a seus timbres particulares. A freqncia tambm denominada registro de um som, pode ser alta ou baixa relativamente as oitavas. Aconselhase a utilizao de tons da mesma oitava para evitar problemas de construo de sinais sonoros.

78

TERCEIRA PARTE: O CICLO DA ENGENHARIA DE USABILIDADE 6. Abordagem para a Engenharia de Usabilidade

O que ainda se verifica em muitos projetos de desenvolvimento atuais a adoo do famoso mtodo LIXE-SE2 o usurio. Os sistemas so simplesmente dotados de todas as funes e informaes possveis e imaginveis e o usurio que se adapte a ele para alcanar seus objetivos e satisfazer suas necessidades e expectativas. Em muitos casos, ele est longe de encontrar algo rpido de aprender, fcil, eficiente de usar ou mesmo, til em relao a seus objetivos. Em conseqncia da abordagem citada, as equipes primeiro concebem e projetam os aspectos internos do sistema (ligados a seu funcionamento) para depois conceber e projetar sua interface com o usurio. O contrrio poderia ocorrer quando do desenvolvimento de um software interativo. Neste tipo de sistema seria natural esperar que o projeto das interfaces fosse prioritrio, ocorrendo antes e condicionando as decises sobre o funcionamento do sistema. No s o mtodo mencionado, mas uma srie de outros mtodos populares em engenharia de software, considera o projeto da interface com o usurio baseado apenas no trabalho prescrito. As atividades reais, onde se verificam as diferentes estratgias de operao, em busca da economia ou da qualidade, as situaes de aprendizado, de resoluo de erros e incidentes no so consideradas. Finalmente, o projeto de IHC pensado independente de seu usurio, e sem que uma anlise de impacto sobre o seu trabalho seja realizada. Um novo sistema muitas vezes, entregue e imposto de forma inapelvel. De fato, a nova IHC pode e deve ser testada pelo usurio, antes mesmo que qualquer ato concreto de sntese tenha sido realizado. A analise de situaes de operao com sistemas que se paream com o sistema futuro vai revelar boas e ms solues, que podem ser reproduzidas, pois se tem a garantia de que funcionam. Caso se constate que no funcionam, estas solues sero descartadas e no se ter gasto tempo e dinheiro em seu desenvolvimento. Qualquer abordagem para a engenharia de usabilidade, deve privilegiar o desempenho do usurio em sua tarefa,
O nome LIXE-SE uma adaptao bem educada de outra expresso empregue informalmente pelo professor e pesquisador Silvio Meira (UFPE) ao provocar uma discusso sobre o projeto de IHC. 79
2

concebendo sistemas adaptados s suas caractersticas e a seus objetivos. Para assegurar tais caractersticas necessrio que o ciclo de desenvolvimento seja centrado no usurio. Isto , o envolvimento do usurio deve ser buscado na anlise, na concepo, no projeto, desenvolvimento, implantao e revises do sistema. Alm disso, a abordagem para a engenharia de usabilidade deve envolver o usurio e equipes multidisciplinares em um processo iterativo para o desenvolvimento, onde atividades de projeto e implementao ou prototipagem so seguidas necessariamente de testes do sistema com o usurio. uma garantia de que se esteja caminhando no espao aberto do projeto De equipes multidisciplinares para o projeto de IHC devem participar, segundo a norma ISO 13407 (Human-centered design for interactive system), os seguintes componentes: Usurios finais Gerentes/compradores Especialistas no domnio Engenheiro de Usabilidade Engenheiro de software Pessoal Marketing Especialistas em ergonomia /fatores humanos Pessoal de suporte/treinamento Ainda segundo a ISO 13407 o planejando da funo Engenharia de Usabilidade envolve as seguintes definies: Definir as atividades para a funo de Engenharia de Usabilidade; Definir as metas e objetivos das atividades da funo de Engenharia de Usabilidade; Definir os procedimentos para integrar as atividades da funo de Engenharia de Usabilidade com as outras atividades do desenvolvimento do sistema; Definir os responsveis pelas atividades funo de Engenharia de Usabilidade, suas competncias, habilidade e responsabilidades; Definir as maneiras de fornecer feedback e documentar as atividades realizadas;

6.1 O envolvimento do usurio no projeto

O envolvimento do usurio pode, se adequadamente conduzido, trazer importantes benefcios para o projeto, ligados principalmente a sua qualidade intrnseca e a sua aceitao pelo pblico-alvo. Esta a forma mais segura de garantir que o sistema ou produto de software desenvolvido atenda os requisitos explcitos e implcitos dos usurios, e assim, seja por eles aceito. Neste tpico so discutidas as formas de

80

envolvimento e a organizao necessria para garantir os bons resultados da participao do usurio no projeto.

6.1.1 As formas de envolvimento

A equipe de projeto que adota um enfoque centrado no usurio deve ter em mente os trs tipos bsicos de envolvimento possveis. Informativo Consultivo Participativo Assim se pode buscar do usurio as informaes necessrias para o projeto, atravs de tcnicas de entrevistas, questionrios ou de sua observao em seu trabalho. Neste tipo de envolvimento o usurio visto como fonte de informao. Pode-se tambm levar ao usurio as decises de projeto para que ele as verifique e emita uma opinio sobre elas. Neste caso se caracteriza como um envolvimento consultivo; o usurio consultado sobre decises de projeto. Este envolvimento tambm pode ser realizado atravs de entrevistas, questionrios e observao do usurio. Os objetos destas atividades so as diferentes verses da interface produzidas pela equipe de projeto. importante salientar que o usurio deve ser consultado com base no conhecimento que s ele possui sobre sua tarefa. Ele pode no possuir o conhecimento necessrio para julgar aspectos tcnicos da usabilidade de objetos de interao, por exemplo. O nvel mais elevado de envolvimento ocorre quando o projetista transfere ao usurio o poder de deciso no projeto. Aqui so empregadas tcnicas de brainstorming ou de sesses de arranjo e organizao, nas quais os usurios manifestam a sua perspectiva sobre determinados aspectos do sistema, como, por exemplo, a organizao modular ou o vocabulrio da interface. Cabe ao projetista planejar e realizar estas atividades e recolher e tratar adequadamente seus resultados. Aplicam-se aqui as mesmas observaes sobre que tipo de conhecimento deve amparar as decises do usurio. importante frisar que o envolvimento com o usurio se d como uma combinao destes diferentes nveis. Deve-se buscar informaes junto ao usurio, consulta-lo sobre decises de projeto e passar a ele o poder de tomar determinadas decises. Como ser abordado a seguir, esta postura exige uma mudana organizacional e cultural importante na empresa e na equipe de projeto.

81

6.1.2 Organizao para o envolvimento do usurio

O usurio de um sistema informatizado, atravs do qual realiza suas tarefas cotidianas, alm do proprietrio, a pessoa que mais conhece o sistema de produo onde ele est inserido. natural buscar repartir com ele o poder sobre muitas decises de projeto. Esta abordagem tem sido desenvolvida principalmente nos pases do norte europeu, onde se tornou obrigatrio por meio de acordos sindicais. A palavra de ordem democracia no projeto e para que os resultados ocorram em toda sua potencialidade, necessrio que se adote uma postura organizacional diferente. Desde a alta gerncia, at os membros da equipe de projeto, devem estar conscientes, preparados e engajados com esta mudana organizacional. Alm disto, iniciativas importantes devem ser tomadas para organizar os usurios por meio de uma estrutura prevendo usurios representantes, especialistas e finais. O usurio representante a figura central desta organizao. Ele deve ser escolhido com base no conhecimento sobre a tarefa e sobre o sistema, mas tambm devido a sua liderana e comprometimento para com os colegas, usurios finais do sistema. De modo a poder tomar decises de projeto, ele deve ser fornecido um treinamento especial para que compreenda os formalismos e tcnicas de descrio empregadas no projeto de interfaces. Ele deve assim, poder avaliar os impactos das alternativas de projeto sobre a tarefa, e exp-las em uma reunio com os colegas. Para isto, lhe deve ser assegurada disponibilidade de tempo para consultar colegas especialistas na tarefa e fornecido o poder de convocar reunies com os colegas usurios finais do sistema. Estes ltimos em particular, devem ter o poder de garantir de que as decises sigam o processo descrito acima. Estes cuidados visam evitar que o representante dos usurios assuma uma postura tecnicista, se transformando em mais um projetista, ou ao contrrio, se tornando seu refm. Neste caso, ele apenas assina a aprovao de alternativas de projeto que no consegue avaliar completamente. As diferentes tcnicas de envolvimento do usurio devem ser conhecidas e aplicadas da maneira mais adequada etapa corrente do desenvolvimento da interface humano-computador.

6.2 O ciclo da Engenharia da Usabilidade

A usabilidade desenvolvida atravs de um conjunto de atividades, que dependendo do paradigma para o ciclo de vida do produto, podem estar encadeadas de diversas formas: em cascata, em ciclos de prototipagem e testes, em espirais evolucionrias ou em diagonais de reutilizao.

82

A pertinncia de um modelo ou outro vai depender do contexto do desenvolvimento, em particular, do caracter inovador das propostas, do conhecimento do domnio do sistema, dos recursos e do tempo disponvel, da experincia de equipe, etc. Mas seja qual for o modelo escolhido, as atividades necessrias para o desenvolvimento pertencero a uma das trs categorias ou perspectivas principais : Anlise, Sntese e Avaliao.

Conforme o paradigma definido, as atividades ligadas a cada perspectiva estaro mais ou menos entremeadas ou estanques. Por exemplo, a etapa de anlise pode acontecer uma

83

s vez, para todo o sistema e pemanecer congelada pelo o resto do ciclo, ou diversas vezes, para cada mdulo ou aplicao e ter seus resultados revisados a cada ciclo de anlises. O mesmo ocorre com as atividades do ciclo de testes. Nos trs captulos que seguem se estar abordando as atividades pertencentes a cada uma das perspectivas : Anlise, Sntese e Avaliao.

84

7. A Perspectiva da Anlise
A perspectiva da Anlise se refere ao esforo para estabelecer uma compreenso de uma realidade ou contexto, muitas vezes, a partir da sua sub-diviso em sub-sistemas ou componentes (dividir para simplificar). Para o desenvolvimento da usabilidade, a anlise no s de uma situao existente, mas tambm de uma futura, assume importncia maior, uma vez que por meio destas atividades que se estabelece um foco e um processo de comunicao e de envolvimento do usurio no desenvolvimento. Quanto mais frequente e progressivo o processo de anlise, maior ser a qualidade nas decises de projeto. Para a usabilidade, a anlise enfoca basicamente os elementos do contexto de operao de um sistema, envolvendo: usurio (categorias, perfil, habilidades, necessidades) tarefa (objetivos, elementos, condicionantes, estrutura, atributos...) ambiente fsico, tcnico e organizacional (equipamento, software, iluminao, rudo, estilo de chefia, ...)

7.1 Definio do Escopo do Sistema

Todo o trabalho de desenvolvimento de um sistema informatizado deveria ter origem em uma definio de seu escopo. Nela so explicitados os principais requisitos funcionais e no funcionais e as restries sobre seu desempenho, segurana, equipamentos, etc. O projeto centrado no usurio deve prever nesta etapa, uma descrio ainda que preliminar do usurio-alvo ou usurio tpico do sistema e de suas tarefas principais. Estes descries serviro de baliza para um aprofundamento no usurio e na tarefa nas etapas subsequentes do desenvolvimento.

7.2 Anlise do Usurio

Qualquer que seja a abordagem do desenvolvimento, a primeira coisa a ser realizada a descrio e anlise das caractersticas da populao-alvo do novo sistema (os atores). Em um sistema podem existir, e em geral existem, dois tipos de usurios; as categorias de usurios que so operadores diretos do sistema, ai incluindo todos os que interagem com ele de forma mais ou menos assdua, e os indiretos como gerentes, supervisores, administradores, que so apenas responsveis pelo sistema. necessrio que as caractersticas das categorias de usurios diretos do sistema sejam identificadas com um nvel de detalhamento que permita conhecer:

85

categoria de uso faixa etria perfil profissional freqncia de uso experincia na tarefa experincia em tecnologia de informtica experincia em sistemas similares motivao

Populaes de usurios jovens vo exigir da interface do sistema uma aparncia e um comportamento bem diferentes do que fariam populaes de usurios idosos. O mesmo se verifica entre pessoas que usam frequentemente ou raramente um sistema, que tm experincia ou que esto iniciando na tarefa ou na informtica. Uma interface que serve pessoas que no tm bons salrios, nem um bom ambiente de trabalho ou perspectiva de crescimento profissional ser certamente mais solicitada do que uma que esteja a servio de pessoas motivadas e satisfeitas em seu trabalho. O conhecimento destas e outras caractersticas dos usurios so pertinentes para o processo e devem ser correlacionados com aspectos de sntese da interface.

7.3 Anlise do Trabalho

A realizao da anlise do trabalho para a especificao de um novo sistema justificada pela abordagem de conhecer para modificar. Com a descrio do trabalho atual, o analista pode avaliar quais so seus problemas efetivos (complexidade, frequencia, nivel de erros, gargalos) e formas de contorna-los com funes e operaes do futuro sistema. Esta anlise pode ser usada tambm para conhecer o trabalho futuro com sistemas que se assemelham ao novo sistema e testar as novas propostas, bem antes delas serem sequer projetadas e implementadas. Isso pode ser conhecido como anlise do trabalho com o estado-da-arte. A estrutura do trabalho atual ou do estado-da-arte pode servir de modelo do novo sistema, podendo ser modificada para acomodar as novas funcionalidades. Estaria-se assegurando assim, a compatibilidade entre antigas e novas tarefas e atividades, fato que sem dvidas, corresponde as expectativas reais dos usurios. O projeto da interface deve ser derivado de resultados das anlises realizadas. Por exemplo; as sequncias identificadas pela decomposio das tarefas atuais podem ser respeitadas no projeto do dilogo; as classificaes de tarefas existentes podem ser respeitadas no projeto de menus; a associao de objetos com aes atuais pode ser respeitada nos menus pop-up (um painel de menu com as possveis aes para um objeto); definio de aes e opes default podem ser

86

resultado da anlise da frequncia de uso, sequncia ou importncia na tarefa. A estrutura da tarefa pode ser usada tambm para organizar manuais e tutoriais visando o treinamento inicial do sistema. Ser uma garantia de que estes recursos estejam voltados para dar apoio a maneira como as pessoas devem utilizar o sistema. O objetivo da Anlise do Trabalho, (AT), segundo uma viso de usabilidade, de examinar um sistema produtivo a partir de suas dimenses tarefa e atividade, considerando sua dinmica e de suas lgicas de utilizao e de funcionamento (ver captulo 1). Para tanto, a AT prev atividades de coleta de informao, entrevistas e de observaes em duas etapas de anlise; anlise das tarefas e anlise das atividades. Uma etapa de anlise do abiente e de elaborao do relatrio da anlise encerra estas atividades.

7.3.1 Anlise das Tarefas

Esta etapa realizada por meio da anlise de documentao e de entevistas com os representantes dos usurios diretos e indiretos. Estes ltimos tem uma viso gerencial, muitas vezes terica e abstrata, dos objetivos e dos mtodos que os operadores devem buscar e empregar em seu trabalho. Esta viso geralmente formalizada pela empresa incluindo dados sobre as interligaes e os aspectos econmicos do sistema. Os operadores, por seu lado, possuem uma representao prpria de como realizar as tarefas que lhes so solicitadas. As representaes do trabalho de cada categoria de usurio, que so o alvo da anlise da tarefa.

7.3.1.1 Entrevistas com gerentes

Nas entrevistas com os gerentes deve-se tentar obter elementos teis sobre: representao do sistema; objetivos, procedimentos, regras de utilizao, restries, etc.; dados organizacionais: organizao do trabalho, ligaes entre os servios, quem opera o sistema, quais os turnos de trabalho; dados econmicos: custo do sistema, vantagens proporcionadas (onde e quanto, diretas/indiretas, prejuzos?). expecativas de informatizao: vantagens esperadas, de que ordem? (onde e quanto, diretas/indiretas).

87

7.3.1.2 Entrevistas com usurios

O encontro com o usurio que efetivamente realizam a operao do sistema ser certamente uma oportunidade de conhecer mais sobre : A representao que ele mesmo tem do sistema e de sua tarefa; objetivos, procedimentos, regras de utilizao, restries, etc.; a satisfao e as queixas em relao ao sistema atual; idias sobre oportunidades para o futuro sistema.

7.3.1.3 Descrio das tarefas

Nesta etapa, parte-se para obter uma descrio sobre a tarefa a ser realizada nos casos de uso principais, segundo os pontos de vistas dos atores: usurios e gerentes do sistema. Com uns e outros, so realizadas entrevistas dirigidas buscando evidenciar as caractersticas do processo de realizao da tarefa. Nesta etapa deve-se tentar obter uma descrio detalhando os elementos do contedo do trabalho, conforme propostos no tpico 1.4. Sucintamente, descreve-se blocos de tarefas a partir dos elementos: Objetivo ltimo a alcanar Decomposio em sub-tarefas/sub-objetivos; Relaes entre as sub-tarefas; Nomes, denominaes e definies das sub-tarefas; Objetivos a alcanar nas sub-tarefas; Mtodos que o operador utiliza em cada sub-tarefa Estados inicial e final do sistema para cada subtarefa; Pr- e ps-condies das sub-tarefas. A descrio interna dos blocos deve ser complementada por uma outra externa, mostrando um estrutura hierrquica de tarefas em diferentes nveis de abstrao, como a proposta pelo formalismo M.A.D. (Scapin, 1993). Esta descrio permite que se tenha uma compreenso geral sobre tarefas que se realizam de forma simultnea, paralela, seqencial e alternativa. Mostra tambm tarefas que se desenvolvem de modo repetitivo, as que so opcionais, as que so prioritrias ou que podem ser interrompidas. Como visto mais adiante, a descrio destes elementos ter fundamental importncia para o processo de reengenharia do trabalho a ser apoiado pela interface humanocomputador de um futuro sistema.

7.3.2 Anlise do Ambiente

Durante uma visita a realidade do trabalho atual e futura podem ser coletados dados gerais sobre o contexto de operao que iro repercutir sobre a sntese de uma interface humanocomputador:

88

layout geral iluminao rudo estado da tecnologia ferramentas de apoio

A repercuso dos fatores acima mencionados sobre a sntese da interface se refere, por exemplo, impossibilidade do emprego de entradas ou sadas sonoras, devido ao nvel de rudo ambiente.

7.3.3 Anlise das atividades

Nesta etapa so realizadas anlises que visam a validao das descries e informaes que foram coletadas e que compem as representaes sobre o trabalho. Para tanto esta etapa deve prever a realizao de observaes in-loco do trabalho do usurio. especialmente recomendado que seja solicitado aos operadores que verbalizem sobre quais os objetivos, critrios, diagnsticos e razes das decises tomadas. Pode-se prever meios de registro em vdeo, audio e um bloco de anotaes para capturar os aspectos citados em trs tipos de situaes; situao de normalidade, situaes consideradas crticas e situaes de erros e incidentes. Assim, a viso geral da tarefa pode ser complementada por um levantamento em termos das informaes envolvidas com as atividade. Desta forma devese conhecer quais so; as informaes necessrias e a ordem em que tornam-se disponveis; as informaes que so difceis de obter; as informaes que so inteis (no so utilizadas); as informaes que so impertinentes (que atrapalham e induzem a erros de interpretao). Tambm deve-se obter informao complementar sobre as atividades; quais so as mais frequentes quais so os horrios (durao) e modo de utilizao quais as deficincias, problemas e incidentes encontrados. Em particular deve-se identificar suas causas, condies de aparecimento, frequncia e os procedimentos para a sua recuperao.

7.3.3.1 Anlise de situaes de normalidade

A anlise de atividades normais feita atravs de observaes contnuas procurando abranger toda a durao do trabalho. Em especial deve-se confrontar a descrio da tarefa realizada na etapa anterior de anlise com o que realmente realizado pelo usurio em termos de objetivo ltimo a alcanar,

89

decomposio da atividade em sub-atividades/sub-objetivos, relaes entre as sub-atividades (sequenciais, paralelas, alternativas, facultativas, etc). Deve-se verificar em particular, os graus de dificuldades na realizao das atividades.

7.3.3.2 Anlise de Situaes Crticas

A partir do que foi levantado na etapa de anlise da tarefa, algumas situaes podem ser consideradas problemticas ou crticas e devem ser observadas com maior ateno. A observao destas situaes se faz ento por amostragem de perodos escolhidos. Nelas deve-se confrontar a descrio da tarefa prescrita com a atividade realizada pelo usurio em termos de mtodos empregados e do fluxo de informao nesta parte do sistema.

7.3.3.3 Anlise de situaes de Erros e Incidentes

As situaes de erros e incidentes so de difcil observao, tanto pela dificuldade de prever sua ocorrncia como pela dificuldade de seguir seu processo. Recomenda-se ento que sejam preparadas simulaes, in-loco (no local de trabalho) ou em laboratrio. Dependendo do sistema, as do primeiro tipo podem ser dispendiosas para empresa, operador e analista. Portanto sua realizao deve ser alvo de uma estudo custo X benefcio cuidadoso. Um outro tipo de simulao poder ser realizado em um cenrio fora da situao de trabalho. Uma situao hipottica deve ser apresentada verbalmente ao usurio que dever descrever os procedimentos para a recuperao da situao de normalidade.

7.3.4 A elaborao do Relatrio de Anlise

O relatrio de Anlise do Trabalho deve trazer a descrio detalhada e hierarquizada de tarefa e atividade de seus operadores. Ele deve prever um diagnstico das situaes problemticas e as solues possveis baseadas em recomendaes para a concepo da interface com o usurio do futuro sistema. Ele pode apresentar a seguinte estrutura: Identificao de tarefas e usurios; Descrio/modelagem da estrutura organizacional das tarefas atuais dos usurios, conforme formalismo M.A.D. Anlise das tarefas em termos de: complexidade, freqncia, nivel de erros, redundncia, gargalos, mobilidade dos usurios, interrupes Priorizao dos problemas e gargalos principais

90

7.4 Anlise das possibilidades e restries tecnolgicas

Esta anlise vai enfocar o ambiente tecnolgico onde a sntese da interface ser realizada. Em particular so examinados; O estilo geral da interface (WIMP, WEB, RV, etc.) As bibliotecas a serem empregadas na implementao As ferramentas de apoio implementao Uma anlise cuidadosa destes itens pode facilitar em muito a sntese de interfaces com usabilidade.

91

8. A Perspectiva da Sntese
O processo de sntese de uma interface com o usurio deve ser fruto de uma sequncia lgica de etapas. Mesmo um prottipo, a partir do qual a interface evolui, no aparece do nada, como pretendem os mtodos populares de engenharia de software. A lgica da perspectiva de sntese (especificao, projeto e implementao) de uma nova interface com o usurio, apresenta a seguinte estrutura de atividades: Especificao do contexto de uso para o qual a interface estar sendo desenvolvida Definio da nova estrutura do trabalho com o novo sistema, resultante da re-engenharia do trabalho atual; Especificao do desempenho em termos de usabilidade que a interface deve alcanar (incluindo especificaes quantitativas e qualitativas); Elaborao do projeto da interface; Especificao das regras para o projeto grfico para a interface;

8.1.1 Especificao do Contexto de Uso

O primeiro passo na perspectiva de sntese tornar explcito, a todos envolvidos no projeto, para qual contexto de uso a interface do sistema estar sendo desenvolvida. A norma ISO 9241:11 fornece um bom apoio a esta tarefa ao definir os componentes de um contexto de uso os usurios: os usurios, suas tarefas com o sistema, o equipamento (hardware, software e documentos) e os aspectos do ambiente fsico, social e organizacional, suscetveis de influenciar a usabilidade de um produto dentro de um sistema de trabalho. Esta especificao ir balizar todo o desenvolvimento e em especial, a montagem das condies nas quais os testes de usabilidade do sistema sero realizados. Ao realizar esta especificao, o analista de usabilidade tem a oportunidade de realizar as primeiras definies referentes aos estilos, componentes e processos da futura interface.

8.1.2 Definio da nova estrutura do trabalho

Para poder especificar a estrutura da futura tarefa (componente do contexto de uso) necessrio um processo de (re)engenharia do trabalho seja realizado. A decises sobre quem faz o qu, devem ser baseadas nas caractersticas cognitivas dos dois agentes envolvidos no sistema. Em relao ao ser humano, sabe-se que o computador apresenta enormes vantagens sob o ponto de vista de velocidade e preciso de tratamentos lgicos formais e
92

algortmicos, alm da capacidade superior de estocar e sincronizar a informao no tempo. Por outro lado, as pessoas so melhores para reconhecerem padres de comportamento, realizar julgamentos, de abstrair e de generalizar no processo de tomada de deciso. De qualquer forma, as tarefas que resultem para o usurio devem ter significado como um todo, e no ser apenas o que sobrou para ele, depois do que foi alocado para a mquina. Outro aspecto importante nessa etapa da concepo se refere ao controle das atividades e ao grau de automatizao que possa ser conferido execuo da tarefa interativa. Nesse sentido importante ressaltar a relao inversamente proporcional entre a alienao do processo e a capacidade do operador humano de decidir sobre ele. Tambm importante considerar a necessidade de flexibilidade na realizao da tarefa de controle. A atividade de re-engenharia do trabalho tem com ponto de partida o Relatrio de Anlise do Trabalho, conforme descrito no tpico 7.3.4, desta apostila. Deste relatrio recupera-se os seguintes elementos: Descrio da estrutura do trabalho com o sistema atual, segundo o formalismo M.A.D ; Identificao dos problemas e gargalos na estrutura do trabalho atual; Priorizao dos problemas e gargalos principais (os mais freqentes e os mais crticos) A partir destas informaes, o processo de re-engenharia se desenvolveria, de forma a envolver o usurio nas seguintes atividades: Definir para cada tarefa problemtica, diversas maneiras diferentes para sua realizao; Priorizar estas maneiras conforme desejo do usurio e viabilidade tcnica, definida pelos projetistas Definir uma nova estrutura da tarefa que represente maneiras desejadas e viveis para sua realizao;

8.1.3 Especificao da usabilidade esperada

A interface com o usurio comea a ser concebida na especificao da usabilidade que se pretende alcanar com o novo sistema. Isto deve ser feito de duas: quantitava e qualitativamente. A especificao quantitiva da usabilidade se refere aos aspectos da qualidade em uso ou de aceitao de um sistema. Segundo prope a norma ISO 9241:11, para um determinado contexto de operao, eles so os seguintes: Eficcia Eficincia
93

Satisfao

Na medida em que os resultados de testes de aceitao de usabilidade para diversos sistemas tenham sido registrados, a especificao do nvel de usabilidade poderia ser feita em termos relativos. Para o sistema em desenvolvimento, espera-se que o nvel de usabilidade esteja acima do verificado para o sistema atual. A anlise do contexto de operao do novo sistema permite que se especifique que tipo de usabilidade deve ser construda. Uma boa ferramenta para esta especificao qualitativa so os critrios ergonmicos definidos por Bastien & Scapin (1993) e apresntados no captulo 4 desta apostila. Por exemplo, se os usurios forem sempre novatos, a conduo uma qualidade importante para as interfaces. Se eles forem se tornar especialistas, a diminuio da carga de trabalho pode lhes ajudar bastante em suas atividades. Se ambos os tipos de usurios coexistirem, a felxibilidade da interface ser importante. Caso as tarefas apoiadas sejam de grande responsabilidade, a gesto de erros ir certamente ajudar em muito aos usurios.

8.1.4 O Projeto da Interface

As atividades de projeto da interface com o usurio visam definir formas de apoiar a realizao da futura estrutura de trabalho no contexto de uso definido para o sistema do sistema, relacionado com os tipos de usurio, as suas tarefas e o seu ambiente tcnico, organizacional e social. Mais especificamente, nesta etapa, o projetista realiza um detalhamento da especificao do contexto de uso, processo no qual so definidas as diferentes caractersticas das Interfaces HumanoComputador. Dentre as diversas abordagens para o projeto de IHC so apresentadas aqui duas bem conhecidas; a abordagem The Bridge, proposta por Tom Dayton e seus colegas da Bellcore (1996) e a abordagem Usage-Centered Design proposta por Cnstantine em seu livro Software for Use (1999).

8.1.4.1 The Bridge - Projeto de IHC orientado objetos.

Tom Dayton e seus colegas da Bellcore propuseram uma abordagem para o projeto de IHC, a partir de sua longa experincia no envolvimento de usurios neste tipo de atividade. A abordagem, chamada The Bridge (Dayton, McFarland & Kramer, 1996) est baseada em uma seqncia de sesses de projeto participativo, envolvendo usurios, engenheiros de usabilidade, engenheiros de software, programadores, que trabalham apenas com lpis, papel, cartes colantes e desenhos pr-impressos de janelas para juntos, construrem uma ponte (The Bridge) entre os requisitos dos usurios e da organizao e

94

o projeto de uma interface que apoie estes requisitos. A ponte possui trs passagens principais: Parte 1 Expressar requisitos do usurio em termos de um Fluxo de Tarefas Parte 2 Mapear os Fluxos da Tarefa em Objetos da Tarefa Parte 3 Mapear Objetos da Tarefa em Objetos de Interfaces
8.1.4.1.1 Parte 1 Fluxo de Tarefas

Nesta primeira etapa da abordagem, os projetistas e usurios realizam a definio de um (novo) fluxo de trabalho a ser executado pelo usurio com o novo sistema. Este descrito por um fluxograma apresentando blocos para o incio, para os processos e decises, assim como para o resultado esperado do trabalho. As descries nos blocos devem conter nomes, associados a objetos e atributos manipulados pelos usurios e verbos, associados as aes realizadas pelos usurios sobre estes objetos. Na figura a seguir apresentado um exemplo de fluxo de tarefa para o trabalho de check in em um hotel. .
Incio Hspede solicita a realizao de Check In Atendente Solicita o sobrenome do Hspede Atendente Encontra a reserva do usurio Atendente faz o check In (escolhe um quarto)

Resultado Hspede ocupa um quarto

Muito frequentemente, nesta etapa se faz a re-engenharia do fluxo de trabalho dos usurios de um sistema atual, j existente, conforme os passos apresentados no tpico 8.1.2 desta apostila, sobre a definio de uma nova estrutura do trabalho:
8.1.4.1.2 Parte 2 Mapear Fluxo da Tarefa em Objetos de Tarefa

Uma vez validados, os fluxos de tarefa so em seguida, analisados visando a definio de classes de Objetos de Tarefa. Estes, so definidos como unidades discretas de informao com as quais os usurios realizam a sua tarefa. Via de regra, correspondem a janelas, caixas de dilogo e caixas de mensagens vistas como as entidades de dados e funes de que os usurios necessitam para realizar suas tarefas. O processo de

95

definio de classe de objetos de tarefa est associado ao contedos das caixas que compem sua representao: Caixa de identificao da classe. Esta definio se d, comumente, a partir dos substantivos nas descries dos fluxos de tarefas; Caixas de propriedades: seu contedo definido a partir dos substantivos qualificadores que aparecem nas descrio de processos do fluxo de tarefas. As propriedades de uma classe de objetos podem ser de dois tipos: atributos da classe propriamente ditos, como nome e endereo de uma classe Hotel por exemplo, e seus componentes, que so outras classes de objetos que nela esto contidas, como por exemplo, a classe Quarto. Atributos e composies sero tratados de diferentes formas no mapeamento em objetos de interface (etapa seguinte).; Caixa das aes: Representam as aes que os usurios podem realizar sobre estes objetos, usando-os para realizar suas tarefas. Correspondem comumente aos verbos que aparecem nas descries dos fluxos de tarefas. Caixa das relaes de agregao entre objetos: Esta definio visa distinguir composies das quais uma classe faz parte e as classes de componentes que dela fazem parte. A composio de mais alto nvel o Desktop no ambientes windows.

HOTEL Coleo de quartos para alugar aos hspede Atributos Componentes Nome Quartos Layout Hspedes Quartos livres Ver Editar Salvar Estou em Desktop

Identificao

Propriedades

Aes Imprimir Possuo Quarto Hspede Relaes de Agregao

Algumas regras aplicveis as definies de classes de objetos so listadas abaixo:

96

 Se o conhecimento do usurio sobre o domnio da aplicao associa unidades de dados a objetos ento torne-os objetos. Ex; Catlogo telefnico; Se um usurio s vezes quer ver apenas poucos dos atributos de uma unidade, e as vezes quer v-los todos, ento a unidade pode ser um objeto e ser apresentado na interface, ora fechado (como um item de uma lista) e aberto (como uma janela); Um carto de objetos sem atributos indica que ele se refere a um atributo de outro objeto; Se existem diversas instncias de uma unidade de dado, e especialmente, o nmero de instncias que possam existir desconhecido, mas pode ser grande, ento esta unidade de dado pode ser um objeto; Se os usurios querem criar, excluir, mover e copiar a unidade de informao, ele esta tratando-a como faria com um objeto fsico, ento a unidade pode ser um objeto; Com o conjunto de classes de objetos de tarefa definidos, j possvel testar sua utilidade para o usurio, face os fluxos de tarefa definidos para o projeto.
8.1.4.1.3 Parte 3 Mapear Objetos da Tarefa em Objetos de Interfaces

Na terceira e ltima etapa da abordagem The Bridge, os projetistas mapeiam as composies de objetos de tarefa e seus atributos em composies e atributos de objetos grficos de interfaces com o usurio. Um especialista em estilo de usabilidade deve participar das sesses de trabalho para ajudar nas seguintes tomadas de deciso: Qual objeto de interface associar a um objeto de tarefa? Na maioria dos casos, os objetos de tarefa so mapeados como janelas grficas, primrias e secundrias, recebendo como identificao o contedo da caixa de identificao do objeto de tarefa. Como apresentar as propriedades dos objetos de tarefa (componentes e atributos) nos objetos de interface? Elas so apresentadas nas reas cliente das janelas de que fazem parte, de diferentes maneiras (nmeros, textos, imagens, cones, etc ),. Quais os comados para os objetos de interface? As opes de menu e os grupos de botes de comando das janelas so definidos a partir das caixas de aes dos objetos de tarefa. Nesta etapa, os projetistas definem e prototipam a parte principal das janelas que apoia os comandos mais relevantes face as vistas apresentadas. Os autores da abordagem The Bridge propem que detalhamentos maiores, envolvendo opes de menu, teclas

97

aceleradoras, mnemnicos, bolhas de ajuda, etc, sejam deixados para sesses das quais no participem os usurios. Segundo eles, estas sesses no so meios eficientes para definies detalhadas. Os prottipos dos objetos de interface definidos nesta etapa, devem ter sua usabilidade testada pelos usurios participantes das sesses de projeto.

8.1.4.2 Usage-Centered Design 1999)

(Constantine,

A abordagem para o projeto de IHC proposta por Constantine baseada em trs tipos de modelagens: Usurios e categorias relacionadas Estruturas de trabalho Arquitetura da Interface As arquiteturas de interface so evidentemente projetadas para satisfazer tipos especficos de usurios e estruturas de trabalho projetadas.
8.1.4.2.1 Usurios e categorias relacionadas

As categorias a serem consideradas como fonte de informao visando uma modelagem do usurio incluem: Usurios finais Consumidores e gerentes Especialistas no domnio, pessoal de treinamento, supervisores Informantes e interpretes pessoal de marketing, vendas, apoio tcnico, documentalistas Outras fontes de requisitos indiretas para a modelagem do usurio incluem manuais, questionrios, e qualquer outra forma de informao disponvel nas empresas. A principal componente do modelo de usurios o Papel de Usurio, definido como um conjunto abstrato de necessidades, interesses, expectativas, comportamentos e responsabilidades, caracterizando um relacionamento entre classes ou tipos de usurios e o sistema. Trata-se de uma abstrao que desempenhada por usurios que assumem um relacionamento com o sistema, como administradores, operadores, supervisores, alunos, professores, tutores etc.. Fundamentalmente, estas categorias de usurios tem acesso a diferentes conjuntos de funes e informaes do sistema, o que deve ser documentado no incio do projeto. Os papis podem ser desempenhados por mais de um usurio e um nico usurio pode assumir mais de papel. Um modelo de papis apresenta uma lista ou um mapa estruturado com todos os papis definidos

98

para um sistema. Um mapa de papis interrelaciona papis segundo uma hierarquia de classes de papis. Os papis mais importantes sob o ponto de vista de quantidade de usurios ou de sua responsabilidade frente a negcios, por exemplo, devem ser identificados e definidos como Papis Focais. Sobre eles se concentrar ateno especial no decorrer do projeto.
8.1.4.2.2 Estruturas de Trabalho

Para entender os componentes da abordagem de Constantine para modelagem de estruturas de trabalho, necessrio esclarecer alguns conceitos-chave, em particular Cenrios, Casos de Uso e Casos de Uso Essenciais Constantine define cenrio como uma descrio concreta e detalhada de uma seqncia particular de eventos em uma situao especfica, que se pretenda representativa de um tipo mais geral de interao. De maneira similar, Nilesen define cenrio como descrio auto-contida de um usurio individual interagindo com um subconjunto especfico de facilidades do sistema para alcanar resultados especficos sob condies especficas e dentro de um certo intervalo de tempo. Para Constantine, um caso de uso uma descrio narrativa da interao entre um usurio, institudo de algum papel, e alguma parte do sistema. Em OO, os casos de uso podem se referir tambm a interaes entre sistemas e equipamentos, mas para o projeto de IHC s interessem os envolvendo usurios e o sistema. Eles descrevem vises externas de alguma funcionalidade fornecida pelo sistema e que aparece como uma caixa-preta. Os casos de uso so parte da especificao de requisitos de um sistema e diferem dos cenrios, no sentido em que so abstraes de padres gerais, extrados de exemplos especficos. Um exemplo de caso de uso mostrado a seguir. Pegando Dinheiro AES DO USURIO RESPOSTA DO SISTEMA --------------------------------------------------------------------------------------insere o carto l o carto solicita ID entra ID verifica ID mostra menu de transaes pressiona tecla mostra menu da conta pressiona tecla solicita montante entra montante

99

mostra montante pressiona tecla devolve o carto pega o carto entrega o dinheiro pega o dinheiro --------------------------------------------------------------------------------------Constantine prope modelar o trabalho a partir de Casos de Uso Essenciais, definidos como uma narrativa estruturada, expressa em termos de linguagem do domnio da aplicao e do usurio, compreendendo uma descrio simplificada, generalizada, abstrada e livre de detalhes de tecnologia e de implementao, de uma tarefa ou de uma interao bem definida, do ponto de vista dos usurios em algum papel ou papis face o sistema, e que incorpora os objetivos ou intenes subjacentes interao. Um exemplo de caso de uso essencial mostrado a seguir. Pegando Dinheiro INTENES DO USURIO RESPONSABILIDADES DO SISTEMA --------------------------------------------------------------------------------------Identificar-se Verificar a identificao Oferecer opes escolher fornecer o dinheiro pegar o dinheiro --------------------------------------------------------------------------------------A modelagem do trabalho com o futuro sistema se refere a identificar e descrever estes casos de uso essenciais e de elaborar uma viso estruturada dos inter-relacionamentos observados entre eles, em Mapa de Casos de Uso. Um Mapa de casos de uso a repartio da funcionalidade total do sistema em colees de casos de uso ligadas por relaes de especializao, extenso, composio e afinidade. Um uma Especializao, os casos de uso so tipos de outros. Observe o exemplo onde retirarDinheiro ou DepositarDinheiro so tipos da interao UsarMaquina.
Usando Mquina Especializa

Retirando Dinheiro

Depositando Dinheiro

Verificando Estatus Especializa Verificando Saldo 100

Por uma relao de Extenso, um caso de uso estende um outro bsico, que passa a apresentar padres inseridos ou substitudos. Veja o exemplo no qual Alterando Imagem estendido pelo caso de uso Browsing Imagem. Alterando Imagem INTENES DO USURIO RESPONSABILIDADES DO SISTEMA --------------------------------------------------------------------------------------Solicita Alterao Mostra imagens apropriadas Seleciona Imagem Mostra Preview Confirma Fecha --------------------------------------------------------------------------------------O caso de uso Browsing Imagens poderia ser til em situaes onde os arquivos disponveis no sejam os que o usurio quer. Empregando a extenso de caso de uso Browsing Imagens, a narrao do caso de uso bsico (Alterando Imagem) permaneceria simples.
Alterando Imagens Browsing Imagens estende

Na relao de Composio uma interao representada pelo super caso realizada empregando as interaes definidas dentro de sub casos de uso. No exemplo que segue, o super caso de uso Iniciando Login formado a partir de Autorizando Acesso e Entrando Parmetros.
Iniciando Login Autorizando Acesso emprega Entrando Parmetros

A relao de Afinidade serve para as muitas situaes nas quais conjuntos de casos de uso mantm relaes, no muito bem definidas, com outros casos de uso.
Verificar Status Retirando dinheiro Transferindo fundos Depositando fundos

parece

101

Afinidade representa relaes evidentes, porm ambguas e no muito claras, de similaridade entre casos de uso. Elas so especialmente teis nas fases iniciais de projeto e nos diagramas, as classe com afinidades aparecem levemente sobrepostas, ligadas por linhas tracejadas. Em contraposio a classes que no se assemelham aparecem distanciadas no diagrama de caso de uso. Antes de encerrar o diagrama de casos de uso, necessrio indicar um ou mais casos de uso focais, que so o foco da ateno ao redor dos quais a interface ou algum parte sua, ser organizada. Os casos de uso focais para o sistema como um todo, incorpora os casos de usos mais importantes, centrais e representativos para seu usurio. Eles so representados nos diagramas de casos de uso como elipses com bordas duplas.
8.1.4.2.3 Arquitetura da Interface

A definio de uma arquitetura da interface capaz de apoiar usurios e os casos de uso definidos at agora no projeto feita pela elaborao de dois modelos. Modelo de Contedo da Interface Mapa de navegao entre contextos
8.1.4.2.3.1 Modelo de Contedo da Interface

As pessoas realizam tarefas em uma srie de contextos interconectados e especialmente montados com as ferramentas e materiais necessrios. Boas interfaces so organizadas de modo a fornecer todos os contextos de interao, de que o usurio necessita. Os contedos de contextos de interao so ferramentas, materiais e os espaos necessrios para mante-los, assim, o modelo de contedo de uma interface uma apresentao interna, de contedos de vrios contextos de interao e externa, das interconexes entre os contextos. O modelo de contexto deriva do modelo de casos de uso, pela regra geral de que cada caso de uso ser apoiado por um prprio contexto de interao. Os componentes abstratos dos modelos de contedo so ferramentas abstratas, que fornecem as funes e os materiais abstratos, que fornecem os dados, os componentes de dados, as apresentaes, e as reas de trabalho sobre as quais as ferramentas devem ser operadas. O processo de modelagem do contedo inicia-se pela analise das narrativas validadas de casos de uso, linha por linha, de modo a identificar quais ferramentas e materiais tero que ser

102

fornecidos de forma a que o usurio seja capaz de realizar a interao. Neste processo, inicialmente so definidos os materiais necessrios. Na seqncia, os casos de uso essenciais so revistos em busca das ferramentas e operaes necessrias. Os materiais e as ferramentas identificados so listados no modelo de contedo do espao de interao. Uma descrio de sua forma e comportamento pode ser adicionada, como forma de avanar sobre decises do modelo de implementao. Estes j podem ser agrupados de modo a refletir o modo como eles devem provavelmente ser usados ou faam mais sentido ao usurio. As ferramentas devem ser agrupadas parte, sugerindo uma barra de ferramentas, por exemplo. Segundo Constantine, no necessrio, nem prtico tentar definir solues de layout usando o modelo de contedo. Isto ser feito mais adiante, por meio do modelo de implementao. Cada espao abstrato de interao ir se tornar uma tela, janela ou caixa de dilogo que precisa ser entendida pelo usurio e cada mudana de contexto deve corresponder uma mudana de pensamento no usurio.
8.1.4.2.3.2 Mapa de navegao entre contextos

Um mapa de navegao na verdade, um diagrama de transio de estados, onde os espaos de interao so representados por retngulos e as transies so representadas por flechas conectando espaos. Caixa de dilogo ou de mensagem, ou qualquer contexto de interao

Tela ou Janela

Pginas de informao

Os mapas de navegao explicitam um dos mais importantes compromissos no projeto da arquitetura da interface com o usurio, que envolve a deciso entre limitar o contedo de cada espao de interao mantendo-os pequenos e simples, ou limitar o nmero deles, aumentando a complexidade de cada um. A primeira soluo pode ser aparentemente boa para usurios novatos, mas pode aborrecer usurios experientes impondo-lhes excessivas transies entre espaos de interao. A segunda pode favorecer usurios experimentados, mas sobrecarregar usurios novatos.

103

8.2 Consideraes sobre o Projeto de IHC

At a algum tempo atrs, as abordagens para o desenvolvimento de IHC eram se baseados em ciclos de prototipagens rpidas e testes com o usurio. Esta estratgia, apesar de vlida, no explicitava o processo pelo qual os prottipos eram gerados. Afinal, como surgem os prottipos? Vale a pena gastar tempo e recursos fazendo o projeto de uma interface (como os descritos aqui) antes de prototip-la? Como ficou registrado em diversos comentrios durante a descrio do processo de projeto de IHC, ele permite que se avaliem as alternativas de maneira precoce e isolada. possvel avaliar a intuitividade e a carga de trabalho de interaes, sem que qualquer desenho ou implementao tenha sido feita. O mesmo ocorre com a densidade informacional de telas das quais se sabe apenas a lista de componentes. Cada verso do projeto apresenta por outro lado, uma natureza especfica, que pode ser avaliada isoladamente. O mesmo no ocorre com prottipos, em cuja avaliao aparecem solues resultantes de diversos projetos (dos fluxos de tarefas, dos objetos de tarefas e dos objetos de interao e dos caminhos da interface) reunidas em uma coisa s. evidente que o tempo e os recursos necessrios para realizar este projeto so argumentos a favor de uma prototipagem pura e simples. Ainda mais se possvel partir da algo que j exista e que seja parecido com o que se quer para a futura interface. Mas, a exemplo do ncleo funcional, a interface com o usurio merece ter seu processo de projetao documentado, mesmo que este envolva solues reutilizveis. O gasto de tempo e recursos pode ser bastante diminudo na medida em que um ambiente informatizado venha a apoiar este processo, propondo editores, bibliotecas de diversos nveis de componentes orientadas a objetos e a reutilizao. Por outro lado, o projeto de interfaces humano-computador deve ser apoiado por regras de mapeamento e configurao de objetos de interao compiladas em guias de recomendaes e de estilo. Enquanto o primeiro refere-se a solues para componentes e contexto de operao abstratos ou gerais, um guia de estilo trs propostas de solues mais concretas para uma interface de um determinado tipo e em um ambiente tecnolgico definido. O guia de recomendaes abordar formulrios de diversos tipos, sem se prender a um em particular ou a uma plataforma especfica. Um guia de estilo mostrar como construir formulrios combinados com tabelas e mquinas de busca na plataforma JAVA, por exemplo, uma vez que estes so o tipo de aplicao e a tecnologia da empresa. O captulo 5, sobre componentes de interface, representa um guia de recomendaes til como conhecimento de base para qualquer projeto. Para apoiar o projeto grfico, especificamente,

104

recomenda-se a leitura dos itens 5.2.4 sobre as primitivas grfica a serem usadas no projeto de IHC. So elas: cones Fontes Textos Layout Cores Backgrounds Finalmente, importante salientar que as etapas de definies dos elementos do projeto de uma interface em qualquer abordagem, podem ser realizadas segundo duas sequncias diferentes. Largura primeiro, pela qual se esgota cada etapa de definies completamente, antes de passar prxima. So definidas todos os fluxos de tarefas, depois todos os objetos de tarefa, depois todos os objetos de interao. Profundidade primeiro, pela qual so realizadas todas as etapas de definio dos elementos de uma determinada tarefa. So definidas os fluxos, objetos de tarefa e os objetos de interao associados apenas a uma parte da estrutura de interaes. Depois so definidos os elementos de uma outra parte da estrutura, e assim por diante.

105

9. A Perspectiva da Avaliao
A usabilidade definida pela norma ISO 9241 como a capacidade que apresenta um sistema interativo de ser operado, de maneira eficaz, eficiente e agradvel, em um determinado contexto de operao, para a realizao das tarefas de seus usurios. Assim, a avaliao de usabilidade de um sistema interativo tem como objetivos gerais (i) validar a eficcia da interao humano-computador face a efetiva realizao das tarefas por parte dos usurios, (ii) verificar a eficincia desta interao, face os recursos empregados (tempo, quantidade de incidentes, passos desnecessrios, busca de ajuda, etc.)e (iii) obter indcios da satisfao ou insatisfao (efeito subjetivo) que ela possa trazer ao usurio. Estes objetivos devem ser pensados em relao aos diferentes contextos de operao previstos para o sistema. A usabilidade de um sistema est sempre associada as caractersticas de determinados tipos de usurios, tarefas, equipamentos e ambientes fsicos e organizacionais. Assim, um problema de usabilidade pode se fazer sentir fortemente em determinados contextos de operao e ser menor ou mesmo imperceptvel, em outros.

9.1 Problema de usabilidade

Um problema de usabilidade ocorre em determinadas circunstncias, quando determinada caracterstica do sistema interativo, acaba por retardar, prejudicar ou mesmo inviabilizar a realizao de uma tarefa, aborrecendo, constrangendo ou at traumatizando a pessoa que usa o sistema interativo. Deste modo, um problema de usabilidade se revela durante a interao, atrapalhando o usurio e a realizao de sua tarefa, mas tem sua origem em decises de projeto equivocadas. Conforme os termos da definio acima proposta, um problema de usabilidade deve ser descrito a partir de informaes sobre: o contexto de operao onde o problema pode ser encontrado, os efeitos possveis sobre o usurio e sua tarefa, a incluindo a freqncia com que este problema/contexto se manifesta.

9.1.1 Contexto de um problema de usabilidade

O contexto de um problema de usabilidade caracterizado por determinados tipos de usurios, realizando determinadas tarefas, com determinados equipamentos e em determinados

106

ambientes fsicos ou organizacionais, para os quais a usabilidade do sistema diminuda. Para efeito do raciocnio sobre usabilidade, as caractersticas do sistema devem ser examinadas sem perder a perspectiva de que usurios mais velhos esto sujeitos a problemas de acuidade visual e de controle manual e que uma porcentagem considervel dos homens esto sujeitos a cegueira s cores (principalmente o verde e o vermelho). importante tambm considerar as dificuldades que tero na realizao da tarefa informatizada as pessoas em formao profissional (na prpria tarefa), as novatas na informtica, ou as que se valem do sistema de forma eventual. Com o mesmo objetivo interessa saber que equipamentos em mau estado de conservao, podem diminuir a legibilidade das apresentaes e induzir acionamentos involuntrios, por exemplo. Interessa tambm saber que a presso temporal pode induzir o usurio a erros em tarefas complexas e mal estruturadas, e que este ser sempre uma espcie novato na realizao de tarefas espordicas.

9.1.2 Efeitos de um problema de usabilidade

Os efeitos de um problema de usabilidade se fazem sentir diretamente sobre o usurio e indiretamente sobre sua tarefa. Assim, por exemplo, efeitos sobre o usurio como uma sobrecarga perceptiva (dificuldade de leitura), cognitiva (desorientao ou hesitao) ou fsica, (dificuldade de acionamento) podem levar a efeitos sobre sua tarefa como perda de tempo, falhas ou perda de dados.

9.1.3 A descrio de um problema de usabilidade

Com base no que foi exposto acima prope-se um formato para a descrio de um problema de usabilidade, como o apresentado no exemplo que segue: Identificao do problema: cones pequenos; Descrio: Os cones que rotulam os botes de comando que participam da barra de ferramentas so muito pequenos. Tipo de usurio considerado: pessoas com problemas de acuidade visual e de coordenao motora Tipo de equipamento considerado: em mau estado de conservao Tipo de tarefa considerado freqente; Efeito sobre o usurio: dificuldade de leitura /sobrecarga motora/acionamentos involuntrios Efeito sobre a tarefa: perda de tempo e sobre-carga de trabalho do usurio para acionar uma opo devido a necessidade de maior preciso no movimento com o mouse

107

Sugesto de melhoria: Aumentar a rea de apresentao dos cones e a rea sensvel dos botes icnicos.

Cabe ressaltar que nesta proposta de formato, os problemas de usabilidade sero identificados por sua origem no projeto da interface, e no por suas conseqncias durante a interao.

9.1.4 Tipos de problemas de usabilidade

Com base em algumas combinaes entre a natureza do problema, o tipo de usurio que ele prejudica e seus efeitos sobre a usabilidade das funes do sistema, pode-se propor o seguinte sistema de classificao: Uma anlise da natureza de um problema de usabilidade permite classific-lo como uma barreira, um obstculo ou um rudo. Barreira: se refere a um aspecto da interface no qual o usurio esbarra sucessivas vezes e no aprende a suplant-lo. Uma barreira voltar a se apresentar ao usurio na prxima realizao da tarefa, comprometendo fortemente seu desempenho e fazendo com que ele desista de usar uma funo do sistema. A presena de barreiras na interface implica em prejuzos definitivos, que dependendo da tarefa e usurio, podem inviabilizar economicamente o sistema. Obstculo: se refere a um aspecto da interface no qual o usurio esbarra e aprende a suplant-lo. Em funo do obstculo, as prximas realizaes da tarefa se daro custa de uma perda de desempenho. A presena de um obstculo implica na acumulao de prejuzos para os que operam e para os que adquiriram o sistema; Rudo: se refere a um aspecto da interface que, sem se consistir em barreira ou obstculo ao usurio, causa uma diminuio de seu desempenho na tarefa. Em funo de rudos na interao o usurio pode desenvolver uma m impresso do sistema (aspecto subjetivo); A partir do tipo de tarefa em que ele se manifesta, o problema de usabilidade pode ser classificado como principal ou secundrio. Principal: um aspecto da interface que compromete a realizao de tarefas freqentes ou importantes. Secundrio: um aspecto da interface compromete a realizao de tarefas pouco freqentes ou pouco importantes.

108

Com base no tipo de usurio que afeta, um problema de usabilidade pode ser classificado como geral, inicial, definitivo e especial. Geral: um aspecto da interface que atrapalha qualquer tipo de usurio durante a realizao de sua tarefa. De iniciao: um aspecto da interface que atrapalha o usurio novato ou intermitente durante a realizao de sua tarefa. Avanado: um aspecto da interface que atrapalha o usurio especialista durante a realizao de sua tarefa; Especial: um aspecto da interface que atrapalha tipos de usurios especiais (portadores de deficincia) durante a realizao de sua tarefa, mas que os outros so capazes de suplantar, sem prejuzos para sua tarefa. importante citar a existncia de duas categorias de problemas, ortogonais em relao ao sistema de classificao proposto, que salientam os possveis efeitos de uma reviso de projeto equivocada. Elas se referem ao falso e ao novo problema de usabilidade. Falso: refere-se a um aspecto da interface que, apesar de classificado como problema, na realidade no traz qualquer prejuzo ao usurio, nem a sua tarefa. Tratase de um engano provocado pela falta de experincia do avaliador ou de uma deficincia em sua ferramenta de avaliao; Novo: um aspecto da interface que representa um obstculo, devido a uma reviso de usabilidade equivocada; A anlise de causas e efeitos de um problema de usabilidade permite algumas concluses sobre a severidade deste tipo de problema. Por exemplo, um problema verificvel para qualquer tipo de usurio , logicamente, mais prioritrio que um outro que se verifique somente para alguns tipos de usurios (usurio novato na operao, novato na tarefa, c/ problemas visuais, com idade avanada, etc.). Por seu lado, pode-se considerar tambm prioritrio o problema de usabilidade que possa causar perda de tempo em tarefas com elevada freqncia de realizao ou o que cause falhas ou perda de dados em tarefas de elevada importncia.

9.2 Objetivos de uma avaliao de usabilidade

As atividades ligadas a esta perspecitva do ciclo de engenharia de usabilidade visam identificar, seja por prospeco, diagnstico ou observao, os problemas de usabilidade em interfaces humano-computador e contribuir para a sua

109

eliminao. Assim, no desenvolvimento de sistema interativo, um engenheiro-avaliador de usabilidade ter como primeira tarefa a elaborao de um Plano de Testes de Usabilidade, no qual propor a realizao de uma sequncia estrutrada de avaliaes de usabilidade, uma para cada verso do sistema. Entre os objetivos a serem atingidos, constam pelas avaliaes constam: constatar, observar e registrar, problemas efetivos de usabilidade durante a interao; calcular mtricas objetivas para eficcia, eficincia e produtividade do usurio na interao com o sistema; diagnosticar as caractersticas do projeto que provavelmente atrapalhem a interao por estarem em desconformidade com padres implcitos e explcitos de usabilidade; prever dificuldades de aprendizado na operao do sistema; prever os tempos de execuo de tarefas informatizadas; conhecer a opinio do usurio em relao ao sistema; sugerir as aes de re-projeto mais evidentes face os problemas de interao efetivos ou diagnosticados.

Com base nestes resultados podemos distinguir trs tipos de tcnicas de avaliao ergonmica; as Tcnicas Prospectivas, que buscam a opinio do usurio sobre a interao com o sistema, as Tcnicas Preditivas ou diagnsticas, que buscam prever os erros de projeto de interfaces sem a participao direta de usurios e as Tcnicas Objetivas ou empricas, que buscam constatar os problemas a partir da observao do usurio interagindo com o sistema.

9.3 Tcnicas Prospectivas

Este tipo de tcnica est baseada na aplicao de questionrios/entrevistas com o usurio para avaliar sua satisfao ou insatisfao em relao ao sistema e sua operao. Ela mostra-se bastante pertinente na medida em que o usurio a pessoa que melhor conhece o software, seus defeitos e qualidades em relao aos objetivos em suas tarefas. Nada mais natural em buscar suas opinies para orientar revises de projeto. Muitas empresas de software elaboram e aplicam regularmente este tipo de questionrio, como parte de sua estratgia de qualidade. Alguns questionrios de satisfao encontram-se disponveis na internet como o QUIS Questionaire for User Interaction Satisfaction - Univ. Maryland (Norman, 1989) (http://www.lap.umd.edu/QUIS/index.html) importante salientar que os questionrios de satisfao tm uma taxa de devoluo reduzida (mximo 30% retornam), o que indica a necessidade de elaborao de um pequeno nmero

110

de questes sucintas. Um espao para opinies e sugestes livres deve sempre ser proposto ao usurio. Por outro lado, este tipo de tcnica pode ser empregada para aumentar a efetividade de avaliaes analticas, realizadas por especialistas que diagnosticam problemas de usabilidade. Apoiados pelas respostas de questionrio de satisfao estes podem centrar suas anlises sobre os pontos problemticos no sistema, apontados pelo usurio. ISONORM (Prumper, 1999) um questionrio de satisfao que tem o objetivo de direcionar a aplicao da norma ISO9241-10 somente aos quesitos apontados como problemticos pelo usurio atravs de ISONORM.

9.4 Tcnicas Preditivas ou Diagnsticas

As tcnicas diagnsticas dispensam a participao direta de usurios nas avaliaes, que se baseiam em verificaes e inspees de verses intermedirias ou acabadas de software interativo, feitas pelos projetistas ou por especialistas em usabilidade. Elas podem ser classificadas como: Avaliaes Analticas Avaliaes Heursticas Inspees por Checklists As avaliaes analticas envolvem a decomposio hierrquica da estrutura da tarefa para verificar as interaes propostas. As tcnicas de verificao conhecidas como avaliaes heursticas se baseiam nos conhecimentos ergonmicos e na experincia dos avaliadores que percorrem a interface ou seu projeto para identificar possveis problemas de interao humano-computador. As inspees por checklists tm esse mesmo objetivo, mas dependem do conhecimento agregado ferramenta de inspeo, uma vez que se destinam a pessoas sem uma formao especfica em ergonomia.

9.4.1 Avaliaes Analticas

Esse tipo de tcnica empregado nas primeiras etapas da concepo de interfaces humano-computador, quando ela no passa de uma descrio da organizao das tarefas interativas. Mesmo nesse nvel, j possvel verificar questes como a consistncia, a carga de trabalho e o controle do usurio sobre o dilogo proposto e de realizar modifica. A especificao da futura tarefa interativa, pode ser realizada nos termos de um formalismo apropriado como MAD, GOMS (Goals, Operators, Methods and Selections rules) e CGL (Command Grammar Language). Em particular, GOMS prope uma tabela associando tempos mdios de realizao aos mtodos primitivos, que correspondem a primitivas de aes fsicas ou cognitivas. Com

111

base nesta tabela e na descrio da tarefa realizada segundo o formalismo possvel calcular os tempos provveis para a realizao das tarefas previstas.

9.4.2 Avaliaes Heursticas

Uma avaliao heurstica representa um julgamento de valor sobre as qualidades ergonmicas das interfaces humanocomputador. Essa avaliao realizada por especialistas em ergonomia, baseados em sua experincia e competncia no assunto. Eles examinam o sistema interativo e diagnosticam os problemas ou as barreiras que os usurios provavelmente encontraro durante a interao. As avaliaes heursticas abordadas nesta enfocam os seguintes aspectos: Usabilidade em geral Intuitividade (Inspeo Cognitiva) Gesto de erros (Inspeo Preventiva) apostila

9.4.2.1 Avaliaes Heursticas de Usabilidade

Neste processo os avaliadores baseiam-se em heursticas ou ou padres de usabilidade gerais, prprios ou desenvolvidos por especialistas na rea. No momento atual, podem ser citadas conjuntos de heursticas como: Os Critrios Ergonmicos, propostos por Scapin e Bastien (1993), e apresentados no captulo 4 desta apostila; As Heursticas de Usabilidade, propostas por Jacob Nielsen, em seus livros sobre Engenharia de Usabilidade; Os Princpios de Dilogo, propostos pela norma ISO 9241:10, apresentados no captulo 10 desta apostila. As avaliaes heursticas de usabiliade podem produzir timos resultados, em termos da rapidez de avaliao e da quantidade e importncia de problemas diagnosticados. Entretanto, seus resultados dependem da competncia dos avaliadores e das estratgias de avaliao por eles empregadas. Acabam sendo subjetivas, exigindo um grupo razovel de avaliadores de usabilidade, de modo a identificar a maior parte dos problemas ergonmicos das interfaces (Jeffries et al, 1991). Pollier (1993) registrou a dinmica da avaliao de um sistema interativo por especialistas em ergonomia de software, para analisar seus resultados e principalmente suas estratgias de ao. Abordagem por objetivos dos usurios: o avaliador aborda a interface a partir de um conjunto de tarefas e sub-tarefas principais dos usurios ou das relacionadas aos objetivos principais do software;

112

 Abordagem pela estrutura de interface; por esta estratgia, especialmente direcionada para dilogos por menu, o avaliador aborda a interface como uma rvore de menu com nveis hierrquicos e das aes que permitem as transies de um nvel a outro. Dois encadeamentos so possveis nessa estratgia; exame por profundidade ou largura da rvore; Abordagem pelos nveis de abstrao; o avaliador aborda a interface como um modelo lingstico estruturado em camadas de abstrao (ver tpico 5.1) que podem ser examinadas em dois sentidos; top-down ou bottom-up; Abordagem pelos objetos das interfaces; o avaliador aborda a interface como um conjunto de objetos (cap 5); Abordagem pelas qualidades das interfaces: o avaliador aborda a interface a partir das qualidades ou heursticas de usabilidade que elas deveriam apresentar (cap. 4). Atravs do estudo, a autora verificou que, embora as abordagens citadas tenham um carter sistemtico e exaustivo, os analistas trocam de perspectiva constantemente durante a avaliao, realizando um encadeamento oportunista, particular a cada indivduo. Desta forma, a autora pode constatar as grandes diferenas entre os resultados das avaliaes individuais, o que evidencia um carter subjetivo em cada avaliao individual. Nas avaliaes heursticas os resultados dependem diretamente da carga de conhecimento e experincia que as pessoas trazem para as avaliaes, e do tipo de estratgia com que percorrem a interface. Autros autores apontam para uma particularidade deste tipo de tcnica : s vezes, as sugestes de re-projeto so mais consideradas pelos avaliadores do que a caracterizao dos problemas. Deste modo, as avaliaes heursticas apresentam um efeito colateral importante : a posssibilidade de introduzirem novos problemas de usabilidade sobre as interfaces. Os dados obtidos no estudo de Pollier evidenciam a necessidade de um mtodo ou tcnica que possa uniformizar as anlises e garantir uma mdia de desempenho individual superior para os analistas. Nesta apostila encontram-se descritas algumas ferramentas importantes para a realizao de avaliaes heursticas, em particular, o conjunto de critrios e de recomendaes ergonmicas apresentadas no captulo 4, o modelo de nveis de abstrao e o modelo de componentes de interfaces descritos no captulo 5. Como qualquer atividade de avaliao, este tipo de tcnica iniciada pela anlise do contexto da avaliao, quando o responsvel pela avaliao verifica, junto aos responsveis pelo software, os recursos disponveis e os objetivos da avaliao.
113

Em funo desta anlise podem ser alocados um nmero maior ou menor de avaliadores trabalhando em paralelo. Em funo de se ter ou no acesso a usurios reais, questionrios e entrevistas podem ser preparados, de modo a coletar informaes sobre seu perfil e sobre o modo como utiliza o software. importante frisar que o contato com o usurio, mesmo que por fax ou telefone de bastante til para conduzir as avaliaes. Face a tipos especiais de interfaces ou aplicaes, algumas vezes o avaliador deve procurar o conhecimento necessrio para julgar as qualidades do software. A estratgia para a avaliao como foi visto varivel e vai depender do avaliador, do tipo de software, do tipo de interface, etc.. A ltima etapa e a mais crtica, a de redao do relatrio de avaliao, que deixar registrados os problemas identificados e as propostas de solues sugeridas. Sugere-se a adoo de um formato de descrio de problemas, como o apresentado anteriormente neste captulo. Ele permitir esclarecer e priorizar os problemas de usabilidade.

9.4.2.2 Inspeo Cognitiva da Intuitividade

Esta um tipo de avaliao heurstica, onde os especilistas enfocam especificamente os processos cognitivos que se estabelecem quando o usurio realiza a tarefa interativa pela primeira vez (Kieras e Polson, 1991). Ela est baseada em um modelo de como se desenvolvem as aes cognitivas dos usurios. Assim, ela visa avaliar as condies que o software oferece para que o usurio faa um rpido aprendizado das telas e das regras de dilogo. A intuitividade o aspecto central na aplicao de uma inspeo cognitiva. A validade desta tcnica est justamente em seu enfoque nos processos cognitivos. Para realiz-la o avaliador deve atentar para aquilo que o usurio conhece da tarefa e da operao de sistemas informatizados. Deve tambm conhecer o caminho previsto para a realizao das principais tarefas do usurio. De posse destas informaes ele passa a percorrer os caminhos previstos aplicando, para cada ao o seguinte checklit. o usurio a tentar realizar a tarefa certa? Ao encontrar-se no passo inicial de determinada tarefa, o usurio, baseado no que lhe apresentado, se propor a realizar o objetivo previsto pelo projetista? ele ver o objeto associado a esta tarefa? Este objeto est suficientemente vista do usurio? ele reconhecer o objeto como associado tarefa? As denominaes ou representaes grficas so representativas da tarefa e significativas para o usurio? ele saber operar o objeto? O nvel de competncia na operao de sistema informatizados compatvel com a forma de interao proposta?(esta questo foi
114

adicionada tcnica original a partir das pesquisas de Sears, 1997) ele compreender o feedback fornecido pelo sistema como um progresso na tarefa? A proposta dos autores desta tcnica de que os prprios projetistas possam aplica-la no desenvolvimento do sistema interativo.

9.4.2.3 Inspees preventivas de erros

Esta uma tcnica de avaliao heurstica pela qual o avaliador inspeciona a interface procura de situaes que possa levar a erros ou incidents. Tem portanto uma pertinncia especial para sistemas de alta responsabilidade, como os de controle de processos em tempo real. Para aplic-la o avaliador levanta as caractesticas do contexto de operao e inspeciona a interface seguindo um modelo de tarefas, aplicando aos trs components bsicos da tarefa (entradas, realizao e resultados) um conjunto de heursticas ou guidewords especficas para orientar na deteco de erros. As avaliaes so organizadas em tabelas para cada tarefa esplicitando: Tarefa Guideword de desvio possivel Explicaes sobre os desvios Causas dos desvios Consequncias dos desvios Recomendaes de reprojeto

As guidewords aplicveis as tarefas so as seguintes: E se nada acontecer ? E se algo diferente acontecer ? E se algo acontecer a mais E se algo acontecer a menos E se algo acontecer a diferente E se algo acontecer fora de tempo ? E se algo acontecer antes? E se algo acontecer depois

9.4.3 Inspees Ergonmicas via Checklists

As inspees de usabilidade por checklists, so vistorias baseadas em listas de verificao, atravs das quais

115

profissionais, no necessariamente especialistas em ergonomia, como por exemplo, programadores e analistas, diagnosticam rapidamente problemas gerais e repetitivos das interfaces (Jeffries et al, 1991). Neste tipo de tcnica, ao contrrio das avaliaes heursticas, so as qualidades da ferramenta (checklists) e no dos avaliadores, que determinam as possibilidades para a avaliao. Checklists bem elaborados devem produzir resultados mais uniformes e abrangentes, em termos de identificao de problemas de usabilidade, pois os inspetores so conduzidos no exame da interface atravs de uma mesma lista de questes a responder sobre a usabilidade do projeto. Os resultados obtidos atravs dessa tcnica dependem ento da organizao e do contedo, geral ou especfico, dessas ferramentas. Verses especializadas de um checklist podem ser desenvolvidas a partir de um outro, com questes genricas. As questes do checklist podem vir acompanhadas de notas explicativas, exemplos e de um glossrio a fim de esclarecer possveis dvidas associadas as mesmas. O servio Web ErgoList (http://www.labiutil.inf.ufsc.br/ergolist), desenvolvido pelo LabIUtil, prope esse tipo apoio de aplicao. Algumas questes desse checklist encontram-se no anexo 2 desse livro. A avaliao realizada atravs de checklists apresenta as seguintes potencialidades: possibilidade de ser realizada por projetistas, no exigindo especialistas em interfaces humanocomputador, que so profissionais mais escassos no mercado. Esta caracterstica deve-se ao fato do conhecimento ergonmico estar embutido no prprio checklist; sistematizao da avaliao, que garante resultados mais estveis mesmo quando aplicada separadamente por diferentes avaliadores, pois as questes/recomendaes constantes no checklist sempre sero efetivamente verificadas; facilidade na identificao de problemas de usabilidade, devido a especificidade das questes do checklist; aumento da eficcia de uma avaliao, devido a reduo da subjetividade normalmente associada a processos de avaliao; reduo de custo da avaliao, pois um mtodo de rpida aplicao. Entretanto, estes tipos de resultado dependem essencialmente das qualidades das listas de verificao, e nem sempre so atingidos. Muitas vezes a sistematizao prejudicada devido a questes subjetivas, que solicitam do
116

inspetor um nvel de competncia em usabilidade ou de conhecimento sobre o contexto que ele no possui. Outras vezes a abrangncia das inspees prejudicada devido ao contedo incompleto e organizao deficiente das listas. A economia na inspeo fica prejudicada por listas propondo uma grande quantidade de questes, que em sua maioria no so aplicveis ao sistema em avaliao. Por outro lado, o trabalho de Jeffries et ali (1991) mostra que este tipo de tcnica proporciona a identificao de uma grande quantidade de pequenos problemas de usabilidade que se repetem nas interfaces dos sistemas. Em relao sistemtica de classificao proposta neste texto os problemas identificados por meio de inspees de usabilidade se referem principalmente a rudos gerais. Um tipo de instrumento de inspeo ergonmica bastante bem definido so as normas internacionais de usabilidade. Em particular, o captulo 10 desta apostila faz uma descrio das partes da norma ISO 9241 "Ergonomic requirementes for office work with visual display terminals". O anexo 3 traz os checklists propostos por esta norma internacional em sua parte 10 sobre Princpios de Dilogo.

9.5 Tcnicas Objetivas

As tcnicas empricas, que contam com a participao direta de usurios se referem basicamente aos ensaios de interao e as sesses com sistemas espies.

9.5.1 Ensaios de interao

Um ensaio de interao consiste de uma simulao de uso do sistema da qual participam pessoas representativas de sua populao-alvo, tentando fazer tarefas tpicas de suas atividades, com uma verso do sistema pretendido. Sua preparao requer um trabalho detalhado de reconhecimento do usurio-alvo e de sua tarefa tpica para a composio dos cenrios e scripts que sero aplicados durante a realizao dos testes.

9.5.1.1 As caractersticas dos ensaios

A complexidade do teste vai depender do nvel de exigncia requerido para os resultados, da generalidade do produto e da disponibilidade de recursos e de usurios. Testes simples, para reconhecer a perspectiva do usurio, para produtos especializados, onde se tenha acesso rpido aos usurios, podem ser implementados rapidamente. Situaes mais exigentes e em um quadro de dificuldades, a elaborao pode se tornar bem mais custosa e complicada. Para tomar concincia das dificuldades e facilidades nesta tarefa, importante que se faa uma anlise das caractersticas dos ensaios de interao, envolvendo; o nvel de constrangimento aceitvel, o tipo de

117

verbalizao a ser solicitada ao usurio, o local de realizao dos ensaios e as tcnicas de registro e coleta de dados.
9.5.1.1.1 O Constrangimento

O constrangimento inerente aos ensaios de interao, na medida em que implicam na observao de uma pessoa trabalhando com um sistema interativo. Cabe ao analista procurar tcnicas e mtodos que evitem essa situao, garantindo a validade dos resultados obtidos. Os seguintes cuidados podem ser tomados no sentido de prevenir a integridade psicolgica do usurio: esclarecer o usurio sobre o teste, enfatizando a finalidade do ensaio e da sua participao. Essa atitude deve ser aceita por ambos, observador e observado. no pression-los a participarem dos ensaios; no exp-los a comentrios de colegas. Tentar a realizao de ensaios in loco em horrios de pouco movimento ou presena de colegas de servio; caso o participante se sinta cansado ou constrangido diante de uma determinada situao, prefervel parar a realizao do ensaio, de forma educada, evitando transmitir ou encorajar o sentimento de culpa no usurio. os ensaios devem ser planejados cuidadosamente quanto a divulgao dos resultados, evitando invadir a privacidade dos participantes. A melhor maneira de abordar esta questo evitar a coleta de informaes que possam ser usadas para identificar algum.

9.5.1.1.2

A Verbalizao

Para obter uma informao correta, o analista precisa saber o que os usurios esto pensando e no somente o que eles esto fazendo. Para tanto necessrio solicitar a eles que verbalizem durante ou aps a interao com o software.
9.5.1.1.2.1 Verbalizao Simultnea

Por essa tcnica, deve-se solicitar aos usurios que alm de executarem a tarefa, tambm comentem o que esto pensando enquanto a executam. Deve se ter o cuidado de aplicar esta tcnica com pessoas extrovertidas para as quais o ato de falar sobre a tarefa no seja uma fonte de perturbao. Por outro lado, cabe ao observador dosar a quantidade de verbalizao demandada de acordo com as dificuldades na execuo da tarefa. Considere que na verbalizao simultnea o foco de ateno do usurio, que deve estar na execuo da tarefa, desviado para raciocinar e explicar como execut-la.

118

No decorrer da interao, o analista responsvel pelo ensaio, vai colocando ao usurio questes do tipo: Conte-me o que voc est pensando? O que voc est tentando fazer? O que voc est lendo? Como o trabalho se apresenta? Esses comentrios devem ser registrados ou anotados para que depois possam ser revistos.Por outro lado, o analista deve ao mesmo tempo controlar os acontecimentos e incentivar o usurio a falar sobre o que est fazendo. Os comentrios e os registras da aes tornam evidentes aos projetistas que algumas funes no so bem compreendidas, ou que existem rtulos que causam dvidas, levando o usurio a executar de forma errada a sua tarefa.
9.5.1.1.2.2 Verbalizao Consecutiva

Para determinado tipo de pessoas, o ato de falar, ao mesmo tempo em que deve pensar em como resolver uma tarefa, pode levar a uma sobrecarga mental que vai interferir no seu desempenho enquanto usurio de um sistema. A tcnica de observao simultnea vai desconcentr-lo constantemente da tarefa que executa, podendo s vezes, induzir erros de interao. Uma alternativa para a tcnica de verbalizao simultnea a de verbalizao consecutiva. Trata-se de uma entrevista com o usurio, realizada no final do ensaio de interao, onde este comenta sobre as tarefas que acabou de executar. Pode ocorrer que o usurio venha a esquecer a origem de um problema ou de uma situao de erro. Nesse caso, pode-se fazer uma entrevista valendo-se da fita de vdeo que registrou o ensaio de interao. Ela deve ser mostrada ao usurio como forma de favorecer a recuperao das causas e expectativas de um procedimento. Esta tcnica pode ainda ser conduzida de forma a pedir ao usurio que comente certas caractersticas especficas da interface. Estes comentrios sempre trazem boas sugestes, como tambm, deixam transparecer as reaes positivas ou negativas do usurio, sobre determinados pontos da interface.
9.5.1.1.3 O local do teste

Existem, teoricamente, dois tipos de ambientes onde o ensaio de interao pode ser realizado. O primeiro, o local usual da tarefa, sendo o observador, um elemento adicional neste ambiente. O segundo, num laboratrio, o ambiente da tarefa substancialmente diferente. Usualmente trata-se de uma forma empobrecida do ambiente normal de trabalho.
9.5.1.1.3.1 Teste em Laboratrio

119

A avaliao feita em laboratrio, equipado com recursos e aparelhos sofisticados, permite observar a interao homem/mquina de forma contnua, dando ao analista maior controle da situao. Assim, o analista pode escolher a melhor posio da cmera, ter cmeras focalizadas para o teclado, monitor, mouse, etc. No caso de um software que ainda esteja na fase de concepo, a avaliao feita em laboratrio se mostra mais adequada pois, o analista pode testar uma funo, fazer algumas correes, e tornar a testar o sistema. Em alguns laboratrios existem salas especiais, equipadas com vidros espelhados onde o analista no notado, garantindo que o usurio no seja interrompido e no fique envergonhado. Ele normalmente dispe de um telefone como forma de ajuda instantnea, um canal direto com o projetista. A principal desvantagem desse processo que nos laboratrios, onde tudo parece perfeito, no se consegue retratar a realidade de uma situao de trabalho.
9.5.1.1.3.2 Teste in loco

Um teste realizado no prprio local de trabalho do usurio pode ser mais trabalhoso e cansativo para a equipe de analistas. Mas, por outro lado, traz informaes mais ricas em detalhes. Detalhes estes que tem suas origens em fatores ambientais que influenciam na execuo da tarefa. Observar como o usurio atua quando interrompido por companheiros de trabalho, quando tem que parar para atender o telefone, quando pressionado pelo chefe ou quando tem prazo para entregar um trabalho, pode ser uma maneira de se obter valiosos dados que podero auxiliar na elaborao de determinadas funes. A avaliao feita no prprio local de trabalho mostra as interferncias alheias a tarefa que, muitas vezes, podem induzir situaes de erro na interao com um determinado sistema.
9.5.1.1.4 O registro e a coleta de dados

Como a interao com um software um processo contnuo envolvendo imagens e sons do programa, alm de verbalizaes dos usurios, o mais recomendado utilizar cmaras de vdeo para o registro de tudo. Para evitar possveis constrangimentos procure realizar o ensaio da forma mais conveniente para o usurio (horrio e local). Procure saber se o usurio tem alguma objeo quanto gravao, ou se isso pode vir a lhe trazer problemas de qualquer ordem. Em todo o caso, tome o cuidado de no filmar o rosto dos participantes. Realizar anotaes com lpis e papel pode ser uma tcnica simples que pode ser usada em qualquer lugar e com o mnimo
120

de custo. Entretanto, na medida em que a observao torna-se excessivamente explicita uma tcnica que pode causar certo desconforto ou constrangimento para a pessoa que est sendo observada. Alm disso, esta tcnica requer prtica e habilidade por parte do observador e dificilmente ela pode ser empregada sem o apoio de uma outra tcnica de registro.

9.5.1.2 Montagem de um ensaio de interao

MONTAGEM DE ENSAIO DE INTERAO ANLISE PRELIMINAR Reconhecimento do software Pr-diagnstico Ergonmico DEFINIO DOS CENRIOS E DA AMOSTRA Reconhecimento do usurio Coleta de informaes sobre o usurio e sua tarefa Definio de tarefas para o usurio REALIZAO DOS ENSAIOS Obteno da amostra de usurios Ajuste nos scripts e cenrios Preparao dos ensaios Realizao dos ensaios Coleta e anlise dos dados Diagnstico e relatrio final A montagem de um ensaio de interao pressupe inicialmente uma etapa de anlise preliminar para conhecer o software e seus atributos ergonmicos.
9.5.1.2.1 Anlise Preliminar

Nessa etapa os analistas tomam conhecimento dos fatos a cerca do software e de seu contexto de desenvolvimento e realizam um pr-diagnstico dos problemas ergonmicos de sua interface com o usurio.
121

9.5.1.2.1.1

Reconhecimento do software

Para o reconhecimento do software feita uma sesso de entrevistas preliminares com as pessoas que o projetaram e desenvolveram, que trazem informaes de seu projeto e desenvolvimento. As questes solicitadas equipe de projeto do software abrangem: populao alvo: para que tipo de trabalhador foi destinado o software?; tipo de tarefa que o software visa atender: Que tipo de tarefa o usurio poder desenvolver com este aplicativo?; funes principais do produto: Quais as funcionalidades que, na opinio dos projetistas, tm maior impacto na tarefa e na organizao do trabalho?; equipe de projetistas: Quantas pessoas foram envolvidas no projeto, houveram ergonomistas?; tempo de desenvolvimento: Quanto tempo se gastou no projeto? Houveram interrupes? Por quais motivos?; dados sobre o sistema: Qual o ambiente de programao em que foi desenvolvido o software?; verses precedentes: Qual a verso atual do produto? Quais as alteraes no projeto inicial? situao no mercado: O produto muito comercializado? Os usurios se mantm fiis no uso?; suporte: Existe algum tipo de suporte tcnico que dado aos usurios?; Este levantamento se destina a compreender o ciclo de desenvolvimento pelo qual passou o software e embasar o prdiagnstico.
9.5.1.2.1.2 Pr-diagnstico

A partir das informaes obtidas dos projetistas do software, os analistas examinam todo o aplicativo, primeiro para conhecer bem as funcionalidades do produto, e depois, para identificar as funes mais problemticas. O pr-diagnstico pode ser obtido atravs de uma tcnica de avaliao do tipo heurstica ou ainda a partir de checklists para inspeo ergonmica. Os critrios, recomendaes e normas ergonmicas servem como ferramenta de apoio nessa etapa de avaliao. O resultado do pr-diagnstico um conjunto de hipteses sobre problemas de usabilidade do software que sero posteriormente testadas durante os ensaios de interao.
9.5.1.2.2 Definio dos Scripts, Cenrios e da Amostra de usurios

Os scripts envolvem o conjunto de tarefas que uma amostra de usurios representativos da populao alvo do sistema
122

dever realizar durante os ensaios. O cenrio se refere as condies ambientais e organizacionais que sero trazidas para os teste. Scripts e cenrios so montados a partir das informaes coletadas no reconhecimento do software e de seu pr-diagnstico ergonmico e das informaes trazidas do reconhecimento do perfil do usurio e de sua tarefa.
9.5.1.2.2.1 Reconhecimento do perfil do usurio

A primeira atividade de reconhecimento do usurio consiste em contactar pessoas do pblico-alvo em seus locais de trabalho e de verificar se as pessoas contatadas possuem efetivamente o perfil imaginado pelos projetistas. J nessa etapa possvel prselecionar um grupo de usurios que podero vir a participar dos ensaios. Tome os cuidados de explicar-lhes qual a finalidade da anlise, quais os procedimentos que a equipe adotar e de deix-los livres para participar ou no da atividade proposta.
9.5.1.2.2.2 Coleta de informaes sobre o usurio e sua tarefa

Dependendo da abrangncia da populao-alvo do software, pode ser necessria a realizao de uma etapa mais detalhada de coleta de informaes sobre o usurio e sua tarefa, Nela, o analista deve elaborar questionrios destinados a buscar os dados de uma grande amostra de usurios. Alm de ser enviado aos usurios, o questionrio pode, tambm, servir de roteiro para entrevistas presenciais ou a distncia. Atravs de questionrios pode-se coletar dados a respeito: dos recursos disponveis, tanto tcnicos quanto fsicos, para a realizao da tarefa: Tambm importante saber qual o tipo de suporte que a empresa oferece aos empregados quanto a treinamento e apoio tcnico. do contexto da tarefa: Durante as entrevistas e observaes, os analistas tomam conhecimento do vocabulrio utilizado pelos usurios, das diversas atividades que eles desenvolvem, das presses organizacionais exercidas sobre ele. Uma amostra do resultado final do trabalho dos usurios pode ser bastante til para a montagem dos cenrios; do nvel dos usurios: Dados como formao geral e especfica em informtica e no aplicativo em anlise, tempo de empresa, tempo na atividade desenvolvida e o conhecimento de outros aplicativos permitem diferenciar os usurios novatos e os experientes. da utilizao do sistema; em especial os questionrios visam obter uma viso geral sobre a utilizao de um sistema pronto ou em desenvolvimento. As questes devem estar direcionadas para as funcionalidades, buscando conhecer aquelas que o usurio considera de maior impacto positivo e negativo sobre seu trabalho.

123

Deve-se tambm buscar conhecer as freqncias de utilizao de cada funcionalidade.

9.5.1.2.2.3 Definio dos scripts de tarefas para os ensaios

Para definir os scripts necessrio selecionar as tarefas envolvidas com: os objetivos principais do software, sob o ponto de vista de seus projetistas; as hipteses dos ergonomistas, formuladas no prdiagnstico; as amostras de tarefas dos usurios, que foram recolhidas juntamente com os questionrios; as funcionalidades do sistema consideradas mais e menos importantes pelo usurio; as funcionalidades mais freqentemente acionadas pelos usurios na utilizao do software; Um script nasce da combinao desses parmetros, levando-se sempre em considerao o aspecto custo x benefcio dos ensaios. Uma avaliao perfeita impossvel de ser elaborada. O importante saber avaliar, e manter nos ensaios somente os aspectos crticos, sob o ponto de vista do usurio e de sua tarefa.
9.5.1.2.3 Realizao dos ensaios

A primeira etapa para a realizaro dos ensaios consiste na obteno da amostra de usurios que deles participaro. As outras atividades desta etapa incluem a realizao de ajustes nos cenrios para adapt-los aos usurios participantes da amostra, o planejamento dos ensaios, a sua realizao, a anlise e a interpretao dos dados obtidos.
9.5.1.2.3.1 Obteno da amostra de usurios

necessrio verificar agora, quem da amostra de usurios, realiza efetivamente as tarefas que compem os scripts para a avaliao. Seleciona-se pessoas voluntrias, certificando-se de que: sejam experientes na tarefa; sejam usurios diretos, isto , pessoas que realmente exeram suas atividades com o auxlio do software; sejam metade novatos, metade experientes no software que ser avaliado; Os usurios iniciantes daro mais informaes sobre a facilidade de aprendizagem e a simplicidade de utilizao. J os experientes daro mais informaes sobre a organizao das funes e a repartio das informaes.

124

A experincia do usurio no aplicativo pode ser formada por diversos pontos: participao de cursos de treinamento em aplicativos; experincia anterior com outros softwares; leitura de livros e revistas afins e a prpria habilidade desenvolvida com o aplicativo. Atente para o fato de que o processo de avaliao iterativo. Os usurios novatos, numa segunda etapa de avaliao, devero ser considerados como usurios experientes. O tamanho da amostra deve ser suficiente para cobrir os diferentes tipos de usurios que possam utilizar o software dentro das expectativas e objetivos da avaliao. Deve tambm ser um nmero que permita diferenciar as observaes generalizveis das que possam ser especficas de uma determinada pessoa. A literatura sugere uma margem de 6 a 12 pessoas para atuarem nos ensaios de interao. Finalmente, deve-se deixar bem claro aos participantes dos ensaios, qual a sua extenso, para que se destina e o que se espera deles. importante que o usurio se sinta totalmente a vontade para recusar o convite sem presses da gerncia ou de qualquer tipo.
9.5.1.2.3.2 Ajustes nos scripts e cenrios

Para cada um dos participantes dos ensaios de interao deve ser realizada uma nova entrevista para buscar informaes visando os ajustes nas variveis dos scripts e dos cenrios. Os scripts, com a descrio das tarefas a serem solicitadas ao usurio devem trazer termos e objetivos que lhe sejam familiares. Os cenrios podem reproduzir, em laboratrio, a familiaridade do ambiente domstico ou profissional de determinado usurio.
9.5.1.2.3.3 Planejamento dos ensaios

A preparao dos ensaios envolve a tomada de deciso e a adoo de providncias relativas ao local dos ensaios, equipamento para registro dos acontecimentos, escolha das tcnicas de verbalizao (consecutiva/simultnea) e definio das estratgias de interveno em caso de impasse. Deve-se, neste particular procurar sempre preservar o anonimato dos usurios. As situaes de impasse representam um constrangimento a mais para o usurio. Para lidar com estas situaes sugere-se deixar o usurio tentar resolver sozinho qualquer tarefa; nunca tomar atitudes grosseiras que possam inibir o usurio na continuao do ensaio de interao; depois de algum tempo, persistindo a situao de impasse, propor ao usurio a realizao de uma tarefa alternativa previamente estipulada no script;

125

 caso os usurios participantes dos ensaios de interao encontrem-se realmente constrangidos ou nervosos, os ensaios deveriam ser interrompidos totalmente.
9.5.1.2.3.4 Realizao dos Ensaios

Os ensaios de interao, que podem ser realizados no local de trabalho de cada usurio ou em laboratrio, devem durar no mximo 1 hora. Deles devem participar alm do usurio, 1 ou 2 ergonomistas observadores e 1 assistente tcnico, responsvel pelo funcionamento dos equipamentos. O desenrolar dos ensaios so controlados e dirigidos pelos ergonomistas que devem planejar como proceder nos casos de interrupes, retomadas e encerramento precoce do teste. Alm disso, eles devem realizar anotaes em tempo real, sobre o desempenho do usurio e dos erros e incidentes verificados. Dessas anotaes devem constar indicaes sobre o instante dos eventos perturbadores. Uma boa prtica consiste na realizao de um ensaio piloto para certificar-se de que tudo foi previsto.
9.5.1.2.3.5 Anlise e interpretao dos dados obtidos

Depois da realizao dos ensaios, a equipe de analistas deve rever todas as gravaes buscando dados relevantes que comprovem ou no as hipteses anteriormente estabelecidas. Alm disto, muitas situaes inesperadas de erros e recuperao da informao podem aparecer. Da a importncia dos ensaios, pois estes tipos de erros s tornam-se evidentes em situao realista de uso. Os resultados dos ensaios de interao so relatados e comentados num caderno de encargos que entregue aos projetistas do sistema. No relatrio so descritos os incidentes produzidos durante a interao, relacionando-o com um aspecto do software. Comentrios sobre a prioridade dos problemas devem fazer parte do relatrio.

9.5.2 Os sistemas de monitoramento

Uma outra forma de realizar uma validao emprica, isto , com a observao direta de usurios, se d atravs do emprego de sistemas de monitoramento ou espies. Estes sistemas so ferramentas de software que permanecem residentes na mquina do usurio simultaneamente ao aplicativo em teste (MS Camcorder ou Lotus ScrenCam). Eles so concebidos de maneira a capturar e registrar todos os aspectos das interaes do usurio com seu aplicativo em sua prpria realidade de trabalho. Nesse sentido, essa tcnica permite contornar dois inconvenientes dos ensaios de interao. Mesmo que os usurios estejam cientes dos testes, os sistemas espies no causam constrangimentos ao usurio e capturam as interferncias causadas por sua realidade do trabalho. Por outro
126

lado, no h como incentivar ou registrar as verbalizaes dos usurios. Os sistemas espies apresentam tambm limitaes do ordem tcnica, relacionadas principalmente, a portabilidade das ferramentas de espionagem face a diversidade de ambientes de programao existentes. A quantidade de dados a tratar pode se tornar muito grande. Dessa forma, a durao dos testes deve ser bem planejada pelos analistas.

9.6 Compromisso entre tcnicas de avaliao

Para a escolha de uma tcnica de avaliao importante examinar as suas qualidades no confronto com os recursos disponveis e as expectativas de resultados da avaliao de usabilidade. As diferentes tcnicas de avaliao apresentadas neste captulo apresentam qualidades diferentes em termos do tipo e quantidade de problemas que identificam, da sistematizao de seus resultados, da facilidade de aplicao e das chances que seus resultados apresentam de poder convencer os projetistas das necessidades de mudanas nas interfaces humanocomputador. Efetividade se refere quantidade de problemas srios (recorrentes, transponveis e assimilveis) identificados. Segundo pesquisas realizadas (Jeffries, at ali,1993) as tcnicas mais efetivas so as avaliaes heursticas e os ensaios de interao; Abrangncia se refere quantidade de problemas reais de todos os tipos identificados. As inspees por checklists e as avaliaes heursticas so as mais abrangentes; Eficincia - a razo da quantidade de problemas srios (recorrentes, transponveis e assimilveis) identificados face a quantidade de problemas reais identificados de todos os tipos. A mesma pesquisa indica os ensaios de interao como a tcnica mais eficiente; Produtividade - se refere a razo entre a quantidade de problemas reais de todos os tipos identificados em relao a quantidade de recursos financeiros (U$) necessrios; Sistematizao para esta qualidade concorrem dois fatores igualmente importantes: repetitividade e reproduzibilidade. O primeiro refere-se medida pela qual os resultados produzidos pela tcnica se repetem quando o mesmo avaliador examina o mesmo software algum tempo depois da primeira avaliao. O segundo fator se refere a medida pela qual dois avaliadores diferentes examinando um mesmo software produzem os mesmos resultados; As inspees por checklists so as mais sistemticas Facilidade de aplicao se refere a qualidade da tcnica de no exigir formao ou competncias especficas para sua realizao. Neste sentido, as inspees por checklists so as mais fcil aplicao; Poder de persuaso se refere a qualidade da tcnica de produzir resultados capazes de convencer os projetistas da gravidade dos

127

problemas de usabilidade identificados. Os ensaios de interao e as avaliaes heursticas Poder de desobstruo A desobstruo se refere qualidade da tcnica produzir indicaes de melhorias na usabilidade dos sistemas. O entupimento se refere ao efeito colateral indesejvel de uma modificao de projeto equivocada que tenha sido sugerida por meio de uma avaliao de usabilidade.

9.7 Projeto de Avaliao

O sucesso do desenvolvimento, implantao ou compra de um software interativo est intimamente ligado ao projeto da atividade de verificao&validao de sua usabilidade. Pode-se evitar disperdcios, desenvolvendo idias ou solues equivocadas, ou ao contrrio, concentrar recursos nas idias que podero satisfazer os usurios. Pode-se liberar um softwareproduto para o mercado ou ao contrrio, solicitar alteraes de ltima hora em sua interface com o usurio. Pode-se suspender uma transao de compra e venda de software ou abaliz-la, com base nos resultados de uma avaliao de usabilidade. Deste modo, a avaliao de usabilidade deve ser organizada a partir de uma metodologia de projeto. A norma ISO 14 598 prope uma conduo para a montagem de projetos de avaliao com uma estrutura similar a aqui proposta, prevendo etapas de: anlise : identificao dos requisitos da avaliao; projeto preliminar : seleo das tcnicas aplicveis; projeto detalhado : configurao das tcnicas; implementao : realizao da avaliao; documentao : elaborao do relatrio; validao : confronto entre os resultados esperados e obtidos com a avaliao.

Na etapa inicial de anlise de requisitos deve-se verificar o que se tem como recursos disponveis (dinheiro, pessoal, especialistas, usurios, tempo, verso do software, ferramentas e equipamentos) e quais so os resultados esperados da avaliao (ver tpico 7.2). Com base nesta anlise, faz-se, na etapa de projeto preliminar da avaliao, uma definio sobre quais tcnicas so as mais adequadas. Esta pode se tornar uma tarefa complexa, na medida em que se trata de uma deciso com mltiplas variveis e uma soluo, que pode envolver uma combinao de tcnicas, depende da quantidade de recursos materiais e humanos disponveis e dos tipos de resultados esperados para a avaliao.

128

A etapa de projeto detalhado envolve a configurao das tcnicas selecionadas para a avaliao. Nesta etapa so detalhados parmetros como, por exemplo, nmero de especialistas que iro realizar uma avaliao heurstica, abordagem de varredura, critrios prioritrios, checklists para inspeo de usabilidade, nmero de usurios a observar, local de realizao dos ensaios (em laboratrio ou em campo), scripts de tarefas e cenrios, tempo dos ensaios, etc. Na implementao, a avaliao realizada. Seguindo as indicaes de cada tcnica, coletam-se os dados, identificam-se os problemas, que so categorizados e priorizados. A etapa de documentao envolve a elaborao do relatrio da avaliao. Este deve incluir uma apresentao do contexto e dos requisitos da avaliao realizada, as ferramentas empregadas e os problemas identificados, categorizados por critrio, tarefa ou componente de IHC, e priorizados. Dependendo dos requisitos da avaliao, pode ser necessrio anexar descrio do problema propostas de melhorias que sejam evidentes. Na etapa de validao do processo de avaliao verifica-se se os requisitos esperados para a atividade foram efetivamente alcanados. Esta retro-alimentao sobre o que deu, e sobre o que no deu certo durante a realizao dos testes fundamental para garantir o sucesso de novos projetos de avaliao.

9.8 Plano de Testes

Um plano de testes refere-se a diversos projetos de avaliao, um para cada etapa do desenvolvimento ou verso intermediria do software interativo. Trata-se da combinao de tcnicas para testar o projeto e a implementao do sistema, da forma mais abrangente possvel, dentro das limitaes de recursos disponveis. Ele deve prever, para cada verso intermediria do sistema, mesmo que no passe de um conjunto de idias, qual o tipo de teste apropriado, quais as condies (casos) de teste e quais os resultados admitidos. A figura abaixo mostra uma estratgia de validao ergonmica possvel.

129

PLANO DE TESTES DE ERGONOMIA Etapas de Sntese x ANLISE PROJ CONCEPO PROJ PROJETO PROJ IMPLEMENTAO DESENVOLVI IMPLANTAO IMPLANT REVISES IMPLANT Tcnica de Avaliao Reunies c/o Usurio PROJ Inspeo Cognitiva PROJ Aval. Heursticas PROJ Checklists DESENVOLVI Ensaios de Interao IMPLANT Quest. de Satisfao IMPLANT

130

10. A NORMA ISO 9241

A norma ISO 9241 trata do trabalho de escritrio informatizado atravs do uso de planilhas eletrnicas e de processadores de textos, entre outros aplicativos. No esto includos os aplicativos de projeto auxiliado por computador e de controle de processos (CAD-CAM), bem como as interfaces que usem estereoscopia ou realidade virtual. No so abordados aspectos da emisso de radiaes ou segurana eltrica dos equipamentos, cobertos pelas normas IEC. Esta norma internacional se destina aos profissionais encarregados de garantir um trabalho de escritrio seguro e efetivo com os computadores. Seu objetivo promover a sade e a segurana de usurios de computadores e garantir que eles possam operar estes equipamentos com eficincia e conforto. Isso requer um projeto cuidadoso dos terminais de computadores, dos locais de trabalho e do ambiente nos quais eles so usados, assim como da organizao e do gerenciamento do prprio trabalho. As consideraes da ergonomia so importantes no projeto de qualquer equipamento usado por seres humanos, mais especialmente quando este uso intensivo ou se a preciso e a velocidade forem fatores crticos. Os computadores e seus terminais de vdeo formam uma parte significativa do trabalho de escritrio e muito freqentemente determinam o desempenho do usurio em suas atividades. De uma maneira geral as recomendaes que constam da ISO 9241 foram definidas por evidncia emprica e a partir da reviso da literatura existente, sendo ento generalizadas e formuladas em termos de requisitos para o uso de projetistas e avaliadores de interfaces. O comit tcnico TC-159, que se ocupa de ergonomia, e em particular o sub-comit SC 4, que se ocupa da ergonomia da interao homem-sistema, organizaram a ISO 9241 em um conjunto de 17 partes, cada uma lidando com diferentes aspectos do trabalho em escritrios informatizados. Parte 1: Introduo geral. Parte 2: Conduo quanto aos requisitos das tarefas. Parte 3: Requisitos dos terminais de vdeo. Parte 4: Requisitos dos teclados. Parte 5: Requisitos posturais e do posto de trabalho. Parte 6: Requisitos do ambiente. Parte 7: Requisitos dos terminais de vdeo quanto as reflexes. Parte 8: Requisitos dos terminais de vdeo quanto as cores. Parte 9: Requisitos de dispositivos de entrada, que no sejam os teclados. Parte 10: Princpios de dilogo. Parte 11: Orientaes sobre usabilidade.
131

Parte 12: Parte 13: Parte 14: Parte 15: Parte 16: Parte 17:

Apresentao da informao. Orientaes ao usurio. Dilogos por menu. Dilogos por linguagem de comandos. Dilogos por manipulao direta. Dilogos por preenchimento de formulrio.

No que se refere ao equipamento, as recomendaes tratam somente dos fatores que afetem o desempenho dos usurios e estejam menos sujeitos s variaes do estado da tecnologia. Para medir este desempenho a ISO 9241 fornece indicaes sobre: as caractersticas do equipamento que so importantes sob o ponto de vista ergonmico, como medir ou avaliar estas caractersticas, que equipamento de teste utilizar, como formar uma amostra de usurios apropriada, que condies experimentais montar e qual o nvel de desempenho esperar. Como nem sempre possvel realizar estes testes, a ISO 9241 traz recomendaes que podem ser utilizadas de modo prescritivo, simplesmente auxiliando na busca dos nveis esperados de desempenho humano. As 8 partes que se referem s interfaces de software j so normas internacionais e encontram-se em fase de traduo para compor uma norma brasileira correspondente. De fato, a Comisso de Estudos da ABNT para ergonomia de software foi instalada em julho de 1999 e prepara-se para lanar a parte 1 da norma brasileira. A parte 10 define os 7 princpios de projeto que segundo o comit tcnico que elaborou esta norma ISO podem levar a uma interface humano-computador ergonmica. So eles a adequao tarefa, a auto-descrio, a controlabilidade, a compatibilidade com as expectativas do usurio, a tolerncia erros, a adequao para a individualizao e a adequao para a aprendizagem. Para cada princpio de projeto so apresentadas recomendaes gerais com exemplos especficos. A parte 11 refere-se a especificao da usabilidade dos sistemas, definida como aquelas caractersticas que permitem que o usurio alcance seus objetivos e satisfaa suas necessidades dentro de um contexto de utilizao determinado. Desempenho e satisfao do usurio so especificados e medidos a partir do grau de realizao de objetivos perseguidos na interao (eficcia), pelos recursos alocados para alcanar estes objetivos (eficincia) e pelo grau de aceitao do produto pelo usurio (satisfao). Esta parte da norma ISO 9241 refora a idia de que a usabilidade depende do contexto de utilizao, e que o nvel de usabilidade atingido ser funo das circunstncias particulares de utilizao do produto. O contexto de utilizao compreende os usurios, as tarefas, o equipamento (hardware, software e documentos) e os ambientes fsicos e sociais suscetveis de influenciar a usabilidade de um produto
132

dentro de um sistema de trabalho. As medidas de desempenho e de satisfao dos usurios avaliam a qualidade do sistema de trabalho com todas as suas interligaes. Qualquer mudana como treinamento adicional ou melhoria de iluminao foram uma reavaliao da usabilidade do sistema. A norma ISO 9241-12 lida com a apresentao visual das informaes atravs de terminais de vdeo. Ela traz princpios gerais para a apresentao da informao e se refere tanto a organizao da informao nas telas quanto ao uso de tcnicas de codificao individual. Suas recomendaes referem-se : janelas, reas de entradas e sadas, grupos, listas, tabelas, rtulos, campos, cursores, aspectos sintticos e semnticos de cdigos alfanumricos, abreviaturas, codificao grfica, cdigos de cores e outras tcnicas de codificao visual. A parte 13 se refere conduo ao usurio, vista como o conjunto de informaes suplementares, portanto adicionais ao dilogo habitual entre homem-mquina, que so fornecidas sob comando do usurio ou automaticamente pelo sistema. Os elementos do sistema de conduo incluem os convites, o feedback, as informao sobre o estado do sistema, a gesto de erros e a ajuda em linha. Eles auxiliam a interao do usurio com o sistema evitando a carga de trabalho mental intil, fornecendo aos usurios um meio de gesto de erros, alm de uma assistncia adequada ao seu nvel de competncia. As recomendaes contidas nesta norma se referem a situaes tpicas envolvendo necessidades especficas de informaes e de aes. As partes 14 a 17 se referem a estilos de dilogo; por menu, por linguagem de comandos, por manipulao direta e por preenchimento de campos. As normas fornecem uma estrutura de recomendaes referentes a pertinncia destes estilos de dilogo, sobre como realiz-los em seus diferentes aspectos e como avali-los. Assim por exemplo os dilogos por menus, tratados pela parte 14 so aplicveis quando o uso da aplicao no freqente e quando o conjunto de opes de comandos muito grande para confi-lo memria de um usurio com um mnimo de treinamento, sem prtica de digitao e com pouca ou nenhuma experincia com o sistema. As recomendaes ergonmicas que esto includas nesta parte da norma se referem a estrutura dos menus, a navegao dentro desta estrutura, a seleo e execuo de opes de menu. A parte 15, trata dos dilogos por linguagem de comandos, que se aplicam quando a tarefa requerer um rpido acesso a funes especficas do sistema, onde impossvel fazer prognsticos em termos das escolhas das aes que o usurio v precisar e onde os dados ou opes de comandos possam ser introduzidos em ordem arbitrria. Por seu lado o usurio

133

precisa receber um treinamento formal, fazer uso freqente do sistema e mostrar habilidades de datilgrafo. As recomendaes referem-se a estrutura e sintaxe dos comandos, a suas representaes e as entradas e sadas com este estilo de dilogo. Os dilogos por manipulao direta, assunto tratado pela parte 16, se aplicam quando as entradas forem de difcil descrio e onde possa existir a possibilidade de construir metforas com os objetos do mundo fsico que facilitem a visualizao do sistema. Os recursos dos equipamentos, em termos de resoluo e velocidade de tratamentos grficos devem permitir apresentaes e feedback eficientes. O usurio a quem se destina este tipo de dilogo no apresenta habilidades de digitao e prefere as representaes grficas s textuais. As recomendaes da norma se referem a aparncia e a manipulao de objetos grficos, de texto, de controle e de janelas. A parte 17 trata dos dilogos por preenchimento de formulrios, aplicveis quando as entradas do sistema forem predominantemente de dados, com uma estrutura rgida e com poucos comandos. Os usurios deste tipo de dilogo no precisam de treinamento especfico e suas habilidades de datilgrafo podem ser moderadas. As recomendaes se referem a estrutura dos formulrios, as entradas, ao feedback e a navegao pelos campos.

10.1 Verificando as qualidades ergonmicas atravs da ISO-9241

Para realizar uma avaliao segundo as partes desta norma internacional, os analistas devem, antes de tudo, ler a norma e suas correlatas, conhecer o produto de software, o usurio, a tarefa, o ambiente e o sistema de trabalho que o produto pretenda apoiar. O prximo passo estabelecer uma lista de tarefas a serem usadas na avaliao (as mais importantes e as mais freqentes, por exemplo) e aplicar a norma. Para tanto duas abordagens so examinadas. Na abordagem aconselhada o avaliador utiliza o produto para escolher uma lista de tarefas e observa o usurio realizando estas tarefas. Cada elemento do sistema em anlise ser verificado contra as recomendaes desta norma (ex. conduo ao usurio: convites, informaes sobre o estado, feedback, mensagens de erros e ajuda em linha). Convm que os resultados sejam registrados segundo as rubricas: requisitos inaplicveis, aplicveis e seguidos, aplicveis mas no seguidos. Na outra abordagem sugerida, o prprio avaliador utiliza o produto e estuda os elementos do sistema durante esta utilizao. A conformidade norma ISO 9241 definida a partir dos resultados de duas anlises; a de aplicabilidade do quesito e a

134

de aderncia do sistema ao quesito. Muitos dos quesitos propostos pelas diversas partes desta norma de ergonomia de software so condicionais, isto devem ser seguidas somente dentro de um contexto especfico no qual elas so aplicveis: tipos particulares de usurios, tarefas, ambientes e tecnologia. A norma prev uma sistemtica para justificar a definio da aplicabilidade de um quesito, que pode se dar pela evidncia documentada sobre a tarefa, ou a partir da descrio do sistema ou por sua simples observao. A aplicabilidade pode ainda ser decidida com base na avaliao de um expert (avaliao analtica) ou a partir de procedimentos de testes com usurios finais (avaliao emprica). Por seu lado, uma deciso sobre a aderncia do sistema ao quesito deve ser justificada atravs de diferentes mtodos: por medio, evidncia documentada, observao, avaliao analtica, avaliao emprica ou outro mtodo. Convm que o relatrio da avaliao contenha as tarefas avaliadas, as recomendaes aplicveis e as recomendaes seguidas.

135

11. REFERNCIAS BIBLIOGRFICAS

Barthet, M.-F. (1988). Logiciels interactifs et ergonomie: modles et mthodes de conception (first ed.). Paris: Bordas. Bass, L., & Coutaz, J. (1991). Developing software for the user interface (first ed.). Reading, Massachusetts: Addison-Wesley Publishing Company. Bastien, C. & Scapin , D. (1993). Human factors criteria, principles, and recommandations for HCI: methodological and standatdisation issues. (Internal Repport). INRIA Bastien, C. J. (1991). Validation des critres ergonomiques pour l'valuation d'interfaces utilisateurs. (Rapport de Recherche No. 1427). INRIA. Bodart, F., & Vanderdonckt, J. (1993a). Encapsulating Knowledge for Intelligent Automatic Interaction Objects Selection. In A. Wesley (Ed.), INTERCHI'93 - Human Factors in Computing Systems, 1 (pp. 424 - 429). Amsterdam: ACM Press. Bodart, F., & Vanderdonckt, J. (1993b). Guide Ergonomique de la prsentation des applications hautement interactives. (1 ed.). Namur, Belgique: Presses Universitaires de Namur. Brown, C. M. (1988). Human-computer interface design guidelines (first ed.). Norwood, New Jersey: Ablex Publishing Corporation. Card, S., Moran, T. & Newell, A. (1983). The psychology of human-computer interaction (first ed.). Hillsdale: Lawrence Erlbaum Associates. Chevalier, J. (1980). Dictionnaire des symboles (first ed.). Paris: Robert Laffont. Coutaz, J. (1990). Interfaces homme-ordinateur: conception et ralisation. (first ed.). Paris: Bordas. Damodaran, L. (1966). User involvement in the systems design process - a practical guide for users. Behavior & Information Technology 15(6): 363-377. Dix, A., Finlay. J., Abowd, G. & Beale, R. (1993) . Human-Computer Interaction, Prentice Hall International (UK) Limited Fernandes, T.(1995). Global Interface Design: a guide to designing international user interfaces. Academic Press Inc. Foley, J. D. &. V. D., A. (1984). Fundamentals of interactive computer graphics (first ed.). Massachusets: Addison-Wesley Publishing Company. Hix, D. & Hartson, H. R. (1993). Developing User Interfaces: Ensuring usability through product & process. Wiley Professional Computing. Horton. W. (1994). The Icon Book; visual symbols for computer systems and documentation. John Wiley & Sons, Inc. IBM (1989). Systems Application Architecture, Common User Access: Advanced Interface Design Guide. In Boca Raton: International Business Machines Corp. ISO 9241 Part 1(1993). Ergonomic requirements for office work with visual display terminals, Part 1 General Introduction ; International Standard ISO 9241-1 ISO 9241 Part 2(1993). Ergonomic requirements for office work with visual display terminals, Part 2 Guidance on task requirements ; International Standard ISO 9241-2

136

ISO 9241 Part 3(1993). Ergonomic requirements for office work with visual display terminals, Part 3 Visual display requirements ; International Standard ISO 9241-3 ISO 9241 Part 10 (1993). Ergonomic requirements for office work with visual display terminals, Part 10 Dialogue principles ; Draft International Standard ISO 9241-10 ISO 9241 Part 11 (1993). Ergonomic requirements for office work with visual display terminals, Part 11 Usability Statements ; Draft International Standard ISO 9241-11 ISO 9241 Part 12 (1993). Ergonomic requirements for office work with visual display terminals, Part 12 Presentation of information ; Draft International Standard ISO 924112 ISO 9241 Part 13 (1993). Ergonomic requirements for office work with visual display terminals, Part 13 User guidance ; Draft International Standard ISO 9241-13 ISO 9241 Part 14 (1993). Ergonomic requirements for office work with visual display terminals, Part 14 Menu dialogues ; Draft International Standard ISO 9241-14 ISO 9241 Part 15 (1993). Ergonomic requirements for office work with visual display terminals, Part 15 Command dialogues ; Draft International Standard ISO 9241-15 ISO 9241 Part 16 (1993). Ergonomic requirements for office work with visual display terminals, Part 16 Direct Manipulation dialogues ; Draft International Standard ISO 9241-16 ISO 9241 Part 17 (1993). Ergonomic requirements for office work with visual display terminals, Part 17 Form filling dialogues ; Draft International Standard ISO 924117Laville, A. (1977). Ergonomia (First ed.). So Paulo: Editora Pedaggica e Universitria Ltda. Loshe, G., Walker, N., Biolsi, K., & Rueter, H. (1991). Classifying Graphical INFORMATION. Behaviour and INFORMATION Technology, 10(5), 419-436. Martin, J. (1992). Hyper documentos e como cri-los. Editora Campus. Muller M.J., H. J. H., Dayton T. (1997). Participatory Pratices in the Software Lifecycle. Handbook of Human-Computer Interaction. M. Helander, Landauer, T.K., Prabhu, P.: 255-297. Norman, D. A. (1984). Cognitive engineering principles in the design of human-computer interfaces. In G. Salvendy (Eds.), Human Computer Interaction Amsterdam: Elsevier Science Publisher. OSF (1990). Motif Style Guide (1.1 ed.). Cambridge, MA: Open Software Foundation. Pollier, A. (1991). Evaluation d'une interface par des ergonomes: diagnostiques et stratgies (Rapport de Recherche No. 1391). INRIA. Powell, E.J. (1990). Designing User Interfaces, Data Based Advisor Series, Ed. Lance A. Leventhal, Microtrend Books Ravden, S., & Johnson, G. (1989). Evaluating usability of human-computer interfaces (first ed.). Chichester: Ellis Horwood Limited. Richard, J.-F. (1983). Logique du fonctionnement et logique d'utilisation (Rapport de Recherche No. 202). INRIA. Richard, J.-F., Bonnet, C., & Ghiglione, R. (1990). Trait de Psychologie Cognitive : perception, action, langage(premire ed.). Paris: Bordas. Rivlin, C., Lewis, R., & Davies-Cooper, R. (1990). Guidelines for Screen Design (first ed.). Cambridge: Blackwell scientif Publications.

137

Rogers, Y. (1989). Icons at the Interface: Their Usefulness. Interacting with Computers, 1(1), 105-117. Sacre, B., Sacre-Provot, I., & Vanderdonckt, J. (1992). Une description oriente objet des objets interactifs abstraits utiliss en interfaces homme-machine. (rapport IHM/Ergo No. 10). Facults Universitaires Notre-Dame de La Paix - Institut d'Informatique Projet Trident. Scapin, D. L. (1986). Guide ergonomique de conception des interfaces homme-machine. (Rapport de Recherche No. 77). INRIA - Rocquencourt - France. Scapin, D.L. et al. (1988) - La concption ergonomique d'interfaces: problmes de mthodes, Rapports de Recherche , Rocquencourt, France: INRIA. Scapin, D.L. (1989a) - Guidelines for user-interface design: Konwledge collection and Organisation, Technical Raport TR.D12.1 Version Date 30/12/1989, Rocquencourt, France: INRIA. Scapin, D. L. (1989b) - MAD: Une mthode analytique de description des tches. IN: Colloque sur l'engenirie des interfaces homme-machine, Sophia-Antipolis, France, INRIA Scapin, D. L. (1990d). Organizing human factors knowledge for the evaluation and design of interfaces. International Journal of Human-Computer Interaction, 2(3), 203-229. Scapin, D.L. (1990a) - Decyphering human-factors recommendations, IN: Karwoski,W. & Rahimi, M. (Eds). Ergonomics of hybrid automated Systems II, Amsterdam: Elsevier Science Publisher. Scapin, D.L. (1990b) - Des critres ergonomiques pour l'valuation et la concption d'interfaces. IN: Actes du Congres de la SELF, Montral. Sebillotte, S. (1991). Decrire des tches selon les objetifs des operateurs: de l'interview la formalisation (Rapport de Recherche No. 125). INRIA. Shneiderman, B. (1987). Designing the User Interface: strategies for effective humancomputer interaction (first ed.). Addison-Wesley Publishing Company. Smith, S. (1986). Standards versus guidelines for designing user interface software. Hehaviour and Information Technology, 5(1), 47-61. Smith, S. L., & Mosier, J. N. (1986). Guidelines for designing user interface software No. ESD-TR-86-278). The MITRE corporation. Valentin, A., & Lucongsang, R. (1987). L'ergonomie des logiciels (first ed.). Paris: ANACT. Valentin, A., Vallery, G & Lucongsang, R. (1993). L'valuation ergonomique des logiciels; une dmarche interative de conception (first ed.). Paris: ANACT. Winograd, T., & Flores, F. (1986). Understanding computers and cognition: a new foundation for design (first ed.). Norwwod, New Jersey: Ablex Publishing Corporation.

138