Faculdade de Tecnologia de Sorocaba

Tecnologia em Análise e Desenvolvimento de Sistemas

INTERAÇÃO HUMANO-COMPUTADOR: O COMPUTADOR –

SOFTWARE – Parte 2
ATIVIDADE 6

Prof.º Sergio Moraes

Disciplina: Interação Humano-Computador

Tainara Covas 0030482021043

Pedro Montanini 0030482021028
Eduardo Vidal 0030482021004

Sorocaba
Outubro/2021
 Sumário

Introdução .................................................................................................................. 3
Excesso de funcionalidade ...................................................................................... 5
Caminhos múltiplos .................................................................................................. 7
Projeto para revelação progressiva e evoulção gradual ....................................... 8
Indepêndencia de diálogo ........................................................................................ 8
Manipulação direta .................................................................................................... 9
Conclusão ................................................................................................................ 11

2
Introdução

Os projetos de software tem se tornado cada vez mais complexos, o que leva
os projetistas a levar em consideração vários fatores ao desenvolver interfaces.
Este trabalho descreve como funcionam algumas técnicas de interação entre o
usuário e o software, utilizando analogias com as ferramentas utilizadas e
características do mundo real. Serão descritos alguns conceitos importantes que
devem ser considerados nos projetos de software, como projetos para iniciantes,
especialistas e intermitentes, excesso de funcionalidade, caminhos múltiplos, projeto
para revelação progressiva e evolução gradual, independência de diálogo e
manipulação direta.
O conhecimento desses conceitos, como de muitos outros na área da interação
humano-computador é importante para se projetar bons softwares.

3
Projetos para iniciantes, especialistas e intermitentes

A maioria dos sistemas deve ser projetada para incorporar as necessidades

dos usuários iniciantes, intermitentes e especialistas. Para os principiantes pode ser
necessária a apresentação de muitas mensagens, pelo sistema, e de muita consulta
a menus. Os usuários intermitentes têm menor necessidade das mensagens, porém,
necessitam de consultas ocasionais aos menus, por se esquecerem das funções e
detalhes usados anteriormente.
Usuários iniciantes podem encontrar dificuldades para filtrar a informação de
que necessitam em uma tela carregada. Para eles, a carga de memorização deve ser
minimizada. Shneiderman (1992) fala do critério de densidade informacional, que diz
respeito à carga de trabalho do usuário, de um ponto de vista perceptivo e cognitivo,
com relação ao conjunto total de itens de informação apresentados, e não a cada
elemento ou item individual.
Na maioria das tarefas, o desempenho dos usuários é reduzido quando a
densidade da informação é muito alta ou muito baixa. Nestes casos, a ocorrência de
erros é mais provável. Uma interface minimalista deve, portanto:
• Apresentar somente os itens que estão relacionados à tarefa (o restante
deve ser removido da tela);
• Não forçar os usuários a transportar mentalmente dados de uma tela à outra;
• Evitar realizar procedimentos complicados, como a transformação de
unidades de medida;
• Não colocar os usuários diante de tarefas cognitivas complexas, como as de
especificação de buscas.
Já os especialistas não necessitam perder tempo com mensagens ou menus,
devendo, portanto, lhes ser permitido reduzir caminhos através das mensagens e
menus e definir sequências complexas de ações como um comando de alto nível ou
um macro. É comum notar usuários especialistas que se utilizam de sistemas com
interfaces do tipo CUI (character-based user interface) como a do DOS (Disk
Operating System), reclamarem do uso de interfaces tipo GUI (graphical user
interface) como a do Windows, por falta de atalhos.

4
Excesso de funcionalidade

Simplicidade e facilidade de uso estão intimamente ligadas. Um projeto simples

e elegante é de compreensão mais fácil para o usuário. Uma preocupação constante
do projetista, portanto, deve ser a simplificação de seu projeto. Desta forma, um
projeto de interface deve contemplar apenas o estritamente requerido. Tudo além do
absolutamente essencial torna o projeto desnecessariamente mais complexo e mais
difícil de ser usado.
O excesso de funcionalidade é a tônica de muitos pacotes de software. Muitas
dessas funcionalidades não são acessíveis ao usuário porque o software não é
transparente (muitas facilidades estão ocultas e, por tal razão, ignoradas pela maioria
dos usuários), é complexo (usuários se desorientam e não sabem direito como atingir
os seus objetivos) e é desajeitado para usar (o desempenho dos usuários é
prejudicado por procedimentos ineficientes, o que os deixa muito insatisfeitos). A
operação de um software assim é ineficiente e requer um esforço duplo por parte dos
usuários: executar as suas tarefas usuais e concentrar-se na operação do software.
Não devem ser incluídos comandos ou opções para cada função concebível do
sistema, pois tal excesso de comandos e funções pode inibir o usuário do sistema.
Deve-se determinar a frequência e a criticidade de uso das funções candidatas para
que se estabeleçam prioridades, assim, as funções de baixa prioridade devem ser
eliminadas ou tornadas disponíveis através de caminhos secundários e apenas se
houver dúvidas no caminho primário.
De acordo com Baranauskas (2003), a simplificação de projetos de interface de
usuário deve ser relacionada a três aspectos básicos:

