Projeto de Interfaces de Usurio

Perspectivas Cognitivas e Semiticas

Clarisse Sieckenius de Souza*, Jair Cavalcanti Leite, Raquel Oliveira Prates*, Simone D.J. Barbosa* clarisse@inf.puc-rio.br; jair@dimap.ufrn.br; raquel@les.inf.puc-rio.br; sim@les.inf.puc-rio.br

Resumo A rea de Interao HumanoComputador (IHC) tem por objetivo principal fornecer aos pesquisadores e desenvolvedores de sistemas explicaes e previses para fenmenos de interao usurio-sistema e resultados prticos para o design da interface de usurio [ACM SIGCHI, 1992]. Esta apostila apresenta duas bases tericas que fundamentam os estudos de IHC, e descreve o processo de design de interfaces. Apresenta tambm os modelos e tcnicas utilizados na anlise e modelagem de usurios, tarefas e comunicao; e dois mtodos para avaliao das interfaces resultantes. Abstract The main goal of the HumanComputer Interaction (HCI) area is to provide researchers and developers with explanations and predictions about user-system interaction phenomena, and practical results for user interface design [ACM SIGCHI, 1992]. This material presents two complementary theoretical bases for HCI research, and describes the user interface development process. It presents models and techniques used in users, tasks, and communication analysis and modelling; and two methods for evaluating the resulting user interfaces.

1. INTRODUO
1.1 Viso Geral
Nas ltimas dcadas, tem sido dada cada vez maior importncia interface de aplicaes computacionais. A interface de uma aplicao computacional envolve todos os aspectos de um sistema com o qual mantemos contato [Moran, 1981]. atravs da interface que os usurios tm acesso s funes da aplicao. Fatores de satisfao subjetiva, de eficincia, de segurana, de custo de treinamento, de retorno de investimento, todos, dependem de um bom design de interface. Na indstria de software, o design de interface tem sido conduzido atravs de processos iterativos de construo e avaliao de prottipos baseados em princpios e diretrizes empricas, tal como proposto em The Windows Interface:
*

Pontifcia Universidade Catlica do Rio de Janeiro PUC-Rio Universidade Federal do Rio Grande do Norte UFRN

Guidelines for Software Design [Microsoft, 1995] e Macintosh Human Interface Guidelines [Apple, 1992]. Entretanto, estes princpios podem ser conflitantes em determinadas situaes. Para resolv-los, necessrio basear a prtica de design de interfaces em uma fundamentao terica [Hartson, 1998]. Esta fundamentao orientar o designer ao longo da elaborao da sua soluo particular para o conjunto de problemas que a aplicao pretende resolver. A rea de Interao HumanoComputador (IHC) tem por objetivo principal fornecer aos pesquisadores e desenvolvedores de sistemas explicaes e previses para fenmenos de interao usurio-sistema e resultados prticos para o design da interface de usurio [ACM SIGCHI, 1992]. Com teorias a respeito dos fenmenos envolvidos seria possvel prever antecipadamente se o sistema a ser desenvolvido satisfaz as necessidades de usabilidade, aplicabilidade e comunicabilidade dos usurios. Para isto, estudos de IHC visam desenvolver modelos tericos de desempenho e cognio humanos, bem como tcnicas efetivas para avaliar a usabilidade [Lindgaard, 1994]. Mais recentemente algumas propostas tm enfatizado que alm de usabilidade, as aplicaes devem buscar atingir aplicabilidade [Fischer, 1998] e comunicabilidade [de Souza, 1999], oferecendo ao usurio artefatos fceis de usar, aplicar e comunicar. IHC uma rea multidisciplinar, que envolve disciplinas como [Preece et al., 1994]: Cincia da Computao; Psicologia Cognitiva; Psicologia Social e Organizacional; Ergonomia ou Fatores Humanos; Lingstica; Inteligncia Artificial; Filosofia, Sociologia e Antropologia; Engenharia e Design. No contexto de IHC devemos considerar quatro elementos bsicos: o sistema, os usurios, os desenvolvedores e o ambiente de uso (domnio de aplicao) [Dix et al., 1993]. Estes elementos esto envolvidos em dois processos importantes: a interao usurio-sistema e o desenvolvimento do sistema. O curriculum proposto para IHC identifica cinco enfoques para o estudo destes elementos e para a sua aplicao na melhoria dos processos de desenvolvimento e de interao usuriosistema. Para cada um destes focos, diferentes disciplinas proporcionam os estudos tericos que podem ser aplicados ao desenvolvimento. So eles: design e desenvolvimento do hardware e software: estudo de tecnologias de dispositivos de entrada e sada; e tecnologias de software, como ambientes grficos e virtuais. estudo da capacidade e limitao fsica e cognitiva dos usurios: considera estudos de ergonomia para avaliar limites de esforo fsico do usurio, e estudos de psicologia e cincia cognitiva sobre a capacidade humana de memorizao, raciocnio e aprendizado. instrumentao terica e prtica para o design e desenvolvimento de sistemas interativos: envolve o conhecimento terico a respeito dos fenmenos envolvidos; modelos para o processo de desenvolvimento que descrevam as etapas necessrias e como devem ser conduzidas; diretrizes, tcnicas, linguagens, formalismos e ferramentas de apoio a estas etapas. modelos de interfaces e do processo de interao usuriosistema: para desenvolver modelos abstratos do processo de interao compatveis com as capacidades e limitaes fsicas e cognitivas dos usurios.

anlise do domnio e de aspectos sociais e organizacionais: para avaliar o impacto que o contexto onde est inserido o usurio exerce sobre seus conhecimentos, sua linguagem e suas necessidades.

1.2 Organizao da apostila

Esta apostila est organizada em quatro captulos. No Captulo 1, apresentamos conceitos bsicos da rea de IHC que sero utilizados ao longo do texto. Apresentamos a evoluo de IHC por diferentes perspectivas, e descrevemos os principais estilos de interao. O Captulo 2 descreve as teorias da Engenharia Cognitiva e da Engenharia Semitica e faz uma comparao entre elas. O Captulo 3 descreve um modelo para o processo de design de uma aplicao de acordo com estudos de IHC, e as etapas de modelagem de usurios, tarefas e comunicao. Apresenta tambm as tcnicas de cenrios e storyboarding, e descreve ferramentas de apoio construo de interfaces. No Captulo 4, apresentamos mtodos de testes de usabilidade e comunicabilidade para avaliao de interfaces, e descrevemos tambm os tipos de prototipao e seu papel na etapa de avaliao.

1.3 Conceitos Bsicos

Interface e Interao O termo interface aplicado normalmente quilo que interliga dois sistemas. Tradicionalmente, considera-se que uma interface homem-mquina a parte de um artefato que permite a um usurio controlar e avaliar o funcionamento deste artefato atravs de dispositivos sensveis s suas aes e capazes de estimular sua percepo. No processo de interao usurio-sistema a interface o combinado de software e hardware necessrio para viabilizar e facilitar os processos de comunicao entre o usurio e a aplicao. A interface entre usurios e sistemas computacionais diferencia-se das interfaces de mquinas convencionais por exigir dos usurios um maior esforo cognitivo em atividades de interpretao e expresso das informaes que o sistema processa [Norman, 1986]. Moran props uma das definies mais estveis de interface, dizendo que a interface de usurio deve ser entendida como sendo a parte de um sistema computacional com a qual uma pessoa entra em contato fsica, perceptiva e conceitualmente [Moran, 1981]. Esta definio de Moran caracteriza uma perspectiva para a interface de usurio como tendo um componente fsico, que o usurio percebe e manipula, e outro conceitual, que o usurio interpreta, processa e raciocina. Moran e outros denominam este componente de modelo conceitual do usurio. Vemos, pois, que a interface tanto um meio para a interao usurio-sistema, quanto uma ferramenta que oferece os instrumentos para este processo comunicativo. Desta forma a interface um sistema de comunicao. A interface possui componentes de software e hardware. Os componentes de hardware compreendem os dispositivos com os quais os usurios realizam as atividades motoras e perceptivas. Entre eles esto a tela, o teclado, o mouse e vrios outros. O software da interface a parte do sistema que implementa os processos computacionais necessrios (a) para controle dos dispositivos de

hardware, (b) para a construo dos dispositivos virtuais (os widgets) com os quais o usurio tambm pode interagir, (c) para a gerao dos diversos smbolos e mensagens que representam as informaes do sistema, e finalmente (d) para a interpretao dos comandos dos usurios. Outra caracterstica de uma interface a revelao das affordances do sistema. Affordance um termo que se refere s propriedades percebidas e reais de um artefato, em particular as propriedades fundamentais que determinam como este artefato pode ser utilizado [Norman, 1988]. Segundo Norman, as affordances fornecem fortes pistas ou indicaes quanto operao de artefatos; e quando se tira proveito delas, o usurio sabe exatamente o que fazer s olhando para o artefato. Por exemplo, a affordance de um boto que o pressionemos, de um interruptor, que o comutemos, e assim por diante. A interao um processo que engloba as aes do usurio sobre a interface de um sistema, e suas interpretaes sobre as respostas reveladas por esta interface (Figura 1.1). Ao longo deste texto, veremos como modelar e avaliar este processo.

sistema
ao

usurio
interpretao

interface

aplicao

Figura 1.1 Processo de interao humanocomputador.

Usabilidade A usabilidade de um sistema um conceito que se refere qualidade da interao de sistemas com os usurios e depende de vrios aspectos. Alguns destes fatores so: facilidade de aprendizado do sistema: tempo e esforo necessrios para que os usurios atinjam um determinado nvel de desempenho; facilidade de uso: avalia o esforo fsico e cognitivo do usurio durante o processo de interao, medindo a velocidade de e o nmero de erros cometidos durante a execuo de uma determinada tarefa; satisfao do usurio: avalia se o usurio gosta e sente prazer em trabalhar com este sistema; flexibilidade: avalia a possibilidade de o usurio acrescentar e modificar as funes e o ambiente iniciais do sistema. Assim, este fator mede tambm a capacidade do usurio utilizar o sistema de maneira inteligente e criativa, realizando novas tarefas que no estavam previstas pelos desenvolvedores; produtividade: se o uso do sistema permite ao usurio ser mais produtivo do que seria se no o utilizasse.

Muitas vezes, o designer deve identificar quais destes fatores tm prioridade sobre quais outros, uma vez que dificilmente se consegue alcanar todos de forma equivalente. As decises do projetista determinam a forma de interao entre usurios e sistemas. Freqentemente designers definem a facilidade de uso como sendo o aspecto de usabilidade prioritrio e, por vezes, acabam desenvolvendo sistemas em que os usurios no cometem erros, mas tambm no tm muita opo de ao ou deciso. Adler e Winograd chamam estes sistemas de sistemas anti-idiotas (idiot-proof) e advogam que novas tecnologias sero mais eficazes quando projetadas para aumentar, ao invs de substituir, as capacidades dos usurios [Adler & Winograd, 1992]. Assim, eles denominam desafio de usabilidade o projeto de novas tecnologias que buscam explorar ao mximo as capacidades dos usurios na criao de ambientes de trabalho mais eficazes e produtivos. Outros pesquisadores tambm tm ressaltado a importncia de os sistemas computacionais ampliarem as capacidades do usurio. Norman, um dos mais influentes pesquisadores e um dos pioneiros na aplicao de psicologia e cincia cognitiva ao design de interfaces de usurio, recentemente tem enfatizado que a tecnologia deve ser projetada com o objetivo de ajudar as pessoas a serem mais espertas, eficientes e inteligentes [Norman, 1991; Norman, 1993]. Fischer, por sua vez, argumenta que alm de usabilidade o designer deve buscar atingir tambm aplicabilidade, ou seja, a sua utilidade na resoluo de problemas variados [Fischer, 1998]. Ele insiste no fato de que todo usurio especialista em um domnio e uma aplicao de software deve servir sua especialidade. Neste sentido ela deve funcionar como um instrumento para o usurio e no presumir que o usurio quem deve atender s exigncias de peculiaridades tecnolgicas. Comunicabilidade A comunicabilidade de um sistema a sua propriedade de transmitir ao usurio de forma eficaz e eficiente as intenes e princpios de interao que guiaram o seu design. Faz parte da experincia diria das pessoas entender atravs de um ato de comunicao muitas mensagens subjacentes, como por exemplo perceber a filosofia de um autor atravs da sua pea de teatro. Da mesma forma, o objetivo da comunicabilidade permitir que o usurio, atravs da sua interao com a aplicao, seja capaz de compreender as premissas, intenes e decises tomadas pelo projetista durante o processo de design. Quanto maior o conhecimento do usurio da lgica do designer embutida na aplicao, maiores suas chances de conseguir fazer um uso criativo, eficiente e produtivo da aplicao. Junto com a usabilidade, a comunicabilidade pretende aumentar a aplicabilidade de software. Para ilustrar, a Figura 1.2 mostra uma interface de alta comunicablidade, a de um software para tocar CD s. Atravs da analogia com um o aparelho de tocar CD s esta interface comunica de forma efetiva como os usurios devem interagir para tocarem seus CD s no computador.

