Fundamentos de

Interfaces Homem-Computador

Fabio Nogueira de Lucena

Universidade Federal de Goias (UFG)

Hans K.E. Liesenberg

Universidade Estadual de Campinas (UNICAMP)

Copyright
c 1998
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 desen-
volver 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 sis-
tema, 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 fa-
cilitam a leitura do presente texto. Prossionais envolvidos com o desenvolvimento de
sistemas interativos, estudantes do terceiro ano (ou superior) de graduaca~o em Compu-
tac~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 Homem-
Computador" apresentada em [47].
No nal de cada captulo e apresentado uma lista de exerccios. Os exerccios preten-
dem 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 apre-
sentados.
Sugest~oes s~ao bem vindas! Os autores podem ser contactados via e-mail, nos enderecos
fabio@dcc.unicamp.br e hans@dcc.unicamp.br, 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 subsequen-
tes. 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 ambien-
tes 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, meto-
dologias, 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 conheci-
mento 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 infor-
mac~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. Mui-
ta confus~ao existe entre interface e interac~ao (Homem-Computador). Interac~ao diz res-
peito 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.
Captulo 1. Introduca~o 3

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 tradu-

zir 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 apli-
cac~ao como pela apresentac~ao adequada dos resultados produzidos.

A Figura 1.2-2 mostra um modelo simplicado de um sistema interativo. O compo-