• Simplicidade:
Simplicidade é a qualidade do que é singelo, natural e elegante. Conseguir tal
qualidade não é uma tarefa trivial. O objetivo do projetista é criar interfaces que devem
ser praticamente “invisíveis”, isto é, não devem colocar entraves entre o usuário e as
tarefas por ele executadas. Além de experiências e habilidades, as pessoas também
têm limitações que devem ser respeitadas para não sobrecarregá-las e deixá-las
insatisfeitas. A simplicidade também está relacionada com eficácia. Simplicidade não
é um objetivo por si só. Tornar aplicações simples demais as deixa sem utilidade para
o usuário. Um balanceamento adequado entre a simplicidade e o foco do projeto
5
precisa ser achado. Conceber projetos muito complexos, por outro lado, os torna não
usáveis por muitos. Assim, achar um ponto de equilíbrio entre o que for sem função e
o não usável é uma atribuição do projetista.

• Transparência
Transparência é qualidade do que é evidente e claro. Usuários devem sempre
estar a par e entender o que ocorre na aplicação em relação às suas tarefas e os
passos requeridos para executá-las. Assim, entre outras coisas, usuários devem
sempre saber o estado em que se encontra a tarefa em execução, qual o próximo
passo a tomar, quais as conseqüências de determinadas ações e como a aplicação
reage a determinas entradas.
A qualidade de ser transparente tem a haver com a estrutura global da
aplicação, o esquema de navegação e com procedimentos e funcionalidades que dão
sustentação a procedimentos. A transparência ajuda os usuários a se manterem
orientados, a manter o foco em suas tarefas e a reduzir a sua carga cognitiva.

• Efetividade e eficácia
Efetividade é a qualidade do que produz resultados reais e positivos e que
merece confiança. Eficácia (ou eficiência) é a qualidade de algo que produz o efeito
desejado e dá um bom resultado. Em termos de projeto, efetividade significa que os
usuários atingirão os seus objetivos com o auxílio da aplicação em construção e
eficácia que o desempenho dos usuários seja rápido e livre de erros. Como os
usuários variam em termos de experiência e de habilidades, isto significa que, para
um particular público alvo, mais de um projeto de interface de usuário possa fazer-se
necessário. Software ineficiente também implica em custos mais elevados: usuários
levam mais tempo para realizar as suas tarefas e ficam mais insatisfeitos por sentirem
o software não como um auxílio, mas como um obstáculo para a realização de suas
tarefas. Um software ineficiente gera situações conflitantes.

6
Caminhos múltiplos

Caminhos múltiplos é a resposta para o problema de excesso de

funcionalidade, que seria o excesso de comandos e funções que determinam cada
funcionalidade do sistema. Então, utiliza-se os caminhos secundários para driblar este
carregamento de opções na tela do software.
De acordo com Oscar Carvalho (1994), a técnica de múltiplos caminhos inclui:

• Desvios do menu que permitem, ao usuário, solicitar a opção, a tela ou a

transação desejada através (e diretamente) de um comando, de um código
ou de outro identificador;
• Técnicas de pilha ou de digitação seguida que permitem ao usuário
introduzir, em uma simples entrada, os dados que necessitariam de uma
série de menus e transações, como no exemplo de sequências de comandos
separados por delimitadores como ponto e vírgula;
• Macros, definidas pelo próprio usuário, que acionam sequências de
comandos individuais;
• Opções de dispositivos de entrada que permitem o disparo de uma função
através de mais de um dispositivo de entrada diferente, como é o caso da
seleção de opções, em um menu, por intermédio de dispositivos
apontadores, teclas de controle do cursor no teclado, digitação do número
do item ou da letra de referência do menu, monitor sensível a toques ou
dispositivo de reconhecimento de voz.

Tais itens dependem totalmente do hardware em questão e da forma que está

sendo usado. Cada software trabalha com a ideia de caminhos múltiplos não só no
design, mas sim por de trás de seu funcionamento. O gerenciamento de memórias de
múltiplas escolhas, ou seja, da maneira que o SO gerencia o desempenho do sistema;
e também das múltiplas escolhas que o programa faz quando determinada ação é
atendida. Esses fatores correspondem à interface, pois eles refletem todo o conforto
e usabilidade que o usuário está vivendo.

