Lucena, F. N., Lies En Berg, H. K.e., Fundamentos De Interfaces Homem-computador

Fundamentos de Interfaces Homem-Computador

Fabio Nogueira de Lucena Universidade Federal de Goias (UFG) Hans K.E. Liesenberg Universidade Estadual de Campinas (UNICAMP)

c 1998 Copyright

Prefacio \A interface e frequentemente o mais importante fator para determinar o sucesso ou falha de um sistema, alem de ser um dos mais caros." Baecker e Buxton[1, pag. 1]

Os primeiros computadores e softwares foram projetados por especialistas para serem usados por especialistas. Atualmente a grande maioria dos usuarios de computadores n~ao s~ao especialistas em computac~ao e, consequentemente, necessita de meios apropriados para realizar suas tarefas com o auxlio de um computador. Tais usuarios est~ao procurando por sistemas \amigaveis", enquanto os especialistas buscam produzir sistemas interativos a baixo custo. A import^ancia de uma relaca~o adequada entre esses interesses bem como as peculiaridades do software e do hardware empregados nesta comunicac~ao fez surgir uma nova area. Esta area esta voltada para a compreens~ao da interac~ao entre ser humano e computador bem como o desenvolvimento dos meios computacionais atraves dos quais ela ocorre. E realmente importante estudar este assunto? Nenhum projetista esta apto a desenvolver sistemas interativos, se n~ao conhecer quest~oes fundamentais relacionadas com a interac~ao entre usuario e computador e suas consequ^encias. Sistemas interativos, cujos processos de desenvolvimento n~ao consideram seriamente esta interaca~o, escoram-se na capacidade adaptativa do ser humano para compensar suas de ci^encias, em manuais que tentam explicar o seu funcionamento, no uso intensivo de mensagens de erro, alem de extensos treinamentos. Ou seja, ate mesmo antes que o usuario inicie a utilizar um sistema, os seus custos s~ao onerados pela baixa qualidade da interface. Durante o uso do produto, erros frequentes e di culdades de uso consomem o valioso tempo de usuarios. Em alguns casos, esta situac~ao e su ciente para determinar o fracasso de sistemas que funcionalmente produzem resultados corretos e com o desempenho esperado, mas cujas interfaces s~ao de cientes.

Objetivos

Para prover um meio e ciente de interaca~o entre o ser humano e o computador e preciso conhecer ambos e as restric~oes que cada um imp~oe ao outro. Este texto ressalta o lado \computacional" desta interac~ao. Em particular, ao que diz respeito a construc~ao do software que permite o usuario interagir com o sistema. Esperamos que o leitor adquira uma vis~ao panor^amica desta area e subsdios para que ele possa realizar adequadamente os seus proprios empreendimentos, alem de orienta-lo numa explorac~ao mais ampla e aprofundada da area. O texto contempla tanto o produto (a interface), quanto o processo (din^amica de seu desenvolvimento).

Todos os tipos de sistemas interativos s~ao considerados?

O desenvolvimento de sistemas interativos pode envolver varias tecnologias: realidade virtual, vdeo, animac~ao, visualizac~ao de dados complexos, banco de dados geogra cos, multimdia e hipermdia. Ao contrario de sistemas interativos que fazem uso de tais tecnologias, sistemas interativos WIMP (windows, icons, menus and pointers ), s~ao os mais empregados hoje em dia e restringem-se ao empregam janelas, menus, bot~oes e mouse no processo de interac~ao com o usuario. No presente texto estamos mais interessados em interfaces WIMP, embora parte das informac~oes aqui contidas tambem se aplique a outros casos.

Publico alvo

Conhecimentos mais solidos em linguagens de programac~ao e engenharia de software facilitam a leitura do presente texto. Pro ssionais envolvidos com o desenvolvimento de sistemas interativos, estudantes do terceiro ano (ou superior) de graduaca~o em Computac~ao ou iniciando seus estudos de pos-graduaca~o comp~oem o publico alvo. Os primeiros bene ciam-se da apresentaca~o de conceitos e metodos de forma simples, enquanto aos ultimos possa interessar a apresentac~ao panor^amica e integrada da area, que abrange varios temas, quase sempre discutidos isoladamente em artigos tecnicos ou confer^encias espec cas.

Informac~oes gerais, sugest~oes, contato com os autores . . .

Este texto baseou-se nas recomendac~oes da ACM/IEEE Curriculum [20], HCI Curriculum [79] e observaco~es sobre curso similar preparado pela SEI/CMU [67]. Em particular, ele cobre a parte teorica da proposta de disciplina \Construc~ao de Interfaces HomemComputador" apresentada em [47]. No nal de cada captulo e apresentado uma lista de exerccios. Os exerccios pretendem estimular o leitor a explorar em detalhes as informac~oes apresentadas. A resoluc~ao em grupo deve ser estimulada para promover uma maior discuss~ao sobre os temas apresentados. Sugest~oes s~ao bem vindas! Os autores podem ser contactados via e-mail, nos enderecos [email protected] e [email protected], ou ainda atrav es do endereco abaixo. ic/unicamp

Caixa Postal 6176 13081-970 Campinas/SP, Brasil

Agradecimentos

Muitos contriburam com sugest~oes que provocaram mudancas no conteudo e na forma de apresentac~ao do presente texto. Em particular, Osvaldo Severino Junior.

Lista de Figuras 1.2-1 O conceito de interface [11]. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.2-2 Vis~ao simpli cada de um sistema interativo. . . . . . . . . . . . . . . . . . . . .

4

2.1-1 Modelo de desenvolvimento de sistemas interativos (adaptado de [34]). . . . . . . . 12 2.3-2 Modelo de Ciclo de vida Cascata. . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3-3 Ciclo de vida espiral (adaptado de [7]). . . . . . . . . . . . . . . . . . . . . . . 16 2.4-4 Modelo de processo tpico de desenvolvimento de interface [67]. . . . . . . . . . . 17 2.5-5 Ciclo de vida estrela [29]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.6-6 Ciclo de vida acrescido de especialistas em interfaces (adaptado de [15]). . . . . . . 18 2.6-7 Ciclo de vida estendido (adaptado de [51]). . . . . . . . . . . . . . . . . . . . . 19 2.7-8 Projeto centrado em tarefas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.7-9 Ciclo de vida com ^enfase em avaliac~ao. . . . . . . . . . . . . . . . . . . . . . . 20 3.1-1 Desenvolvimento de interfaces homem-computador. . . . . . . . . . . . . . . . . 25 4.1-1 Fluxo de controle interno (convencional) (a), externo (b) e misto (c). . . . . . . . 37 4.2-2 Organizac~ao funcional e ferramentas de apoio. . . . . . . . . . . . . . . . . . . . 38 4.6-3 Modelo abstrato de um SGI. Modelo de Seeheim [23] . . . . . . . . . . . . . . . 42 4.8-4 Conceitos analogos: independ^encias de dados e dialogo. . . . . . . . . . . . . . . 44 i

Captulo 1 Introduc~ao Acerca do fracasso comercial parcial do Word v2.0, Bill Gates, grande acionista da Microsoft, disse: \Merecemos a culpa por n~ao termos facilitado o seu aprendizado. No tocante aos recursos, o produto era fantastico, mas no que se refere a facilitar os primeiros passos, nos n~ao nos samos muito bem." Ichbiah[38]

Este captulo fornece uma vis~ao geral da area, que e re nada nos captulos subsequentes. Ainda s~ao de nidos conceitos e termos empregados ao longo de todo o texto. Em particular, e enfatizada a import^ancia de interfaces para sistemas interativos e ambientes gra cos precursores com caractersticas comumente encontradas nas atuais interfaces. O captulo ainda descreve muitas das di culdades encontradas ao longo do processo de desenvolvimento de interfaces e indica diversos textos fundamentais da area.

1.1 Interac~ao Homem-Computador A area de interesse deste texto e conhecida por Interac~ao Homem-Computador (IHC). O grupo de interesse especial em IHC da ACM de ne este termo como \uma disciplina pertinente ao projeto, avaliaca~o e implementaca~o de sistemas de computac~ao interativos para uso humano bem como o estudo das principais quest~oes relacionadas". Conforme uma outra de nic~ao [69]: \Interac~ao Homem-Computador e uma area voltada para o desenvolvimento de sistemas computacionais, que d~ao suporte a pessoas para que possam realizar suas atividades de forma produtiva e segura."

2

1.2 Interface Homem-Computador

IHC n~ao e uma disciplina essencialmente voltada para o estudo de computac~ao, nem do ser humano, mas da comunicac~ao entre estas duas entidades. A de nic~ao sugere que os atributos \produtiva" e \segura" s~ao indispensaveis para atingir a usabilidade esperada de um sistema interativo. Usabilidade tem sido amplamente utilizado para caracterizar a qualidade de um software com relac~ao a sua facilidade de uso e aprendizado. Quanto mais facil de usar e aprender, maior e a usabilidade. Esta area e multidisciplinar, envolve a area de Computaca~o (hardware, software, metodologias, tecnicas, ferramentas) e varias outras areas do conhecimento humano (psicologia, fatores humanos, artes gra cas e outras). IHC esta voltada para a aplicaca~o do conhecimento acumulado nestas disciplinas para produzir boas interfaces. Conhecimentos acerca das limitac~oes e capacidades humanas devem ser contrastados com os recursos e restric~oes da tecnologia disponvel, a m de oferecer aos usuarios um meio adequado, atraves do qual eles possam interagir com computadores. IHC compreende um grande volume de informac~oes, compiladas de areas distintas, orientadas para a produca~o de sistemas interativos com melhor usabilidade. A grande maioria da literatura existente sobre o assunto apresenta quest~oes pertinentes a IHC de forma estanque. O carater multidisciplinar de IHC di culta a formaca~o de uma vis~ao holstica da area. Em particular, o processo de desenvolvimento de um sistema interativo e uma das quest~oes mais difceis, conforme sera visto no proximo captulo. Tentamos, no presente texto, alem de fornecer uma vis~ao estanque de quest~oes pertinentes a IHC, apresentar como elas se interrelacionam, quais s~ao as etapas da confecca~o de um sistema interativo e como elas uem ao longo do tempo (processo). Este texto apresenta informac~oes destiladas de diversas refer^encias, das quais algumas exerceram uma in u^encia mais signi cativa: [15, 34, 85] e [69]. [2] e uma fonte atualizada e abrangente. Aspectos relacionados ao software de uma interface homem-computador s~ao extensivamente cobertos em [4].

1.2 Interface Homem-Computador Algumas explicac~oes acerca do termo Interface Homem-Computador s~ao necessarias. Muita confus~ao existe entre interface e interac~ao (Homem-Computador). Interac~ao diz respeito a tudo o que ocorre entre um ser humano e um computador utilizado na execuca~o de tarefas. Trata-se da comunicac~ao que ocorre entre estas duas entidades. Doravante, tal ser humano sera denominado usuario. Interface e o meio (hardware + software) atraves do qual esta interac~ao ocorre. O termo coletivo Homem representa toda a comunidade de usuarios de computadores e n~ao apenas aqueles do sexo masculino. Computador e a entidade com a qual o usuario interage.

3

Captulo 1. Introduca~o

Interface: compreende todos os comportamentos do usuario e do computador que s~ao observaveis externamente [11]. Ha uma linguagem de entrada, uma de sada para re etir resultados e um protocolo de interac~ao (veja a Figura 1.2-1). Observador externo

Entrada

USUÁRIO

Protocolo

SISTEMA INTERATIVO

Saída

Interação

Figura 1.2-1: O conceito de interface [11]. A conceituac~ao acima n~ao fornece a perspectiva totalmente apropriada aos nossos interesses, mais voltados para aspectos relacionados com a area de engenharia de software. Um outro conceito de interfaces com uma de nic~ao fundamentada em software pode ser estabelecido. A de nic~ao seguinte, ilustrada na Figura 1.2-2, fornece tal perspectiva. Interface: parte do software de um sistema interativo responsavel por traduzir ac~oes do usuario em ativac~oes das funcionalidades do sistema (aplicac~ao), permitir que os resultados possam ser observados e coordenar esta interac~ao. Ou seja, a interface e responsavel tanto pelo mapeamento das ac~oes do usuario sobre dispositivos de entrada em pedidos de processamento direcionados a aplicac~ao como pela apresentac~ao adequada dos resultados produzidos.

A Figura 1.2-2 mostra um modelo simpli cado de um sistema interativo. O componente aplicac~ao e o elemento responsavel pela parte funcional do sistema, que transforma dados de entrada em dados de sada atraves da aplicac~ao de uma funca~o a entrada. O componente interface equivale a de nic~ao fornecida acima. A separac~ao entre estes componentes e conhecida por independ^encia de dialogo. Tal independ^encia e amplamente defendida na literatura, contudo obt^e-la n~ao e uma tarefa trivial. A Sec~ao 4.8 traz mais informac~oes sobre a partic~ao de um sistema interativo em interface e aplicaca~o. O termo dialogo geralmente e empregado com a mesma acepc~ao de interface. E comum o uso do termo dialogo como sendo a comunicaca~o existente entre o ser humano e o

4

1.2 Interface Homem-Computador Sistema Interativo INTERFACE

APLICAÇÃO

Figura 1.2-2: Vis~ao simpli cada de um sistema interativo. sistema de computac~ao, i.e., a troca de smbolos e ac~oes entre o usuario e o computador. O termo interface tambem e comumente empregado como o software de suporte e o hardware atraves do qual esta troca (dialogo) ocorre. Ambos referem-se somente as entradas do usuario e ao processamento espec co dessas entradas, juntamente com a apresentac~ao dos resultados produzidos pela aplicac~ao, e excluem o componente encarregado da transformac~ao dos dados de entrada no resultado esperado do processamento do sistema. Esta func~ao e de interesse do componente computacional denominado aplicac~ao. O termo amigavel (user-friendly) e comumente atribudo a interfaces sendo a palavra usabilidade tambem usado em contextos semelhantes. N~ao ha uma de nica~o precisa para estes termos. Contudo, algumas das caractersticas abaixo geralmente est~ao presentes em sistemas com interfaces ditas amigaveis:

 Facilidade de usar e aprender. Embora uma lista de caractersticas indesejaveis em

uma interface possa ser construda [71], de nir \facil de usar" e bem mais difcil. O termo user-friendly e geralmente associado a uma interface para caracteriza-la como facil de uso. Habermann [26] sugere uma sem^antica para easy-to-use e easy-tolearn: (1) a interface e invisvel (o usuario pode concentrar-se mais nas tarefas que necessita realizar cando os detalhes operacionais da interface em segundo plano, se o seu uso e \natural" para o usuario); (2) e previsvel; (3) e exvel e (4) as pessoas gostam dela.

 Taxa de erro mnima. Em sistemas crticos (controle de usinas nucleares, controle de

tra co aereo e outros, onde vidas humanas est~ao em jogo) di cultar a ocorr^encia de erros cometidos pelos usuarios e imprescindvel. Possibilitar uma execuc~ao errada de tarefas, de maneira geral, afeta negativamente o desempenho de usuarios. Eles se sentem menos seguros e a sua produtividade cai.

 Recordac~ao rapida. O usuario esporadico n~ao deve, idealmente, ter que recorrer

a manuais, quando for usar o sistema. A sequ^encia de passos necessarios para a execuc~ao de tarefas deve ser sentida como \natural" pelo usuario.

 Atrativo. Nem sempre o sistema mais poderoso e o preferido pelo usuario, que pode selecionar um sistema mesmo sabendo que seu desempenho na utilizac~ao deste sistema e inferior ao seu desempenho utilizando um outro.

Captulo 1. Introduca~o

5