nente 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 com-
ponentes 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 co-
mum 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 hard-
ware 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 trans-
formac~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-to-
learn: (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 fa-
cilitam 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 siste-
mas 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 desenvolvi-
mento 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. Re-
cursos 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 desen-
volvimento (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 con-
trario, 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 de-
senvolvimento de interfaces. Segundo Curtis, uma vez atingida certa uniformidade na
conabilidade de produtos de software, a qualidade de suas interfaces e o proximo que-
sito 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 anteriormen-
te, 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) International Journal of Human-Computer Interaction.

(f) Interacting with Computers.
(g) Behaviour and Information Technology.
(h) International Journal of Man-Machine Studies.
(i) ACM Transactions on Graphics.
2. Confer^encias especcas ou que contemplam trabalhos desta area:
(a) ACM User Interface Software Technology.
(b) ACM SIGCHI { Human Factors in Computing Systems.
(c) Human Factors Society (encontro anual).
(d) Computer Supported Cooperative Work.
(e) IFIP INTERACT.
(f) International Conference on Human-Computer Interaction
(g) ACM SIGGRAPH
(h) British Computer Society HCI: Human-Computer Interaction.
(i) Eletr^onicas:
i. netnews: comp.human-factors
ii. netnews: comp.cog-eng
iii. internet: students.chi@xerox.com (Administrac~ao: registrar.chi@xerox.com).
Detalhes em http://www.acm.org:82/~fuller/students.chi.html
3. Bases de dados de refer^encias:
(a) HCI Bibliography Project (Gary Perlman, perlman@cis.ohio-state.edu)
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 desenvol-
ver 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 desen-
volvimento, 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 per-
tinentes 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, con-
forme 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 funcio-
nalidade 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, contem-
pla 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 di-
vis~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 Especificações Programas

Projeto Projeto do Implementação

do domínio software da do software
do problema Aplicação da Aplicação

R&P R&P R&P Erros

Teste do
Software
Falhas de projeto, erros, modificações. da
Análise Aplicação
de Especificações de usabilidade
dos requisitos de e
sistema projeto da
interface
Requisitos Especificações Programas Avaliação
do projeto de software
da
Projeto Projeto do Implementação Interface
da software da do software
Interação Interface da Interface

R&P R&P R&P Erros

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

Usabilidade Plano de teste, especificações de usabilidade.

Construção
Avaliação rápida de R&P = restrições e problemas
Protótipos

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 desenvolvi-
mento, 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 considerar-
mos 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 engenha-
ria 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 desenvol-
vimento 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 lingua-
gem 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 contem-
plarem adequadamente a aplicac~ao (funcionalidade). Existem poucas excec~oes, oriundas
do lado de IHC, que contemplam todo o processo de desenvolvimento de um sistema in-
terativo. 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 interati-
vo. 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 re-
sultados 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 meca-
nismos 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, computa-
dores 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 desenvol-
vimento 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 desenvolvi-
mento 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 qua-
lidade do software resultante. Tais modelos s~ao apropriados para o desenvolvimento da
aplicac~ao, n~ao da interface. Eles contemplam adequadamente quest~oes como desempe-
nho, 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, co-
nhecimentos 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 in-
tegrada. 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
Testes

Evolução 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 par-
ticular, 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 mo-
delo, 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 espi-
ral 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, Avaliação de alternativas,
alternativas, identificar e resolver riscos
restrições

Análise
de riscos

Análise
de riscos

Análise
de riscos

Análise Protótipo
de riscos Protótipo3 Operacional
Aceitação Protótipo2
Protótipo1
Revisão
Simulações, modelos, benchma
rks
Partição Plano de Conceitos de
Requisitos Operaçáo Especificação
P
de lan de requisitos Projeto
se o
nv de detalhado
ol Projeto de
P vi
in lan m en software
te o to
gr de Codificação
aç Validação de
ão requisitos
e
te
st Teste de
e Validação de projeto módulos
e verificação
Integracao
e testes

Teste de
aceitação
Implementação

Planejamento das Desenvolvimento, verificar

fases seguintes 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 tradicio-
nais 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
Padroes Reqs 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 usabili-
dade 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 desenvol-
vimentos 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. Pra-
ticamente 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 desen-
volvimento 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

Protótipo Requisitos

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 inte-
rativo 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

Manutenção e
Produção
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 inte-
gra 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
Captulo 2. Processo de Construca~o de Interfaces 19
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 soft-
ware, considerados tpicos e que contribuem signicativamente para os custos de desen-
volvimento. Nestes estagios, contudo, pouca ^enfase e dada ao componente software res-
ponsavel 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

Atividades típicas do desenvolvimento de interfaces

Estudo de viabilidade

Definição de requisitos
Ciclo de vida tradicional de software

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

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 Observação de

e do usuário 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
Definir objetos
de computação

Modelo do usuário Avaliação

Análise de tarefas 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 re-
lac~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 represen-
tativos?
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 mu-
nido 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 in-

terface. A execuc~ao deste projeto requer conhecimentos nas areas de psicolo-
gia, 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 es-
peci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 julga-
do 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 espe-
rada. 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
Captulo 3. Projeto de Interaca~o 25
Especificacoes de usabilidade
dos requisitos de
projeto da Requisitos Especificacoes
interface do projeto de software Programas

Projeto Projeto do Implementacao

da software da do software
Interacao Interface da Interface

Restricoes Restricoes Restricoes Erros

e problemas e problemas e problemas

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 infor-

mac~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 en-
tanto, 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 co-
nhecimentos 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 con-
tribuic~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 for-
mal de dialogos. Lex (gerador de analisador lexico) e Yacc (gerador de analisador
sintatico) s~ao ferramentas do ambiente UNIX que podem ser utilizadas na imple-
mentac~ao de interfaces [63] e exemplicam a in u^encia desta disciplina no desen-
volvimento 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 exem-
plo, 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 reali-
zac~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 de-
senvolva 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 lingua-
gem 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, usual-
mente 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" gene-
ralizac~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, ime-
diatamente 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 ne-
cessario 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, esta-
mos 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 pro-
jeto 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, in-
terpretac~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 co-
mentadas 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 lin-
guagens 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. Ge-
ralmente 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, pretende-
se 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 captu-
rar 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 pa-
ra 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 usa-
das 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 en-
volvidos 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, conheci-
mentos, 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 desenvol-
vimento do software que realiza a interac~ao denida. Este captulo trata essencialmente
deste desenvolvimento: projeto e implementaca~o do software de interfaces. O desen-
volvimento 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 en-
genharia 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 in-

terfaces
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 con-
sequ^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ca-
do 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 con-
fecc~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 ne-
cessario 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 funcio-
nalidade 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.1-
1b), 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
Captulo 4. Construca~o do Software de Interfaces 37
sistema interativo. O controle externo e interno podem ser vistos como casos parti-
culares 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 INTERFACE

Chamada Callback

Retorno Retorno
Codigo Codigo Codigo Codigo

(a) (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. Ob-
ter 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 exe-
cuc~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. Al-

gumas 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, Open-
Look) 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 desenvol-

vimento 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 imple-
mentac~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 \estru-
turado" 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 pa-
ra 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 compu-
tador 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 mi-
lh~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 aborda-
dos 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 per-
mite 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 tare-
fas 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 progra-
mador 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 manipu-
lado 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 dis-
ponveis, 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 au-
tomatica 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 comer-
cialmente, 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 auto-
maticamente 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 ser-
vicos 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 conheci-
da 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 funcio-

nalidade 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, em-
bora 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 inte-
rac~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.
Controle Interface
Apresentacao de com a
Dialogo 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 de-
talhes 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 respec-
tivo 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 implemen-
tado 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 pro-
vido 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 arquite-
turas atualmente existentes.

4.7 Especicac~ao de dialogo

Linguagens de especicac~ao de dialogo podem ser classicadas segundo o modelo de con-
trole de dialogo empregado. Tr^es modelos s~ao comentados abaixo, juntamente com no-
tac~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], diagra-
mas 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 ro-
tuladas 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 ne-
cessaria 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 entra-
nhado 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 gru-
pos 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 in-
terface 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 \imedia-
ta" 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 com-
ponente 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 apa-
rentemente inofensivos em uma lngua podem ser obscenos em outra. Se voc^e estiver
familiarizado com diferentes culturas, voc^e e capaz de enumerar caractersticas des-
tas 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 de-
senvolvimento 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 ativida-
de. 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 mes-
mo 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 mode-
los 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 \vicia-
das" podem n~ao desvendar problemas graves enquanto que grandes variac~oes em
termos de experi^encias anteriores, por exemplo, podem produzir resultados incon-
clusivos. 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, acredita-
mos 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 reco-
mendac~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 tec-
nologicos em diversas areas relacionadas t^em sido as molas propulsoras na area de in-
terfaces. 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 em-
prego 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 Inter-
face 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 Experien-
ces. 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. Compu-
ter 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 Sur-
veys, 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 Com-
puter 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 Soft-
ware, 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. Addison-
Wesley 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 Homem-
Computador: 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 Com-
puting 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. Commu-
nications 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 Compu-