7
Projeto para revelação progressiva e evoulção gradual

O projeto para revelação progressiva e evolução gradual é um conceito pós

treinamento e adaptação do usuário sabendo no mínimo utilizar os recurso sem de
ajuda de terceiros. Este projeto é um dos recursos que vem ganhando mais força entre
os jovens, pois ele depende totalmente da exploração dos recursos do sistema, para
que então encontre novas funções e usabilidades especiais e externas. “[...]conforme
ele vai ganhando confiança e vai explorando, cada vez mais, o sistema, ele vai
encontrado mais recursos para conseguir mais eficiência do mesmo.” (Carvalho,
1994).
Ao usuário descobrir as novas interfaces possíveis com o software, as funções
mais utilizadas devem ser de fácil execução, a experimentação deve ser encorajada,
as consequências dos erros devem ser minimizadas através de ações reversíveis e,
finalmente, o número de seleções requeridas pelo usuário, para produzir as saídas
mais desejadas ou comuns, devem ser minimizadas fazendo com que o sistema
assuma automaticamente tais seleções (Carvalho, 1994).
Enfim, a autoconfiança ganha vida na interface e faz com que a interação
humano-computador seja cada vez bem mais sucedida no sentido de utilização e
bem-estar do software. Ou seja, o usuário consegue, em constante evolução, a
agilidade de requerer funções específicas desejadas, utilizar as teclas de atalho e
interpretar as metáforas e mensagens de possíveis erros que serão eliminados.

Indepêndencia de diálogo

Tradicionalmente a Engenharia de Software tem se ocupado do

desenvolvimento do componente funcional do sistema, também conhecido como
aplicação, enquanto que é do domínio de IHC, o componente que interage com o
usuário, também conhecido como Interface com o Usuário (IU). Esta separação de
componentes, no ponto de vista da arquitetura de sistemas interativos, é denominada
independência de diálogo e possibilita dois benefícios essenciais:

8
 1. A aplicação e a IU podem ser modificados e evoluir separadamente.
2. A interface com o usuário (IU) pode ser projetada por um especialista da
área, o projetista de interfaces, que pode usar conhecimentos de design visual,
psicologia cognitiva, ergonomia, semiótica, etc.
O conceito de independência do diálogo, no entanto, tem sido entendido e
praticado como sinônimo de isolamento de diálogo, uma postura na qual o
desenvolvimento do sistema interativo é feito através do desenvolvimento dos dois
componentes em separado: tipicamente, primeiro a aplicação, depois a IU.
Por outro lado, os projetistas de interface compartilham de uma perspectiva
externa dos sistemas, se concentrando em geral, nos aspectos de interação e não
considerando adequadamente os aspectos funcionais e arquiteturais enfatizados pela
Engenharia de Software. Um sistema interativo deve ser intuitivo e fácil de usar, mas,
como qualquer sistema, também deve ser robusto e fácil de manter, assim como seu
desenvolvimento deve respeitar as restrições de orçamento e cronograma. Um
sistema que não respeita estes aspectos não possui qualidade, nem sob o ponto de
vista da IHC, nem no senso corrente da Engenharia de Software.

Manipulação direta

Manipulação direta é aquela na qual o usuário pode agir diretamente sobre

representações de elementos (objetos) da aplicação, ou seja, oferece certa analogia
entre o cursor do mouse (e a própria mão, caso se pense nas interfaces sensíveis ao
toque presentes em alguns dispositivos móveis), como também entre as
representações gráficas contidas na aplicação. O conceito de manipulação direta foi
proposto por Ben Shneiderman em 1992.
Imagine-se dirigindo um carro em que, em vez de direção, pedais e câmbio tem
apenas um teclado... E R20:E:A35 seria usado para “reduza para 20km/h, vire para a
esquerda, acelere até 35 km/h” Shneiderman (1992) foi quem usou o termo pela
primeira vez para se referir a uma classe emergente de sistemas bastante atraentes
na década de oitenta, como as primeiras planilhas eletrônicas, editores de texto,
sistemas CAD, videogames, etc. Esses sistemas possuíam interfaces gráficas que
permitiam operá-los “diretamente” usando ações manuais em vez de instruções
fornecidas via teclado. Tais sistemas mudaram o paradigma da interação humano-