Figura 1.2 Exemplo de alta comunicabilidade: interface de um software para tocar CD s.

Para contrastar, a Figura 1.3 mostra uma interface de baixa comunicabilidade. O usurio de um sistema Microsoft Windows 9x/NT executa a aplicao Find (Localizar) para procurar um computador e fornece o nome LINX. O computador no encontrado, e uma mensagem com esta informao aparece para o usurio na barra de status na borda inferior da janela. O usurio analisando a interface percebe que a opo de menu Edit (Editar) est disponvel, assim como o item Undo (Desfaz). No entanto, o usurio no sabe o que pode ser desfeito, uma vez que a nica coisa feita foi uma busca sem sucesso. Ao ativar o item Undo, o usurio ento recebe uma mensagem informando que o arquivo no pode ser removido. Neste momento, o usurio no tem como saber a que o sistema se refere, pois o seu discurso, claramente no est relacionado com a tarefa em questo.

Figura 1.3 Exemplo de baixa comunicabilidade: interface do software de localizao de computadores e arquivos no Windows 95.

1.4 Perspectivas em IHC

Para compreender melhor as teorias de design de interface, precisamos entender as diferentes perspectivas que os sistemas de computador vm atravessando ao longo do tempo (Figura 1.4) [Kaamersgard, 1988]. Inicialmente, o usurio era considerado uma mquina, que tinha que aprender a falar a linguagem do computador. Em seguida, com o surgimento da Inteligncia Artificial, tentamos considerar o computador como uma pessoa. Nessas duas perspectivas, era fundamental dar poder ao sistema. Mais tarde, surgiu a perspectiva de computador como ferramenta, que o usurio utiliza para obter um resultado ou produto. Atualmente vemos outra mudana de perspectiva, na qual o computador um mediador da comunicao entre pessoas. Nestas duas ltimas perspectivas, o foco no usurio, e no mais no sistema.

usurio como mquina

computador como pessoa

Capacitando o sistema Capacitando o usurio

trabalho ou produto computador como mdia computador como ferramenta

Figura 1.4 Perspectivas em IHC.

O abordagem de desenvolvimento de sistemas centrado do usurio (User-Centered System Design, ou UCSD [Norman, 1986]) se aplica perspectiva computador como ferramenta. J a abordagem da Engenharia Semitica se aplica s duas ltimas perspectivas, que ocorrem nas aplicaes de software atuais. Estas abordagens sero descritas no Captulo 2.

1.5 Estilos de Interao

Estilo de interao um termo genrico que inclui todas as formas como os usurios se comunicam ou interagem com sistemas computacionais [Preece et al., 1994; Shneiderman, 1998]. Neste curso, destacamos os seguintes estilos de interao: linguagem natural, linguagens de comando, menus, WIMP, preenchimento de formulrio e manipulao direta.

Alm do estilo de interao, o paradigma de interao tambm determina como um usurio interage com o sistema. Um paradigma de interao indica a ordem em que os elementos envolvidos em uma operao so selecionados ou acionados pelo usurio. Este paradigma pode ser ao+objeto ou objeto+ao. No primeiro caso, o usurio tipicamente seleciona a operao a ser realizada, e em seguida o objeto sobre o qual deve atuar. No segundo caso, o usurio seleciona inicialmente o objeto, e em seguida a operao que deseja realizar sobre ele. Linguagem Natural Algumas aplicaes permitem ao usurio se expressar em linguagem natural, ou seja, utilizando a lngua com que ele se comunica com outros seres humanos, seja portugus, ingls, francs, ou outra qualquer. A interao em linguagem natural bastante atrativa para usurio com pouco ou nenhum conhecimento em computao. Entretanto, ela no se aplica a todos os tipos de sistemas. Sistemas de consulta a informaes e sistemas baseados em conhecimento so exemplos onde a utilizao de interfaces em linguagem natural bastante interessante. No primeiro caso, por possibilitar que usurio no especialistas possam fazer consultas em sua prpria lngua. No segundo caso, para que o sistema gere explicaes a partir da sua base de conhecimento, uma vez que a linguagem natural expressiva o suficiente para a descrio do raciocnio artificial do programa, o que no seria possvel com outros estilos de interao. Uma aplicao que oferece interface em linguagem natural precisa lidar com construes vagas, ambguas, e at gramaticalmente incorretas. Ainda no possvel desenvolver sistemas que compreendam qualquer expresso em linguagem natural, mas diversos tipos de sistemas especialistas utilizam com sucesso algum subconjunto de uma linguagem natural, nos quais o usurio deve se expressar de forma inequvoca e tendo em vista as frases que tais sistemas possam interpretar. Para permitir que um usurio interaja com aplicaes em linguagem natural, podemos fornecer uma interface textual onde ele deve digitar as frases que expressem seus comandos ou questionamentos. Outra alternativa so as interfaces orientadas por menus, atravs dos quais ele pode selecionar cada palavra ou expresso at compor a frase desejada. Em uma aplicao em linguagem natural, tentamos aproximar a aplicao do usurio, de forma a privilegiar a forma de comunicao deste. Em outro extremo, tentamos aproximar o usurio do sistema computacional, utilizando linguagens artificiais bastante restritas, chamadas linguagens de comando. Linguagem de Comando A interfaces baseadas em linguagens de comandos proporcionam ao usurio a possibilidade de enviar instrues diretamente ao sistema atravs de comandos especficos [Preece et al., 1994]. Os comandos podem ser compostos por teclas de funes, por um nico caractere, por abreviaes curtas, palavras inteiras ou uma combinao de teclas e caracteres. Embora os comandos na forma de caracteres e teclas de funo sejam disparados com um menor nmero de teclas digitadas,

estes comandos so mais difceis de lembrar do que um nome ou abreviao bem escolhida. As linguagens de comandos podem ser consideradas poderosas por oferecerem acesso direto funcionalidade do sistema e por permitirem maior iniciativa do usurio e maior flexibilidade na construo dos comandos atravs da variao de parmetros e combinao de palavras e sentenas. Contudo, este poder e flexibilidade implicam uma maior dificuldade dos iniciantes em aprender e utilizar o sistema. Os comandos e a sintaxe da linguagem precisam ser relembrados e erros de digitao so comuns mesmo nos mais experientes. A falta de padronizao nos diversos sistemas um fator importante na dificuldade de utilizao deste estilo. Usurios especialistas, no entanto, conseguem maior controle do sistema e produtividade atravs de interfaces baseadas em linguagens de comandos. Ao se projetar uma linguagem de comando, deve-se levar em conta a organizao e estrutura dos comandos, assim como os nomes e abreviaes utilizados. Os comandos podem ser simples ou compostos de parmetros e/ou opes. Deve-se considerar cuidadosamente a ordenao de parmetros, tentando refletir a estrutura da tarefa realizada. Quanto aos nomes e abreviaes, deve-se dar preferncia s palavras-chave em vez de smbolos aleatrios, e considerar cuidadosamente o nvel de apresentao de cada comando, mantendo um equilbrio entre especificidade e generalidade. Existem diversas estratgias de abreviao, como eliminao de variveis, utilizao das primeiras letras de uma palavra ou da primeira letra de cada palavra que descreve o comando, etc.

Figura 1.5 Exemplo de interface no estilo de linguagem de comando.

Algumas interfaces baseadas em comandos podem ser auxiliadas por menus que indicam quais so os diversos comandos e como eles devem ser acionados. A ferramenta de gerenciamento do correio eletrnico PINE um exemplo de interface baseada em comandos elementares auxiliados por menus. A Figura 1.6 ilustra uma tela do PINE.

Figura 1.6 Interface baseada em comandos auxiliada por menus.

Menus Um menu um conjunto de opes apresentadas na tela, no qual a seleo de uma ou mais opes resulta em uma mudana no estado da interface [Paap & RoskeHofstrand, 1988]. Neste estilo de interao os usurios no precisam lembrar o item que desejam, apenas reconhec-lo. Para que este estilo de interao seja eficiente, portanto, os itens de menu devem ser auto-explicativos. Os menus podem ser de seleo simples ou mltipla, e podem ser utilizados para configurar um parmetro ou disparar uma operao. Um menu de seleo simples pode tomar a forma de um grupo de botes de opo, ou radio buttons. J um menu de seleo mltipla pode ser representado por um grupo de botes de seleo, ou check boxes. Quando o nmero de opes torna-se muito grande, temos a preferncia por listas, de seleo simples ou mltipla. A desvantagem da interao por menus que estes ocupam muito espao na tela. Existem diversas tcnicas para se agrupar e apresentar as opes de menus. A mais comum a categorizao hierrquica das opes, na qual deve-se tomar cuidado para a seleo dos nomes dos grupos e de cada opo, para que reflitam as metas e tarefas do usurio. Um menu hierrquico pode ocorrer na forma de uma seqncia de telas, ou como um menu pull-down. Em um menu pull-down, o menu surge ao se clicar em seu ttulo, e desaparece assim que se seleciona uma das opes. Outra alternativa para poupar espao de tela oferecida por menus pop-up. Um menu pop-up aparece ao se clicar em um determinada rea da tela ou elemento de interface, e pode permanecer visvel at que o usurio selecione um de seus itens ou decida fech-lo. Preenchimento de Formulrios Interfaces no estilo de preenchimento de formulrio so utilizadas principalmente para entrada de dados em sistemas de informao. Uma tela de preenchimento de formulrio lembra um formulrio em papel, apresentando campos que devem ser

preenchidos pelo usurio. O layout de um formulrio com freqncia semelhante a um formulrio impresso que o usurio utilizava antes da implantao do sistema, facilitando seu aprendizado. Este estilo de interao til principalmente quando diferentes categorias de informao devem ser fornecidas ao sistema, principalmente quando os mesmos tipos de dados devem ser digitados repetidamente [Preece et al., 1994], como em cadastros, controle de vendas e estoque, etc. Estas interfaces so, em geral, fceis de aprender. Para isto, devem deixar claro o tipo de dado que pode entrar em cada campo, facilitar a correo de erros de digitao e a verificao dos dados digitados atravs de tcnicas como dgitos verificadores e totalizao de valores. Os aspectos principais que vo influenciar na usabilidade do sistema so a produtividade do usurio, a sua satisfao e o esforo fsico provocado pelo sistema, uma vez que estes sistemas so projetados para que os usurios forneam um grande nmero de dados ao longo de um dia de trabalho. Estas interfaces experimentaram uma popularizao importante nas aplicaes de Internet, atravs de formulrios em HTML e scripts CGI. WIMP (Windows, Icons, Menus, and Pointers) O estilo de interao WIMP, um acrnimo em ingls para Janelas, cones, Menus e Apontadores, permite a interao atravs de componentes de interao virtuais denominados widgets. Este estilo implementado com o auxlio das tecnologias de interfaces grficas, que proporcionam o desenho de janelas e o controle de entrada atravs do teclado e do mouse em cada uma destas janelas. Os softwares de interfaces que implementam estes estilos permitem a construo de cones que permite a interao atravs do mouse, comportando-se como dispositivos virtuais de interao. WIMP no deve ser considerado um nico estilo, mas a juno de uma tecnologia de hardware e software, associada aos conceitos de janelas e de widgets que permitem a implementao de vrios estilos. Nas interfaces WIMP possvel encontrar os estilos de menus, manipulao direta, preenchimento de formulrio e linguagem de comandos. WIMP pode ser considerado um estilo ou um framework de interface apoiado pela tecnologia de interfaces grficas (GUI Graphical User Interfaces). A Figura 1.7 apresenta uma tela de aplicao no estilo WIMP.

Figura 1.7 Tela de uma aplicao no estilo WIMP.