1.3 Por que interfaces s~ao importantes? Justi car a import^ancia de uma interface n~ao e uma tarefa difcil atualmente. Muitos dados, apresentados nesta sec~ao e ate, possivelmente, a propria experi^encia do leitor facilitam esta tarefa. A presente sec~ao apresenta fatores subjetivos, econ^omicos, vitais e outros que corroboram o papel de destaque deste componente essencial de um sistema interativo. Dray, em [16], aborda a import^ancia de \boas" interfaces. Essa import^ancia seria irrelevante se os benefcios de uma interface com tal qualidade, ao menos em sistemas interativos n~ao crticos, n~ao fossem su cientes para justi car os custos adicionais de desenvolvimento. Essa quest~ao e discutida em [50]. A interface e um elemento imprescindvel para a aceitac~ao de um sistema interativo por parte do usuario. Por exemplo, nem sempre o usuario prefere um sistema com mais desempenho a outro com uma interface mais agradavel [44]. Muitos pacotes de software acabam sendo rejeitados por seus usuarios por n~ao possurem uma interface \atrativa," \agradavel" e \facil de usar." Naturalmente estas quest~oes t^em um impacto signi cativo sobre o sucesso comercial de um software. Varios custos est~ao associados a interface de um sistema interativo. O desenvolvimento de uma interface compreende o tratamento de varios desa os, conforme comentado adiante. A atual interface do Macintosh, por exemplo, e descendente direta da interface do computador Lisa (Apple), cuja interface foi resultado de um processo de quatro anos de testes e re namentos [66]. Apos produzido, um sistema interativo passa a ser utilizado de forma frequente ou esporadica. Em ambas as situac~oes a e ci^encia do usuario e in uenciada pela interface. Erros cometidos frequentemente, uma demora na realizaca~o de tarefas por parte dos usuarios ou ainda um baixo desempenho na utilizac~ao de sistemas interativos revelam, muitas vezes, interfaces difceis de serem usadas. Os efeitos s~ao ainda mais signi cativos, se o sistema for utilizado constantemente e por um grande numero de usuarios. Neste caso, uma empresa pode estar consumindo desnecessariamente, devido a uma interface ruim, muitas horas de trabalho de seus funcionarios. Alem disto, estes usuarios provavelmente foram treinados para utilizar o sistema de forma efetiva. Quanto mais difcil de aprender, mais onerosa torna-se a fase de treinamento. A produc~ao e impress~ao de manuais tambem contribuem com custos adicionais. Recursos funcionais que jamais chegam a ser usufrudos devido a uma interface que os oculta ou inibe a sua utilizac~ao signi cam trabalho sem proveito realizado por equipes de desenvolvimento (veja citac~ao de Bill Gates no incio do captulo). Existem sistemas, onde riscos fatais est~ao associados a suas interfaces. Nos chamados sistemas crticos que, em alguns casos, s~ao protagonistas de danos fatais com perda de vidas humanas, foram encontrados erros atribudos as suas interfaces mal projetadas. Foi parcialmente atribuda a interface com o usuario, por exemplo, a inabilidade do exercito americano de combater e cazmente os msseis Exocet iraquianos durante a Guerra do Golfo, em 1991. Collins et al em [74] relatam varios desastres atribudos a erros de

6

1.4 Na busca de soluco~ es

software, alguns deles s~ao consequ^encias de interfaces mal projetadas. Conforme [16, 60], economias da ordem de milh~oes de dolares podem ser obtidas atraves de um projeto adequado de uma interface. Neste caso, usuarios cometem poucos erros, o tempo de execuc~ao das tarefas mais usuais e minimizado, a distrac~ao e reduzida e os treinamentos s~ao reduzidos signi cativamente ou s~ao ate desnecessarios. Caso contrario, usuarios frustados, sistemas de custos elevados (treinamento, erros de operaca~o e outros), recursos que jamais s~ao utilizados pela di culdade de acesso imposta ao usuario e ate a ocorr^encia de erros com consequ^encias fatais est~ao entre os resultados possveis e indesejaveis. Recentemente, um esforco internacional (ISO 9126) identi cou seis caractersticas basicas para medir a qualidade de um software | usabilidade e uma delas [41]. As justi cativas acima podem ser corroboradas atraves de outros exemplos apresentados em [62].

1.4 Na busca de soluc~oes Na sec~ao anterior vimos consequ^encias negativas de interfaces ruins. Uma vez que n~ao se pode simplesmente \ignorar" o assunto, as consequ^encias negativas t^em compelido grandes esforcos na busca de propostas para produc~ao de boas interfaces com baixo custo. No paragrafo abaixo s~ao enumerados alguns dos estmulos que a area tem recebido. Curtis destaca, em [14], varios projetos japoneses com a atenc~ao focalizada no desenvolvimento de interfaces. Segundo Curtis, uma vez atingida certa uniformidade na con abilidade de produtos de software, a qualidade de suas interfaces e o proximo quesito que lhes confere uma distinc~ao em termos de vantagens mercadologicas. O projeto Friend21, por exemplo, envolve 14 grandes companhias e um investimento de 120 milh~oes de dolares. O projeto baseia-se no fato de que em futuro proximo praticamente todas as pessoas estar~ao, de uma forma ou outra, utilizando computadores em suas atividades diarias. Conforme Khosha an e Abnous [40], \gigantes" da computaca~o como a IBM, Microsoft, Digital e Hewlett-Packard (HP) tambem t^em dado grande ^enfase a interfaces. Sociedades como a ACM e IEEE ja recomendam a disciplina de interfaces nos cursos de graduac~ao desde 1991 e, de fato, ja vem sendo ministrada em varias instituico~es por todo o mundo. Algumas propostas de disciplinas incluem [20, 67, 79]. Uma proposta adequada a realidade brasileira e apresentada em [48].

1.5 Di culdades e alguns dados estatsticos Subjacentes aos custos elevados com o desenvolvimento de interfaces, vistos anteriormente, podemos encontrar varias di culdades. Elas aumentam a medida que as exig^encias em termos de usabilidade do software tornam-se maiores. Ou seja, quanto mais facil

Captulo 1. Introduca~o

7

deve-se tornar o seu uso, mais di culdades surgem no desenvolvimento de uma interface e, consequentemente, fazem subir os custos de desenvolvimento. Por outro lado, se a usabilidade n~ao e uma preocupaca~o, outros custos relacionados com o seu uso ou ate o fracasso total de um sistema s~ao provaveis. Dray [16] cita varios exemplos de fracassos de sistemas interativos devido a falta de uma maior preocupac~ao com o desenvolvimento de suas interfaces. Dray ainda mostra como a usabilidade de um sistema pode reduzir os custos de utilizaca~o e tornar mais efetivo um sistema. O processo de construc~ao de interfaces (projeto da interac~ao e implementac~ao do software correspondente) e repleto de di culdades [60]. Diversas destas di culdades s~ao vistas, em detalhe, ao longo de todo o texto. Ferramentas voltadas para amenizar as di culdades de construc~ao de interfaces remontam a 1968 [64]. Muitas delas d~ao ^enfase ao desenvolvimento do software de interfaces a um custo baixo. Em 1996 o mercado de interfaces foi estimado em 1.2 bilh~ao de dolares para tais ferramentas em 1996 [61]. Bass e Coutaz [4, pag. v] a rmam que a interface consome ate 70% dos custos totais do ciclo de vida de um sistema interativo. Bobrow et al. [6] relatam que para um sistema especialista poder-se-ia esperar que a maior parte de codigo fosse devotada a base de conhecimento e a maquina de infer^encia. Entretanto, o maior componente do sistema e cujo desenvolvimento exigiu maior tempo foi a interface, que totalizou 42% do codigo. Ainda a rmam que esta n~ao e uma situac~ao atpica e que outros sistemas apresentam percentuais similares. Uma analise recente de dezenas de sistemas interativos constatou que, em media, 48% do codigo de um sistema e dedicado a interface, sendo que o projeto da interface consome, em media, 48% de todo o tempo de projeto do sistema e a implementac~ao 50% de todo o tempo de codi cac~ao do sistema. Do tempo de manutenc~ao de todo o sistema, a interface consome 37%, de acordo com este estudo. Myers apresenta e discute estes e outros dados relacionados em [63].

1.6 Fontes de informac~ao A comunidade cient ca brasileira na area de interfaces ainda e bastante reduzida. Por esta raz~ao ainda n~ao existe um evento ou um periodico cient co nacional espec co sobre o assunto. Parte dos livros, periodicos, grupos de interesse em interfaces e outras das principais fontes de informac~ao disponveis sobre temas da area s~ao relacionados abaixo: 1. Periodicos espec cos ou pertinentes: (a) ACM SIGCHI Bulletin. (b) ACM TOCHI. (c) ACM Interactions. (d) Human-Computer Interactions.

8

1.6 Fontes de informaca~o

(e) (f) (g) (h) (i)

International Journal of Human-Computer Interaction. Interacting with Computers. Behaviour and Information Technology. International Journal of Man-Machine Studies. ACM Transactions on Graphics.

2. Confer^encias espec cas ou que contemplam trabalhos desta area: (a) (b) (c) (d) (e) (f) (g) (h) (i)