ting 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 Human-
Computer 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, Soft-
ware Engineering Institute, Carnegie Mellon University, 1989.
[68] Steven E. Poltrock and Jonathan Grudin. Organizational Obstacles to Interfa-
ce 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 Com-
puting 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 Human-
Computer Interaction. Addison-Wesley Publishing Company, Inc., 1987.
[79] ACM SIGCHI. Curricula for Human-Computer Interaction, 1992. ISBN 0-89791-
474-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 Soft-
ware. 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. Kers-
ten. 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 Interfa-
ces. IEEE Computer Graphics & Applications, 11(2):79{90, March 1991.
Indice
A estilos de interaca~o, 29
analise de tarefas, 28 exerccios, 10, 21, 33, 45, 48
aplicac~ao, 3
apresentac~ao, 42 F
arquitetura de software, 41 facil de usar e aprender, 4
atrativo, 4 feedback, 25
avaliac~ao, 47 ferramentas
avaliacao, 47{49 toolkits, 39
ex, 27
C uxo de controle, 36
caixas, 30 funcionalidade, veja aplicaca~o
callback, 40 G
cascata groupware, 27
ciclo de vida, 15 guidelines, veja diretrizes
cenarios, 48
ciclo de vida, 16 H
Ci^encia da Computac~ao, 26 hipermdia, 2
conclus~oes, 51
consist^encia, 25 I
construtor de interface, 40 cone, 30
controle de dialogo, 42 implementaca~o, 35{45
diculdades, 35
D independ^encia de dialogo, 3, 44
demonstrational, 29 interaca~o
desenvolvimento, 11{21 estilos, 29
dialogo, 3 Interaca~o Homem-Computador, 1
diculdades de desenvolvimento, 6 interaca~o, 2
dispositivos de E/S, 29 interface
conceito, 2
E construtor de, 40
engenharia de software, 14 denica~o, 3
ergonomia, 26 desenvolvimento, 11
especicac~oes de dialogo, 43 estilos, 29
espiral fontes de informaca~o, 7
ciclo de vida, 15 import^ancia, 5
estilo de interaca~o, 30 software de, 35
INDICE 61
interface builder, 40 projeto de interac~ao, 23{33
interface homem-computador, 2 prototipos, 31
Introduc~ao, 1{10 psicologia, 26
L R
lex, 27 raz~ao aurea, 26
linguagem de comandos, 29 reac~ao por infer^encia, 29
linguagem natural, 29 recordac~ao rapida, 4
lingustica, 27 recuperac~ao de erros, 25
look and feel, 24 regras, 28
M S
manipulac~ao direta, 29 SDI, 41
manual do usuario, 48 Seeheim
menus, 30 modelo de, 42
metaforas, 26 SGI, 40
modelo de Seeheim, 42 sistema de janela, 38
modelo formal, 16 sociologia, 27
modelos de dialogo, 43 software
multidisciplinar, veja projeto arquitetura, 41
multimdia, 2, 51 organizaca~o, 38
software de interfaces, 35
N desaos, 36
numero magico 7 + = ; 2, 26 Star, 38
O statecharts, 43
objeto de interac~ao, 39 T
P tamanho da interface, 6
task-centered
padr~oes, 28
portabilidade, 37 design, 26
preenchimento de formularios, 30 taxa de erro mnima, 4
princpios, 28 tempo de aprendizado, 26
consist^encia, 25 tipograa, 27
feedback, 25 toolkits, 39
habilidades distintas, 25
metaforas, 26
U
UIDS, 41
minimizar erro, 25 UIMS, veja SGI
minimizar memoria, 26 UNIX, 27
recuperar erro, 25 usabilidade, 2
processo de projeto, 11 user-friendly, 4
projeto usuario, 2
denic~ao de, 24
multidisciplinar, 26 W
produto de, 32 Waterfal, veja cascata
62 INDICE

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