Manipulao Direta Interfaces de manipulao direta so aquelas que permitem ao usurio agir diretamente sobre os objetos da aplicao (dados ou representaes de objetos do domnio) sem a necessidade de comandos de uma linguagem especfica. Neste tipo de interface, os comandos so aes baseadas numa analogia entre o cursor e a mo, e as representaes grficas e os objetos do domnio. Na interao por linguagens de comandos o usurio interage indiretamente, atravs de comandos textuais e nomes que representem os objetos do sistema. As interfaces grficas que se utilizam da metfora de desktop, como as do Apple Macintosh, baseada no Xerox Star, proporcionam um estilo no qual os usurios podem interagir com o gerenciador de arquivos do sistema operacional atravs de manipulao de cones que representam arquivos, diretrios, discos e outros componentes computacionais. O usurio interage com cones, utilizando o mouse ou outro dispositivo equivalente, atravs de aes do tipo clicar, arrastar (dragand-drop), etc.

2. BASES TERICAS
2.1 A Engenharia Cognitiva
As abordagens dominantes que tm caracterizado IHC so as de base cognitiva [Preece et al., 1994]. Elas tm razes comuns com as reas de psicologia cognitiva, cincia cognitiva e inteligncia artificial que estudam a cognio, isto , o processo pelo qual se pode adquirir conhecimento, e aplicam suas teorias na compreenso das capacidades e limitaes da mente dos usurios. Os resultados delas so de longe mais numerosos do que os de qualquer outra abordagem. A estratgia das abordagens cognitivas para o apoio ao design de sistemas interativos consiste na elaborao de modelos cognitivos genricos que permitam aos designers entender os processos cognitivos humanos usados na interao e realizar experimentos ou previses com estes modelos. A idia bsica que modelos cognitivos que descrevem os processos e estruturas mentais (e.g. recordao, interpretao, planejamento e aprendizado) podem indicar para pesquisadores e projetistas quais as propriedades que os modelos de interao devem ter de maneira que a interao possa ser desempenhada mais facilmente pelos usurios. Como estas abordagens adotam uma perspectiva centrada nos aspectos cognitivos do usurio, o design feito com base nelas chamado de design de sistemas centrado no usurio (User Centered System Design UCSD). Uma das teorias mais conhecidas de design centrado no usurio a Engenharia Cognitiva [Norman, 1986]. Norman considera que o designer inicialmente cria o seu modelo mental do sistema, chamado modelo de design, com base nos modelos de usurio e tarefa (ver sees 3.2 e 3.3). O modelo implementado deste modelo de design a imagem do sistema. O usurio ento interage com esta imagem do sistema e cria seu modelo mental da aplicao, chamado de modelo do usurio. Este modelo mental que permite ao usurio formular suas intenes e objetivos em termos de comandos e funes do sistema. A Figura 2.1 mostra o processo de design na abordagem da Engenharia Cognitiva.

modelo de tarefas = + modelo de usurios

modelo de design

modelo de uso

interao

designer

imagem do sistema

usurio

Figura 2.1 Modelo de interao da Engenharia Cognitiva.

Assim, segundo a Engenharia Cognitiva a meta do designer em desenvolver um sistema que permita ao usurio, durante o processo de interao, criar um modelo mental consistente com o modelo projetado pelo designer. Para que isto seja possvel, Norman argumenta que o designer precisa entender o processo atravs do qual o usurio interage com a interface do sistema e prope a teoria da ao. A teoria da ao define que a interao usurio-sistema desempenhada num ciclo-de-ao com sete etapas e dois golfos a serem atravessados. Um deles o golfo da execuo e envolve as etapas de formulao da meta, especificao da seqncia de aes e atividade fsica de execuo. O outro o golfo da avaliao e deve ser atravessado pelas etapas de percepo, interpretao e avaliao da meta (ver Figura 2.2).
Golfo de Avaliao

percepo

interpretao

avaliao

interao

execuo

especificao da seqncia de aes

Golfo de Execuo

formulao da inteno

Figura 2.2 Etapas de ao do usurio durante a interao com o sistema.

O usurio utiliza o sistema com o objetivo de realizar uma determinada tarefa. Para isto, ele deve formular metas a serem alcanadas atravs da interao com as funes disponveis no sistema. Em seguida, o usurio deve definir quais so as aes a serem executadas para que ele consiga atingir a sua meta. Note-se que, at este ponto, o usurio realizou a preparao mental para a execuo da meta. Resta-lhe concretizar o que foi mentalizado atravs de uma ao fsica. Estas trs fases compreendem a travessia do golfo de execuo, e no precisam ser necessariamente realizadas na seqncia descrita. Por exemplo, a especificao e o planejamento podem ser realizados intercaladamente ou pode-se comear a executar o comando sem que se tenha ainda especificado todas as aes por completo. Assim que o sistema executa a ao definida pelo usurio inicia-se o golfo de avaliao. A primeira etapa da travessia deste golfo a percepo do usurio do novo estado em que o sistema se encontra. O usurio ento interpreta este novo estado e o avalia de acordo com a sua meta inicial. Com base nesta avaliao o usurio prossegue para definir sua prxima ao. importante notar que, se o usurio no perceber que o sistema mudou de estado atravs de uma sinalizao

clara, ele possivelmente interpretar que nada ocorreu e que a sua meta inicial no foi atingida.

Exemplo Etapas da interao usuriosistema

Em um sistema de biblioteca, um usurio que queira fazer uma consulta sobre um livro ou artigo poderia passar pelas seguintes etapas de interao, de acordo com a abordagem centrada no usurio: formulao da inteno: Quero procurar a referncia completa do livro HumanComputer Interaction, editado por Preece. Devo selecionar o comando de busca e entrar com os dados que eu tenho. Ativo busca no menu; digito o nome do livro no campo nome do livro; digito o nome do autor no campo nome do autor; seleciono OK Apareceu uma nova tela com dados de livro. Os dados apresentados correspondem busca que eu fiz. Encontrei as informaes que eu queria. Completei a tarefa com sucesso.

especificao da seqncia de aes:

execuo:

percepo: interpretao: avaliao:

O designer pode ajudar o usurio a atravessar estes golfos diminuindo-os. Para isto ele deve definir quais so as aes e estruturas mais adequadas para comandar as funes do sistema, escolher os elementos de interface que melhor comunicam a informao desejada, optar por feedbacks significativos, dentre outras escolhas de design. Assim, quanto mais prxima da tarefa e das necessidades do usurio for a linguagem de interface oferecida pelo designer, menos esforo cognitivo o usurio ter que fazer para atingir seus objetivos. A Figura 2.1 mostra que, em Engenharia Cognitiva, o processo de design se inicia com o modelo mental que o designer cria do sistema. No entanto, a Engenharia Cognitiva focaliza centralmente a interao usurio-sistema, enfatizando o produto final do processo de design, o sistema, e o modo como o usurio o entende. A seguir, apresentamos a Engenharia Semitica que complementa a Engenharia Cognitiva, medida que focaliza centralmente o designer e o processo de design.

Exerccios

1. Imagine que voc o usurio do sistema de biblioteca do exemplo anterior e deseja imprimir a referncia encontrada, e que na interface existe um boto imprime. Descreva cada um dos passos que voc tomaria para atravessar o golfo de execuo. Observao: A travessia do golfo de avaliao, neste caso, envolve dispositivos perifricos, papel, submetas, etc. 2. Imagine que voc o usurio do sistema de biblioteca e precisa fazer uma consulta. Para isto, voc seguiu os trs primeiros passos descritos no exemplo anterior para atravessar o golfo de execuo. Para cada uma das respostas do sistema apresentadas abaixo, descreva seus passos para atravessar o golfo de avaliao (percepo, interpretao, avaliao): sistema no forneceu feedback sistema emitiu um som de bip sistema voltou para a tela inicial

2.2 A Engenharia Semitica

As abordagens semiticas tm como base terica a semitica, disciplina que estuda os signos, os sistemas semiticos e de comunicao, bem como os processos envolvidos na produo e interpretao de signos. Um signo algo que representa alguma coisa para algum [Peirce, 1931]. Por exemplo, tanto a palavra <co> em portugus, quanto uma fotografia de um co representam o animal cachorro, e assim so signos de cachorro para falantes da lngua portuguesa. Nestas abordagens toda aplicao computacional concebida como um ato de comunicao que inclui o designer no papel de emissor de uma mensagem para os usurios dos sistemas por ele criados, [Nadin, 1988; Andersen et al., 1993; de Souza, 1993; Jorna & Van Heusden, 1996]. Para que a comunicao entre duas pessoas acontea, preciso que o emissor da mensagem a expresse em um cdigo que tanto ele, quanto o receptor conheam. Cada mensagem pode ser formada por um ou mais signos. Assim que o receptor recebe a mensagem, ele gera uma idia daquilo que o emissor quis dizer e inicia o seu processo de compreenso [Jakobson, 1970]. Esta idia que ele gera chamada de interpretante, e pode, ele mesmo, gerar novos interprentantes na mente do receptor, numa cadeia indefinida de associaes. A este processo se d o nome de semiose ilimitada [Eco, 1976] e ele acontece at que ou o receptor acredite que ele tenha uma boa hiptese do que o emissor quis dizer, ou ele conclua que no capaz de, ou no est disposto a, criar tal hiptese. Neste caso, ele pode ou no dar continuidade ao processo de comunicao, passando ento para o papel de emissor. A Figura 2.3 ilustra este processo de comunicao.

interpretante

interpretante

semiose ilimitada

interpretante

codificao Meu tipo ideal o decodificao dos morenos canal mensagem (signos)

Figura 2.3 Processo de comunicao entre duas pessoas.

Na Engenharia Semitica [de Souza, 1993; de Souza, 1996] em particular a interface de um sistema vista como sendo uma mensagem sendo enviada pelo designer ao usurio. Esta mensagem tem como objetivo comunicar ao usurio a resposta a duas perguntas fundamentais: (1) Qual a interpretao do designer sobre o(s) problema(s) do usurio?, e (2) Como o usurio pode interagir com a aplicao para resolver este(s) problema(s)? O usurio concebe a resposta a estas perguntas medida que interage com a aplicao. Assim, esta mensagem unilateral, uma vez que o usurio recebe a mensagem concluda e no pode dar continuidade ao processo de comunicao [de Souza, 1993] naquele mesmo contexto de interao. Alm disso, como esta mensagem (a interface) ela mesma capaz de trocar mensagens com o usurio, ela um artefato de comunicao sobre comunicao, ou meta-comunicao. A Figura 2.4 mostra este processo de comunicao entre designer e usurio. Existem dois pontos que devem ser ressaltados nesta figura. Primeiramente, notese que a interao usurio-sistema parte da meta-mensagem do designer para o usurio, uma vez que a partir desta meta-mensagem que o usurio aprender a interagir com o sistema. Alm disso, para que a comunicao entre o designer e o usurio tenha sucesso, o modelo conceitual da aplicao pretendido pelo designer e o modelo da aplicao percebido pelo usurio, embora diferentes, devem ser consistentes entre si.

modelo pretendido da aplicao

contexto

modelo percebido da aplicao

contexto meio

designer

usurio

Figura 2.4 Ato de comunicao entre designer e usurio, na Engenharia Semitica.

Na abordagem da Engenharia Semitica, o designer autor de uma mensagem ao usurio, que transmitida pela interao que caracteriza o processo metacomunicativo. Assim, o design de interfaces envolve no apenas a concepo do modelo da aplicao, mas a comunicao deste de maneira a revelar para o usurio o espectro de usabilidade da aplicao. A Engenharia Semitica ressalta ainda que a presena do designer no cenrio comunicativo deve ser explicitada e tornada sensvel para os usurios para que eles tenham maior chance de entender as decises de design tomadas e a aplicao com que esto interagindo, sendo assim capazes de fazer um uso mais criativo e eficiente desta aplicao. A Figura 2.5 apresenta duas telas de consulta de uma aplicao. Observe que a primeira tela (2.5a) comunica claramente a restrio da busca a apenas um campo, enquanto na segunda (2.5b) se permite realizar a busca por um ou mais campos.

(a)

(b)

Figura 2.5 Exemplos de diferentes mensagens para uma tarefa de consulta.

Exerccio

