A importancia de IHC no desenvolvimento de software
Usabilidade de aplicações
1. Manuel Menezes de Sequeira
DCTI, ISCTE-IUL
Manuel.Sequeira@iscte.pt, D6.02
As apresentações desta série baseiam-se nas apresentações disponibilizadas por Ian
Sommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e
finalmente por Manuel Menezes de Sequeira.
2. Na aula anterior
Desenho arquitectónico
Decisões no desenho arquitectónico
Organização de sistemas
Estilos de decomposição
Estilos de controlo
Arquitecturas de referência
2009/2010
Engenharia do Software I
2
4. Sumário
Desenho de interfaces com o utilizador
Problemas de desenho
Heurísticas de Nielsen para interfaces com
2009/2010
o utilizador
Estilos de interacção
Processo de desenho de interfaces com o
utilizador
Análise dos utilizadores
Prototipagem de interfaces com o utilizador
Avaliação de interfaces
Engenharia do Software I
4
5. Objectivos
Sugerir princípios gerais do desenho de
interfaces
Explicar
Diferentes estilos de interacção e sua utilização
Quando usar apresentações gráficas e textuais
de informação
Principais actividades do processo de desenho
de interfaces
Apresentar atributos de usabilidade e
abordagens à avaliação de sistemas
2009/2010
Engenharia do Software I
5
6. A interface com o utilizador
Deve ajustar-se a competências, experiência
e expectativas de prospectivos utilizadores
Utilizadores muitas vezes julgam sistema pela
interface e não pela funcionalidade
Interface mal desenhada pode induzir
utilizador a erros catastróficos
Mau desenho leva muitos sistemas não serem
usados
2009/2010
Engenharia do Software I
6
7. Factores humanos no desenho
de interfaces
Memória de curta duração
limitada
Humanos recordam instantaneamente
cerca de sete itens de informação. Mais
informação, mais probabilidade de erro.
Humanos erram
Quando humanos erram e sistemas
falham, alertas e mensagens
inapropriados aumentam stress e, por
isso, probabilidade de novos erros.
Humanos são diferentes
Humanos têm grande gama de
capacidades físicas. Designers não
devem desenhar para si mesmos.
Humanos têm diferentes
Alguns preferem imagens, outros
preferências de interacção preferem texto.
2009/2010
Engenharia do Software I
7
8. Princípios do desenho de
interfaces com o utilizador
Desenho considera
necessidades, experiência e capacidades
de utilizadores
Designers cientes de limitações físicas e
mentais de humanos (e.g., memória de
curta duração limitada) e reconhecem que
humanos erram
Princípios subjazem a desenho de
interfaces, nem todos os princípios
aplicáveis a todos os desenhos
2009/2010
Engenharia do Software I
8
9. Princípios do desenho de
interfaces com o utilizador
Familiaridade
Usar termos e conceitos recolhidos da experiência
das pessoas que mais usarão sistema.
Consistência
Sempre que possível, operações comparáveis
activadas da mesma forma.
Mínima surpresa
Utilizadores nunca são surpreendidos pelo
comportamento do sistema.
Recuperabilidade Incluir mecanismos para utilizadores recuperarem
de erros.
Orientação
Disponibilizar informação quando erros ocorrem e
mecanismos de ajuda sensíveis ao contexto.
Diversidade
Proporcionar mecanismos de interacção para
diferentes tipos de utilizadores do sistema.
2009/2010
Engenharia do Software I
9
10. Familiaridade
Termos e conceitos recolhidos da
experiência das pessoas que mais usarão
sistema
Termos e conceitos orientados para
utilizador e não computacionais
Por exemplo, sistema administrativo deve
usar cartas, documentos e pastas e não
ficheiros, identificadores ou directórios
2009/2010
Engenharia do Software I
10
11. Consistência
Sempre que possível, operações
comparáveis activadas da mesma forma
Exemplos
Comandos e menus com o mesmo formato
Pontuação de comandos semelhante
Utilização consistente de maiúsculas e
minúsculas
2009/2010
Engenharia do Software I
11
12. Mínima surpresa
Utilizadores nunca são surpreendidos
pelo comportamento do sistema
Se utilizador conhece efeito de um
comando, deve conseguir prever efeitos
de comandos comparáveis
2009/2010
Engenharia do Software I
12
13. Recuperabilidade
Incluir mecanismos para utilizadores
recuperarem de erros
Resiliência face a erros do utilizador
Anular ou desfazer comandos
Confirmação de acções destrutivas
Remoções com possibilidade de
recuperação
2009/2010
Engenharia do Software I
13
14. Orientação
Disponibilizar informação quando erros
ocorrem e mecanismos de ajuda
sensíveis ao contexto
Disponibilização de orientação
Sistemas de ajuda
Manuais em linha
2009/2010
Engenharia do Software I
14
15. Diversidade
Proporcionar mecanismos de interacção
para diferentes tipos de utilizadores do
sistema
Alguns utilizadores têm dificuldades de
visão: disponibilizar texto com maiores
caracteres
2009/2010
Engenharia do Software I
15
16. Heurísticas de Nielsen
Visibilidade do
estado do sistema
Manter utilizadores informados acerca do que
está a acontecer através da disponibilização
atempada de informação.
Correspondência
entre sistema e
mundo real
Falar a língua do utilizador, usando palavras,
frases e conceitos familiares e não termos
orientados para o sistema. Seguir convenções
do mundo real, fazendo informação surgir de
forma natural e por uma ordem lógica.
Controlo e
liberdade do
utilizador
Dar aos utilizadores uma “saída de emergência”
para abandonarem estado do sistema no qual
entraram por engano. Não forçar o utilizador a
diálogo extenso para sair desses estados.
Suportar mecanismos para desfazer e refazer.
Consistência e
padrões
Não forçar utilizadores a pensar se diferentes
palavras, situações ou acções têm o mesmo
significado. Seguir convenções.
2009/2010
Engenharia do Software I
16
17. Heurísticas de Nielsen
Prevenção de erros Mostrar boas mensagens de erro e sobretudo
desenhar de forma a evitar ocorrência de
problemas. Eliminar condições propensas a
erros ou verificá-las e dar possibilidade de
confirmar antes de realizar acções.
Reconhecer em vez Minimizar recurso a memória do utilizador
de recordar
tornando visíveis objectos, acções e opções.
Não obrigar utilizador a recordar dados de uma
parte para outra de diálogo. Tornar instruções de
utilização visíveis ou fáceis de obter.
Flexibilidade e
eficiência de
utilização
2009/2010
Criar atalhos – invisíveis para utilizador iniciado
– que acelerem interacção de utilizador
experiente. Adequar sistema simultaneamente a
utilizadores iniciados e experientes. Permitir
configuração de acções frequentes.
Engenharia do Software I
17
18. Heurísticas de Nielsen
Desenho estético e
minimalista
Desenhar diálogos sem informação irrelevante
ou raramente necessária. Itens adicionais de
informação num diálogo competem com
unidades de informação relevantes e diminuem
a sua visibilidade relativa.
Ajudar a
reconhecer,
diagnosticar e
recuperar de erros
Exprimir mensagens de erro em linguagem
simples (sem códigos) precisando qual o
problema e sugerindo construtivamente uma
solução.
Ajuda e
documentação
Pode ser necessário disponibilizar ajuda e
documentação, apesar de ser preferível que o
sistema possa ser usado sem documentação.
Informação de ajuda e documentação deve ser
fácil de pesquisar, estar focada na tarefa do
utilizador e listar passos concretos a dar. Não
deve ser demasiado grande.
2009/2010
Engenharia do Software I
18
19. Dois problemas de desenho
Como disponibilizar ao sistema informação
vinda do utilizador?
Como disponibilizar ao utilizador
informação vinda do sistema?
Interacção com utilizador e apresentação
de informação podem ser integradas em
estrutura coerente (e.g., metáfora de
interface com o utilizador)
2009/2010
Engenharia do Software I
19
20. Estilos de interacção
Manipulação directa
Selecção em menus
Preenchimento de formulários
Comandos
Linguagem natural
2009/2010
Engenharia do Software I
20
21. Estilos de interacção
Estilo
Vantagens
Desvantagens
Manipulação
directa
Interacção rápida e
intuitiva; fácil aprender.
Difícil implementar; aplicável só se
tarefas e objectos têm metáfora
visual.
Selecção em Evita erros do utilizador;
Lento para utilizadores experientes;
• Controlo decom muitas opções é complexo.
Sistemas operativos.
stocks.
menus
pouca digitação. Jogos.dos sistemas de
Sistemas
Maioria de recuperação
•
• Gestão pessoal de
Sistemas de comando
de informação.
utilização geral.
• Sistemas CAD.
Formulários Introdução simplescontrolo. Ocupa muito ecrã; opções do
e de
empréstimos.
dados; fácil aprender;
utilizador podem não corresponder
verificável.
a campos.
Comandos
Poderoso e flexível.
Difícil aprender; gestão fraca de
erros.
Linguagem
natural
Acessível a utilizadores
ocasionais; fácil estender.
Muita digitação; pouca fiabilidade.
2009/2010
Engenharia do Software I
21
22. Múltiplas interfaces
Interface gráfica de
utilização (Gnome/KDE)
Interface de linha de
comandos (bash/ksh)
Gestor da interface
gráfica de utilização
do X Window System
Interpretador de
comandos
Sistema operativo Linux
2009/2010
Engenharia do Software I
22
23. Interacção LIBSYS
Pesquisa de documentos Utilizadores usam os mecanismos de
pesquisa para procurar os documentos de
que precisam.
Pedido de documentos
2009/2010
Utilizadores pedem a entrega de um
documento na sua máquina ou num
servidor para impressão.
Engenharia do Software I
23
24. Interfaces baseadas na
Web
Muitos sistemas baseados na Web têm
interfaces baseadas em formulários cujos
campos podem ser
Menus
Caixa de texto livre
Botões de rádio
Etc.
LIBSYS: Menu para escolher onde
pesquisar e caixa de texto para frase a
procurar
2009/2010
Engenharia do Software I
24
25. Formulário de pesquisa do
LIBSYS
LIBSYS: Pesquisa
Escolher colecção
Todas
Palavra ou frase
Procurar usando
Título
Palavras adjacentes
Pesquisar
2009/2010
Sim
Limpar
Engenharia do Software I
Não
Cancelar
25
26. Apresentação da
informação
Apresentação ao utilizador de informação
do sistema
Informação pode ser apresentada
Directamente – Texto num processador de texto
Transformada – Formato gráfico
Padrão de desenho.
Abordagem Modelo-Vista-Controlador
suporta múltiplas vistas dos mesmos
dados
2009/2010
Engenharia do Software I
26
29. Apresentação da
informação
Informação estática
Inicializada no início de uma sessão
Não muda durante uma sessão
Pode ser numérica ou textual
Informação dinâmica
Muda durante a sessão
Mudanças têm de ser comunicadas ao
utilizador
Pode ser numérica ou textual
2009/2010
Engenharia do Software I
29
30. Factores da apresentação da
informação
Utilizador interessa-se por informação precisa ou
relações entre dados?
Quão depressa mudam os valores da informação?
Alterações devem ser indicadas imediatamente?
Utilizador deve responder a alterações?
Há interface de manipulação directa?
Informação textual ou numérica? Valores relativos
importantes?
2009/2010
Engenharia do Software I
30
31. Apresentações alternativas da
informação
Jan. Fev. Mar. Abr. Mai. Jun.
2842 2851 3164 2789 1273 2835
4000
3000
2000
1000
0
2009/2010
Jan.
Fev.
Mar.
Abr.
Engenharia do Software I
Mai. Jun.
31
32. Apresentação analógica ou
digital?
Apresentação digital
Compacta – Ocupa pouco espaço no ecrã
Permite comunica valores precisos
Apresentação analógica
Fácil ter ideia dos valores num relance
Possível mostrar valores relativos
Fácil ver valores excepcionais dos dados
2009/2010
Engenharia do Software I
32
35. Visualização de dados
Grandes quantidades de informação
Revela tendências e relações entre entidades
Possíveis visualizações
Informação meteorológica recolhida em vários locais
Estado de rede como conjunto de nós ligados
Fábrica como conjunto de tanques e tubos
mostrando pressões e temperaturas
Modelo 3D de molécula
Páginas Web como árvore hiperbólica
2009/2010
Engenharia do Software I
35
36. Ecrãs coloridos
Cor adiciona dimensão extra à interface
Ajuda a compreender estruturas
complexas de informação
Usada para destacar eventos
excepcionais
2009/2010
Engenharia do Software I
36
37. Erros comuns
Usar a cor para comunicar significado
Superabundância de cor no ecrã
2009/2010
Engenharia do Software I
37
39. Orientações para uso de cores
Limitar o número de cores
Ser conservador
Mostrar alterações de estado
Suportar tarefas do utilizador com
código de cores
Usar de forma pensada e consistente
Cautela com emparelhamentos
2009/2010
Engenharia do Software I
39
41. Mensagens de erro
Bom desenho é crítico: más mensagens de
erro podem levar à rejeição do sistema
Devem ser
Educadas
Concisas
Consistentes
Construtivas
Formação e experiência dos utilizadores é
factor determinante no desenho
2009/2010
Engenharia do Software I
41
42. Factores na redacção de
mensagens de erro
Contexto
Reflectir contexto corrente do utilizador. Deve-se estar
ciente das suas acções e gerar mensagens relevantes.
Experiência
Mensagens longas e “cheias de significado” irritam
utilizadores experientes. Mensagens concisas não são
percebidas por utilizadores iniciados. Disponibilizar
ambas: utilizador controla grau de concisão.
Nível de
Adequar mensagens a competências e experiência do
competência utilizador. Conceber mensagens diferentes para tipos
de utilizador diferentes usando diferentes terminologias.
Estilo
Redigir mensagens de forma positiva. Usar a voz activa
e não a voz passiva. Não insultar nem tentar ter piada.
Cultura
Estudar culturas locais dos utilizadores. Há diferenças
culturais assinaláveis entre Europa, Ásia e os EUA:
mensagens adequadas numa cultura podem não o ser
noutra.
2009/2010
Engenharia do Software I
42
43. Erro do utilizador
Nome do paciente
Introduza o nome do
paciente:
Ximenes, Xisto
Assuma que um(a)
enfermeira(o) se
engana no nome do
paciente de cujo
registo necessita.
2009/2010
OK
Engenharia do Software I
Cancelar
43
44. Mau desenho: mensagem de
erro orientada para o sistema
Erro!
!
Erro 27
ID de paciente inválido!
OK
2009/2010
Engenharia do Software I
Cancelar
44
45. Bom desenho: mensagem de
erro orientada para o utilizador
Paciente “Xisto Ximenes” desconhecido
“Xisto Ximenes” não está registado como paciente.
Carregue em “Pacientes” para ver uma lista de pacientes.
Carregue em “De novo” para introduzir o nome de novo.
Carregue em “Ajuda” para obter mais ajuda.
Pacientes
2009/2010
Ajuda
De novo
Engenharia do Software I
Cancelar
45
46. Processo de desenho de
interfaces com o utilizador
É processo iterativo
Relações estreitas entre utilizadores e
designers
Três actividades centrais
Análise do utilizador
Prototipagem do sistema
Avaliação da interface
2009/2010
Engenharia do Software I
46
47. Actividades centrais do
processo
Análise de utilizadores
Compreender o que os utilizadores irão
fazer com o sistema.
Prototipagem do sistema
Desenvolver uma série de protótipos para
realizar experiências.
Avaliação da interface
Fazer experiências com os protótipos
envolvendo os utilizadores.
2009/2010
Engenharia do Software I
47
48. Processo de desenho
Analisar e
compreender
actividades dos
utilizadores
Produzir
primeiro
protótipo
em papel
Avaliar
desenho com
utilizadores
finais
2009/2010
Avaliar
desenho com
utilizadores
finais
Protótipo
executável
Protótipo de
desenho
Produzir
protótipo
dinâmico
Implementar
interface com
o utilizador
final
Engenharia do Software I
48
49. Análise de utilizadores
Sem perceber o que utilizadores
pretendem fazer não é possível desenhar
interface eficaz
Análises descritas em termos que
utilizadores e designers possam entender
Cenários descrevendo casos de uso
típicos são forma de descrever análises
2009/2010
Engenharia do Software I
49
50. Cenário de interacção com o
utilizador
A Joana é aluna de Estudos Religiosos. Está a trabalhar num
ensaio sobre arquitectura indiana e sobre a forma como foi
influenciada pela prática religiosa. Para melhor compreender
o assunto, gostaria de aceder a fotografias de pormenores de
edifícios importantes. No entanto, não conseguiu encontrar
nada de relevante na sua biblioteca local.
Aborda o bibliotecário para discutir as suas necessidades.
Este sugere-lhe alguns termos de pesquisa. Também lhe
sugere algumas bibliotecas em Nova Deli e Londres que
talvez tenham o material desejado. Entram nos catálogos da
biblioteca e fazem pesquisas com esses termos. Encontram
algum material e fazem um pedido para serem enviadas
directamente à Joana fotocópias das fotografias com
pormenores arquitectónicos que encontraram.
2009/2010
Engenharia do Software I
50
51. Requisitos do cenário
Utilizadores podem não estar cientes de
termos de pesquisa mais apropriados
Precisam de ajuda na escolha dos termos
Têm de poder escolher colecções a
pesquisar
Têm de poder pesquisar e pedir cópias do
material relevante encontrado
2009/2010
Engenharia do Software I
51
52. Técnicas de análise
Análise de tarefas
Modelar os passos que completar uma
tarefa envolve.
Entrevistas e questionários
Perguntar aos utilizadores acerca do
trabalho que realizam.
Etnografia
Observar os utilizadores enquanto
trabalham.
2009/2010
Engenharia do Software I
52
53. Análise hierárquica de
tarefas
Obter imagens a
partir de bibliotecas
remotas
Fazer 1, 2 e 3 até imagens encontradas, 4
1
2
Descobrir
possíveis
fontes
Estabelecer
termos de
pesquisa
3
4
Pesquisar
imagens
Pedir fotocópias
dos itens
encontrados
Fazer 3.1, 3.2 e 3.3 até imagens encontradas, 3.4 se necessário, 3.5
3.1
Seleccionar
biblioteca
3.2
3.3
Autenticar
no catálogo
Pesquisar
imagens
3.4
Modificar
termos de
pesquisa
3.5
Registar
itens
relevantes
3.3.1, 3.3.2 e 3.3.3
3.3.1
2009/2010
Introduzir
termos de
pesquisa
3.3.2
Iniciar
pesquisa
Engenharia do Software I
3.3.3
Analisar
resultados
53
54. Entrevistas
Conceber entrevistas semi-estruturadas
baseadas em perguntas abertas
Utilizadores fornecem informação que
julgam essencial, e não apenas informação
que se previu recolher
Entrevistas de grupo e grupos foco
permitem a utilizadores discutirem entre si
o que fazem
2009/2010
Engenharia do Software I
54
55. Etnografia
Observador externo observa utilizadores
trabalhando e questiona-os sobre o seu
trabalho
Valor decorre de muitas tarefas serem
intuitivas e difíceis de descrever e explicar
pelos utilizadores
Ajuda a compreender papel de influências
sociais e organizacionais no trabalho
2009/2010
Engenharia do Software I
55
56. Registos etnográficos
O controlo do tráfego aéreo usa um determinado número de
„pacotes‟ em que os pacotes de controlo de sectores adjacentes do
espaço aéreo são fisicamente colocados lado a lado. Os voos num
sector são representados por tiras de papel enfiadas nas ranhuras
de um suporte de madeira por uma ordem que reflecte a sua
posição no sector. Se não houver suficientes ranhuras num suporte
(e.g., o espaço aéreo está muito intenso), os controladores
espalham as tiras na secretária em frente do suporte.
Enquanto observávamos os controladores, notámos que os
controladores olhavam regularmente para os suportes de tiras no
sector adjacente. Chamámos a atenção para este facto e
perguntámos-lhes porque o faziam. Responderam que, quando um
controlador adjacente tem tiras na sua secretária, há muitos voos
que se preparam para entrar no seu sector. Quando isso acontece,
eles tentam acelerar a velocidade das aeronaves no seu sector
para „fazer espaço‟ para os voos que para ele se dirigem.
2009/2010
Engenharia do Software I
56
57. Resultados da análise
etnográfica
Controladores têm de ver todos os voos
num sector: deve evitar-se visualizações
em que voos deslizem para fora do ecrã
(quer pelo topo, quer pela base)
Interface deve mostrar quantos voos
estão em sectores adjacentes de modo
a que controlador possa planear como
lidar com pico de esforço que se
aproxima
2009/2010
Engenharia do Software I
57
58. Prototipagem da interface com
o utilizador
Dar aos utilizadores experiência directa
com interface
Sem ela é impossível aferir usabilidade da
interface
Pode ser processo com duas etapas
Inicialmente protótipos em papel
Depois desenho é refinado e desenvolvem-se
protótipos automatizados com sofisticação
crescente
2009/2010
Engenharia do Software I
58
59. Prototipagem em papel
Estudar cenários usando esboços da
interface
Usar guião para apresentar série de
interacções com sistema
Eficaz para obter reacções dos
utilizadores a uma proposta de desenho
2009/2010
Engenharia do Software I
59
60. Técnicas de prototipagem
Com guião
Programação visual
Baseada na Web
2009/2010
Desenvolver conjunto de guiões e ecrãs usando
ferramenta como Macromedia Director. Quando
utilizador interage com ecrã, salta para próximo
ecrã.
Capítulo 17
Usar linguagem concebida para
desenvolvimento rápido como o Visual Basic.
Usar navegador Web e linguagens associadas
Engenharia do Software I
60
61. Avaliação de interfaces com o
utilizador
Necessária para aferir se desenho é
adequado
Avaliação completa muito cara e
impraticável para maioria dos sistemas
Idealmente interfaces avaliadas face a
especificação de usabilidade; mas é
raro serem produzidas especificações
2009/2010
Engenharia do Software I
61
62. Atributos de usabilidade
Apreensibilidade
Quanto demora um utilizador a se tornar produtivo
com o sistema?
Velocidade de
operação
Quão próxima está a resposta do sistema da
prática do utilizador?
Robustez
Quão tolerante é o sistema face a erros do
utilizador?
Recuperabilidade Quão bem recupera o sistema de erros do
utilizador?
Adaptabilidade
2009/2010
Quão preso está o sistema a um único modelo de
trabalho?
Engenharia do Software I
62
63. Técnicas de avaliação simples
Questionários ao utilizador
Gravação vídeo de utilização do sistema e
posterior avaliação
Instrumentação de código para recolher
informação acerca da utilização de
funcionalidades e da ocorrência de erros do
utilizador
Disponibilização de código para recolha em
linha de opiniões do utilizador
2009/2010
Engenharia do Software I
63
64. A reter
Princípios do desenho guiam desenho
de interfaces com utilizador
Estilos de interacção incluem
Manipulação directa
Sistemas de menu
Preenchimento de formulários
Linguagens de comandos
Língua natural
2009/2010
Engenharia do Software I
64
65. A reter
Apresentações gráficas mostram tendências e
valores aproximados
Apresentações digitais mostram valores
precisos
Cor usada com parcimónia e consistência
Processo de desenho inclui
Análise de utilizadores
Prototipagem do sistema
Avaliação da interface
2009/2010
Engenharia do Software I
65
66. A reter
Análise de utilizadores sensibiliza
designers para forma de trabalho efectiva
de utilizadores
Prototipagem é processo em etapas;
protótipos iniciais em papel base para
protótipos automáticos
Avaliação da interface informa como
melhorar desenho e afere cumprimento de
requisitos de usabilidade
2009/2010
Engenharia do Software I
66
67. A ler
Ian Sommerville, Software Engineering,
8.ª edição, Addison-Wesley, 2006
Capítulo 16
2009/2010
Engenharia do Software I
67