9
computador, do “diálogo” baseado em linguagem de comando para a “manipulação”
baseada na linguagem visual.
Em vez de um meio computacional abstrato, toda programação é feita
graficamente, em uma forma que tenta casar com a maneira como pensamos no
problema (Hutchins et al., 1986).
Do mundo que se “comanda” passou-se para o mundo com o qual se “interage”.
O primeiro marco em interface de manipulação direta é o Sketchpad, um programa
para design gráfico criado por Sutherland em 1963. Seu trabalho é um marco não
apenas pela prioridade histórica, mas por antecipar a concepção da saída na tela
como “folha de papel”, o uso de dispositivos de apontamento e a importância de
mostrar abstrações graficamente.
Nas interfaces de manipulação direta não há operações escondidas, sintaxe ou
nomes de comandos para aprender. O único conhecimento requerido é no próprio
domínio da tarefa. Excelentes exemplos de tais interfaces na época eram os editores
WYSWYG (what you see is what you get). A diretividade em interfaces, entretanto,
apresenta-se em vários níveis dentro de um continuum. Tomemos como exemplo um
editor gráfico numa tarefa de criar ilustrações; a operação de mover um círculo mostra
os graus de indireção que podem estar presentes na interface:
A) o usuário aponta na tela o círculo e o move levando-o para a posição
desejada com o dedo.
B) a introdução do mouse coloca mais um grau de indireção, uma vez que para
mover o círculo é necessário mover o mouse.
C) com as setas de direção acrescenta-se mais um nível de indireção, uma vez
que não há equivalência de movimentos.
D) o uso de um comando para mover o círculo acrescenta mais um nível uma
vez que a sintaxe e a semântica determinam o que acontece. A “ilusão” da
manipulação direta foi sumarizada por Shneiderman (1983) em três princípios de
design:

1. Representação contínua do objeto de interesse;

2. Ações físicas (cliques, arraste, etc.) em vez de sintaxe complexa;
3. Operações incrementais reversíveis, cujo impacto no objeto de interesse é
imediatamente visível.

10
Conclusão

A interface, com toda a sua complexidade, é o item essencial para o

desenvolvimento e aplicação de um software. Os conceitos apresentados em
sequência aos do módulo anterior, continuam com a ideia da adaptação do usuário
ao computador.
Tais adaptações podem ser classificadas em projetos para iniciantes,
especialista e intermitentes. Que seriam os projetos de utilização do design do sistema
de acordo com o seu nível de experiência. Iniciantes têm dificuldades com sistemas
complexos cheios de botões e funções, não conseguindo filtrar as informações.
Especialistas já são mais exigentes, utilizam atalhos e quase nunca observam ou
relatam erros no sistema, ignorando mensagens e afins. Os intermitentes seriam os
intermediários entre eles, conseguindo utilizar atalhos e menos mensagens, porém
ainda com consulta dos menus e afins.
O excesso de funcionalidade, como já descrito, interfere ao usuário iniciante,
portanto, um software deve ter, de acordo com Baranauskas(2003), simplicidade
(naturalidade), transparência (claro) e efetividade e eficácia (resultados claros de
confiança).
Para driblar tais excessos, é utilizado a estratégia de múltiplos caminhos, que
é a técnica de simplicidade da maneira que as funções são mostradas e interagidas
com o usuário. E, como já tratamos, o usuário ganha confiança e experiência para
desfrutar das funcionalidades presentes no software (isso, de acordo com projetos
para revelação progressiva e evolução gradual).
Tal confiança e experiência podem ter ganho rápido em softwares que utilizam
a manipulação direta com o usuário, ou seja, dispositivos touchs que mostram
nitidamente o que está ocorrendo em tempo real para o usuário (como arrastar algum
componente). E, tais tecnologias de ergonomia e afins, são tão fortes que o
desenvolvimento desses softwares não necessita do diálogo com o usuário.

11
Referências bibliográficas

CARVALHO, J O. F.; Referenciais para projetistas e usuários de interfaces

de computadores destinadas aos deficientes visuais. Dissertação (Mestrado em
Engenharia Elétrica) - Unicamp Faculdade de Eng. Elétrica. Campinas 1994.

HUTCHINS, E.L., Hollan, J.D., Norman, D.A. (1986) Direct Manipulation

Interfaces. Em User Centered System Design: New Perspectives on Human-
Computer Interaction, D.A. Norman, e S.W. Draper, (eds.) (1986) Hillsdale, NJ:
Lawrence Erlbaum Associate Publishers.

SHNEIDERMAN B. Designing the User Interface: Strategies for

Effective Human-Computer Interaction. Addison Wesley. March 2004 6 72pp .
Edition Number: 4, 2005.

ROCHA, H.V.; BARANAUSKAS, M.C.C. Design e Avaliação de

Interfaces Humano- Computador. Campinas: NIED/UNICAMP, 2003. Disponível
em: https://www.nied.unicamp.br/biblioteca/design-e-avaliacao-de-interfaces-
humano-computador/

12