Imagine que voc o designer do sistema de biblioteca e deseja projetar a interface para que o usurio faa uma consulta a um livro ou artigo. 1. 2. 3. Que informaes voc considera importantes para esta tarefa? Que mensagem voc pretende passar ao usurio? Como voc organizaria a tela para passar esta mensagem?

2.3 Engenharia Semitica x Engenharia Cognitiva

Tanto a Engenharia Semitica quanto a Engenharia Cognitiva vem o processo de design se iniciando com o designer que cria o seu modelo mental da aplicao, e com base neste, implementa a prpria aplicao. O usurio interage com esta aplicao e atravs dela cria o seu prprio modelo mental da aplicao. A criao da aplicao pelo designer e a interao do usurio so assncronas, ou seja, se do em diferentes momentos no tempo. A Engenharia Cognitiva se concentra na segunda etapa deste processo de design, ou seja, na interao usurio-sistema, deixando a etapa designer-sistema em segundo plano. Assim, ela enfatiza o produto deste processo, que o sistema, e a interpretao do usurio deste produto. Em outras palavras, a Engenharia Cognitiva d subsdios para se definir a meta ideal do processo de design, um produto, cognitivamente adequado para a populao de usurios. A Engenharia Semitica por sua vez, junta estas duas etapas ao transferir seu ponto de vista para um nvel mais abstrato, no qual o designer envia ao usurio uma meta-mensagem. Desta forma, a Engenharia Semitica d um zoom-out no processo de design e inclui a Engenharia Cognitiva. Assim, todos os resultados obtidos na Engenharia Cognitiva continuam sendo vlidas na Engenharia Semitica. No entanto, a interao usurio-sistema deixa de ser o foco da Engenharia Semitica, dando lugar para a expresso do designer e o processo de design como um todo. A Figura 2.6 mostra a relao entre as Engenharias Semitica e Cognitiva. Em outras palavras, a Engenharia Semitica d subsdios para se definir o plano de design, um processo semioticamente coeso e consistente, levando com segurana a mensagem do produtor (designer) ao consumidor (usurio).

Engenharia Cognitiva contexto

Engenharia Semitica contexto

contexto meio

designer

usurio

Figura 2.6 Relao entre Engenharia Cognitiva e Engenharia Semitica.

A conseqncia de a Engenharia Cognitiva focalizar na interao usurio-sistema que ela d margem para que se passe a idia de que existe uma soluo ideal para o problema do usurio. Quando isto acontece, o designer no deixa claro para o usurio que a soluo sendo oferecida uma dentre vrias e que esta soluo determinada por suas [do designer] interpretaes e decises de design. O usurio por sua vez no percebe que a aplicao a criao de uma outra pessoa e que pode conter interpretaes no ideais, ou at mesmo errneas, e muitas vezes trata a aplicao como se ela fosse infalvel ou, ao contrrio, como se ela que estivesse enganada sobre o domnio ou o usurio, e no o designer que a concebeu. Ao trazer o designer para dentro do foco, a Engenharia Semitica evidencia a sua presena e permite ao usurio entender que todo sistema uma soluo potencial de um designer (ou de uma equipe de design). Assim, o usurio, ao ter problemas de interao com a aplicao, pode tentar entender o que o designer pretendia, e acertar o seu modelo mental da aplicao, aproximando-o cada vez mais daquele do designer. Fazendo isto, o usurio capaz de alcanar um melhor entendimento das motivaes e decises tomadas pelo designer, e assim usar a aplicao de forma mais eficiente.

3. MODELOS E TCNICAS DE MODELAGEM EM IHC

3.1 Um modelo para o processo de design de interfaces
Design a atividade intelectual de conceber e descrever um produto a partir dos requisitos de seus potenciais usurios. Esta atividade requer tcnicas e ferramentas adequadas, aliadas criatividade, ao talento e experincia do designer. O produto concebido em uma atividade de design precisa ser apresentado atravs de um prottipo e/ou de uma especificao. A prototipao consiste na descrio do que foi concebido, utilizando materiais mais baratos e dimenses reduzidas. O objetivo poder fazer uma avaliao. A especificao consiste na descrio abstrata, rigorosa, idealmente correta e completa do produto, utilizando uma notao ou linguagem adequadas. A especificao e a prototipao permitem vises e formas de avaliao complementares do produto concebido. A especificao permite uma descrio e avaliao a partir de tcnicas associadas s notaes utilizadas. J a prototipao permite uma descrio e avaliao mais concreta do produto no contexto de utilizao. O design de interfaces de usurio uma atividade que requer anlise dos requisitos dos usurios, concepo, especificao e prototipao da interface, e avaliao da utilizao do prottipo pelos usurios. Diversos modelos do desenvolvimento de software baseados em prototipao argumentam que este processo deve ser realizado de forma cclica, isto , a avaliao deve levar a um novo design e ser posteriomente avaliado. Na abordagem da Engenharia Semitica, a mensagem do designer contempla tanto a funcionalidade quanto o modelo de interao. A interface , portanto, responsvel por fazer o usurio ter condies de interagir com a funcionalidade do sistema. O design da interface de usurio depende da especificao dos modelos de interao e da funcionalidade do sistema. A especificao da funcionalidade visa descrever quais funes o sistema deve oferecer para os usurios. Por funes entenda-se aquilo que permite ao usurio atingir as suas metas, independente de como implementado. Elas so chamadas aqui de funes do domnio numa referncia quelas funes do sistema aplicadas ao domnio. A especificao do modelo de interao visa descrever de forma abstrata e precisa como o usurio pode interagir com o sistema independente de quais dispositivos de interao ou widgets ele vai utilizar e de como este processo de interao ser implementado pelo software da interface. O objetivo descrever que o usurio pode comandar uma funo do sistema, que ele deve fornecer uma informao especfica ou que ele deve ler uma mensagem na tela. A partir desta descrio o designer da interface deve escolher qual o modelo de interao especfico (estilo ou padro) o usurio ir utilizar para interagir. A descrio abstrata oferece a vantagem de ser independente de estilo e ferramenta de interface.

No desenvolvimento de sistemas centrado-no-usurio a especificao da funcionalidade e a do modelo de interao so derivadas do modelo de tarefas (considerando tambm os diferentes perfis de usurios) e so a base para o restante do desenvolvimento. A partir destas especificaes o designer da interface deve realizar a especificao detalhada da interface de acordo com o modelo de interao, bem como a construo de um prottipo de interface. Num processo de design baseado em prototipao apenas este ltimo realizado. O prottipo da interface dever permitir uma avaliao da interao com os usurios do sistema. Esta avaliao pode ser feita utilizando-se dois tipos de testes bsicos: testes de usabilidade e testes de comunicabilidade. Os testes de usabilidade visam avaliar fatores relacionados com facilidade de uso, produtividade, flexibilidade e satisfao do usurio. Os testes de comunicabilidade visam avaliar as decises do designer em termos de escolhas de signos de interface para comunicar melhor o modelo conceitual da aplicao. Resumindo, o processo de design de interfaces inicia-se com a anlise de usurios e tarefas (que constitui a anlise de requisitos) e deve ser conduzido num processo cclico ou iterativo no qual cada passo apresenta evolues a partir da etapa anterior. Cada ciclo envolve a especificao da funcionalidade e do modelo de interao, a prototipao de interfaces (que possibilite a interao de acordo como o modelo especificado) e a sua avaliao junto aos usurios. A partir desta avaliao um novo ciclo de especificao, prototipao e avaliao deve ser realizado. Este processo pode ser visualizado na Figura 3.1. importante ressaltar que o design da interface pode (e deve) ser conduzido independentemente da implentao do software da interface.

especificao prototipao

anlise

avaliao

prottipos

Figura 3.1 Processo de design de interfaces.

3.2 Anlise e Modelagem de Usurios

O usurio deve sempre ser o foco central de interesse do projetista ao longo do design da interface. O objetivo da anlise e modelagem de usurios identificar quem so os usurios e caracteriz-los, isto , especificar quais funes exercem, quais capacidades possuem, etc. Podemos destacar os seguintes fatores de anlise de usurios: Papel (ou funo) especfico de cada usurio: definido pelas tarefas que ele realiza. Numa organizao, as pessoas trabalham juntas, de maneira estruturada. A estrutura da organizao define relacionamentos entre as

pessoas. A implicao imediata dos diferentes papis de cada usurio so as diferentes tarefas que eles iro realizar. Algumas tarefas podem ser comuns a diferentes papis de usurios, enquanto outras podem ser exclusivas de papis especficos. familiaridade com computadores: o grau de conhecimento e capacidade medido pela proficincia no uso de dispositivos de entrada (p.ex., teclado, mouse) e pela familiaridade com o modelo de interao do ambiente de interface. Esta capacidade pode ser adquirida pela experincia prvia com outras interfaces semelhantes, ou pela freqncia de uso. Os valores extremos desta medida so iniciante e experiente. Um usurio iniciante costuma cometer erros e precisa de auxlio e apoio extensivo ao aprendizado (e.g. help on-line e tutorial). Um usurio experiente no precisa de suporte extensivo, e prefere uma interao mais rpida, que oferea shortcuts (atalhos), para aumentar seu desempenho. Usurios iniciantes podem se tornar experientes atravs do uso freqente da aplicao. nvel de conhecimento do domnio da aplicao: um usurio que no tem conhecimento prvio do domnio da aplicao considerado novato, enquanto um usurio que conhece no apenas o domnio, mas tambm diferentes maneiras de realizar as tarefas considerado especialista. A interface projetada para um usurio novato deve proporcionar informaes sobre o estado da aplicao para guiar o usurio e oferecer dicas claras para recuperao de erros. Para um especialista, ela deve oferecer sofisticados recursos que lhe permitam estender a aplicao. freqncia de uso da aplicao: um usurio ocasional no melhora suas capacidades com o computador ou com a aplicao ao longo do tempo, e pode at diminu-las. Em contrapartida, a capacidade de um usurio freqente aumenta e suas necessidades de ajuda e apoio ao aprendizado diminuem ao longo do tempo, enquanto a necessidade de interao mais sofisticada aumenta. contexto scio-cultural: h um conjunto de fatores que visam analisar as diferenas scio-culturais entre os usurios da aplicao, tais como problemas de lnguas ou dialetos diferentes e tradies culturais distintas. Estes fatores tm grande importncia em aplicaes que sero distribudas em diversos pases, ou em diversas regies de um mesmo pas ( o caso de software de uso geral e software de companhias multinacionais).

Procedimento para conduo da anlise de usurios A anlise de usurios pode ser dividida em cinco etapas [Lee 1993]: 1. Identificar fatores de anlise crticos centrais para a aplicao. Nesta etapa, identificamos quais dos fatores citados acima tm importncia para a aplicao em questo. Por exemplo, em uma aplicao mono-usurio, a funo do usurio no um fator crtico para anlise. Alm disto, uma aplicao situada em um ambiente social comum tambm no apresenta diferenas scio-culturais.

2.

Explorar outros fatores crticos adicionais para a aplicao. Alm dos fatores bsicos citados acima, pode-se considerar outros, como a familiaridade com algum estilo de interface grfica (Windows, Macintosh, Motif, etc.), por exemplo. Estes fatores podem ajudar a determinar caractersticas do projeto e da aplicao que ainda no estejam especificadas, como plataforma, estilo de interao preferido, requisitos no-funcionais como eficincia e custo, etc. Ao identificar novos fatores crticos para a modelagem de usurio, importante definir tambm quais suas implicaes sobre o design da interface, ou seja, que aspectos da interface sero influenciados ou determinados para cada valor definido para estes fatores. Estimar a distribuio de usurios para cada fator. Aps identificar os fatores crticos, deve-se fazer um levantamento estimado do percentual de usurios em cada grupo de fator crtico. Por exemplo, pode-se estimar que 10% dos usurios sejam iniciantes, e 90% deles experientes com computadores. Mais que isto, aconselhvel ter em conta que nenhum usurio permanece novato para sempre, e que a aplicao deve tratar do ciclo de aprendizado inteiro. Identificar grupos majoritrios de usurios. Para cada fator preciso determinar qual a categoria dominante. Desta forma possvel ter um perfil do usurio majoritrio. Analisar a implicao coletiva da distribuio de usurios. A distribuio no deve ser um fator absoluto e alguns aspectos subjetivos podem ser considerados. Como vimos, deve-se considerar que usurios iniciantes vo adquirir experincia, e que isto pode mudar o modelo final de usurios. Por exemplo, em uma aplicao onde a maioria seja experiente no uso de computadores e no estilo de interao escolhido, deve-se priorizar o acesso rpido s funes, e no ao suporte extensivo ao aprendizado, com tutoriais detalhados. Contudo, preciso dar condies para os novatos se tornarem proficientes, com mdulos ou configuraes especiais a eles dedicadas.

