usabilidade de aplicações

68
Manuel Menezes de Sequeira DCTI, ISCTE-IUL [email protected] , 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.

Upload: vitor-juliao

Post on 13-Jul-2015

104 views

Category:

Documents


2 download

TRANSCRIPT

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

2009/2010 3Engenharia 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

Mau exemplo

2009/2010 38Engenharia do Software I

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

Bom exemplo

2009/2010 40Engenharia do Software I

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