Upload
vitor-juliao
View
104
Download
2
Embed Size (px)
Citation preview
Manuel Menezes de Sequeira
DCTI, ISCTE-IUL
[email protected], D6.02
As apresentações desta série baseiam-se nas apresentações disponibilizadas por IanSommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e
finalmente por Manuel Menezes de Sequeira.
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 2Engenharia do Software I
Sumário
Desenho de interfaces com o utilizador
Problemas de desenho
Heurísticas de Nielsen para interfaces com 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
2009/2010 4Engenharia do Software I
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 5Engenharia do Software I
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 6Engenharia do Software I
Factores humanos no desenho
de interfacesMemó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
preferências de interacção
Alguns preferem imagens, outros
preferem texto.
2009/2010 Engenharia do Software I 7
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
Princípios do desenho de
interfaces com o utilizadorFamiliaridade 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
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
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
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
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
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
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
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
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
de recordar
Minimizar recurso a memória do utilizador
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
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.
2009/2010 Engenharia do Software I 17
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
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
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
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
menus
Evita erros do utilizador;
pouca digitação.
Lento para utilizadores experientes;
com muitas opções é complexo.
Formulários Introdução simples de
dados; fácil aprender;
verificável.
Ocupa muito ecrã; opções do
utilizador podem não corresponder
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
• Jogos.
• Sistemas CAD.
Maioria dos sistemas de
utilização geral.
• Controlo de stocks.
• Gestão pessoal de
empréstimos.
• Sistemas operativos.
• Sistemas de comando
e controlo.
Sistemas de recuperação
de informação.
Múltiplas interfaces
2009/2010 22Engenharia do Software I
Gestor da interface
gráfica de utilização
do X Window System
Interface gráfica de
utilização (Gnome/KDE)
Interpretador de
comandos
Interface de linha de
comandos (bash/ksh)
Sistema operativo Linux
Interacção LIBSYS
Pesquisa de documentos Utilizadores usam os mecanismos de
pesquisa para procurar os documentos de
que precisam.
Pedido de documentos Utilizadores pedem a entrega de um
documento na sua máquina ou num
servidor para impressão.
2009/2010 Engenharia do Software I 23
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
Formulário de pesquisa do
LIBSYS
2009/2010 25Engenharia do Software I
TodasEscolher colecção
Palavra ou frase
TítuloProcurar usando
Palavras adjacentes Sim Não
CancelarLimparPesquisar
LIBSYS: Pesquisa
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
Abordagem Modelo-Vista-Controladorsuporta múltiplas vistas dos mesmos dados
2009/2010 Engenharia do Software I 26
Padrão de desenho.
Apresentação da
informação
2009/2010 27Engenharia do Software I
Informação
a mostrar
Software de
apresentação
Ecrã
Modelo-vista-controlador
2009/2010 28Engenharia do Software I
estado
métodos
Controlador
estado
métodos
Vista
estado
métodos
Modelo
Entradas do
utilizador
Edições do
modelo
Interrogações e
actualizações
do modelo
Mensagens de
modificação
da vista
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
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
Apresentações alternativas da
informação
2009/2010 31Engenharia do Software I
4000
3000
2000
1000
0Jan. Fev. Mar. Abr. Mai. Jun.
Jan.
2842
Fev.
2851
Mar.
3164
Abr.
2789
Mai.
1273
Jun.
2835
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
Métodos de apresentação
2009/2010 33Engenharia do Software I
1
2
3
4
0 10 20
Mostrador eagulha
Gráfico emqueijo Termómetro
Barrahorizontal
Mostrando valores relativos
2009/2010 34Engenharia do Software I
0 200 400100 300
Pressão
0 50 10025 75
Temperatura
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
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
Erros comuns
Usar a cor para comunicar significado
Superabundância de cor no ecrã
2009/2010 Engenharia do Software I 37
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
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
Factores na redacção de
mensagens de erroContexto 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
competência
Adequar mensagens a competências e experiência do
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
Erro do utilizador
2009/2010 43Engenharia do Software I
Introduza o nome do
paciente: Ximenes, Xisto
CancelarOK
Nome do paciente
Assuma que um(a)
enfermeira(o) se
engana no nome do
paciente de cujo
registo necessita.
Mau desenho: mensagem de
erro orientada para o sistema
2009/2010 44Engenharia do Software I
! Erro 27
ID de paciente inválido!
CancelarOK
Erro!
Bom desenho: mensagem de
erro orientada para o utilizador
2009/2010 45Engenharia do Software I
“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.
CancelarDe novo
Paciente “Xisto Ximenes” desconhecido
AjudaPacientes
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
Actividades centrais do
processoAná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
Processo de desenho
2009/2010 48Engenharia do Software I
Analisar e
compreender
actividades dos
utilizadores
Produzir
primeiro
protótipo
em papel
Produzir
protótipo
dinâmico
Implementar
interface com
o utilizador
final
Protótipo de
desenho
Avaliar
desenho com
utilizadores
finais
Protótipo
executável
Avaliar
desenho com
utilizadores
finais
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
Cenário de interacção com o
utilizadorA Joana é aluna de Estudos Religiosos. Está a trabalhar numensaio sobre arquitectura indiana e sobre a forma como foiinfluenciada pela prática religiosa. Para melhor compreendero assunto, gostaria de aceder a fotografias de pormenores deedifícios importantes. No entanto, não conseguiu encontrarnada de relevante na sua biblioteca local.
Aborda o bibliotecário para discutir as suas necessidades.Este sugere-lhe alguns termos de pesquisa. Também lhesugere algumas bibliotecas em Nova Deli e Londres quetalvez tenham o material desejado. Entram nos catálogos dabiblioteca e fazem pesquisas com esses termos. Encontramalgum material e fazem um pedido para serem enviadasdirectamente à Joana fotocópias das fotografias compormenores arquitectónicos que encontraram.
2009/2010 Engenharia do Software I 50
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
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
Análise hierárquica de
tarefas
2009/2010 53Engenharia do Software I
Obter imagens a
partir de bibliotecas
remotas
Descobrir
possíveis
fontes
Estabelecer
termos de
pesquisa
Pesquisar
imagens
Seleccionar
biblioteca
Autenticar
no catálogo
Pesquisar
imagens
Modificar
termos de
pesquisa
Registar
itens
relevantes
Introduzir
termos de
pesquisa
Iniciar
pesquisa
Analisar
resultados
Pedir fotocópias
dos itens
encontrados
1 2 3 4
3.1 3.2 3.3 3.4 3.5
3.3.1 3.3.2 3.3.3
Fazer 1, 2 e 3 até imagens encontradas, 4
Fazer 3.1, 3.2 e 3.3 até imagens encontradas, 3.4 se necessário, 3.5
3.3.1, 3.3.2 e 3.3.3
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
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
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 doespaço aéreo são fisicamente colocados lado a lado. Os voos numsector são representados por tiras de papel enfiadas nas ranhurasde um suporte de madeira por uma ordem que reflecte a suaposição no sector. Se não houver suficientes ranhuras num suporte(e.g., o espaço aéreo está muito intenso), os controladoresespalham as tiras na secretária em frente do suporte.
Enquanto observávamos os controladores, notámos que oscontroladores olhavam regularmente para os suportes de tiras nosector adjacente. Chamámos a atenção para este facto eperguntámos-lhes porque o faziam. Responderam que, quando umcontrolador adjacente tem tiras na sua secretária, há muitos voosque se preparam para entrar no seu sector. Quando isso acontece,eles tentam acelerar a velocidade das aeronaves no seu sectorpara „fazer espaço‟ para os voos que para ele se dirigem.
2009/2010 Engenharia do Software I 56
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
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
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
Técnicas de prototipagem
Com guião Desenvolver conjunto de guiões e ecrãs usando
ferramenta como Macromedia Director. Quando
utilizador interage com ecrã, salta para próximo
ecrã.
Programação visual Usar linguagem concebida para
desenvolvimento rápido como o Visual Basic.
Baseada na Web Usar navegador Web e linguagens associadas
2009/2010 Engenharia do Software I 60
Capítulo 17
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
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 Quão preso está o sistema a um único modelo de
trabalho?
2009/2010 Engenharia do Software I 62
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
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
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
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
A ler
Ian Sommerville, Software Engineering,
8.ª edição, Addison-Wesley, 2006
Capítulo 16
2009/2010 Engenharia do Software I 67
A ver
useit.com: Jakob Nielsen's Website
2009/2010 Engenharia do Software I 68