3.

4.

5.

Como resultado da anlise e modelagem de usurio, temos a indicao dos requisitos mais importantes que devem estar presentes na interface a ser projetada. A partir desta indicao, os projetistas devem poder tomar decises acertadas sobre as caractersticas da interface.

Exemplo Questionrio para Anlise de Usurios

Para um sistema de bibliotecas, um questionrio para anlise dos usurios da biblioteca poderia conter os seguintes fatores: nvel de familiaridade com computador: iniciante, intermedirio, ou experiente nvel de familiaridade/especializao no domnio da aplicao (conhecimento sobre como realizar as mesmas tarefas sem o auxlio do computador): novato, intermedirio, ou especialista freqncia de uso: ocasional (menos de duas vezes por ms) ou freqente ambiente grfico preferido: Windows 95, Macintosh, ou indiferente

Exerccio

Para o mesmo sistema de bibliotecas, identifique os fatores crticos para anlise dos funcionrios da biblioteca, desde funcionrios que cadastram os livros at os funcionrios que atuam no emprstimo dos mesmos.

3.3 Anlise e Modelagem de Tarefas

O objetivo da anlise de tarefas fornecer ao designer a viso dos usurios das tarefas que eles precisam realizar. A modelagem de tarefas consiste em formalizlas de forma a mape-las na interface grfica. Cenrios Cenrios so narrativas textuais, pictricas ou encenadas, de situaes fictcias mas plausveis (seno desejveis) de uso situado da aplicao. Devem ser ricos em contextualizao e possuir um foco claro que transmita a usurios e designers as idias sendo testadas. O levantamento de requisitos sobre as tarefas e os usurios pode ser melhor realizado quando os analistas procuram descrever situaes do processo de trabalho. Os mtodos baseados em cenrios consistem de uma coleo de narrativas de situaes no domnio do problema que permitem a identificao de componentes de design. Assim, eles so um meio de representao de fcil compreenso para os usurios envolvidos (muitas vezes de formao bastante heterognea) que passam a poder avaliar, criticar e fazer sugestes. Eles permitem a reorganizao de componentes e tarefas do domnio. Isto ocorre porque quando se introduz novas tecnologias, parte do contexto de tarefa de uma organizao alterado. Nesta reengenharia, novas tarefas e prticas so incorporadas enquanto outras so eliminadas.

Exemplo Cenrio

Para o nosso sistema de bibliotecas, um cenrio de uso tpico seria: Um aluno chega na biblioteca para procurar livros-texto dos cursos que est freqentando. Ele entra no sistema e seleciona os cursos, e obtm uma lista de todos os livros-texto e sua localizao na biblioteca. Seleciona a opo de bibliografia complementar , e uma nova lista de livros e artigos lhe apresentada. Ele ento manda imprimir todas as referncias encontradas.

Exerccio

Elabore um cenrio de uso para situaes de consulta em uma biblioteca. Em seguida, entreviste alguns usurios de bibliotecas para elaborar cenrios para a mesma situao. Note as diferenas entre o ponto de vista do designer (o seu) e do usurio (seus entrevistados). Repita este exerccio para outras situaes, como por exemplo, para tarefas dos funcionrios de uma biblioteca. Os cenrios tambm podem ser utilizados para formar uma base de casos [Carey & Rusli, 1995], que pode ser utilizada tanto no aprendizado de IHC quanto no reuso de designs. Neste caso, ao invs de se utilizar cenrios para tentar prever possveis situaes de uso, os cenrios so registros de situaes reais, que podem ser comparadas em diversos nveis, como em desempenho e eficincia de determinadas escolhas e decises de design. Anlise de Tarefas Utilizando Cenrios: Tcnica de Questionamento Sistemtico A descrio de informaes do domnio atravs de narrativas s efetivamente realizada se o processo de compreenso por parte dos analistas e projetista for realizado de maneira sistemtica [Carroll et al., 1994]. A tcnica apresentada aqui pode ser utilizada, segundo os autores, tanto para mtodos de anlise e design orientado a objetos quanto para interao usurio-sistema. O questionamento sistemtico uma tcnica de psico-lingstica que permite a psiclogos e lingistas examinar o contedo e a estrutura de informaes contidas numa narrativa. Uma narrativa um sumrio de um conjunto de eventos e aes envolvendo agentes e objetos do mundo. Nem todas as informaes integrantes do contexto so passadas atravs da narrativa. Muitas destas informaes so inferidas do conhecimento cultural de cada indivduo. Outras, entretanto, precisam ser obtidas diretamente na fonte, isto , junto ao autor da narrativa. Essa tcnica foi desenvolvida para se entender melhor o processo de compreenso de estrias em narrativas. O objetivo compreender tudo o que envolve o

contexto daquilo que est sendo passado na narrativa. Assim, analistas e projetista podem utilizar esta tcnica para adquirir mais eficazmente conhecimento sobre o domnio e inferir objetos e interaes que no esto descritos na narrativa. So realizadas diversas questes sobre cada componente da narrativa. As respostas a estas questes servem de ponte entre uma idia e outra, e revelam novas conexes cruciais para o entendimento preciso da narrativa. A tcnica de questionamento sistemtico pode ser decomposta nos seguintes passos: 1. Gerao do cenrio. As narrativas que compem o cenrio devem ser escritas pelo especialista no domnio. O analista pode motiv-lo fazendo perguntas como num processo convencional de entrevista. Um exemplo de cenrio seria: Eu quero sacar R$100,00. Eu insiro o carto do banco no caixa eletrnico, pressiono o boto de saque rpido, digito minha senha, retiro o dinheiro e o carto. 2. Elaborao da rede de proposies. As narrativas devem ser simplificadas e expressas atravs de proposies, como por exemplo, cliente insere carto no caixa eletrnico; cliente pressiona boto de saque rpido; cliente digita senha; cliente pega dinheiro; cliente retira carto. Anlise. A partir das proposies, pode-se determinar o perfil das tarefas (aes e objetos) e dos usurios (agentes das aes). Questionamento sistemtico. Novas proposies podem ser elaboradas atravs de questes que so feitas sobre elementos das proposies anteriores, num processo iterativo. Existem diversos tipos de questes, dentre as quais destacamos: Por que ? Estas questes visam revelar conseqncias e causas a respeito de eventos da narrativa. Como ? Estas questes oferecem maiores detalhes a respeito de determinados eventos, permitindo determinar sub-tarefas e maiores detalhes sobre a interao. O que ? Questes deste tipo podem ser feitas sobre objetos, e revelam atributos e hieraquias de objetos. Ento isto /ocorre assim? Perguntas de verificao podem ser feitas para se saber se as proposies esto sendo entendidas corretamente. Estas perguntas tm resposta sim ou no. Uma taxonomia mais completa ainda est sendo pesquisada pelos autores do mtodo.

3. 4.

Exerccio

Para o cenrio apresentado no exemplo anterior, elabore a rede de proposies, faa uma anlise e levante as questes sobre os elementos destas proposies.

Modelos de Tarefas Existem diversos modelos de tarefas, cada qual com notao e objetivos especficos, dentre os quais podemos destacar: TAG (Task-Action Grammar) [Payne & Green, 1989]: gramtica gerativa, onde so especificadas aes a partir das tarefas. A tcnica consiste em identificar tarefas simples, represent-las de forma categorizada e atravs de regras de produo. Esta notao permite tratar diversos tipos de consistncia, a nvel lexical, sinttico e semntico. Permite ainda verificar a completeza do modelo UAN (User Action Notation) [Hix & Hartson, 1993]: utilizado principalmente para interfaces de manipulao direta, onde representa aspectos do comportamento do sistema do ponto de vista do usurio, ou seja, que tarefas e aes o usurio realiza na interface. Este modelo associa as aes do usurio ao feedback do sistema, ao estado do sistema e ao modelo computacional da aplicao. GOMS (Goals, Operators, Methods, and Selection Rules) [Card et al., 1983]: este modelo pretende representar o comportamento dinmico da interao com o computador, com base num modelo do comportamento humano que possui trs subsistemas de interao: o perceptual (auditivo e visual), o motor (movimentos brao-mo-dedo e cabea-olho), e cognitivo (tomadas de deciso e acesso a memria). Este comportamento definido por: metas (goals), que podem ser decompostas numa hierarquia de sub-metas; operadores (operators), que so os atos perceptivos, motores ou cognitivos bsicos que os usurios devem executar para afetar o ambiente da tarefa; mtodos (methods), que so sequncias de passos para se atingir uma meta; e regras de seleo (selection rules), expresses do tipo condio ao, que devem ser utilizadas para selecionar um determinado mtodo para atingir uma meta, sempre que houver mais de um mtodo disponvel para tanto.

Modelo Keystroke-Level [Card et al., 1983]: este modelo faz parte da famlia GOMS de modelos, mas em um nvel mais baixo, o nvel de atividade motora. O objetivo aqui prever o tempo que o usurio leva para realizar uma tarefa. So considerados os operadores primitivos, como uma tecla digitada, um boto clicado, os atos de apontar, de levar a mo at um dispositivo, desenhar, realizar uma operao mental e esperar a resposta do sistema. Os tempos de execuo de uma tarefa so calculados sobre mtodos, que so seqncias de operadores.

Abordaremos a anlise de tarefas atravs de um modelo GOMS simplificado [Lee, 1993]. O GOMS permite que se construa modelos de tarefas bem mais complexos

e detalhados do que o necessrio numa tarefa de anlise para a construo de interfaces. Usaremos uma verso simplificada do GOMS, pois: o modelo da tarefa no dever descrever informaes de design da interface, uma vez que ela ainda no foi construda; o analista no um especialista em psicologia cognitiva; o modelo simplificado pode ser expandido para o original, caso seja necessrio.

Procedimento para conduo da anlise de tarefas 1. 2. 3. 4. 5. 6. 7. Faa a anlise top-down. Comece pelas metas mais gerais, e v acrescentando detalhes em direo s mais especficas. Use termos gerais para descrever metas. No use termos especficos de interfaces. Examine todas as metas antes de subdividi-las. Isto facilita o reuso de metas. Considere todos os cenrios de tarefas. Utilize regras de seleo para representar alternativas. Use sentenas simples para especificar as metas. Estruturas complexas indicam a necessidade de decompor uma meta em sub-metas. Retire os passos de um mtodo que sejam operadores. Os operadores so dependentes da interface, e no so tratados no modelo GOMS simplificado. Pare a decomposio no limite do design da interface. A modelagem GOMS deve terminar quando as descries estiverem to detalhadas que os mtodos sejam operadores ou envolvam pressuposies de design.

Para aplicaes com mltiplas funes de usurios, temos algumas orientaes especficas: Inicie especificando metas de alto nvel para cada funo de usurio. Se uma meta for compartilhada por mais de uma funo de usurio, identifique estas funes de usurio ao definir a meta. Isto torna-se desnecessrio se a meta for compartilhada por todas as funes de usurio.

Exemplo Modelagem de Metas

Em nosso sistema de biblioteca, teramos as seguintes funes de usurio: FU1 (usurio da biblioteca), FU2 (funcionrio responsvel pelo emprstimo), FU3 (funcionrio responsvel pelo cadastro dos exemplares). As metas de alto nvel poderiam ser: *; 1: consultar uma referncia (um asterisco * representa todas as funes de usurio)

FU1, FU2; 2: reservar um exemplar FU2; 3: registrar um emprstimo FU2; 4: registrar uma renovao de emprstimo FU2; 5: registrar uma revoluo FU3; 6: cadastrar um exemplar FU3; 7: alterar dados de um exemplar FU3; 8: remover dados de um exemplar

Exemplo Modelagem de Tarefa