ACM User Interface Software Technology. ACM SIGCHI { Human Factors in Computing Systems. Human Factors Society (encontro anual). Computer Supported Cooperative Work. IFIP INTERACT. International Conference on Human-Computer Interaction ACM SIGGRAPH British Computer Society HCI: Human-Computer Interaction. Eletr^onicas: i. netnews: comp.human-factors ii. netnews: comp.cog-eng iii. internet: [email protected] (Administrac~ao: [email protected]). Detalhes em http://www.acm.org:82/~fuller/students.chi.html

3. Bases de dados de refer^encias: (a) HCI Bibliography Project (Gary Perlman, [email protected]) http://www.hcibib.org/ (Fornece extensiva bibliogra a sobre IHC.) (b) HILITES { The Information Service for the World HCI Community. SIGCHI Bulletin, vol. 24, numero 3, julho/1992, pags. 40-49. 4. \Links" (URLs), onde ha informaco~es sobre ferramentas para desenvolvimento de interfaces. Alguns dos toolkits de domnio publico s~ao citados, sem necessariamente terem sido avaliados por parte dos autores do presente texto. O leitor pode obter em http://www.dcc.unicamp.br/projects/Xchart/correlatos.html estes e outros \links" concernentes. (a) Ferramentas para desenvolvimento de interfaces

http://web.inf.rl.ac.uk/vis/publications/guireport.html

(b) Tcl/Tk (toolkit)

http://cuiwww.unige.ch/eao/www/TclTk.html

Captulo 1. Introduca~o

9

(c) Amulet (toolkit)

http://www.cs.cmu.edu/~amulet

(d) Fresco (toolkit)

http://www.faslab.com/fresco/HomePage.html

(e) wxWindows (toolkit)

http://www.aiai.ed.ac.uk/~jacs/wxwin.html

(f) Motif (toolkit, padr~ao e outras informac~oes)

http://www.cis.ohio-state.edu/hypertext/faq/usenet/motif-faq/top.html

(g) Extensa lista de ferramentas disponveis (Brad Myers)

http://www.cs.cmu.edu/afs/cs.cmu.edu/user/bam/www/toolnames.html

(h) Texto abrangente sobre ferramentas

http://www.cs.cmu.edu/afs/cs.cmu.edu/project/garnet/doc/papers/uimssurvey.ps

(i) Outra lista de ferramentas (Martina Manhartsberger)

http://socrates.ani.univie.ac.at/ani/users/mm/Toollist.html

(j) Sistemas de gerenciamento de interfaces

http://dxsting.cern.ch/sting/comp.software-eng/uims.txt

(k) Ferramentas CASE relacionadas a interfaces

http://www.qucis.queensu.ca:1999/Software-Engineering/

(l) Avaliac~ao de ferramentas - Ralf Lukner's evaluation

http://www.che.utexas.edu/fluids-group/cpp tools eval.html

(m) X FAQ e ferramentas

ftp://ftp.x.org:/contrib/faqs/FAQ

5. A partir dos \links" (URLs) abaixo e possvel obter uma grande quantidade de informac~oes sobre os mais variados aspectos de IHC: (a) Teses em andamento

http://www.ida.liu.se/labs/aslab/groups/um/hci/tip/

(b) New Directions in HCI Education, Research and Practice

http://www.sei.cmu.edu/arpa/hci/directions/TitlePage.html

(c) HCI Education Survey

http://www.cis.ohio-state.edu/~perlman/educhi.html

(d) Human Factors and Ergonomics Society http://www.hfes.vt.edu/HFES/

(e) Human Factors FAQ

http://www.dgp.toronto.edu/people/ematias/faq/contents.html

(f) Resources in Interaction Design

http://is.twi.tudelft.nl/hci/

10

1.7 Exerccios

(g) Informac~oes sobre metricas de usabilidade (questionario de avaliac~ao) http://www.ucc.ie/hfrg/sumi/

(h) Questionario de identi cac~ao de satisfac~ao de usuario

http://www.cs.umd.edu/projects/hcil/Research/1994/

(i) Ergonomics and training

http://www.usernomics.com

(j) Software de interfaces

http://www.cs.bgsu.edu/HCI/sw.html

(k) Pesquisa de mercado - X Business Group http://sparc.xbg.com/welcome.html

1.7 Exerccios 1. Por que apenas especialistas da area de computac~ao para compor esta equipe e contra-indicado? Que tipo de equipe de especialistas seria necessario para desenvolver uma interface \boa"? Justi que a sua resposta. 2. Analise a interface de um pacote de software que voc^e esta habituado a utilizar com base nos criterios de usabilidade apresentados na Sec~ao 1.2. Quais o seu pacote satisfaz e em que grau? Justi que as suas a rmativas. 3. Com relac~ao ao pacote escolhido (exerccio 2) voc^e usa o seu manual e, em caso a rmativo, em que situac~oes? Poderia ser evitado? E possvel obter pelo menos parte das informac~oes contidas no manual via interface? 4. Para que tipo de tarefas apoiadas pelo seu pacote predileto voc^e considera \natural" a sua execuc~ao em termos dos recursos oferecidos pela sua interface? Algumas tarefas s~ao difceis de serem realizadas? A interface inibe (di culta, desestimula) a execuc~ao de alguma tarefa?

Captulo 2 Processo de Construc~ao de Interfaces \Embora o projeto de interface seja em parte uma arte, pode-se pelo menos sugerir uma abordagem organizada para o processo." Foley et al.[19, pag. 429]

No captulo anterior foi destacada a import^ancia, os custos relacionados com o desenvolvimento, uso, possveis riscos e algumas de nic~oes basicas associadas a interfaces. Esse captulo discute o processo de desenvolvimento de sistemas interativos e, em particular, o que diz respeito ao processo de desenvolvimento de interfaces e algumas quest~oes pertinentes a este processo. Em especial, este captulo trata da din^amica ou como evoluem, ao longo do tempo, as varias atividades necessarias para a produca~o de uma interface. S~ao ainda apresentadas as di culdades deste processo, o seu relacionamento com a area de engenharia de software e algumas dos modelos (de processos) existentes.

2.1 Consideraco~es iniciais Desenvolver um sistema interativo envolve a confecc~ao de dois grandes componentes, conforme visto no captulo anterior: a aplicac~ao e a interface. Tambem vimos que este texto focaliza o componente interface de um sistema interativo. O desenvolvimento da funcionalidade ou aplicac~ao de um sistema interativo n~ao e de interesse direto deste trabalho. A Figura 2.1-1 ressalta a separac~ao entre o desenvolvimento destes dois componentes. N~ao se trata de uma proposta de processo de desenvolvimento, o modelo apresentado nesta gura apenas identi ca tarefas importantes que devem ser realizadas e o uxo de informac~oes entre elas [34]. Neste modelo de desenvolvimento, a parte superior contempla o desenvolvimento da aplicac~ao e a inferior, separada por uma linha tracejada, contempla o da interface. O desenvolvimento da interface e dividido em tr^es grandes tarefas: o projeto de interac~ao, o projeto do software de interaca~o e a implementac~ao. Esta divis~ao identi ca quest~oes que pertencem a domnios diferentes. O projeto de interac~ao e coberto no Captulo 3, enquanto o projeto de software e a implementaca~o deste software

12

2.2 Algumas dificuldades

s~ao comentados no Captulo 4. Por ora e su ciente que o processo de desenvolvimento de um sistema interativo deve orientar uma equipe de desenvolvimento na realizac~ao das atividades descritas nesta gura. O projeto de interaca~o, que faz parte de um ciclo no canto inferior esquerdo, esta essencialmente voltado para a de nic~ao de uma interface (face comportamental). As atividades subsequentes tratam da realizac~ao desta de nic~ao atraves do desenvolvimento de software correspondente (face computacional). Desenvolvimento da Funcionalidade da Aplicação Plano de teste, critérios Requisitos

Requisitos

Projeto do software da Aplicação

Projeto do domínio do problema R&P

Análise de sistema

Especificações

R&P

Programas

Implementação do software da Aplicação Erros

R&P

Teste do Software da Aplicação

Falhas de projeto, erros, modificações. Especificações de usabilidade dos requisitos de projeto da Requisitos interface do projeto de software

Projeto da Interação R&P

Especificações

Projeto do software da Interface R&P

Programas

Implementação do software da Interface R&P

e Avaliação da Interface

Erros

Falhas de projeto, erros e modificações (baixa usabilidade). Plano de teste, especificações de usabilidade.

Usabilidade

Avaliação

Construção rápida de Protótipos

R&P = restrições e problemas

Desenvolvimento da Interface da Aplicação

Figura 2.1-1: Modelo de desenvolvimento de sistemas interativos (adaptado de [34]).

2.2 Algumas di culdades IHC e uma area multidisciplinar e, portanto, desenvolver uma interface pode signi car o envolvimento de especialistas de varias areas distintas alem daqueles especializados em computac~ao. O desenvolvimento da aplicaca~o exige analistas de sistemas, engenheiros de software e possivelmente outros especialistas, conforme as necessidades espec cas da aplicac~ao. Dessa forma, e imprescindvel ter um modelo claro do processo de desenvolvimento, onde s~ao identi cadas atividades, produtos e responsaveis para orientar a equipe de especialistas envolvidos no processo de desenvolvimento. Representantes tpicos ou os proprios usuarios tambem podem estar envolvidos nesse processo. Como o resultado nal do trabalho da equipe acima envolve uma produc~ao consideravel de software relacionado a interface (veja Seca~o 1.5 do captulo anterior) e, se considerarmos erros de uso como erros de software induzidos pela interface em decorr^encia de um

Captulo 2. Processo de Construca~o de Interfaces

13

projeto inadequado, ent~ao nada mais natural que tomar emprestado da area de engenharia de software modelos de ciclo de vida de sistemas. E importante observar ainda, que o processo de desenvolvimento de uma interface e parte integrante do processo de desenvolvimento de um sistema interativo, cuja confecc~ao e tipicamente de responsabilidade de um engenheiro de software. Contudo, as abordagens tradicionais est~ao timidamente cobrindo aspectos pertinentes ao desenvolvimento de interfaces, a ^enfase continua na aplicac~ao, a interface recebe um tratamento super cial. Por exemplo, embora Pressman inclua em [70] o termo usabilidade e outros bem conhecidos em IHC, as abordagens apresentadas para o desenvolvimento de sistemas n~ao contemplam adequadamente o desenvolvimento de suas interfaces. Em particular, o modelo cascata (waterfall ) foi proposto em 1970, epoca na qual praticamente inexistiam sistemas interativos ou eram muito distantes dos requisitos dos atuais. A tecnologia amplamente empregada oferecia apenas uma linguagem de comandos para o usuario expressar suas intenc~oes e textos impressos para registrar a sada. Do lado oposto, as abordagens empregadas em IHC enfatizam a interface, sem contemplarem adequadamente a aplicac~ao (funcionalidade). Existem poucas excec~oes, oriundas do lado de IHC, que contemplam todo o processo de desenvolvimento de um sistema interativo. Hartson e Hix [29] citam algumas e apresentam uma proposta \ponte" com o intuito de integrar o desenvolvimento da interface e da aplicac~ao de um sistema interativo. Contudo, os esforcos para integrar quest~oes pertinentes a usabilidade e engenharia de software ainda n~ao s~ao tratadas de forma satisfatoria. Neste cenario, algumas propostas de processos de projeto de interfaces sugerem que pequenas modi cac~oes sejam feitas nestes processos para viabilizar esta integraca~o. O objetivo e permitir que o papel de IHC (melhorar a qualidade da interac~ao entre ser humano e computador), no desenvolvimento de um sistema interativo, n~ao seja sacri cado por abordagens incompatveis entre engenharia de software e IHC. Por exemplo, o modelo cascata, comentado mais adiante, n~ao permite iteraco~es nas suas varias etapas, o que colide frontalmente com o atual consenso de que o desenvolvimento de interfaces e um processo essencialmente iterativo. Atualmente inexistem regras de ouro que, uma vez seguidas, conduzem a usabilidade esperada para um sistema. Ou seja, embora um modelo de processo possa oferecer uma abordagem organizada para o desenvolvimento de interfaces, isto n~ao assegura que os resultados desejados ser~ao obtidos. Em consequ^encia, iterac~ao e vista como o unico meio de atingir resultados satisfatorios atraves da contnua avaliac~ao do projeto especialmente por parte de usuarios. O processo deve ser iterativo, os resultados intermediarios devem ser continuamente avaliados por usuarios representativos e o processo deve possuir mecanismos de analise custo/benefcio. A ^enfase, portanto, esta na iterac~ao, nos prototipos e nas avaliac~oes efetuadas por usuarios representativos.

14

2.3 Engenharia de software

2.3 Engenharia de software Boa parte dos modelos atualmente empregados para o processo de desenvolvimento de software (ciclos de vida) tiveram suas origens associadas aos cart~oes perfurados, computadores de grande porte e sistemas com pouca interac~ao com os seus usuarios. Ou seja, tais sistemas possuem requisitos diferentes dos atuais sistemas interativos. Em consequ^encia, estes modelos n~ao promovem o uso de notaco~es e tecnicas para o suporte da perspectiva do usuario de um sistema interativo. As praticas convencionais para o desenvolvimento de software n~ao contemplam princpios de projeto de interfaces. Embora essa integrac~ao seja importante [82], ela continua sem um modelo que aglutine as contribuic~oes de IHC e engenharia de software [9]. Relacionamentos entre notac~oes, ferramentas e abordagens para o projeto de interfaces e os metodos tradicionais para desenvolvimento de sistemas s~ao comentados em [82]. Varios esforcos ja foram feitos com o intuito de integrar as abordagens para o desenvolvimento de interfaces com as de analise estruturada, metodologia de Jackson, orientaca~o a objetos e outras [25, 46]. Contudo, resultados satisfatorios ainda n~ao foram produzidos. A grande di culdade reside na inexist^encia de metodos apropriados, nas abordagens de engenharia de software, que contemplem adequadamente as necessidades do desenvolvimento de interfaces. O uso dos modelos cascata e o espiral (comentados mais adiante) geralmente produz software cuja usabilidade deixa a desejar. Eles n~ao foram cunhados para obter esta qualidade do software resultante. Tais modelos s~ao apropriados para o desenvolvimento da aplicac~ao, n~ao da interface. Eles contemplam adequadamente quest~oes como desempenho, portabilidade, modularidade e outras qualidades desejaveis em software, mas n~ao a sua usabilidade. Isto fez com que varias propostas surgissem para o desenvolvimento de interfaces. Algumas propostas tentaram adaptar tais modelos por serem amplamente utilizados. Para contemplar usabilidade s~ao precisos processos, metodos, notac~oes, conhecimentos e ferramentas adequados. Neste captulo estamos interessados no processo (atividades e organizaca~o delas ao longo do tempo). Outros captulos deste texto tratam das demais quest~oes. Todos os modelos, aqueles para o desenvolvimento de interfaces e aqueles espec cos para a aplicac~ao, no entanto, apresentam uma di culdade em comum: carecem de uma vis~ao geral integrada do desenvolvimento de todo um sistema interativo. Modelos oriundos de IHC geralmente subestimam a funcionalidade da aplicac~ao enquanto aqueles oriundos da engenharia de software focalizam principalmente essa funcionalidade. Cada qual da ^enfase ao componente para o qual foi concebido, a interface ou a aplicac~ao, sem uma conex~ao entre eles. Embora estes componentes n~ao possam ser desenvolvidos de forma completamente isolada um do outro, nenhuma proposta inclui uma abordagem mais integrada. Esta, portanto, ainda e uma quest~ao em aberto.

Captulo 2. Processo de Construca~o de Interfaces

15

2.3.1 Ciclo de vida Cascata O modelo de ciclo de vida cascata (waterfall ) e um dos mais criticados na literatura. Trata-se de uma excelente ferramenta para o gerenciamente de projeto. As etapas bem de nidas facilitam essa tarefa. Entretanto, acredita-se que poucos softwares possam ser desenvolvidos em etapas, cujos produtos e sequ^encia sejam bem de nidos a priori. A suposic~ao de que fases uem sequencialmente uma apos a outra, onde o desenvolvimento e estritamente top-down, n~ao se aplica quando os requisitos do sistema s~ao desconhecidos, por exemplo. A iterac~ao necessaria ao desenvolvimento da interface n~ao pode ser realizada neste modelo. Análise de requisitos

Especificação

Projeto lógico Projeto

Projeto físico Codificação Desenvolvimento

Evolução

Testes Operação e Manutenção

Figura 2.3-2: Modelo de Ciclo de vida Cascata.

2.3.2 Ciclo de vida Espiral O ciclo de vida espiral (Figura 2.3-3) elimina algumas de ci^encias do anterior. Em particular, reconhece que, para sistemas complexos, n~ao ha como lidar com os detalhes de todo o sistema de uma unica vez. A analise de risco, elemento caracterstico deste modelo, permite identi car um componente importante que sera considerado no proximo ciclo, aumentando gradativamente o numero de voltas na espiral e, consequentemente, aproximando-se do sistema nal com toda a sua funcionalidade. Contudo, o modelo espiral n~ao prev^e a contnua avaliac~ao por parte do usuario, exceto em uma etapa espec ca. Para o desenvolvimento da interface, a contnua avaliac~ao durante todo o desenvolvimento da interface e importante. Note ainda que os ciclos no modelo espiral s~ao relativamente \longos", comparados com os ciclos de desenvolvimento de uma interface. Por exemplo, para estabelecer os rotulos mais adequados para um menu, podem ser realizadas varias iteraco~es com respectivas avaliaco~es por parte do usuario, o que e uma atividade de uma dimens~ao pequena demais para merecer uma \volta" completa no modelo espiral.

16

2.4 Modelo tpico de desenvolvimento de interface Custos acumulados Progresso através de passos Identificar objetivos, alternativas, restrições

Avaliação de alternativas, identificar e resolver riscos

Análise de riscos Análise de riscos Análise de riscos Análise de riscos

Aceitação

Protótipo Operacional

Protótipo3 Protótipo2

Protótipo1

Revisão

Simulações, modelos, benchma rks

Partição P de lan se o nv de ol vi m

P in lan te o gr de aç ão

Plano de Requisitos

en

Conceitos de Operaçáo

Especificação de requisitos

Projeto detalhado

Projeto de software to

Codificação

Validação de requisitos e te

st

e

Validação de projeto e verificação

Teste de módulos Integracao e testes

Teste de aceitação Implementação

Planejamento das fases seguintes

Desenvolvimento, verificar próximo nível do produto

Figura 2.3-3: Ciclo de vida espiral (adaptado de [7]).

2.4 Modelo tpico de desenvolvimento de interface O desenvolvimento de interfaces e um processo essencialmente iterativo, no qual atividades de projeto devem ser seguidas de alguma forma de avaliac~ao que, por sua vez, realimenta o proprio processo. Vers~oes de projeto re nadas a cada teste com usuarios representativos podem substancialmente melhorar a forma de interaca~o com o sistema em construca~o [65]. Conforme a Figura 2.4-4, para um projeto podem contribuir: padr~oes, diretrizes (guidelines ), experi^encia com outros sistemas e, obviamente, os proprios requisitos do sistema. O resultado de uma atividade de projeto e uma especi cac~ao, que pode ser utilizada durante a implementac~ao, ou um modelo formal. O emprego de um modelo formal permite que a interface em desenvolvimento possa ser avaliada sem a necessidade de implementa-la previamente. A implementac~ao pode envolver a construca~o de todo o sistema, de parte ou a construc~ao de um prototipo. A avaliac~ao pode ser feita sobre um um modelo formal ou sobre a implementaca~o do projeto. Mas apenas parte do projeto precisa eventualmente ser implementado para avaliac~ao preliminar. Quanto ao ciclo de vida da Figura 2.4-4, convem ressaltar que modelos mais tradicionais como o modelo cascata n~ao s~ao apropriados para acomodar e conviver com modelos de desenvolvimento de interfaces como o apresentado nesta gura. A suposica~o de que as atividades envolvidas ocorrem de forma linear n~ao e valida no contexto de interfaces. Conforme [27], a interface pode n~ao estar bem de nida ate poucos instantes antes da liberac~ao de um sistema interativo!

Captulo 2. Processo de Construca~o de Interfaces

17

Diretrizes Padroes Experiencia Avaliacao Requisitos PROJETO

Especificacao Modelos Formais IMPLEMENTACAO

Diretrizes Reqs Padroes

Prototipo / Sistema

AVALIACAO

Figura 2.4-4: Modelo de processo tpico de desenvolvimento de interface [67].

2.5 Ciclo de vida estrela Hartson e Hix [29] apresentam outro ciclo de vida para o desenvolvimento de interfaces exibido na Figura 2.5-5. Este ciclo foi cunhado para melhorar especi camente a usabilidade de uma interface. Neste aspecto difere tanto do modelo cascata quanto do modelo espiral. A liberdade em relac~ao a ordem em que as atividades podem ser realizadas, ou mesmo para iniciar o processo de desenvolvimento, distancia-o bastante das sequ^encias rgidas impostas por outros modelos. Neste modelo, virtualmente qualquer atividade pode seguir qualquer outra, depois de uma avaliaca~o. Esta proposta baseia-se na observac~ao de projetistas experientes realizando desenvolvimentos de 2 a 3 anos de duraca~o em grandes empresas. Identi caram que o trabalho realizado ora seguia de forma descendente (top-down ), ora ascendente (bottom-up ). Por exemplo, podia-se iniciar o processo pela analise de tarefas e posteriormente implementar varios prototipos para determinar um leiaute satisfatorio para uma caixa de dialogo. Praticamente inexistem restric~oes com relac~ao a ordem em que tarefas s~ao realizadas nesse modelo.

2.6 Integrando Processos de Desenvolvimento Embora o projeto da interaca~o seja uma atividade importante, as atuais praticas de desenvolvimento de sistemas t^em imposto uma serie de restrico~es para a aplicaca~o de princpios bem aceitos em projetos de interaca~o. Poltrock e Grudin [68] comentam em detalhes tais obstaculos. Em geral, as propostas para o desenvolvimento de software s~ao descritas como

18

2.6 Integrando Processos de Desenvolvimento Implementação

Análise de tarefas

Avaliação Requisitos

Protótipo

Projeto Conceitual

Figura 2.5-5: Ciclo de vida estrela [29]. abordagens alternativas, embora elas possam ser vistas como complementares [70]. Ou seja, cada abordagem e empregada no desenvolvimento de parte do sistema a qual mais se adapta. Downton [15, cap. 1] mostra como o desenvolvimento tradicional de um sistema interativo pode incorporar especialistas em interfaces, ilustrado na Figura 2.6-6. Esta gura ressalta os instantes do desenvolvimento de um sistema nos quais s~ao realizados atividades pertinentes ao desenvolvimento da interface. Escopo da Aplicação Especificação

Análise de tarefas/ Modelagem do usuário

Avaliação de viabilidade

Especificação formal da interação

Análise de sistemas/ Desenvolvimento Prototipagem rápida Implementação

Ferramentas de projeto de diálogo

Depuração

Técnicas de avaliação formal

Produção

Manutenção e Manual do usuário

Manutenção DOCUMENTAÇÃO

Figura 2.6-6: Ciclo de vida acrescido de especialistas em interfaces (adaptado de [15]). Lee [43] apresenta uma proposta de desenvolvimento de sistemas interativos que integra o processo de desenvolvimento da aplicac~ao e o desenvolvimento da interface. O ciclo de vida proposto e orientado a objetos. McDaniel et al. [53] tambem apresentam uma proposta que combina metodos para o desenvolvimento de interfaces e aqueles voltados

19

Captulo 2. Processo de Construca~o de Interfaces

para o desenvolvimento de software em geral usando o paradigma de objetos. Mantei e Teory [51] identi cam varios estagios, ao longo do ciclo de vida de um software, considerados tpicos e que contribuem signi cativamente para os custos de desenvolvimento. Nestes estagios, contudo, pouca ^enfase e dada ao componente software responsavel pela interface. Contemplar no desenvolvimento tradicional as etapas necessarias para o desenvolvimento adequado da interface signi ca acrescentar o tempo dedicado a estas atividades, que obviamente tem um impacto sobre os custos de desenvolvimento. O ciclo e apresentado na Figura 2.6-7. Análise de mercado

Ciclo de vida tradicional de software

Definição de requisitos Análise de aceitação do produto

Análise de tarefas Projeto global Construção de protótipos

Teste do usuário e avaliação Implementação do sistema Teste do produto

Teste do usuário Manutenção

Atividades típicas do desenvolvimento de interfaces

Estudo de viabilidade

Revisão do produto

Figura 2.6-7: Ciclo de vida estendido (adaptado de [51]).

2.7 Outros modelos Nesta sec~ao ainda s~ao exibidos outros dois modelos que tambem d~ao ^enfase a construc~ao de prototipos e a avaliac~ao por parte de usuarios representativos.

2.7.1 Projeto centrado em tarefas Na proposta apresentada por Lewis e Rieman [45], o processo e organizado em torno de tarefas espec cas que o usuario ira realizar com o sistema em desenvolvimento. A premissa basica e que um sistema interativo alcanca o sucesso somente se o usuario e capaz de executar as tarefas que necessita realizar de forma conveniente. Ou seja, a ^enfase apenas na aplicac~ao ou somente na interface podem comprometer o sucesso do sistema. As tarefas relevantes s~ao identi cadas bem no incio do processo e s~ao ent~ao,

20

2.7 Outros modelos

utilizadas para questionar o projeto, bem como auxiliar na tomada de decis~oes de projeto e na sua posterior avaliac~ao. A Figura 2.7-8 fornece uma ilustrac~ao do processo. Análise de tarefas e do usuário

Observação de sistemas existentes

Projeto inicial Características gerais Análise inicial Projeto Projeto Construir protótipo

Avaliação

Protótipo

Figura 2.7-8: Projeto centrado em tarefas.

2.7.2 Ciclo de vida centrado na avaliac~ao Bass e Coutaz [5] tambem apresentam um ciclo, onde iterac~ao e avaliaca~o s~ao os termos primordiais. A Figura 2.7-9 ilustra cinco atividades que se interrelacionam via a atividade de avaliac~ao. Ao contrario do ciclo estrela, a ordem em que s~ao realizadas as atividades n~ao e t~ao exvel. As atividades a esquerda da avaliaca~o tendem a ser realizadas antes daquelas a direita. A atividade de de nir objetos de computaca~o estabelece como as tarefas, identi cadas na analise de tarefas, estar~ao disponveis aos usuarios. O projeto equivale a esta atividade acrescida da de nic~ao da interface. Definição do problema

Modelo do usuário

Análise de tarefas

Definir objetos de computação Avaliação

Definição da interface

Figura 2.7-9: Ciclo de vida com ^enfase em avaliac~ao.

Captulo 2. Processo de Construca~o de Interfaces

21

2.8 Exerccios 1. Alguns dos modelos de ciclos de vida comentados t^em caractersticas fundamentais em comum com o modelo estrela e o modelo proposto por Bass & Coutaz com relac~ao a atividade central de avaliac~ao. Baseadas em caractersticas compartilhadas, poderamos agrupa-las em \famlias" de modelos. Voc^e consegue identi car outras famlias? Quais caractersticas fundamentais voc^e utilizou para agrupa-las? 2. A analise de tarefas e uma atividade constante em praticamente todos os modelos de desenvolvimento de interfaces comentados no presente captulo. A que voc^e atribui este fato? 3. De que forma est~ao relacionadas as atividades de analise de requisitos e analise de tarefas? 4. Como voc^e avaliaria uma interface sem e com a participaca~o de usuarios representativos? 5. No modelo apresentado na Figura 2.1-1 o processo de desenvolvimento da aplicac~ao e o da interface so t^em a primeira e a ultima fase em comum. A primeira fase comum, a de Analise do Sistema, portanto, precisa alimentar a fase de projeto dos dois processos de desenvolvimento que a sucedem. Que tipo de informac~ao voc^e imagina que seja passada nos dois casos?

22

2.8 Exerccios

Captulo 3 Projeto de Interac~ao Precisamos nos educar acerca de projeto visual e princpios de interac~ao, seja para melhor comunicarmo-nos com especialistas ou para realizarmos um trabalho mais competente. Marc Rettig [72]

A import^ancia e o impacto de uma interface foram estabelecidos no primeiro captulo. No captulo anterior foi comentado o processo de desenvolvimento de interfaces. Neste captulo e apresentado o conhecimento com o que o projetista da interaca~o deve estar munido para realizar, adequadamente, uma das atividades principais descritas nos processos do captulo anterior: o projeto de interaca~o. Este conhecimento consiste em informac~oes (entradas) que auxiliam o projetista na tomada de suas decis~oes durante a realizac~ao deste projeto, alem daquelas necessarias para registrar os resultados desta etapa (sadas). O captulo ainda apresenta formas de registrar as decis~oes tomadas, ou seja, o projeto de interac~ao enquanto produto.

3.1 O que e projeto de interac~ao? Conceber um projeto (design ) n~ao e uma tarefa simples. Em ess^encia, projeto e a descric~ao de um objeto a partir da qual ele pode ser construdo. Tambem pode ser visto como um planejamento de uma construc~ao de um objeto. Note que o termo projeto e comumente empregado ora com o signi cado de \processo" ora de \produto." Pequenos empreendimentos podem ser realizados sem a descrica~o explcita de um projeto, ou seja, eles podem ser executados a medida que seus detalhes s~ao \concebidos." Outros, no entanto, n~ao permitem esta abordagem devido aos custos envolvidos na eliminac~ao de possveis falhas. Corrigir um erro seria caro, quando n~ao impossvel. Por outro lado, corrigir modelos e especi cac~oes e uma atividade bem menos onerosa do que os seus efeitos correspondentes sobre objetos reais. Por exemplo, com lapis e borracha pode-se reposicionar o bot~ao liga/desliga de um controle remoto de uma televis~ao, aumentar ou abaixar a altura de uma ponte ou, ainda, corrigir a sua direca~o em alguns graus sem

24

3.1 O que e projeto de interaca~o?

grandes di culdades. No entanto, as consequ^encias destas mudancas sobre tais objetos em construc~ao ou ja acabados s~ao claramente bem mais dispendiosas. A construc~ao de interfaces ainda n~ao possui um padr~ao de desenvolvimento sistematico que possa ser aplicado com sucesso garantido (o captulo anterior fornece mais detalhes). Ou seja, de nir uma interface com a qual o usuario ira interagir e, paulatinamente, re nar esta de nic~ao atraves da avaliaca~o de prototipos/modelos formais ate a obtenca~o de um projeto satisfatorio e uma necessidade! Posteriormente, a implementac~ao ainda pode revelar di culdades n~ao identi cadas na fase de projeto e, neste caso, o projeto e realimentado com novos dados e refeito. A esta de nica~o de uma interface da-se o nome de projeto da interac~ao. O projeto de interac~ao e a atividade que de ne o look and feel de uma interface. O termo Look and Feel compreende tanto a apar^encia quanto a din^amica de interaca~o de uma interface. Extensas e elucidativas discuss~oes sobre o projeto de interac~ao podem ser obtidas em [3, 42]. Outras refer^encias recomendadas incluem [8, 19, 84]. Projeto de interac~ao: de ne o comportamento e a apresentac~ao de uma interface. A execuc~ao deste projeto requer conhecimentos nas areas de psicologia, fatores humanos, tecnologia dos dispositivos de entrada e sada, tipos de dialogos, analise de tarefas, princpios, diretrizes, padr~oes, regras, prototipos e avaliac~ao de sistemas existentes entre outros. O resultado do projeto e a especi cac~ao do projeto, geralmente atraves de especi cac~oes formais, prototipos ou ainda documentos informais.

No Captulo 2, pagina 12, Figura 2.1-1, foi apresentado um modelo de atividades e o tipo de informac~ao trocada entre elas no desenvolvimento de um sistema interativo. A parte superior desta gura refere-se ao desenvolvimento da aplicac~ao. A parte inferior e reproduzida na Figura 3.1-1, ligeiramente ampliada. Esta ampliaca~o torna mais claro o relacionamento desta atividade com as suas vizinhas, alem de olhar esta atividade de uma perspectiva funcional. Esta gura merece algumas consideraco~es. Primeiro, pode ser necessario construir varios prototipos ate que o resultado desta atividade seja julgado satisfatorio em uma determinada fase de avaliac~ao. Segundo, aspectos computacionais podem impor restrico~es ao projeto, ou seja, aspectos humanos n~ao e a unica entrada esperada. Terceiro e ultimo, o resultado desta atividade e o produto projeto de interac~ao, que deve ser entregue a uma equipe de desenvolvimento preparada para construir o software de uma interface. Na sec~ao abaixo e comentado o carater multidisciplinar do projeto de interac~ao. Nas sec~oes posteriores s~ao apresentados, respectivamente, varias fontes de informac~oes uteis a realizac~ao desta atividade e alguns dos mecanismos empregados para registrar (descrever) o produto dela resultante. Algo importante a ser dito em relac~ao a princpios, guias de estilo e outras fontes de informaca~o utilizadas por projetistas para orientar as suas

25

Captulo 3. Projeto de Interaca~o Especificacoes de usabilidade dos requisitos de projeto da Requisitos Especificacoes interface do projeto de software

Projeto da Interacao Restricoes e problemas

Projeto do software da Interface

Restricoes e problemas

Programas

Implementacao do software da Interface

Restricoes e problemas

Erros

Figura 3.1-1: Desenvolvimento de interfaces homem-computador. atividades relacionadas com o projeto de interac~ao, e que elas n~ao s~ao su cientes para assegurar que a interface produzida seja boa | n~ao existem regras que garantam isto [55, 57]. Em varios pontos deste texto e enfatizado o fato de inexistir uma \linha de conduta" que invariavelmente produza uma boa interface. Tais conhecimentos s~ao utilizados apenas como \heursticas." Note ainda que estas informac~oes n~ao t^em relev^ancia isoladamente. O processo ao longo do qual estas informac~oes s~ao utilizadas e de primordial import^ancia, conforme visto no captulo anterior.

3.2 Princicipos de projeto de interac~ao  Consist^encia. O dialogo deve seguir regras simples e n~ao apresentar casos especiais 

 



ou excec~oes para operac~oes similares. Retroalimentac~ao (feedback). Ac~oes do usuario devem gerar uma retroalimentac~ao para certi car ao usuario as consequ^encias de suas ac~oes. Geralmente isto e obtido atraves de representac~oes visuais e sinais sonoros que re etem, constantemente, informac~oes sobre o estado interno do sistema e, por conseguinte, alteraco~es deste estado. Minimizac~ao de possibilidades de erro. Devem ser fornecidos ao usuario somente os comandos passveis de serem executados em um particular instante da interaca~o. Se uma operac~ao n~ao pode ser disparada, ent~ao n~ao deve ser acessvel. Fornecimento de um meio de recuperac~ao de erros. Entre operaco~es desejaveis em uma interface comum podemos citar: refazer um contexto anterior a execuc~ao de um comando (undo), cancelar, interromper a sua execuca~o ou substituir um dado ou comando fornecido. Sem estas operac~oes a di culdade de corrigir um erro pode ser inaceitavel ou inibir a experimentac~ao por parte dos usuarios. Tratamento adequado de usuarios com habilidades diferentes. Alguns sistemas s~ao usados por uma grande variedade de pessoas, desde novatos ate especialistas com conhecimentos previos variados. A cada um destes grupos deve estar disponvel um dialogo apropriado.

26

3.3 Uma atividade multidisciplinar

 Minimizac~ao da necessidade de memorizac~ao. Quanto menor o numero de informac~oes que precisam ser memorizadas, melhor e a aceitaca~o de uma interface. Menus e metaforas de formularios, por exemplo, s~ao estilos utilizados com esta nalidade.

 Metaforas. Visam reduzir barreiras da interaca~o atraves de ac~oes, procedimentos

e conceitos familiares ao usuario. Detalhes sobre metaforas podem ser obtidos em [10].

 Realizac~ao do projeto do pondo de vista do usuario. Este princpio, tambem e conhe-

cido por user-centered design, onde o objetivo e realizar o projeto da interac~ao do ponto de vista do usuario em vez da perspectiva de um especialista em computac~ao.

 Tempo de aprendizado. O dominio das tarefas a serem realizadas com o sistema n~ao devem exigir, idelamente, grande esforco por parte do usuario.

3.3 Uma atividade multidisciplinar O projeto de uma interface envolve o conhecimento de varias areas. Em geral, no entanto, sistemas s~ao concebidos sem o auxlio de especialistas pertinentes a estas areas e, em alguns casos, apenas especialistas em computaca~o tentam aplicar empiricamente os conhecimentos destas areas. Conforme Downton [15], projetos desenvolvidos sem os conhecimentos especializados destas areas acabam fazendo uso da capacidade de adaptac~ao do ser humano para compensar suas de ci^encias. Downton comenta, em detalhes, a contribuic~ao de cada uma das areas abaixo. Algumas contribuem mais que outras, conforme a natureza do sistema.

 Ci^encia da Computac~ao. Fornece a estrutura tecnologica para facilitar o projeto e

implementaca~o de interfaces alem de restrico~es (custos, viabilidade e outras) que o projeto da interac~ao devera satisfazer. O tema interface e considerada neste texto segundo a perspectiva desta area.

 Psicologia. Preocupa-se com o entendimento do comportamento humano, percepc~ao,

cognic~ao e outros. A psicologia permite derivar metodos para auxiliar o usuario na realizac~ao de suas atividades. O princpio do numero magico 7 + = ; 2 [54] e um exemplo que estabelece que o ser humano e capaz de considerar simultaneamente, em geral, de 5 a 9 topicos distintos. Outro exemplo e [21], que destaca a melhor aceitac~ao por parte de usuarios de objetos de interaca~o retangulares que apresentam a raz~ ao aurea (quociente entre a altura e largura de um ret^angulo dada por  = 1+p5  1:61803 : : :). 2

 Ergonomia. Envolve-se com aspectos fsicos da adaptac~ao das maquinas para uso

humano. Por exemplo, formatos de dispositivos fsicos de interaca~o s~ao (teclado, mouse e outros) de interesse desta area.

Captulo 3. Projeto de Interaca~o

27

 Lingustica. A interac~ao homem-computador baseia-se em uma linguagem. Lingustica e o estudo de linguagens. A teoria de linguagens formais compartilha formalismos com a ci^encia da computac~ao que s~ao amplamente utilizados na especi cac~ao formal de dialogos. Lex (gerador de analisador lexico) e Yacc (gerador de analisador sintatico) s~ao ferramentas do ambiente UNIX que podem ser utilizadas na implementac~ao de interfaces [63] e exempli cam a in u^encia desta disciplina no desenvolvimento de interfaces. Idealmente, mensagens de erros, por exemplo, devem ser de nidas por especialistas nesta area.

 Sociologia. No contexto de interfaces a sociologia preocupa-se com o impacto dos

sistemas interativos na estrutura da sociedade. Groupware applications, por exemplo, bene ciam-se de teorias sociologicas [17]. Tais sistemas d~ao suporte a grupos de pessoas envolvidas na realizaca~o de uma tarefa comum e fornecem uma interface para um ambiente compartilhado.

 Desenho gra co e tipogra a. As habilidades esteticas dessas areas s~ao importantes a medida que tornam \bonita" e \atraente" a apresentac~ao de uma interface aos olhos dos usuarios.

N~ao e esperado que um unico indivduo (projetista) possua conhecimentos em todas estas areas. Uma alternativa mais realstica e ter um grau de \consci^encia" (nvel de entendimento) acerca destas areas, combinado com o apoio especializado em uma ou outra area, conforme as exig^encias impostas pela interface a ser desenvolvida. Este nvel de entendimento e particularmente essencial para os especialistas em computaca~o em situac~oes onde ter~ao que desenvolver sistemas interativos sem o auxlio de especialistas em IHC. O conhecimento destas areas ou de especialistas em IHC tambem pode se apresentar na forma de diretrizes, metodos, tecnicas e ferramentas desenvolvidas por pesquisadores para serem utilizadas por especialistas em computac~ao ou por outros membros de uma equipe de desenvolvimento. Convem ressaltar que, em ambos os casos, n~ao se tem a garantia de que a interface resultante sera de alta qualidade. O conhecimento de especialistas em computaca~o e geralmente insu ciente para a realizac~ao de projetos de interac~ao. A formaca~o basica tpica deste pro ssional n~ao contempla todos os conhecimentos necessarios para o desenvolvimento adequado de tal atividade. Sendo assim, o melhor e, sempre que possvel, permitir que o especialista pertinente desenvolva o projeto de interac~ao. Alternativamente, o especialista em computac~ao pode fazer uso de ferramentas que utilizam, de forma subjacente, os conhecimentos necessarios.

3.4 Atividade de projeto Os projetistas tentam satisfazer as expectativas de usuarios em relaca~o a um sistema interativo atraves do projeto da interac~ao, que envolve a aplicac~ao de conhecimentos de varias areas de conhecimento (conforme ja enfatizado na sec~ao anterior). Contudo, esta

28

3.4 Atividade de projeto

interac~ao n~ao envolve apenas o usuario. Em um dos extremos desta comunicac~ao esta o computador, que tambem possui limitaco~es e tambem deve ser \conhecido" para permitir a realizac~ao adequada de um projeto de interaca~o. Dessa forma, informac~oes acerca dos usuarios e de computadores devem ser utilizadas e interpretadas durante o processo que ira produzir uma especi caca~o de um projeto de interac~ao. Contudo, o conhecimento das capacidades e limitac~oes de usuarios e computadores n~ao e su ciente. Tambem e preciso compreender as formas alternativas atraves das quais usuario e computador podem interagir. Na sec~ao seguinte s~ao apresentadas tecnicas, subtarefas e informac~oes relevantes para o projeto de interaca~o denominadas entradas deste processo. Note que nem todas estas entradas s~ao necessarias para o desenvolvimento de um sistema interativo e que a lista aqui apresentada n~ao e exaustiva. Os topicos abordados s~ao aqueles mais frequentemente empregados.

3.4.1 Entradas do processo Analise de tarefas A analise de tarefas e uma das primeiras etapas de um projeto. Esta atividade identi ca as tarefas disponiveis aos usuarios de um dado sistema. Uma tarefa pode ser decomposta em outras tarefas.

Informac~oes sobre os usuarios Os usuarios novatos, intermitentes e frequentes podem ser adequadamente tratados de formas distintas. Projetar uma interface que contemple apenas uma destas categorias de usuarios ira trazer di culdades para os usuarios das demais categorias. Ha outras informac~oes que tambem s~ao uteis: sexo, idade e habilidades fisicas s~ao exemplos. O nivel de conhecimento, por exemplo, auxilia a identi car o conteudo a ser apresentado via a ajuda do sistema (help).

Princpios, padr~oes, diretrizes e regras S~ao sugest~oes para a tentativa de produzir uma boa interface. Re etem o \senso comum" ou o \bom senso" no projeto de interfaces. Embora Shneiderman [78] faz refer^encia a \regras de ouro" para denominar a lista abaixo, nada assegura que estes princpios conduzir~ao a uma boa interface. Russell et al. [75] citam situac~oes em que surgem con itos entre eles. Downton, em [15], e mais incisivo ao a rmar que contra-exemplos podem ser estabelecidos para cada princpio. Smith e Mosier [81] apresentam uma extensa lista com 944 diretrizes. Outra refer^encia sobre este assunto e [19, pags. 391-414].

Captulo 3. Projeto de Interaca~o

29

Dispositivos de entrada e sada Dispositivos de entrada (teclado, mouse) e sada (impressora, tela) conectam os \sentidos" humanos aos canais utilizados pelo computador para a comunicac~ao com o mundo externo. O projetista deve conhecer as tecnologias disponveis e saber quando emprega-las.

Estilos de interac~ao Um estilo de interaca~o refere-se a uma forma atraves da qual ocorre uma interac~ao entre usuario e computador. Em geral, varios estilos s~ao empregados em uma mesma interface. Eles visam obter ou apresentar informac~oes ao usuario atraves de um comportamento bem de nido. Abaixo s~ao comentados varios estilos. Detalhes podem ser obtidos em [19] e [78]. O projetista deve conhecer os estilos de interaca~o para poder emprega-los de forma apropriada. Um guia pratico e extenso acerca do emprego de estilos de interac~ao pode ser obtido em [15, 52]. Estilos de interac~ao menos convencionais (p.ex., data glove) s~ao abordados em [89].

 WYSIWYG. Atraves de uma interface WYSIWYG (What You See Is What You

  



Get) o usuario observa na tela, em tempo real, o resultado nal, ou um modelo dele, ou uma aproximac~ao destes do processamento da aplicaca~o. Por exemplo, um editor de texto WYSIWYG mostra na tela o que sera impresso enquanto o usuario atua sobre o texto. Linguagem de comandos. Meio de interac~ao em que o usuario fornece, via teclado, uma sequ^encia de caracteres correspondentes a entrada. Geralmente e empregado por usuarios experientes em uma aplicac~ao. Fornece um acesso rapido aos recursos providos mas exige memorizaca~o. Linguagem natural. Extens~ao do caso anterior, onde o usuario n~ao esta limitado a usar um vocabulario exguo de palavras e uma sintaxe rgida para expressar os comandos que deseja ver executados pela aplicac~ao. Manipulac~ao direta. Este termo esta associado as seguintes ideias centrais [77]: (1) visibilidade do objeto de interesse; (2) aco~es rapidas e reversveis; (3) visualizac~ao imediata do resultado; e (4) substituic~ao de estilos de interac~ao como os de linguagem de comandos e menus pela manipulac~ao direta da representac~ao do objeto de interesse. Em outras palavras, este estilo permite que o usuario manipule, usualmente com o emprego do mouse, representac~oes de objetos do mundo real, dando-se a ele a impress~ao de estar atuando sobre estes objetos e n~ao apenas sobre suas representac~oes. Reac~ao por infer^encia. Em ingl^es o termo utilizado e demonstrational. Estilo no qual o usuario pode usar exemplos, fornecidos atraves de manipulac~ao direta, para

30

3.4 Atividade de projeto

 

 

especi car operac~oes abstratas [58]. O sistema usa infer^encias para \sugerir" generalizac~oes. Por exemplo, em uma interface que adota este estilo, na segunda vez que o usuario \arrasta" um arquivo com extens~ao .bak ate uma lata de lixo, imediatamente o sistema conclui que o usuario, provavelmente, deseja remover todos os arquivos com esta extens~ao. Antes de realizar esta operac~ao, no entanto, esta \infer^encia" e con rmada com o usuario. Ic^onico. Icone e um smbolo gra co que apresenta uma semelhanca ou estabelece uma analogia com um objeto, propriedade ou aca~o. Em interfaces ic^onicas, tarefas s~ao associadas a cones e acionadas atraves do mouse. Menus. Menu e uma lista de opc~oes da qual o usuario pode realizar selec~oes. Reduz a necessidade de memorizac~ao e limita o conjunto de opc~oes. Ha varias formas de apresentac~ao de um menu. Os menus em formatos circulares (pie menus ), por exemplo, permitem a mesma facilidade de acesso a todos os itens [36], o que n~ao e possvel com os menus tradicionais. Preenchimento de formularios. Estilo adequado para a entrada de dados composta por varios campos. Pode-se alternar entre campos, identi cados por rotulos, e fornecer a entrada em qualquer ordem. Caixas. A rea retangular usada para varios propositos: pode apresentar uma lista de opc~oes (geralmente de nidas em tempo de execuc~ao), obter informac~ao (texto) do usuario, apresentar mensagens ou, ainda, referir-se a um conjunto de estilos empregados para a realizac~ao de determinada tarefa. ListBoxes e caixas de dialogo s~ao exemplos de caixas.

Guias de estilo Um guia de estilo estabelece uma colec~ao de estilos de interac~ao e uma orientaca~o acerca de quando e como utilizar cada um deles. Para cada estilo s~ao bem de nidos o seu comportamento e a sua forma de apresentac~ao. Alguns deles s~ao citados abaixo:

   

Common User Access (CUA), IBM OpenLook, AT&T, Xerox e Sun Motif, OSF (Open Software Foundation) Windows, Microsoft

Em geral, estes guias v^em acompanhados de toolkits (veja Sec~ao 4.4). Cada toolkit implementa os estilos de interac~ao do guia ao qual esta associado e fornece uma interface de programac~ao. O objetivo e eliminar a difcil tarefa de implementar cada um dos estilos e permitir a sua reutilizaca~o. Guias de estilo s~ao independentes de plataforma (hardware

Captulo 3. Projeto de Interaca~o

31

e software), onde s~ao empregados. Por exemplo, e possvel implementar uma interface no padr~ao Motif em ambiente MS-Windows.

3.4.2 Sadas do processo A vis~ao do projeto de interac~ao de uma perspectiva funcional, identi ca o material necessario que serve de entrada a este processo e aquele por ele produzido (sada). O responsavel pelo projeto de interac~ao realiza este \mapeamento." Na seca~o anterior foi apresentado parte do material que serve de entrada para esta atividade. Nesta seca~o, estamos interessados nas varias formas que o resultado do projeto de interac~ao pode assumir. Em geral o projeto e documentado atraves de uma combinac~ao de guras, prototipos e descric~ao em linguagem natural, semi-formal ou, ainda, atraves de linguagem formal. Prototipos s~ao abordados abaixo. Linguagens semi-formais seriam aquelas que imp~oem restric~oes a uma descric~ao em linguagem natural, mas n~ao apresentam o rigor e precis~ao de linguagens formais. Uma linguagem semi-formal, com o proposito de descrever o projeto da perspectiva de usuarios, e apresentada. Contudo, a grande maioria das propostas atuais para descrever um projeto de interac~ao baseia-se em linguagens com sem^antica formalmente de nida e voltada para a implementaca~o de interfaces. Esta perspectiva da construc~ao (implementac~ao) de um projeto de interac~ao de uma interface e util para especialistas em computac~ao, mas apresenta di culdades de manuseio (aprendizado, interpretac~ao) para especialistas de outras areas (que tambem podem estar presentes em uma equipe de desenvolvimento) alem de potenciais usuarios da interface a ser construda. Dessa forma, deixamos para o Captulo 4 o tratamento de tais linguagens, pois este trata do desenvolvimento do software de interfaces. Convem ressaltar que as linguagens comentadas naquele captulo e aquelas aqui apresentadas capturam uma mesma realidade, mas registram esta realidade de perspecitivas distintas. Hix e Hartson [34] fornecem mais detalhes sobre estas perpectivas, suas diferencas e a motivac~ao para a exist^encia de linguagens que as capturem adequadamente. Eles sugerem que as abordagens atuais para o desenvolvimento de interfaces, na sua maioria, tomam emprestado da area de computac~ao linguagens proprias para a implementac~ao e as empregam em um outro domnio, o que n~ao necessariamente implica em bons resultados.

Prototipos A complexidade intrnseca de interfaces e o conhecimento ainda insatisfatorio acerca de como constru-las obrigam a validar decis~oes de projeto antes de p^o-las em pratica. Geralmente isto e feito atraves da construc~ao parcial da interface com o e de proposito de demonstrar o leiaute de telas bem como a apresentaca~o e a sintaxe de comandos. Tal construc~ao parcial e conhecida por prototipo. As ferramentas utilizadas para construir prototipos, geralmente, n~ao s~ao as mesmas utilizadas para a implementac~ao de nitiva de uma interface dado os objetivos de cada implementac~ao. No caso de prototipos pretende-se

32

3.4 Atividade de projeto

construir algo rapido para testar ideias enquanto que, em relac~ao a interface, pretendese gerar um codigo e ciente e robusto. Muitas ferramentas (Captulo ??, contudo, ja pretendem facilitar um maior reaproveitamento dos esforcos colocados na construc~ao de prototipos atraves de um esquema, onde especi caco~es de prototipos s~ao interpretadas e, uma vez validados, e gerado codigo a partir destas especi cac~oes. Tecnicas para a construc~ao rapida de prototipos s~ao descritas em [88]. O projeto de uma interac~ao, geralmente, dura semanas ate que algum resultado possa ser apresentado ao usuario. Uma forma alternativa de construir prototipos em pouco tempo de projeto e apresentada em [73]. Nesta abordagem, em vez das tradicionais ferramentas para confecc~ao de prototipos s~ao utilizados papel, canetas coloridas e outros materiais tpicos de um escritorio para gerar esbocos de telas que representam instantes de uma interaca~o. A caracterstica principal desta abordagem esta na rapidez com que o usuario pode ser envolvido na avaliaca~o de um projeto. Tradicionalmente, prototipos exigem tempo consideravel para serem construdos e modi cados. Usando esta tecnica, em pouco tempo podem ser desenhados menus, telas, bot~oes e caixas de dialogo. Todos estes desenhos podem ser utilizados durante uma execuca~o simulada da interface utilizando estes esbocos. As vantagens, neste caso, residem na pouca resist^encia a alterac~oes no projeto por parte do projetista, na devida atenc~ao dada aos aspectos mais relevantes, em detrimento de cores, formato de letras e outros que s~ao, pelo proprio processo de confecc~ao, eliminados e, por ultimo, no contato mais cedo do usuario com a interface em desenvolvimento.

Especi cac~oes de projeto: perspectiva do usuario A linguagem UAN (User Action Notation ) foi desenvolvida especi camente para registrar o projeto de interac~ao de uma perspectiva do usuario ao fornecer mecanismos para capturar suas ac~oes, em detrimento da perspectiva computacional, para a qual existem recursos proprios para o desenvolvimento do software de interac~ao [30]. UAN e uma alternativa para o extenso conjunto de tecnicas de representac~ao de decis~oes de projeto voltadas para a implementac~ao de interfaces. O captulo seguinte comenta varias destas tecnicas.

Especi cac~oes de projeto: outras abordagens Vimos que grande parte das linguagens existentes s~ao desenvolvidas para serem usadas por especialistas em computaca~o. Ha ainda a notac~ao UAN, citada acima, voltada para a captura do projeto, da perspectiva do usuario. Contudo, estes n~ao s~ao os unicos grupos de linguagens existentes para desenvolvimento de interfaces. No captulo seguinte ser~ao apresentadas aquelas que d~ao ^enfase ao desenvolvimento do software de interfaces. Outros, n~ao comentadas neste texto, incluem, por exemplo, linguagens para serem usadas pelo usuario (end-user programming). Um tratamento extenso sobre linguagens para desenvolvimento de interfaces pode ser obtido em [59].

Captulo 3. Projeto de Interaca~o

33

3.5 Exerccios 1. No captulo foi mencionado que restrico~es s~ao impostas pelos dois protagonistas envolvidos em uma interac~ao, isto e, o usuario e o computador. Voce poderia enumerar algumas e descrever as suas implicac~oes? 2. Enumere tr^es exemplos, onde uma tarefa e executada de forma mais rapida e precisa por um estilo de interac~ao do que se fosse executada baseada em outro estilo. 3. Icones e menus tornam disponveis operaco~es providas pela aplicac~ao associada a uma interface. Em que situac~oes voc^e usaria cones e em quais menus seriam mais proprios? 4. Voc^e acredita que informac~oes acerca dos usuarios (experi^encia, idade, conhecimentos, cultura e outras) s~ao importantes para de nir uma interface para serem utilizados por eles. Justi que sua resposta.

34

3.5 Exerccios

Captulo 4 Construc~ao do Software de Interfaces \O software de uma interface e inerentemente difcil de ser criado, porque ele congrega alguns dos aspectos mais difceis de programar" Brad A. Myers, Ablex Publishing, 1993 Advances in Human-Computer Interaction, vol 4, pag. 145.

Nos captulos precedentes foram apresentados conhecimentos e tecnicas uteis a de nic~ao da interac~ao (projeto de interaca~o) e como registra-la. Independente dos recursos e do processo empregados, uma vez realizado este projeto, o proximo passo e o desenvolvimento do software que realiza a interac~ao de nida. Este captulo trata essencialmente deste desenvolvimento: projeto e implementaca~o do software de interfaces. O desenvolvimento do software do restante de um sistema interativo (ou seja, da aplicac~ao) e extensivamente coberto em inumeras metodologias e abordagens comuns a area de engenharia de software. Elas enfatizam o desenvolvimento de aspectos funcionais de um sistema interativo e n~ao s~ao exploradas aqui. Neste captulo s~ao apresentadas abordagens que visam facilitar o desenvolvimento do software de interfaces. Naturalmente, se existem mecanismos que tornam menos difcil esta atividade, menor e o seu custo. A reduc~ao de custos, contudo, n~ao e a unica meta de tais abordagens. Prover o suporte adequado para a confecc~ao do software de \boas" interfaces e o grande objetivo. De nir o que e uma \boa" interface n~ao e uma quest~ao simples e o Captulo 1 lidou com este problema. Por outro lado, facilitar a construc~ao do software de interfaces signi ca amenizar os bem conhecidos desa os desta atividade. Sendo assim, o captulo inicia-se com a apresentac~ao de tais desa os seguidos de esforcos que os enfrentam.

36

4.1 Dificuldades com a confecca~o do software de interfaces

4.1 Di culdades com a confecc~ao do software de interfaces O desenvolvimento do software de uma interface e uma tarefa n~ao trivial. O projeto do software envolve di culdades relacionadas com a descric~ao do projeto, arquitetura de software a ser empregada e varios compromissos a serem estabelecidos. A implementac~ao exige habilidades n~ao usuais de um programador convencional. Em [60, 80] pode ser encontrada uma extensa discuss~ao sobre as di culdades de desenvolvimento do software de interfaces. Algumas delas seguem abaixo: 1. Projeto iterativo. N~ao ha \regras de ouro" para o projeto de interfaces. Em consequ^encia, o codigo e frequentemente modi cado ate que resultados satisfatorios sejam obtidos. Logo, este codigo deve ser escrito de forma que possa ser modi cado facilmente e, se possvel, sem afetar outras partes do sistema n~ao diretamente relacionadas com as correc~oes a serem efetuadas. 2. Apresentac~ao atrativa. Usar os pacotes gra cos e bibliotecas disponveis para a confecc~ao de interfaces gra cas n~ao e uma tarefa trivial. Obter um resultado satisfatorio pode ser um desa o. 3. Entrada assncrona. As interfaces que empregam o estilo de manipulaca~o direta s~ao guiadas pelas ac~oes dos usuarios, que podem ocorrer a qualquer momento atraves de qualquer dispositivo disponvel. O emprego de um controle externo faz-se necessario e requer uma estrutura de software diferente da utilizada em programas convencionais. Uma das decis~oes no projeto de software de uma interface envolve a fonte de controle de um sistema interativo. Na Figura 4.1-1 vemos tr^es alternativas. Em aplicac~oes tradicionais, o controle reside na aplicac~ao. Em termos de programac~ao, o controle (thread ) esta na aplicac~ao. A interface e vista como um servidor de apresentac~ao. Uma alternativa e colocar o controle na interface, como e o caso de muitas interfaces produzidas com o uso de ferramentas. Neste caso, a interface transfere o controle para rotinas da aplicac~ao em resposta as ac~oes dos usuarios. Do ponto de vista da interface, a aplicac~ao e uma biblioteca de procedimentos que implementa a funcionalidade do sistema, ou seja, um servidor de operac~oes da aplicac~ao. Quest~oes de controle e comunicac~ao pertinentes ao software da interface s~ao contemplados em [32]. Conforme [83], quando o controle reside na interface ele e dito externo (4.11b), quando reside na aplicac~ao e dito interno (4.1-1a). O controle ainda pode ser misto (4.1-1c), ou seja, ele e exercido tanto pela interface quanto pela aplicaca~o e a relac~ao entre eles n~ao e do tipo cliente-servidor, mas uma relac~ao entre pares de mesmos direitos (peer-to-peer ). O controle, durante a execuca~o de uma interface, n~ao necessariamente assume apenas uma unica forma das citadas acima. Em um determinado instante pode ser misto, externo ou interno e mudar mudar em outro instante subsequente. Naturalmente, o tipo de controle depende da natureza do

37

Captulo 4. Construca~o do Software de Interfaces

sistema interativo. O controle externo e interno podem ser vistos como casos particulares do controle misto. O controle misto, contudo, imp~oe maiores exig^encias ao ambiente operacional para a execuca~o do sistema interativo. APLICACAO

INTERFACE

APLICACAO

Chamada

Codigo

Retorno

(a)

INTERFACE Callback

Codigo

Codigo

Retorno

Codigo

(b)

Figura 4.1-1: Fluxo de controle interno (convencional) (a), externo (b) e misto (c). 4. Concorr^encia. Func~oes da aplicac~ao podem consumir grande quantidade de tempo para serem executadas. No entanto, a interface n~ao deve esperar pelo termino de tais execuc~oes e suspender toda e qualquer interaca~o com o usuario. Ela deve estar \pronta" para receber os pedidos dos usuarios sempre que requisitada. Em decorr^encia, o sistema deve ser organizado em multiplos processos. Isto signi ca, que o programador devera tratar problemas de sincronizac~ao, exclus~ao mutua e outros relacionados. 5. E ci^encia. Resposta imediata as aco~es dos usuarios e um requisito desejavel. Obter esta reac~ao imediata requer um trabalho adicional signi cativo por parte do programador, em alguns casos. 6. Manipulac~ao de erros. Sistemas interativos n~ao devem admitir o termino de execuc~ao em decorr^encia de erro do usuario. E preciso informa-lo e, se possvel, permitir que o erro possa ser corrigido. 7. Suspens~ao da execuca~o, undo e ajuda. Geralmente sistemas interativos permitem que uma atividade seja suspensa em qualquer instante ou, ainda, que ela possa ser \desfeita." Ha ainda a necessidade de prover ajuda ao usuario, i.e., help on-line. Estes requisitos acrescentam mais funcionalidade ao codigo da interface. Ha uma vasta quantidade de ferramentas utilizadas na construca~o de interfaces. Algumas disponveis comercialmente, enquanto outras atraves de centros de pesquisa. Estas ferramentas distinguem-se umas das outras em relac~ao a funcionalidade que prov^eem, a facilidade de uso da propria ferramenta, estilos de interac~ao empregados (Motif, OpenLook) e a portabilidade da interface gerada [31]. Hix & Schulman [35] apresentam uma metodologia para avaliar tais ferramentas nos seus varios aspectos sob duas dimens~oes: funcionalidade e usabilidade. Nesta seca~o abordaremos varios tipos de ferramentas para

38

4.2 Organizaca~o do software de interfaces

o desenvolvimento de interfaces. Ferramentas enfatizam atividades distintas do desenvolvimento de uma interface, algumas apoiam a confecca~o de prototipos, outras o projeto de interac~ao e ha ainda aquelas que apoiam a atividade de avaliaca~o. Portanto, a implementac~ao e apenas uma, n~ao a unica, das atividades de desenvolvimento de interfaces que possuem ferramentas de apoio.

4.2 Organizac~ao do software de interfaces Atualmente existem varias abordagens para o desenvolvimento sistematico ou \estruturado" do software de interfaces. Neste sentido, a organizac~ao funcional do software desempenha um papel importante. Funcionalmente, o software de uma interface pode ser dividido em varias camadas de abstrac~ao, conforme a tecnologia disponvel. Na Figura 4.2-2 (esquerda) cada camada fornece servicos para a superior. Esta descric~ao e util para classi car as varias ferramentas existentes (direita) de acordo com o tipo de recurso que oferecem. Cada ferramenta enfatiza uma ou outra camada deste modelo funcional, amenizando alguma di culdade associada a confecc~ao do software que realiza a func~ao pertinente. Aplicação

Aplicação

Controle de diálogo

Ferramentas de Alto Nível

Objetos de interação

Toolkit

Sistema de Janela

Sistema de Janela

Drivers

Sistema Operacional

Figura 4.2-2: Organizac~ao funcional e ferramentas de apoio. As sec~oes seguintes tratam das ferramentas que d~ao suporte ao desenvolvimento ou execuc~ao das camadas funcionais que s~ao de interesse neste texto: sistema de janela, toolkits, e ferramentas de alto nvel (sistemas de gerenciamento de interfaces).

4.3 Sistemas de janela Um marco ntido na historia das atuais interfaces foi a criaca~o do ambiente Smalltalk, um dos primeiros a fazer uso de janelas (windows ) atualmente muito comuns em qualquer sistema interativo. Janelas podem ser selecionadas e transladadas na tela com o uso do mouse. A primeira vers~ao deste ambiente, conforme [38], foi testada no Alto, um prototipo de computador desenvolvido no Xerox PARC (Palo Alto Research Center). Este computador e considerado um dos de uso mais faceis naquela epoca. Conceitos empregados no

Captulo 4. Construca~o do Software de Interfaces

39

Alto (desktop, windows, WYSIWYG e outros) foram re nados no XEROX Star em 1981. Baseado em conceitos apresentados nestas maquinas e com preco mais acessvel surge o Apple Macintosh em 1984. Em 1985 e lancado o Windows | uma tentativa de fornecer aos usuarios do computador mais difundido, o IBM-PC, facilidades semelhantes aquelas que os usuarios dos computadores supracitados possuam. O Windows consumiu 110 mil horas de programaca~o. Resultado: em dezembro de 1989 ja haviam sido vendidas 2 milh~oes de copias. No m de 1990 e incio de 1991 eram vendidas 30 mil copias por semana [38]. Grande parte deste sucesso e atribudo, sobretudo, a interface com o usuario, que tambem e um destaque do seu sucessor, o Windows 95. A ttulo de curiosidade, interface para o Star consumiu 6 anos de desenvolvimento [12]. Isto reforca dois pontos abordados no Captulo 1: a interface e importante para determinar o sucesso de um sistema interativo e seu desenvolvimento e uma atividade onerosa. Estes sucessos popularizaram os sistemas de janelas (Window Systems), como o X Windows [76] comum em ambiente UNIX. Um sistema de janela e um software que permite a criac~ao de varias janelas simult^aneas em uma unica tela, associa os dispositivos a entrada de uma delas e coordena a interaca~o entre elas e o usuario. Este sistema ainda e responsavel por ocultar depend^encias de dispositivos: uma aplicaca~o MS-Windows, por exemplo, n~ao tem que se preocupar com a in nidade de tipos de dispositivos de entrada e sada existentes e compatveis com o MS-Windows. Uma taxonomia para gerenciadores de janela e varias caractersticas peculiares de um sistema de janela s~ao apresentados em [56]. Sistema de Janela: gerencia recursos tpicos de um ambiente de janela, tais como eventos, criac~ao e remoc~ao de janelas, dispositivos de entrada e sada (mouse, teclado, vdeo e outros).

Um sistema de janela possui pelo menos duas interfaces: uma com o usuario e outra para uso de um programa. Os recursos fornecidos para programas, no entanto, s~ao de baixo nvel e exigem um esforco substancial do programador mesmo para realizar tarefas simples. O desenvolvimento do software de uma interface para o qual s~ao utilizados recursos fornecidos exclusivamente pelo sistema de janela e extremamente difcil. Com o intuito de prover recursos de mais alto nvel de abstraca~o, simpli car a tarefa do programador e permitir a reutilizac~ao de elementos comumente encontrados em interfaces foram criados os toolkits.

4.4 Toolkits Toolkit e uma biblioteca, usada por programadores, composta de uma colec~ao de widgets. Widget e um objeto de interac~ao, ou seja, um elemento que pode ser percebido e manipulado pelo usuario, com uma apresentac~ao e um comportamento bem de nidos. Um objeto

40

4.5 Ferramentas de alto nvel

de interac~ao implementa um elemento tpico de uma interface como um bot~ao, menu ou outro. Dessa forma, este tipo de ferramenta evita que elementos comuns em interfaces tenham que ser refeitos para cada novo sistema a ser desenvolvido. Widgets est~ao disponveis, usualmente, na forma de procedimentos ou objetos (inst^ancias de classes em um ambiente orientado a objetos). A interface desenvolvida com o uso de um toolkit interage, geralmente, com outras partes do sistema interativo atraves da invocac~ao de callbacks, isto e, func~oes fornecidas pelo programador para serem executadas em pontos espec cos da interac~ao em resposta a uma ac~ao do usuario sobre dispositivos de entrada. Para facilitar o posicionamento e a composic~ao de widgets, os toolkits geralmente s~ao acompanhados por um construtor de interface (interface builder), que permite realizar interativamente tais tarefas, sem necessidade de programac~ao, atraves da gerac~ao automatica de codigo que utiliza as facilidades do toolkit pertinente. Em geral os toolkits s~ao implementados utilizando os recursos providos pela interface de programaca~o de um sistema de janela. Por exemplo, MFC e OWL s~ao exemplos de toolkits, disponveis comercialmente, para ambiente PC que s~ao implementados fazendo uso dos recursos de baixo nvel do ambiente Windows. O emprego de toolkits facilita a consist^encia e a reutilizac~ao de widgets entre varios sistemas. Contudo, mesmo fornecendo uma abstraca~o maior do que aquela fornecida por um sistema de janela, o seu emprego e difcil (inclusive para programadores experientes) e o tempo de aprendizado e longo alem de possuir um conjunto limitado de objetos de interac~ao. Com o intuito de amenizar di culdades que ainda permanecem com o uso de toolkits, ao mesmo tempo que tenta desfazer aquelas decorrentes do emprego dos proprios toolkits, ferramentas de mais alto nvel s~ao o proximo passo para oferecer uma maquina abstrata ainda mais poderosa. Ferramentas de alto nvel que criam esta maquina abstrata s~ao comentadas na seca~o seguinte.

4.5 Ferramentas de alto nvel Ferramentas de alto nvel podem ser empregadas em fases distintas do ciclo de vida de uma interface, como as de especi cac~ao, projeto, implementac~ao, avaliac~ao e ate mesmo durante a execuc~ao de uma interface. Naturalmente, nem todas as ferramentas de alto nvel fornecem todos estes servicos. Em geral, cada ferramenta enfatiza uma fase deste ciclo de vida ou fornece uma proposta avancada para o desenvolvimento de um aspecto particular de interfaces. Ferramentas que operam em um nvel mais elevado de abstraca~o, oferecem servicos mais so sticados do que aqueles encontrados em toolkits e, geralmente, est~ao associadas a alguma forma de descric~ao do projeto de interac~ao da qual codigo executavel e automaticamente gerado, que se baseia em facilidades providas por um toolkit. O termo mais empregado para designar este tipo de ferramenta e Sistema de Ger^encia de Interfaces ou, simplesmente, SGI.

Captulo 4. Construca~o do Software de Interfaces

41

Um SGI (Sistema de Ger^encia de Interfaces) ou UIMS (User Interface Management System) esta para interfaces assim como um SGBD esta para uma base de dados. N~ao ha uma de nic~ao precisa e amplamente empregada. Normalmente um SGI designa servicos distintos. Um consenso em relaca~o a este tipo de ferramenta, porem, reside na \separac~ao" entre o codigo da interface daquele da aplicac~ao, separaca~o esta conhecida por independ^encia de dialogo (veja Sec~ao 4.8). Neste texto adotamos uma de nic~ao \classica," bastante abrangente. SGI: colec~ao de ferramentas integradas orientadas para especi cac~ao, projeto, implementac~ao, avaliac~ao e execuc~ao de interfaces.

Normalmente, um SGI enfatiza um ou outro aspecto do desenvolvimento ou funcionalidade de uma interface. Em particular, o termo SGI esta relacionado com ferramentas de alto nvel de apoio ao desenvolvimento de interfaces que oferecem consideravel suporte a interface em tempo de execuca~o. Neste sentido, ger^encia seria o termo apropriado, embora execuc~ao n~ao seja o unico tipo de servico oferecido, mas apenas o de maior destaque da ferramenta. Tambem e comum na literatura o termo Sistema de Desenvolvimento de interfaces (SDI) ou User Interface Development System (UIDS), que caracteriza aquelas ferramentas, cujo principal servico oferecido refere-se ao desenvolvimento da interface, isto e, a fase anterior a sua execuca~o. Ferramentas de alto nvel ou SGIs podem ser classi cados de acordo com o mecanismo empregado pelo projetista para descrever uma interface. Vimos no captulo anterior, por exemplo, que grande parte das tecnicas empregadas para descrever o projeto de interac~ao enfatizam a implementac~ao de interfaces, ou seja, s~ao de uso proprio para programadores. Myers [61] apresenta uma classi caca~o de um grande numero de ferramentas de alto nvel baseada na forma com que uma interface e descrita.

4.6 Arquitetura de software Um aspecto crtico do projeto de qualquer sistema de software grande relaciona-se com a organizac~ao, em alto nvel, de seus elementos computacionais bem como com as interac~oes entre estes elementos, o que e usualmente denominado de arquitetura de software [22]. Paradigmas de arquiteturas de software n~ao s~ao importantes apenas no domnio de engenharia de software. O projeto de interaca~o de uma interface bene cia-se da escolha de uma arquitetura de software apropriada. Sem um paradigma de arquitetura adequado, a construc~ao de sistemas interativos torna-se uma tarefa ardua, o software resultante e difcil de ser mantido e o re namento iterativo e praticamente impossvel. Ferramentas comentadas na sec~ao anterior, por exemplo, s~ao produzidas com o proposito de facilitar o desenvolvimento de parte da funcionalidade de uma interface e, portanto, possuem um foco de interesse distinto da organizaca~o do software em componentes e dos protocolos

42

4.6 Arquitetura de software

de comunicac~ao entre eles. Em outras palavras, o emprego de tais ferramentas, sem um modelo de refer^encia para orientar a identi caca~o de componentes de software interativo e o relacionamento entre eles, pode conduzir a sistemas monolticos com uma complicada mescla de codigos de propositos distintos. No restante desta sec~ao e apresentada uma evoluc~ao das arquiteturas para o software de interfaces. Uma discuss~ao extensiva sobre arquiteturas de software para interfaces pode ser obtida em [13].

4.6.1 Modelo de Seeheim O modelo de Seeheim e composto de tr^es componentes, como ilustrado na Figura 4.6-3. O componente de apresentaca~o gerencia a tela (criac~ao) e monitora os dispositivos de entrada, mapeia as ac~oes do usuario sobre os dispositivos de entrada em operac~oes de entrada descritas em uma linguagem abstrata e interpreta operaco~es abstratas de sada produzindo alterac~oes correspondentes na tela. A sequ^encia, em que operac~oes de entrada s~ao entregues ao controle de dialogo, guia o dialogo e produz solicitac~oes a serem enviada ao componente de interface com a aplicac~ao. No sentido contrario, o controle de dialogo recebe informac~ao da interface com a aplicaca~o relativas aos resultados produzidos por solicitac~oes executadas, o que pode, por sua vez, resultar em operac~oes abstradas de sada a serem interpretadas pelo componente de apresentac~ao. O componente de interface com a aplicac~ao pode responder diretamente a solicitac~oes do controle de dialogo, quando estas solicitac~oes n~ao forem sintaticamente validas, ainda e de responsabilidade deste componente transformar a sada da aplicaca~o em informaco~es nos formatos reconhecveis pelo controlador de dialogo. Em teoria, toda informac~ao da aplicac~ao que e para ser exibida deve passar pelo controle de dialogo. Em muitos casos o controle de dialogo n~ao esta interessado nos dados que passam por ele, que apenas atribui aos dados um formato e os passa para o componente de apresentac~ao. Uma vez que o controle de dialogo n~ao precisa processar estes dados, eles s~ao diretamente transferidos para o componente de apresentac~ao. Aquela ligac~ao signi ca esta atribuic~ao apos a qual o controle de dialogo n~ao participa da transfer^encia. Apresentacao

Controle de Dialogo

Interface com a Aplicacao

Figura 4.6-3: Modelo abstrato de um SGI. Modelo de Seeheim [23] De modo grosseiro, pode-se considerar o componente de apresentac~ao como o \nvel lexico" do sistema interativo. Um analisador lexico pode ser utilizado para ocultar os detalhes irrelevantes para o controle de dialogo de como os comandos e par^ametros podem ser fornecidos (p.ex., um comando pode ser originado da selec~ao de um menu e seu respectivo par^ametro de uma caixa de dialogo ou alternativamente, o comando foi selecionado

Captulo 4. Construca~o do Software de Interfaces

43

via cone e seu par^ametro atraves de um bot~ao pressionado). O controlador de dialogo, que pode ser visto como o \nvel sintatico" do sistema interativo, pode ser implementado como um analisador sintatico, que recebe os tokens pre-processados do analisador lexico (as operac~oes de entrada produzidas pelo componente de apresentac~ao) e veri ca a correc~ao sintatica do uxo de tokens a medida que s~ao obtidos. O \nvel sem^antico" e provido pela interface com a aplicac~ao. Embora esta interpretaca~o em nveis lexico, sintatico e sem^antico bene cie-se de varios avancos em compiladores, interfaces mais so sticadas di cilmente podem usufruir destes avancos devido as di culdades com esta arquitetura. Estas di culdades serviram de estmulo na identi caca~o de outras propostas de arquiteturas atualmente existentes.

4.7 Especi cac~ao de dialogo Linguagens de especi cac~ao de dialogo podem ser classi cadas segundo o modelo de controle de dialogo empregado. Tr^es modelos s~ao comentados abaixo, juntamente com notac~oes tpicas de cada modelo. Em [39] e apresentada uma lista de qualidades desejaveis em linguagens de especi cac~ao de dialogo. Geralmente as notac~oes est~ao associadas a ferramentas de apoio para construc~ao e execuc~ao de descrico~es. Conforme [87], diagramas de transic~ao e leiautes de tela s~ao inadequados para serem avaliados pelo usuario na aus^encia de um interpretador destes diagramas.

Modelos de controle de dialogo Comentarios exaustivos sobre tr^es modelos de dialogos (redes de transica~o, gramaticas e o modelo de eventos) podem ser obtidos em [24]. Abaixo s~ao descritos os modelos e as notac~oes tpicas empregadas. Estes modelos podem ser usados como metodos para formalmente especi car uma interface, possivelmente para servir de entrada para algum SGI, que gerasse automaticamente o controle da interface. O modelo mais comum para descrever interfaces e baseado em redes de transic~ao. Diagramas de Transica~o de Estados (DTEs) constituem a notaca~o mais conhecida deste modelo, que considera uma interface como uma coleca~o de estados ligados por arestas rotuladas com eventos. Estes eventos podem estar associados as ac~oes do usuario, instantes de tempo e resultados (sada) da aplicaca~o. A ocorr^encia de um evento e a condic~ao necessaria para que ocorra uma transic~ao entre estados. Alem disto, o estado onde a aresta representante da transic~ao se origina, deve estar ativo no instante em que o evento ocorre. Uma caracterstica positiva dos DTEs e a sua representaca~o gra ca. Statecharts [28] s~ao derivados dos DTEs empregados na especi cac~ao de sistemas reativos, em particular, o controle de dialogo de uma interface [49]. Statecharts permitem descrico~es hierarquicas bem como descrevem concorr^encia, comunicaca~o de informac~oes de controle e retorno a estados previamente visitados (historia).

44

4.8 Independ^encia de dialogo

Notac~oes baseadas em gramaticas consideram o dialogo entre usuario e aplicaca~o como uma linguagem descrita por regras gramaticais. Um gramatica utilizada para este m pode ser especi cada em BNF (Backus-Naur Form), que e amplamente empregada na especi cac~ao formal da sintaxe de linguagens de programaca~o. A notaca~o geralmente e estendida para permitir que codigo da aplicac~ao seja executado sempre que uma regra e utilizada. Notac~oes baseadas no modelo de eventos apresentam facilidades para a descric~ao de dialogos complexos, caractersticos de interfaces que empregam o estilo de manipulac~ao direta [18, 33]. Neste caso, uma interface e vista como um conjunto de eventos e tratadores para estes eventos e n~ao como estados e transico~es entre estados disparadas pela ocorr^encia de eventos. Eventos podem ser gerados por aco~es do usuario sobre dispositivos de entrada, por tratadores de eventos ou em decorr^encia de resultados produzidos pela aplicaca~o.

4.8 Independ^encia de dialogo O desenvolvimento de sistemas interativos onde o software da interface encontra-se entranhado com o da aplicac~ao, e tido como inconveniente. Em particular, quest~oes diferentes que necessitam ser tratadas de formas distintas n~ao est~ao devidamente separados. Na area de banco de dados ha um problema similar: o isolamento desejavel entre programas e dados, de tal forma que mudancas efetuadas em um n~ao afetem o outro. A soluc~ao e conhecida por independ^encia de dados. Uma soluc~ao analoga, no ^ambito de sistemas interativos, e chamada de independ^encia de dialogo, efetivada por um protocolo de comunicac~ao entre a interface e a aplicac~ao que de ne a linha divisoria entre estes dois subsistemas. A Figura 4.8-4 relaciona estes dois conceitos. Independencia de dialogo

Interface

Aplicacao

Banco de dados

Independencia de dados

Figura 4.8-4: Conceitos analogos: independ^encias de dados e dialogo. A independ^encia de dialogo permite separar quest~oes concernentes a interface, de um lado, e a aplicac~ao, de outro. Note que a aplicac~ao n~ao se interessa na forma como dados de entrada s~ao obtidos (menus, linguagem de comandos e outras), mas nos dados propriamente ditos. Analogamente, a interface n~ao se interessa pelo processamento dos dados (desconhece por completo qualquer que seja o algoritmo utilizado). A interface preocupa-se com a obtenc~ao de dados produzidos por usuarios e com a exibic~ao dos resultados das transformac~oes realizadas sobre estes dados pela aplicaca~o. Esta separac~ao produz alguns benefcios:

Captulo 4. Construca~o do Software de Interfaces

45

 Quest~oes que dizem respeito a um componente t^em in u^encia limitada no outro.  O desenvolvimento pode ser realizado independentemente, exceto quanto a de nic~ao

do protocolo de comunicac~ao entre eles.  Interfaces diferentes para uma mesma aplicac~ao podem ser desenvolvidas para grupos de usuarios distintos. Por exemplo, por motivo de lngua, cultura ou experi^encias individuais diferentes multiplas interfaces se fazem necessarias.

Obter esta separac~ao n~ao e uma tarefa simples, pois a divis~ao de atribuic~oes entre interface e aplicac~ao n~ao apresenta um fronteira ntida. Ha tambem argumentos contrarios a esta separac~ao. Por exemplo, a separac~ao entre estes componentes requer uma forma so sticada de comunicac~ao entre eles que pode comprometer a retroalimentac~ao \imediata" em interfaces que empregam manipulac~ao direta. Em outras palavras, o arrasto de um objeto sob a posic~ao do mouse, por exemplo, passando por varios pontos de uma tela, pode exigir uma comunicac~ao muito intensa entre a interface e a aplicac~ao, a tal ponto, que a interface n~ao consegue adequadamente atualizar a tela em tempo habil para prover a sensac~ao de arrasto no usuario. Em [31, 37] s~ao comentados, em mais detalhe, as implicaco~es desta separac~ao.

4.9 Exerccios 1. Cite um exemplo onde a arquitetura de software a ser empregada no desenvolvimento de um sistema interativo imp~oe restric~oes ao projeto de interac~ao da interface deste sistema. Explique ao menos um tipo de restrica~o. 2. O que voc^e entende por uma \interface atrativa"? De que forma voc^e usaria cores no desenho de um cone, por exemplo? 3. Existe um canal de comunicac~ao direta da interface com a aplicaca~o com o componente de apresentac~ao no modelo de Seeheim. Por que, na sua opini~ao, ele foi contemplado neste modelo? 4. Ferramentas de nvel mais alto abstraem de detalhes relevantes em nveis inferiores? O que se ganha e o que se perde com isto? 5. O gesto, por exemplo, utilizado por americanos para dizer que algo esta otimo e entendido como insulto no contexto brasileiro. Siglas, abreviaco~es ou termos aparentemente inofensivos em uma lngua podem ser obscenos em outra. Se voc^e estiver familiarizado com diferentes culturas, voc^e e capaz de enumerar caractersticas destas culturas que requeiram um tratamento diferenciado para serem utilizadas por interfaces?

46

4.9 Exerccios

Captulo 5 Avaliac~ao \A complexidade de sistemas constitudos tanto por seres humanos quanto por computadores fazem com que a interac~ao entre eles seja menos previsvel do que gostaramos que fosse. Mesmo as melhores intenc~oes podem resultar em sistemas n~ao utilizaveis ou, ainda mais frequentemente, em sistemas com problemas." Perlman [67]

N~ao ha formulas magicas para o desenvolvimento de interfaces. Por esta raz~ao a iterac~ao e uma necessidade neste processo, conforme visto no Captulo 2. Uma iterac~ao, por si so, contudo, n~ao teria utilidade sem a exist^encia de uma avaliac~ao ao nal de cada iterac~ao para determinar se um novo ciclo se faz necessario. Implcito em iterac~ao esta o otimismo de que cada ciclo aproxima mais um produto em desenvolvimento da sua forma ideal. N~ao somos pessimistas, mas e importante ressaltar que a tecnica de iterac~ao n~ao e uma soluc~ao enquanto tambem n~ao assegura a qualidade desejavel em um produto e que seu uso e caz depende fortemente da qualidade da avaliaca~o a ser realizada. O escopo do processo de avaliac~ao se estende desde a observac~oes de resultados de decis~oes de projetistas ate aquela realizada pelo usuario quando rejeita ou opta por um produto. Dessa forma, uma avaliac~ao pode tomar varias formas, ter propositos distintos e outras particularidades, que podem ser utilizadas para classi car as varias tecnicas existentes. Este captulo trata sucintamente deste tema, que pode ocupar sozinho todo o conteudo de um livro. Recomendadmos [86] para mais detalhes.

5.1 Vis~ao geral A avaliac~ao de um projeto geralmente apresenta-se como uma atividade necessaria no desenvolvimento de sistemas, n~ao exclusivamente de software. No mundo real, a construc~ao de um sistema, seguida de sua avaliac~ao e posterior correca~o de erros e impraticavel na grande maioria dos casos. Projetistas geralmente manipulam modelos, que so apos pelo menos um mnimo de \validac~ao" s~ao implementados. Esta regra tambem e aplicavel ao desenvolvimento de interfaces. O papel da avaliaca~o e veri car (projeto) se o sistema realmente se comporta como esperado e se ele atende as necessidades dos usuarios. No

48

5.2 Exerccios

contexto de interfaces ha indcios favoraveis que recomendam a realizaca~o desta atividade. O \censo comum", por exemplo, e algo comumente empregado durante o projeto. No entanto, n~ao pode ser aplicado de forma con avel e muitos resultados de pesquisas t^em contradito este princpio. Outro indcio diz respeito a postura do projetista, que assume, em geral, seu comportamento como representativo, o que e uma falacia. Estes e outros problemas s~ao comentados em [15]. A avaliac~ao pode ser executada durante todo o ciclo de vida do projeto e ate mesmo antes da exist^encia de um sistema executavel envolvendo apenas os projetistas, por exemplo. Em particular, tais projetistas podem injetar erros ao alterar um prototipo. Avaliac~ao e o mecanismo utilizado para tentar assegurar a converg^encia de um projeto para um sistema de qualidade satisfatoria. No entanto, isto n~ao substitui o teste com as pessoas para as quais o sistema e projetado: os usuarios. Neste ultimo caso, entretanto, e utilizado alguma forma de implementac~ao do sistema: desde simulac~ao de especi cac~oes, prototipos ate o sistema completamente implementado. Varias tecnicas podem ser usadas para a avaliaca~o de um produto na sua forma nal ou representado por um modelo. Por exemplo, os metodos analticos empregam modelos formais de interaca~o. Os metodos empricos utilizam-se de observac~oes do usuario, questionarios, entrevistas e experimentos desenvolvidos formalmente. Abaixo s~ao citados alguns metodos:

 Cenarios. Fornecem uma indicac~ao de caractersticas a serem conferidas a uma      

interface. Manual do usuario preliminar. Durante a escrita de detalhes espec cos, pode-se descobrir melhores metodos de operac~ao. Sistemas de fachada (mock-up). Demonstra a apar^encia pretendida para a interface. Simulaco~es previas. Demonstra o comportamento din^amico da interface. Prototipos. Mostra um limitado subconjunto da funcionalidade a ser implementada. Verbalizaca~o dos pensamentos (Think aloud). O usuario relata o que esta pensando enquanto esta operando um prototipo ou vers~ao preliminar do sistema. Teste formal de prototipo. Fornece informaco~es acerca do grau de facilidade com que tarefas podem ser realizadas. Usa tecnicas de pesquisas em fatores humanos e estatstica.

5.2 Exerccios 1. Como voc^e faria o registro de uma sess~ao de uso de um prototipo por parte de um usuario tpico? Que informac~oes devem ser coletadas para posterior analise? Uma

Captulo 5. Avaliaca~o

49

simples mudanca na express~ao facial pode signi car que alguma di culdade no seu uso foi encontrada. Que parte da coleta poderia ser automatizada? 2. Uma quest~ao importante em relaca~o a interfaces que apoiam a execuca~o de tarefas repetidas inumeras vezes por um numero grande de usuario, que trabalham em uma mesma empresa, e a sua produtividade. Que voc^e avaliaria em uma interface como esta, onde a quest~ao de produtividade e primordial? 3. A amostra de usuarios tpicos para testar prototipos de interface pode in uenciar signi cativamente os resultados obtidos no processo de avaliaca~o. Amostras \viciadas" podem n~ao desvendar problemas graves enquanto que grandes variac~oes em termos de experi^encias anteriores, por exemplo, podem produzir resultados inconclusivos. Que tipos de cuidados devem ser tomados para n~ao invalidar o processo de avaliac~ao?

50

5.2 Exerccios

Captulo 6 Palavras Finais \Para os usuarios, a interface representa o sistema." Hix and Hartson [34]

Este texto apresenta fundamentos de uma area relativamente recente relacionada com a interac~ao de seres humanos com computadores. Varios aspectos do desenvolvimento de interfaces s~ao abordados. As informaco~es apresentadas s~ao sucintas, contudo, acreditamos que o \todo" sirva de arcabouco, onde mais informac~oes podem ser obtidas atraves das refer^encias fornecidas. Buscou-se passar uma vis~ao geral da area baseada em recomendac~oes sobre o ensino do topico [20, 79, 67], com ^enfase em aspectos de interesse de especialistas em computac~ao. A estrutura do texto pretende servir de guia para estes pro ssionais com relac~ao a vasta bibliogra a existente. Acreditamos que, no espaco disponvel, a abordagem empregada produz melhores resultados do que a apresentaca~o deste ou de outro metodo de projeto, que pode ser encontrada na bibliogra a apresentada. Alem disto os fundamentos s~ao mais estaveis do que informac~oes sobre processos espec cos, que s~ao mais volateis, ja que os temas desta area, relativamente instavel, est~ao sujeitos a constantes mudancas. Os fundamentos s~ao uteis no entendimento de propostas descritas na literatura e de propostas ainda a serem feitas. Expectativas sempre crescentes de usuarios de computadores bem como avancos tecnologicos em diversas areas relacionadas t^em sido as molas propulsoras na area de interfaces. Mega esforcos de programaca~o para desenvolver sistemas de apoio a trabalho cooperativo que utilizem a infra-estrutura ja instalada de redes de computadores de longa dist^ancia s~ao esperados para o futuro proximo. Interfaces n~ao WIMP, por exemplo, que empregam reconhecimento de voz, gestos e outras formas de interac~ao bem como o emprego de realidade virtual s~ao sistemas cada vez mais comuns. Estes exemplos implicam em novos desa os tambem para a area de interfaces. Conforme Myers [61], multimdia, sistemas distribudos e sistemas de informac~ao geogra ca s~ao nichos para os quais existe um futuro promissor para boas ferramentas de apoio ao desenvolvimento de tais sistemas.

52 Novas fronteiras demandar~ao projetos e implementac~oes de sistemas interativos mais e mais complexos a serem desenvolvidos por pro ssionais com conhecimento cada vez mais especializado na area, ja que o sucesso deste tipo de empreendimento depende fortemente da qualidade de suas interfaces. Esperamos que o presente texto sirva de iniciac~ao para aqueles que enfrentar~ao os desa os da area atualmente colocados e os que ainda ser~ao feitos no futuro.

Bibliogra a [1] Ronald M. Baecker and William A. S. Buxton, editors. Readings in Human-Computer Interaction { A Muldisciplinary Approach. Morgan Kaufmann, 1987. [2] Ronald M. Baecker, Jonathan Grudin, William A. S. Buxton, and Saul Greenberg, editors. Readings in Human-Computer Interaction: Toward the Year 2000. Morgan Kaufmann, second edition, 1995. [3] Lon Bar eld. The User Interface - Concepts & Design. Addison-Wesley Publishing Company,Inc., 1993. ISBN 0-201-54441-5. [4] Len Bass and Joelle Coutaz. Developing Software for the User Interface. SEI Series in Software Engineering. Addison-Wesley Publishing Company, Inc., 1991. [5] Len Bass, Ross Faneuf, Reed Little, Niels Mayer, Bob Pellegrino, Scott Reed, Robert Seacord, Sylvia Sheppard, and Martha R. Szczur. A Metamodel for the Runtime Architecture of an Interactive System. SIGCHI Bulletin, 24(1):32{37, January 1992. [6] Daniel G. Bobrow, Sanjay Mittal, and Mark J. Ste k. Expert Systems: Perils and Promise. Communications of the ACM, 29(9):880{894, September 1986. [7] Barry W. Boehm. A Spiral Model of Software Development and Enhancement. IEEE Computer, pages 61{72, 1988. [8] Susanne Bdker. Through the Interface: A Human Activity Approach to User Interface Design. Lawrence Erlbaum Associates, Inc., 1991. ISBN 0-8058-0570-2. [9] Judy Brown. Exploring Human-Computer Interaction and Software Engineering Methodologies for the Creation of Interactive Software. SIGCHI Bulletin, 29(1):32{ 35, January 1997. [10] John M. Carrol, Robert L. Mack, and Wendy A. Kellogg. Interface Metaphors and User Interface Design. In Martin Helander, editor, Handbook of Human-Computer Interaction. Elsevier Science - Publishers B.V, 1988. [11] Uli H. Chi. Formal Speci cation of User Interfaces: A Comparison and Evaluation of Four Axiomatic Approaches. IEEE Software, SE-11(8):671{685, August 1985.

54

BIBLIOGRAFIA

[12] Joelle Coutaz. Abstractions for User Interface Design. IEEE Computer, 18(09):21{34, September 1985. [13] Joelle Coutaz. Software Architecture Modeling for User Interfaces. Technical Report, 1992. ftp.imag.fr/pub/IHM. [14] Bill Curtis. Japan's Research Focus Shifts to Interfaces. IEEE Software, November 1991. [15] Andy Downton, editor. Engineering the Human-Computer Interface. McGraw-Hill, 1991. ISBN 0{7-707321-5. [16] Susan Dray. The Importance of Designing Usable Systems. Interactions, 2(1):17{20, January 1995. [17] Clarence Ellis, Simon Gibbs, and Gail Rein. Groupware: Some Issues and Experiences. Communications of the ACM, 34(1):38{58, January 1991. [18] Mark A. Flecchia and R. Daniel Bergeron. Specifying Complex Dialogs in ALGAE. In Proceedings of the ACM CHI+GI'87, pages 229{234, April 1987. [19] James D. Foley, Andries van Dam, Steven K. Feiner, and John F. Hughes. Computer Graphics: Principles and Practice. Addison-Wesley Publishing Company, Inc., second edition, 1990. [20] ACM/IEEE-SC Joint Curriculum Task Force. Computing Curricula 1991, 1991. ISBN 0-8979-381-7. [21] Jason Gait. Pretty Pane Tiling of Pretty Windows. IEEE Software, pages 9{14, September 1986. [22] David Garlan. Research Directions in Software Architecture. ACM Computing Surveys, 27(2):257{261, June 1995. [23] Mark Green. Report on Dialogue Speci cation Tools. In Gunther E. Pfa, editor, User Interface Management Systems, pages 9{20. Springer-Verlag, 1985. [24] Mark Green. A Survey of Three Dialogue Models. ACM Transactions on Graphics, 5(3):244{275, July 1986. [25] Jonathan Grudin. Integratin Human Factors and Software Development. In Human Factors in Computing Systems, Proceedings SIGCHI'88, pages 157{159, Washington, D.C., May 1988. [26] Frits Habermann. Giving Real Meaning to easy-to-use' Interfaces. IEEE Software, pages 90{91, July 1991.

BIBLIOGRAFIA

55

[27] Andrew Harbert, William Lively, and Sallie Sheppard. A Graphical Speci cation System for User-Interface Design. IEEE Software, 7(4):12{20, July 1990. [28] D. Harel. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8(3):231{274, June 1987. [29] H. Rex Hartson and Deborah Hix. Toward Empirically Derived Methodologies and Tools for Human-Computer Interface Development. Int. J. Man-Machine Studies, pages 477{494, 1989. [30] H. Rex Hartson, Antonio C. Siochi, and Deborah Hix. The UAN: A User-Oriented Representation for Direct Manipulation Interface Designs. ACM Transactions on Information Systems, 8(3):181{203, July 1990. [31] H.R. Hartson and D. Hix. Human-Computer Interface Development: Concepts and Systems for its Management. ACM Computing Surveys, 21(1):5{92, March 1989. [32] Rex Hartson. User-Interface Management Control and Communication. IEEE Software, pages 62{70, January 1989. [33] Ralph D. Hill. Event-Response Systems | A Technique for Specifying Multi-Thread Dialogues. In Proceedings of the ACM CHI+GI'87, pages 241{248, April 1987. [34] Deborah Hix and H. Rex Hartson. Developing User Interfaces: Ensuring Usability Through Product & Process. John Wiles & Sons, Inc., 1993. ISBN 0471-57813-4. [35] Deborah Hix and Robert S. Schulman. Human-Computer Interface Development Tools: A Methodology for their Evaluation. Communications of the ACM, 34(3):74{ 87, March 1991. [36] Don Hopkins. The Design and Implementation of Pie Menus. Dr. Dobb's Journal, pages 16{26, December 1991. [37] W. D. Hurley and J. L. Sibert. Modeling User Interface-Application Interactions. IEEE Software, pages 71{77, January 1989. [38] Daniel Ichbiah and Susan Knepper. MICROSOFT. Editora Campus, Rio de Janeiro, 1992. Traduc~ao do original: The Making of Microsoft. [39] Robert J. K. Jacob. Using Formal Speci cations in the Design of a Human-Computer Interface. Communications of the ACM, 26(4):259{264, April 1983. [40] Setrag Khosha an and Razmik Abnous. Object Orientation: Concepts, Languages, Databases, User Interfaces, chapter User Interfaces, pages 323{387. John Wiley & Sons, Inc., 1990. [41] Barbar Kitchenham and Shari Lawrence P uger. Software Quality: The elusive target. IEEE Software, 13(1):12{21, January 1996.

56

BIBLIOGRAFIA

[42] Brenda Laurel, editor. The Art of Human-Computer Interface Design. AddisonWesley Publishing Company, Inc., 1990. ISBN 0-201-51797-3. [43] Geo Lee. Object-Oriented GUI Application Development. Prentice-Hall, 1993. [44] Jonathan Levy. Measuring Usability: Preference vs. Performance. Communications of the ACM, 37(4):66{75, April 1994. [45] Clayton Lewis and John Rieman. Task-Centered User Interface Design: A Practical Introduction. Shareware, 1994. FTP an^onimo: ftp.cs.colorado.edu, /pub/CS/distribs/clewis/HCI-Design-Book. [46] K. Y. Lim, J. B. Long, and N. Silcock. Integrating Human Factors with the Jackson System Development. Ergonomics, 35(10):1135{1161, 1992. [47] Fabio N. Lucena. Construca~o de Interfaces Homem-Computador: O Uso de Estadogramas na Especi cac~ao e Implementaca~o de Interfaces. Master's thesis, dcc/imecc/unicamp, Campinas/SP, 1993. [48] Fabio N. Lucena and Hans K. E. Liesenberg. Construca~o de Interfaces HomemComputador: Uma Proposta de Disciplina de Graduaca~o. Workshop de Educac~ao em Informatica (XV SBC, pages 191{200, Agosto 1995. [49] Fabio N. Lucena and Hans K.E. Liesenberg. Re ections on Using Statecharts to Capture User Interface Behaviour. Proceedings of XIV Int. Conf. of the Chilean CSS, October 1994. [50] Arnold M. Lund. Another Approach to Justifying the Cost of Usability. Interactions, 4(3), 1997. [51] M. M. Mantei and T. J. Teory. Cost/Bene t Analysis for Incorporating Human Factors in the Software Lifecycle. Communications of the ACM, 31:428{439, 1988. [52] Deborah J. Mayhew. Principles and Guidelines in Software User Interface Design. Prentice-Hall, 1992. ISBN 0-13-721929-6. [53] Susan E. McDaniel, Gary M. Olson, and Judith S. Olson. Methods in Search of Methodology { Combining HCI and Object Orientation. In Human Factors in Computing Systems CHI'94 Conference Proceedings, pages 145{151, 1994. [54] G. A. Miller. The Magical Number 7, plus or minus 2: Some Limits of our Capacity for Processing Information. Psychological Review, 1956. Number 63. [55] Rolf Molich and Jakob Nielsen. Improving a Human-Computer Dialogue. Communications of the ACM, 33(3):338{348, March 1990. [56] Brad A. Myers. A Taxonomy of Window Manager User Interfaces. IEEE Computer Graphics & Applications, pages 65{84, September 1988.

BIBLIOGRAFIA

57

[57] Brad A. Myers. Encapsulating Interactive Behaviors. In Human Factors in Computing Systems, Proceedings SIGCHI'89, pages 319{324, Austin,TX, April 1989. [58] Brad A. Myers. Demonstrational Interfaces: A Step Beyond Direct Manipulation. IEEE Computer, pages 61{73, August 1992. [59] Brad A. Myers, editor. Languages for Developing User Interfaces. J&B, 1992. [60] Brad A. Myers. Challenges of HCI Design and Implementation. Interactions, 1(1):73{ 83, 1994. [61] Brad A. Myers. User Interface Software Tools. Transactions on Computer-Human Interaction, 2(1):64{103, March 1995. [62] Brad A. Myers, Jim Hollan, and Isabel Cruz et al. Strategic directions in HumanComputer Interaction. ACM Computing Surveys, 28(4):794{809, 1996. [63] Brad A. Myers and Mary Beth Rosson. Survey on User Interface Programming. In CHI'92 Proceedings, pages 195{202, Monterey, California, May 1992. [64] William M. Newman. A System for Interactive Graphical Programming. Proceedings of the Spring Joint Computer Conference, pages 47{54, 1968. [65] J. Nielsen. Iterative User-Interface Design. Computer, 26(11):32{41, Nov 1993. [66] Roderick Perkins, Dan Smith Keller, and Frank Ludolph. Inventing the Lisa User Interface, February 1997. [67] Gary Perlman. User Interface Development. Technical Report SEI-CM-17-1.1, Software Engineering Institute, Carnegie Mellon University, 1989. [68] Steven E. Poltrock and Jonathan Grudin. Organizational Obstacles to Interface Design and Development: Two Participant Observer Studies. Transactions on Computer-Human Interaction, 1(1):52{80, March 1994. [69] Jenny Preece, Yvonne Rogers, Helen Sharp, David Benyon, Simon Holland, and Tom Carey. Human-Computer Interaction. Addison-Wesley, 1994. [70] Roger S. Pressman. Software Engineering: A Practitioner's Approach. McGram-Hill, European edition, 1994. [71] Jef Raskin. Wanted for Crimes Against the Interface: Thoughts of an HCI Poster. Interactions, 3(6):70{76, November 1996. [72] Marc Rettig. Interface Design When you don't Know How. Communications of the ACM, 35(1):29{34, January 1992. [73] Marc Rettig. Prototyping for Tiny Fingers. Communications of the ACM, 37(4):21{ 27, April 1994.

58

BIBLIOGRAFIA

[74] W. robert Collins, Keith W. Miller, Bethany J. spielman, and Phillip Wherry. How Good is Good Enough? Communications of the ACM, 37(1):81{89, January 1994. [75] Mattew D. Russell, Howard Xu, and Lingtao Wang. Action Assignable Graphics A Flexible Human-Computer Interface Design Process. In Human Factors in Computing Systems CHI'92 Conference Proceedings, pages 71{72, Monterey, California, May 1992. [76] Robert W. Schei er and Jim Gettys. The X Window System. ACM Transactions on Graphics, 5(2):79{109, April 1986. [77] Ben Shneiderman. Direct Manipulation: A Step Beyond Programming Languages. IEEE Computer, 16(8):57{69, August 1983. [78] Ben Shneiderman. Designing the User Interface: Strategies for Eective HumanComputer Interaction. Addison-Wesley Publishing Company, Inc., 1987. [79] ACM SIGCHI. Curricula for Human-Computer Interaction, 1992. ISBN 0-89791474-0. [80] H. W. Six and J. Voss. User Interface Development: Problems and Experiences. Lecture Notes in Computer Science, 555:306{319, June 1991. [81] Sidney L. Smith and Jane N. Mosier. Guidelines for Designing User Interface Software. Technical Report ESD-TR-86-278, US Air Force, 1986. Anonymous ftp: archive.cis.ohio-state.edu, pub/hci/Guidelines. [82] R. Summersgill and D. P. Browne. Human Factors: Its Place in System Development Methods. ACM SIGSOFT Engineering Notes, 14(3):227{234, May 1989. [83] P. P. Tanner and W. A. S. Buxton. Some Issues in Future User Interface Management System (UIMS). In Gunther E. Pfa, editor, User Interface Management Systems, pages 67{79. Springer-Verlag, 1985. [84] Harold Thimbleby. User Interface Design. ACM Press, 1990. ISBN 0-201-41618-2. [85] Siegfried Treu. User Interface Design: A Structured Approach. Plenum Press, 1994. [86] Siegfried Treu. User Interface Evaluation: A Structured Approach. Plenum Press, 1994. [87] Anthony I. Wasserman, Peter A. Pircher, David T. Shewmake, and Martin L. Kersten. Developing Interactive Information Systems with the User Software Engineering Methodology. IEEE Software, SE-12(2):326{345, February 1986. [88] James Wilson and Daniel Rosenberg. Rapid Prototyping for User Interface Design. In M. Helander, editor, Handbook of Human-Computer Interaction, chapter 39, pages 859{875. Elsevier Science Publishers B.V., 1988.

BIBLIOGRAFIA

59

[89] Michael Wilson and Anthony Conway. Enhanced Interaction Styles for User Interfaces. IEEE Computer Graphics & Applications, 11(2):79{90, March 1991.

Indice A

analise de tarefas, 28 aplicac~ao, 3 apresentac~ao, 42 arquitetura de software, 41 atrativo, 4 avaliac~ao, 47 avaliacao, 47{49

C

caixas, 30 callback, 40 cascata ciclo de vida, 15 cenarios, 48 ciclo de vida, 16 Ci^encia da Computac~ao, 26 conclus~oes, 51 consist^encia, 25 construtor de interface, 40 controle de dialogo, 42

D

demonstrational, 29 desenvolvimento, 11{21 dialogo, 3 di culdades de desenvolvimento, 6 dispositivos de E/S, 29

E

engenharia de software, 14 ergonomia, 26 especi cac~oes de dialogo, 43 espiral ciclo de vida, 15 estilo de interaca~o, 30

estilos de interaca~o, 29 exerccios, 10, 21, 33, 45, 48

F

facil de usar e aprender, 4 feedback, 25 ferramentas toolkits, 39

ex, 27

uxo de controle, 36 funcionalidade, veja aplicaca~o

G

groupware, 27 guidelines, veja diretrizes

H

hipermdia, 2

I

cone, 30 implementaca~o, 35{45 di culdades, 35 independ^encia de dialogo, 3, 44 interaca~o estilos, 29 Interaca~o Homem-Computador, 1 interaca~o, 2 interface conceito, 2 construtor de, 40 de nica~o, 3 desenvolvimento, 11 estilos, 29 fontes de informaca~o, 7 import^ancia, 5 software de, 35

INDICE

61

interface builder, 40 interface homem-computador, 2 Introduc~ao, 1{10

projeto de interac~ao, 23{33 prototipos, 31 psicologia, 26

lex, 27 linguagem de comandos, 29 linguagem natural, 29 lingustica, 27 look and feel, 24

raz~ao aurea, 26 reac~ao por infer^encia, 29 recordac~ao rapida, 4 recuperac~ao de erros, 25 regras, 28

L

M

manipulac~ao direta, 29 manual do usuario, 48 menus, 30 metaforas, 26 modelo de Seeheim, 42 modelo formal, 16 modelos de dialogo, 43 multidisciplinar, veja projeto multimdia, 2, 51

N

numero magico 7 + = ; 2, 26

O

objeto de interac~ao, 39

P

padr~oes, 28 portabilidade, 37 preenchimento de formularios, 30 princpios, 28 consist^encia, 25 feedback, 25 habilidades distintas, 25 metaforas, 26 minimizar erro, 25 minimizar memoria, 26 recuperar erro, 25 processo de projeto, 11 projeto de nic~ao de, 24 multidisciplinar, 26 produto de, 32

R

S

SDI, 41 Seeheim modelo de, 42 SGI, 40 sistema de janela, 38 sociologia, 27 software arquitetura, 41 organizaca~o, 38 software de interfaces, 35 desa os, 36 Star, 38 statecharts, 43

T

tamanho da interface, 6 task-centered design, 26 taxa de erro mnima, 4 tempo de aprendizado, 26 tipogra a, 27 toolkits, 39

U

UIDS, 41 UIMS, veja SGI UNIX, 27 usabilidade, 2 user-friendly, 4 usuario, 2

W

Waterfal, veja cascata

62 widget, 39 WIMP, 2 Windows, 38 Windows NT, 38 WYSIWYG, 29

INDICE