Vamos modelar a tarefa *;1: consultar uma referncia. *;1. consultar uma referncia // nmeros indicam a estrutura das metas (1, 1.1, 1.2, 2, etc.) *;1.1a: se (conhecer dados precisos sobre a referncia) // letras indicam regras de seleo ento (realizar busca) { 1: iniciar busca // mtodos so representados entre chaves 2: digitar dados conhecidos 3: disparar busca 4: verificar dados apresentados 5: encerrar consulta } se (no conhecer dados precisos sobre a referncia) ento (realizar varredura) { 1: iniciar varredura 2: comparar referncia apresentada com a referncia desejada 3a: se (referncia apresentada no for a desejada e houver prxima referncia) ento ({ 3a.1: ir para a prxima referncia 2: comparar referncia apresentada com a referncia desejada //reuso }) 3b: se (referncia apresentada for a desejada ou estiver na ltima referncia) ento (encerrar consulta) }

*;1.1b:

Exerccio

Modele as outras tarefas. Sempre que possve, reutilize metas e mtodos.

3.4 Modelagem de Comunicao

Na modelagem de comunicao, o designer tem que definir o que vai dizer, e como. Trata-se de organizar e transmitir aos usurios respostas s duas perguntas fundamentais da Engenharia Semitica: 1. Qual a interpretao do designer sobre o(s) problema(s) do usurio? 2. Como o usurio pode interagir com a aplicao para resolver este(s) problema(s)?

Partindo-se das modelagens de usurios e de tarefas, organizamos as mensagens utilizando signos. Cada signo possui dois aspectos: expresso, que o que se percebe, e contedo, que o que o signo significa ou representa. A expresso do signo deve revelar seu contedo, ou seja, transmitir informaes sobre seu significado e comportamento. Uma tela pode ser considerada um signo complexo, composto de diversos outros signos. O modelo para a interface como expresso permite ao designer construir uma expresso atravs de signos de interface. Estes signos so dispostos espacial e temporalmente no medium interface, que no caso das interfaces convencionais a tela do computador. A estruturao do contedo da mensagem motivada pelo modelo do processo de interao apresentado por Norman que descreve os passos necessrios para o usurio realizar o mapeamento tarefa-ao [Norman, 1986]. O modelo conceitual da aplicao deve conter funes de aplicao ou do domnio que o usurio possa utilizar para atingir as metas estabelecidas. Estas funes atuam sobre signos que representam conceitos do domnio e so chamado de signos do domnio. As funes da aplicao so controladas por uma estrutura de aes que compem um comando de funo. A ativao de uma funo pelo seu comando causa uma mudana no estado dos signos do domnio. Os signos do domnio, as funes da aplicao e os comandos de funes so os tipos de elementos bsicos que formam o contedo da mensagem e precisam ser expressos atravs dos signos de interface.

Figura 3.1 Exemplo de interface para uma funo de aplicao

No exemplo da Figura 3.1, temos uma nica funo da aplicao a funo busca. So signos do domnio publicaes e autores. A interface apresenta para o designer o comando associado a esta funo e indica quais so as informaes sobre os signos do domnio e como o usurio pode acionar os controles da funo. Para apoiar a comunicao dirigida do designer para os usurios, criamos a LEMD (Linguagem de Especificao de Mensagens do Designer [Leite, 1998]). A LEMD diferencia os seguintes tipos de mensagens: Mensagens de metacomunicao direta, que permitem ao designer enviar uma mensagem diretamente ao usurio para se referir a qualquer componente de usabilidade. Esta mensagem especificada atravs do elemento View da LEMD. Na Figura 3.1, o texto que vem na parte superior da janela Preencha o formulrio com os dados... uma mensagem do designer que apresenta a funo e as aes que o designer deve desempenhar para comand-la. Mensagens sobre estados de signos do domnio, que revelam o estado do sistema e permitem ao usurio avaliar se a sua meta foi atingida. O estado de um signo como ttulo da publicao deve ser representado adequadamente para os usurios. O designer deve decidir, por exemplo, se melhor comunicar este signo atravs de tabelas de nmeros ou de grficos. Como resultado da busca efetuada pela funo ilustrada pela Figura 3.1, o designer pode utilizar texto para representar o signos do domnio: nome do autor, ttulo e data da publicao, editora, ISBN, nmero de referncias encontradas e escopo da busca. Mensagens sobre funes da aplicao, revelando o estado operacional de cada funo e o que o usurio deve fazer para control-la. Uma das grandes deficincias das aplicaes atuais falta de representao e controle operacional de funes. Na maioria das vezes o nico retorno que o usurio tem o resultado final. O designer deve poder mostrar o desempenho do sistema e permitir que o usurio interrompa ou reinicie quando a funo estiver sendo executada. No mostramos mensagens sobre o estado operacional da funo de busca. Entretanto, um signo que mostre se a funo

est realizando a busca ou se houve alguma interrupo um exemplo de mensagem deste tipo. Mensagens sobre interaes bsicas indicando ao usurio a interao a ser desempenhada. As interaes bsicas previstas na linguagem so acionar (Activate), fornecer informao (Enter) e selecionar informao (Select). O acionamento pode ser comunicado atravs de botes de acionamento. O fornecimento de informaes, expresso na LEMD atravs de Enter pode ser expresso por diversos widgets. Para o usurio fornecer as informaes textuais sobre as referncias no exemplo da Figura 3.1, o designer optou por utilizar campos de texto (text boxes), e para o acionamento da busca um boto de comando (command button). Mensagens sobre a estrutura sinttica dos comandos, ou seja, a estrutura e a articulao das interaes que o usurio precisa desempenhar. A estrutura sinttica determina como as interaes bsicas podem ser articuladas na formao de comandos compostos. As interaes podem ser agrupadas em seqncia (Sequence), repetio (Repeat), agrupamento (Join), combinao (Combine) e seleo (Select). Na interface para o comando impresso utilizamos algumas destas estruturas. Por exemplo, para que o usurio possa fazer o controle operacional da funo ele deve primeiro fornecer as informaes associadas aos signos do domnio. Neste caso, existe uma estrutura seqencial expressa por um layout vertical e pela cor cinza do boto de acionamento, dando a idia de que eles no est disponvel, at que o usurio fornea as informaes nos campos superiores.

Mensagens de metacomunicao para apresentao e controle da leitura da mensagem que comunicam como o usurio deve ler a prpria mensagem do designer. A navegao entre telas, mover, aumentar e diminuir janelas so exemplos de aes que o usurio faz para ler a interface, como quem folheia um livro. Estas aes do usurio no modificam o estado funcional do sistema e, portanto, no so considerados comandos em nosso modelo. A LEMD diferencia os controles de leitura dos comandos convencionais chamando a ateno do designer para este aspecto. Uma especificao completa da LEMD [Leite, 1998] no necessria para esta introduo a IHC. Porm, podemos exemplificar os efeitos de us-la atravs do exemplo que utilizamos. A especificao do modelo de interao pode ser descrita como uma mensagem utilizando a LEMD. A especificao da mensagem que comunica este modelo a seguinte.
Task-Message Busca Join { View "Preencha o formulrio com os dados da publicao" Sequence { Join { Enter Information-of Autor Enter Information-of Ttulo Enter Information-of ISBN } Join { Activate Start Application-Function Realiza busca Activate Waive Application-Functi on Realiza busca } }

A mensagem acima deve ser expressa atravs dos widgets de uma interface grfica. As construes da interface esto associadas a regras de correlao de acordo com a Tabela 3.1.
Sequence Join Enter Activate Configurao espacial com os elementos da seqncia em cinza claro indicando no disponvel Configurao espacial (agrupamento visual) Campos para digitao de valores. Boto de acionamento Tabela 3.1 Regras de mapeamento semntico utiliza

A partir da especificao da mensagem do designer e aplicando as regras de correlao associadas a signos de interface da ferramenta Microsoft Visual Basic, pode-se elaborar a mensagem final mostrada na Figura 3.1.

3.5 Storyboarding
Esta tcnica envolve a especificao atravs de imagens que descrevam certas situaes que esto sendo planejadas. Como permite descrever situaes de uso, esta tcnica est bastante relacionada com cenrios. Entretanto, enquanto cenrios utilizam principalmente narrativas para a descrio dos casos de uso, o storyboarding utiliza desenhos e ilustraes, utilizando papel ou computadores. Assim, os cenrios so mais adequados para a anlise das tarefas, enquanto storyboards permitem a validao dos cenrios e a elaborao de prottipos no operacionais para designs iniciais. Alm disto, o storyboarding usado de maneira mais livre. A Figura 3.2 apresenta um exemplo de storyboard gerado a partir do cenrio exemplificado na seo 3.3.

Figura 3.2 Storyboard para consulta em uma biblioteca.

3.6 Ferramentas de Apoio Construo de Interfaces

Uma interface grfica composta de diversos componentes visuais interativos, chamados widgets. Para cada ambiente grfico, geralmente existe uma ou mais

bibliotecas de widgets. Uma biblioteca define padres de aparncia e comportamento da interface, chamados comumente de look and feel de uma interface grfica. Para implementar interfaces grficas utilizando widgets, utilizamos toolkits. Um toolkit pode ser utilizado para mais de uma plataforma, ou para uma plataforma especfica. Um toolkit oferece uma ou mais bibliotecas de widgets. Ferramentas de alto nvel para apoio construo de interfaces facilitam a utilizao de toolkits e sistemas de janelas para a construo de interfaces grficas. Geralmente so ferramentas de implementao, permitindo construir desde prottipos a sistemas inteiros. Para o ambiente Windows, por exemplo, o Microsoft Visual Basic e o Borland Delphi podem ser considerados ferramentas de apoio construo de interfaces grficas. importante notar que a utilizao de ferramentas de apoio construo de interfaces no o suficiente para garantir a qualidade da interface resultante. Elas devem ser utilizadas aps terem sido feitas anlises e modelagens de usurios, de tarefas e de comunicao da aplicao, ou seja, aps o designer ter toda a informao necessria para tomar decises de design acertadas. Existem diversos esforos de pesquisa no sentido de criar ferramentas de apoio ao design de interfaces. Seguindo a abordagem da Engenharia Semitica, desenvolvemos a Linguagem de Especificao de Mensagens do Designer [LEMD Leite, 1998] e modelos de design da interao de aplicaes de manipulao direta [Martins, 1998], multi-usurio [Prates, 1999], e de aplicaes extensveis [Barbosa, 1999; da Silva et al., 1997]. Um dos objetivos destes trabalhos justamente possibilitar a criao de ferramentas que auxiliem o designer a comunicar suas intenes e pressuposies aos usurios, atravs da interface da aplicao.

4. AVALIAO DE INTERFACES
A avaliao da interface um importante passo do processo de design, afinal atravs dela que se consegue estimar o sucesso ou insucesso das hipteses do designer sobre a soluo que ele est propondo, tanto em termos de funcionalidade, quanto de interao. Ainda que o designer se baseie em uma abordagem terica e conte com a ajuda de diretrizes e princpios de design, necessrio que ele avalie o resultado obtido [Hartson, 1998]. As avaliaes de interface podem ser classificadas como formativas ou somativas [Preece et al., 1994; Hartson, 1998]. As formativas so aquelas que so feitas durante o processo de design, permitindo que identifique e conserte um problema de interao antes que a aplicao seja terminada, ou at mesmo antes de ser implementado. As somativas, por sua vez, avaliam o produto j terminado. Existem vrios mtodos possveis para se coletar e analisar dados. A escolha de qual mtodo deve ser aplicado em um caso especfico depende de vrios fatores, como o que se deseja avaliar, disponibilidade de pessoas especialistas, ambiente e equipamento para aplicar o teste, acesso ao usurio e dentre outros. Muitas vezes

fatores como o oramento ou tempo disponvel que decidem o mtodo de avaliao a ser aplicado. A maior parte dos mtodos de avaliao existentes podem ser descritos como observao e monitorao de usurios, coleta da opinio dos usurios, experimentos ou testes de benchmark, interpretao de interaes que ocorrem naturalmente, ou ainda predio do uso a ser feito da aplicao. Observao e monitorao de usurios normalmente feita informalmente, ou no ambiente de trabalho do usurio ou em um laboratrio, e os dados so coletados atravs de notas do observador ou algum tipo de gravao, como por exemplo de vdeo. Coletar a opinio dos usurios to importante quanto avaliar o seu desempenho, uma vez que se os usurios no gostarem da aplicao por qualquer razo, eles no a usaro. A aplicao de experimentos e testes de benchmark em IHC normalmente adotam uma perspectiva semi-cientfica em comprarao com o que normalmente associado a eles. Isto porque as variveis a ser medidas envolvem interaes complexas com seres humanos e o valor obtido muitas vezes pode ser questionado. Assim, este tipo de avaliao normalmente se refere a tcnicas mais rigorosamente controladas do que em observao e monitorao de usurios (mesmo que as tcnicas sejam as mesmas). O objetivo de mtodos interpretativos permitir que o designer entenda melhor como usurios usam o sistema em seu ambiente natural e como estes sistemas integram com outras atividades. Assim, dados so coletados informalmente e depois interpretados pelos designers. Muitas vezes os usurios participam da coleta, anlise ou interpretao dos dados. Mtodos de predio buscam prever os tipos de problemas que os usurios tero ao usar o sistema, sem no entanto test-lo com usurios de fato. Normalmente estes mtodos envolvem tcnicas de modelagem psicolgicas dos usurios ou mtodos de inspeo, nos quais especialistas em interfaces avaliam o sistema em relao aos problemas que os usurios possivelmente tero.

Nas prximas duas sees apresentaremos duas tcnicas de avaliao de interfaces em mais detalhes, Testes de Usabilidade e Testes de Comunicabilidade.

Exerccio

Compare os mtodos de avaliao formativa e somativa de interfaces. Que vantagens e desvantagens voc esperaria de cada um deles?

4.1 Testes de Usabilidade

O objetivo de testes de usabilidade medir quantitativamente o valor alcanado pelo sistema em cada um dos fatores de usabilidade de interesse (ver seo 1.3).

Para isto, so executados experimentos com os usurios e os valores de cada um destes fatores medido. Com base na interpretao dos resultados obtidos com os testes, o designer conclui se os valores atingidos so ou no satisfatrios. Uma das tcnicas formativas mais conhecidas de testes de usabilidade a Engenharia de Usabilidade [Nielsen, 1993]. Ela um mtodo que permite que se aplique um procedimento sistemtico para se testar a usabilidade de um produto durante o seu desenvolvimento. Para aplic-la o designer define quais so os fatores de usabilidade prioritrios ao seu design e define o valor quantitativo desejado para cada um destes aspectos. Para que esta deciso seja tomada, o designer deve conhecer ou medir os valores destes fatores no momento de incio do projeto1. Durante o desenvolvimento do sistema estes valores so medidos e usados para determinar se as metas do sistema j foram alcanadas. importante ressaltar que os valores definidos como objetivos devem ser valores realistas, seno alcan-los pode se tornar uma tarefa impossvel ou fazer com que o custo de atingi-las seja maior que o benefcio.
Exemplo Fatores Crticos para Usabilidade

Alguns fatores crticos em um sistema de consulta para um usurio de biblioteca so apresentados na tabela a seguir:
fator taxa de aprendizado uso inicial uso espordico, aps 2 semanas sem uso preferncia sobre fichas impressas avaliao inicial avaliao de usurio experiente restries ao uso do sistema mtodo de medio comparao entre primeira e segunda medies tempo para realizar uma consulta nmero de vezes em que o sistema de ajuda acessado em cada tela questionrio pior caso mesma coisa nvel almejado segunda medio melhor 1,5 min nenhuma vez melhor caso muito melhor 0,5 min nenhuma vez

20 min mais de uma vez

igual

questionrio sobre impresses questionrio sobre impresses questionrio

neutro neutro

maior preferncia ao sistema positivo positivo

nenhuma preferncia s fichas muito positivo muito positivo nenhuma

muitas

poucas

O processo de design pode ser ento caracterizado como sendo uma iterao design-avaliao-design. A cada iterao o designer avalia os valores dos fatores

Mesmo que ainda no exista um sistema que auxilie o usurio na execuo da tarefa, os valores atuais (por exemplo, tempo de execuo da tarefa ou nmero de erros cometidos usando lpis e papel) devem ser medidos [Newman & Lamming, 1995]

para ver se estes j alcanaram o valor desejado. Caso ainda no tenham, o designer precisa definir como proceder para que estes valores sejam atingidos.

Exerccio

O exemplo anterior mostra alguns fatores relevantes para o sistema de biblioteca. Que outros fatores voc citaria como importantes? Descreva um cenrio onde as prioridades dos fatores de usabilidade seriam diferentes das definidas no exemplo. Observao: Considerando o mesmo cenrio, o designer pode definir as prioridades de forma diferente. Por exemplo, pode considerar o fator satisfao do usurio mais importante que rapidez na recuperao da informao .

4.2 Testes de Comunicabilidade

O mtodo de avaliao da comunicabilidade [de Souza et al., 1999] de um software baseado na Engenharia Semitica (ver seo 2.2) e tem como objetivo avaliar a sua interface com relao sua propriedade de comunicabilidade (ver seo 1.3). Para isto, este mtodo prope um conjunto de interjeies que o usurio potencialmente pode usar para se exprimir em uma situao onde acontece uma ruptura na sua comunicao com o sistema. Estas interjeies de fato no so direcionadas aplicao, mas sim ao seu designer. A aplicao do mtodo pode ser dividida em duas etapas: a coleta de dados e a anlise destes dados. Os passos para se fazer a coleta so: 1. Solicitar ao usurio a execuo de uma tarefa pr-determinada na aplicao 2. Gravar a interao do usurio com a aplicao, usando para isto um software de captura as aes do usurio, como por exemplo o Lotus ScreenCam . Anotaes do aplicador do teste e gravao em vdeo podem ser feitos para enriquecer os dados. Entrevista com o usurio (opcional) sobre a sua interao com a aplicao. Uma vez coletados os dados passa-se para sua anlise: Ver gravaes da interao e atribuir a interjeio apropriada nos momentos de ruptura da interao. Tabular a informao obtida, ou seja, as interjeies obtidas Interpretar a tabela de acordo com as interjeies e os problemas de usabilidade associados a elas, obtendo ento um mapa dos pontos crticos da interao e um perfil da interao da aplicao.

3. 4. 5. 6. 7.

A escolha das interjeies foi feita de forma a se obter um conjunto capaz de expressar as rupturas de interao que acontecem durante o uso de uma aplicao, e ao mesmo ser natural, ou seja, interjeies que fazem parte do cotidiano das pessoas e que potencialmente seriam expressas pelos usurios nestas situaes. A

seguir apresentamos o conjunto de interjeies, seus significados e sintomas, ou seja, aes que permitem atribuir uma determinada interjeio (e no outra) situao. Cad? / E agora? Usurio procura em menus e toolbars por uma funo especifica que ele deseja executar. No caso do E agora? o usurio no sabe o que fazer e tenta descobrir qual o seu prximo passo. Sintomas: Usurio inspeciona menus, sub-menus e tooltips (dicas) sem, no entanto, executar nenhuma ao. Que isso? O usurio tenta descobrir o que significa um objeto ou ao da interface. Sintomas: Usurio coloca cursor sobre algum smbolo da interface esperando um tooltip, ou procura o help daquele smbolo, ou ainda hesita entre duas opes que lhe paream equivalentes. Epa! / Onde estou? O usurio executa uma ao que no era a desejada e imediatamente o percebe, desfazendo ento a ao. No caso do Onde estou? o usurio, sem perceber, executa aes que apropriadas para outros contextos, mas no para o que ele se encontra. Sintomas: Usurio executa uma ao e em seguida a desfaz. Por que no funciona? / U, o que houve? A ao executada no obtm o resultado esperado, no entanto, o usurio no entende porque este resultado no foi alcanado. Assim, ele insiste, acreditando que ele tenha cometido algum erro na execuo da ao. No caso do U, o que houve? o usurio no tem feedback do sistema e no consegue entender o resultado da sua ao. Sintomas: Usurio executa uma ao e no percebe, entende ou aceita o resultado. Ele ento repete os mesmos passos para conferir o resultado. Para mim est bom O usurio obtm um resultado que ele acredita ser o desejado, mas que no o . Sintomas: Usurio d a tarefa por terminda sem, no entanto, perceber que no alcanou o resultado desejado. No d. O usurio no capaz de alcanar o objetivo proposto, ou porque os recursos (tempo, pacincia, informao desejada, etc.) no estavam disponveis, ou porque ele no sabia como. Sintomas: Usurio abandona a tarefa sem ter conseguido atingir seu objetivo. Deixa pra l / No, obrigado. O usurio no entende as solues de interao primrias oferecidas pelo designer, e resolve seu problema de alguma outra forma. No caso do No, obrigado. ele entende a soluo, mas prefere outras formas de interao. Sintomas: Usurio no encontra a forma de interao principal oferecida para se executar uma ao, ou ento decide no us-la. Note-se que este caso tipicamente segue uma interjeio de Onde est?

A maior parte dos problemas de interao e usabilidade podem ser classificados como sendo de falha na execuo da tarefa, navegao, atribuio de significado

ou de no percepo. Problemas de falha na execuo da tarefa so os mais graves, uma vez que o usurio no neste no consegue atingir o seu objetivo que o levou a usar a aplicao. Os de navegao se referem queles nos quais os usurios se perdem durante a interao com o sistema. Os de atribuio de significado, conforme o nome diz, o usurio no capaz de atribuir um significado (relevante) a signos encontrados na interface. Finalmente, no caso dos de no percepo aspectos da interface e da aplicao passam despercebidos ao usurio. Na Tabela 4.1 mostramos como as interjeies acima podem ser associadas a estas classes de problemas, e acrescentamos ainda mais uma: a de recusa de formas de interao. Neste caso, por algum motivo o usurio decide no usar algumas destas formas disponibilizadas pelo designer.
Interjeio Cad? E agora? Que isso? Epa! Onde estou? Por que no funciona? U o que houve? Para mim est bom No d. Deixa para l No, obrigado. Problema Navegao Atribuio de significado Navegao / Atribuio de significado Atribuio de significado Atribuio de significado Falha de execuo da tarefa Incompreenso de como usar affordance Recusa de usar affordance

Tabela 4.1 Associao entre interjeies e problemas de interao e usabilidade.

Exemplo Ruptura de Comunicabilidade

Considere a tela de consulta abaixo. O usurio que esteja familiarizado com o ambiente Windows espera que os botes de opo sejam mutuamente exclusivos. Entretanto, dois deles esto selecionados simultaneamente. Ao se deparar com uma situao destas, o usurio tipicamente se pergunta O que houve? ou Por que no funciona?. Observe que, neste caso, funcionar diz respeito s expectativas do usurio com relao ao comportamento de botes de opo.

Este exemplo revela uma ruptura de atribuio de significado, entre o comportamento esperado, transmitido pela escolha de um determinado componente de interface, e o comportamento real deste componente. Sempre que se utiliza componentes de uma biblioteca de widgets, fundamental conhecer seu comportamento e em que contextos de uso devem ser utilizados. Que critrios deveriam ser levados em conta na seleo de uma tarefa para um teste de comunicabilidade? Os pontos onde o designer est ciente ou acredita que possa haver ruptura de comunicao. Alguns destes pontos podem surgir devido ao dilema de comunicabilidade. Pontos crticos da aplicao, ou seja, onde o usurio no pode errar.

Exerccio

Classifique as rupturas de comunicabilidade que podem ocorrer na seqncia de telas a seguir.

usurio clica em Busca

4.3 Testes de Usabilidade x Testes de Comunicabilidade

Apesar de os testes de usabilidade e comunicabilidade serem capazes de identificar alguns problemas comuns, eles focalizam diferentes aspectos da interface. Testes de usabilidade fornecem medidas quantitativas sobre o produto, mesmo que durante o processo de design. Assim, mesmo que atravs deles se determine aspectos do produto que precisam ser modificados, eles no fornecem nenhum indicador de que ao tomar para se alcanar o resultado desejado. Os testes de comunicabilidade tambm geram medidas quantitativas e estas podem ser usadas para avaliar os problemas mais graves, ou pelo menos mais freqentes, de interao e usabilidade do produto. No entanto, estes testes fornecem tambm uma avaliao qualitativa da interface, medida que identificam pontos de ruptura da comunicao entre designer e usurios2. Como a identificao feita atravs das interjeies potenciais do usurio, ela no apenas
2

Estes pontos de ruptura identificam uma mudana do nvel de abstrao desta comunicao, uma vez que quando isto acontece a conversa entre designers e usurios deve deixar de ser sobre o problema sendo resolvido e passar a ser sobre a interao.

aponta que existe uma ruptura, mas ela tambm informa ao designer o que foi que o usurio no entendeu, e d indicadores de que tipo de informao precisa ser alterada ou acrescentada para que ele entenda. Tanto testes de usabilidade quanto de comunicabilidade podem funcionar tanto como formas de avaliao formativa ou somativa. No entanto, vale a pena ressaltar que para se aplicar e analisar testes de usabilidade, necessrio ser especialista, tanto em interfaces, quanto em usabilidade. J em testes de comunicabilidade, como as interjeies so parte do vocabulrio cotidiano das pessoas, outros designers (no especialistas em interface ou comunicabilidade), ou at mesmo usurios poderiam participar da etapa de identificao de rupturas e coleta de dados3. As etapas de anlise e de propostas de soluo continuam tendo que ser feitas por um especialista. Entretanto, designers e usurios que tivessem participado da etapa anterior poderiam ser colaboradores e fornecer insights interessantes, uma vez que eles saberiam quais so os problemas a serem resolvidos. Por avaliarem diferentes aspectos da interface, em certas situaes pode-se desejar aplicar ambos, de forma complementar, a uma mesma interface. Assim, se teria medidas quantitativas e qualitativas da interface que dariam indicaes tanto sobre aspectos do desempenho desta interface, quanto da sua qualidade de comunicao.

Exerccios

Crie um cenrio que ilustre uma situao onde um teste de usabilidade seja mais apropriado. Faa o mesmo para teste de comunicabilidade. Voc consegue imaginar um cenrio onde uma avaliao de comunicabilidade no tenha nada para acrescentar, quando comparado a uma avaliao de usabilidade? E o contrrio?

4.4 Prototipao
Um prottipo uma aplicao, normalmente experimental e incompleta, que permite aos designers avaliarem suas idias de design durante o processo de criao da aplicao pretendida. Ele deve ser construdo rapidamente e com baixo custo e seu tempo de vida no definido. Dentre as informaes extradas de um prottipo, podemos destacar a funcionalidade necessria ao sistema, seqncias de operao, necessidades de suporte ao usurio, representaes necessrias, look and feel da interface [Preece et al., 1994] e comunicabilidade da aplicao. Um prottipo pode ser classificado em relao sua funo no processo de desenvolvimento, o seu objetivo de avaliao e a tcnica de sua construo. Em relao sua funo no processo de desenvolvimento ele pode ser classificado como:
3

Esta facilidade faz com que esta etapa do teste de comunicabilidade possa ser feita com um oramento menor, onde se tem a participao dos prprios clientes.

Funo Apresentao

Descrio Permite ao designer apresentar ao cliente a sua percepo do sistema, mostrando que ele vivel e que a sua interface se adequa aos requisitos do usurio. Ilustra aspectos especficos da interface de usurios ou da funcionalidade, ajudando na compreenso dos problemas envolvidos. Normalmente provisrio e funcional. Ajuda a equipe de desenvolvimento compreender questes relacionadas com a construo do sistema. Esse prottipo derivado do modelo de domnio ou da especificao do software e no interessa aos usurios. Contm um ncleo bsico da aplicao a ser experimentado com os usurios. Assim, usado para fins mais do ilustrativos.

Autntico

Funcional

Sistema Piloto

Em relao ao seu objetivo de avaliao, a prototipao pode ser classificada como exploratria, experimental e evolutiva. A prototipao exploratria usada para ajudar a esclarecer requisitos do usurios, ou para examinar uma variedade de opes de soluo de design para que se determine a mais adequada. A prototipao experimental enfatiza aspectos tcnicos do desenvolvimento, oferecendo aos desenvolvedores resultados experimentais para a tomada de decises de design e implementao. Finalmente, a prototipao evolutiva avalia o impacto que a introduo de novas tecnologias podem trazer para uma pessoa, seu modo de trabalhar e para a organizao como um todo. Neste caso, os designers devem trabalhar em cooperao com os usurios em um processo contnuo de reengenharia. Por fim podemos classificar as tcnicas de construo do prottipo como completa, horizontal ou vertical. Um prottipo completo contm toda a funcionalidade da aplicao pretendida, mas porm com baixo desempenho. O prottipo horizontal exibe apenas uma camada especfica da aplicao, como por exemplo a camada de interface. O vertical, por sua vez, apresenta a implementao completa (interao e funcionalidade) de uma parte restrita da aplicao. Como mencionamos anteriormente, o prottipo no tem tempo de vida definido. Em certos casos, ele temporrio e uma vez usado para avaliar o aspecto desejado, ele jogado fora. Em outros, ele vai sendo incrementado e se torna parte integrante do sistema. Uma das grandes vantagens de prottipos eles serem parte de um design iterativo centrado no usurio, permitindo que os designers experimentem idias junto a usurios e recebam seu feedback. Assim, eles so uma prtica comum na avaliao da interpretao dos requisitos de design, alternativas de soluo e das solues propostas.

Exemplo

O resultado de uma consulta a um sistema de biblioteca pode conter diversas referncias. Para avaliarmos o tipo de tela de resultado desta busca, poderamos construir um prottipo horizontal, que contenha diferentes organizaes da informao. Por exemplo, uma opo seria apresentar uma das referncias encontradas na consulta de cada vez, em detalhes, com a possibilidade de navegar seqencialmente pelas referncias. Outra opo seria apresentar uma lista que resumisse as informaes mais importantes da referncia, e permitir que o usurio selecione um dos itens da lista, caso deseje ver mais detalhes. Para este tipo de avaliao, utilizamos um prottipo horizontal parcial, ou seja, apenas as telas e signos de interface envolvidos nesta tarefa, sem que seja necessrio implementar o acesso a um banco de dados real. Em contrapartida, se a rapidez e eficincia dos algoritmos de busca for especificada como um fator crtico nesta aplicao, seria necessrio fazer uma implementao vertical desta funcionalidade, de forma a permitir fazer a avaliao de desempenho, possivelmente utilizando diversos algoritmos diferentes para compar-los.

Exerccios

Em um sistema de biblioteca, que tipo de prottipo voc construiria para: convencer um bibliotecrio a comprar a aplicao? avaliar a melhor forma de um funcionrio cadastrar os dados de uma publicao? testar a comunicao com a base de dados?

REFERNCIAS BIBLIOGRFICAS
ACM SIGCHI (1992) Curricula for human-computer interaction. Technical report, ACM, NY, 1992. Disponvel on-line em http://www.acm.org/sigchi/. Adler, P. & Winograd, T. (eds., 1992) Usability: Turning Technologies into Tools. Oxford University Press. New York, NY. Andersen, P.B.; Holmqvist, B.; Jensen, F.F. (eds., 1993) The Computer as Medium. Cambridge University Press. Apple Computer, Inc. (1992) Macintosh Human Interface Guidelines. Reading, Ma. Addison Wesley. Barbosa, S.D.J. (1999) Programao Via Interface. Tese de Doutorado. Departamento de Informtica, PUC-Rio.

Card, S.; Moran,T. & Newell A. (1983) The Psychology of Human-Computer Interaction, Hillsdale, NJ: Lawrence Erlbaum Associates. Carey, T. e Rusli, M. (1995) Usage Representations for Reuse of Design Insights: A Case Study of Access to On-line Books. In Carroll (ed.) ScenarioBased Design: Envisioning Work and Technology in System Development. New York, NY: John Wiley & Sons. Carroll et al. (1994) Binding Objects to Scenarios of Use, International Journal of Human-Computer Studies. da Silva, S.R.P.; de Souza, C.S.; Ierusalimschy, R. (1997) A Communicative Approach to End-User Programming Languages. Em Lucena, C.J.P. (ed.) Monografias em Cincia da Computao. Departamento de Informtica. PUCRioInf MCC 47/97. Rio de Janeiro. de Souza, C.S.; Prates, R.O.; Barbosa, S.D.J. (1999) A Method for Evaluating Software Communicability. Em Lucena, C.J.P. (ed.) Monografias em Cincia da Computao. Departamento de Informtica. PUC-RioInf MCC 11/99. Rio de Janeiro. 11p. de Souza, C.S. (1993) The Semiotic Engineering of User Interface Languages. International Journal of Man-Machine Studies 39. Academic Press. pp. 753-773. de Souza, C.S. (1996) The Semiotic Engineering of Concreteness and Abstractness: from User Interface Languages to End-User Programming Languages. Em Andersen, P.; Nadin, M.; Nake, F. (1996) Informatics and Semiotics. Dagstuhl Seminar Report No. 135, p. 11. Schlo Dagstuhl., Germany. de Souza, C.S. (1999) Semiotic engineering principles for evaluating end-user programming environments. Em Lucena, C.J.P. (ed.) Monografias em Cincia da Computao. Departamento de Informtica. PUC-RioInf MCC 10/99. Rio de Janeiro. 23p. Dix, A.; Finlay, J.; Abowd, G.; e Beale, R. (1993) Human-Computer Interaction. Prentice-Hall International. Eco, U. (1976) A Theory of Semiotics. Bloomington, IN: Indiana University Press. Fischer, G. (1998) Beyond Couch Potatoes : From Consumers to Designers In Proceedings of the 5th Asia Pacific Computer-Human Interaction Conference. IEEE Computer Society. pp.2-9. Hartson, H.R. (1998) Human-Computer Interaction: Interdisciplinary roots and trends. In The Journal of System and Software, 43, 103-118. Hix, D. & Hartson, H. (1993) Developing User Interfaces: Ensuring Usability Through Product & Process. John Wisley & Sons. Jakobson, R. (1970) Lingstica e Comunicao. Cultrix, So Paulo. Jorna, R. & Van Heusden, B. (1996). Semiotics of the user interface. Semiotica, 109(3/4):237-250. Kammersgaard (1988) Four differents perspectives on Human-Computer Interaction. in International Journal of Man-Machine Studies, 28, 343-362 Lee, G. (1993) Object-Oriented GUI Application Development. NJ: Prentice Hall.

Leite, J. C. (1998) Modelos e Formalismos para a Engenharia Semitica de Interfaces de Usurio. Tese de Doutorado. Departamento de Informtica. PUCRio. Lindgaard. G. (1994) Usability Testing and System Evaluation London, UK: Chapman & Hall. Martins, I.H. (1998) Um Instrumento de Anlise Semitica para Linguagens Visuais de Interfaces. Tese de Doutorado. Departamento de Informtica. PUCRio, Brasil. Microsoft Corporation. (1995) The Windows Interface Guidelines for Software Design. Redmond. Microsoft Press. Moran, T. (1981) The Command Language Grammars: a represetantion for the user interface of interactive computer systems. International Journal of ManMachine Studies, 15, 3-50. Nadin, M. (1988) Interface Design and Evaluation Semiotic Implications. Em Hartson, R. e Hix, D. (eds.), Advances in Human-Computer Interaction, Volume 2, 45-100. Newman, W. & Lamming, M. (1995) Interactive System Design. AddisonWesley. Nielsen, J. (1993) Usability Engineering. Academic Press. Norman, D. (1986) Cognitive Engineering. In D. Norman & S. Draper (eds.) User Centered System Design. Hillsdale, NJ. Lawrence Erlbaum. pp.31-61. Norman, D. (1988) Psychology of Everyday Things. BasicBooks. HarperCollins Publishers. Norman, D. (1991) Cognitive Artifacts. In Carroll (ed.) Designing Interaction: Psychology ate the Human-Computer Interface. pp.17-38. Norman, D. (1993) Things that make us smart: defending human attributes in the age of the machine. Reading, MA: Addison-Wesley. Paap, K.R. e Roske-Hofstrand, R.J (1988). Design of Menus In Helander (ed.) Handbook of Human-Computer Interaction. Amsterdam: North-Holland. Payne, S. e Green, T.R.G. (1989). Task-action grammar: the model and its developments. In Diaper (ed.) Task Analysis for Human-Computer Interaction. Chichester: Ellis Horwood. Peirce, C.S. (1931-1958). Collected Papers. Edio brasileira: Semitica. So Paulo, Ed. Perspectiva (coleo estudo, n.46) 1977. Prates, R.O. (1999) A Engenharia Semitica de Linguagens de Interfaces MultiUsurio. Tese de Doutorado. Departamento de Informtica. PUC-Rio, Brasil. Preece, J.; Rogers, Y.; Sharp, E.; Benyon, D.; Holland, S.; Carey, T. (1994) Human-Computer Interaction. Addison-Wesley. Shneiderman, B. (1998) Designing the User Interface, 3rd Edition. Reading, MA: Addison Wesley.