Disser Tac A Ool I Bario

Usabilidade da interface de dispositivos mveis:
heursticas e diretrizes para o design
Olibrio Jos Machado Neto
ii
iii
SERVIO DE PS-GRADUAO DO ICMC-USP
Data de Depsito:
Assinatura:________________________
______

heursticas e diretrizes para o design
Olibrio Jos Machado Neto
Orientadora: Profa. Dra. Maria da Graa Campos Pimentel
Dissertao apresentada ao Instituto de Cincias

Matemticas e de Computao - ICMC-USP, como
parte dos requisitos para obteno do ttulo de Mestre
em Cincias - Cincias de Computao e Matemtica
Computacional. EXEMPLAR DE DEFESA
USP So Carlos
Abril de 2013
iv
Ficha catalogrfica elaborada pela Biblioteca Prof. Achille Bassi

e Seo Tcnica de Informtica, ICMC/USP,
com os dados fornecidos pelo(a) autor(a)
JM113u
u
Jos Machado Neto, Olibrio

heursticas e diretrizes para o design / Olibrio
Jos Machado Neto; orientadora Maria da Graa Campos
Pimentel. -- So Carlos, 2013.
118 p.
Dissertao (Mestrado - Programa de Ps-Graduao
em Cincias de Computao e Matemtica
Computacional) -- Instituto de Cincias Matemticas
e de Computao, Universidade de So Paulo, 2013.
1. Avaliao heurstica. 2. Usabilidade de
interfaces. 3. Computao mvel. I. da Graa Campos
Pimentel, Maria, orient. II. Ttulo.
Agradecimentos
A Deus pelo Seu incomensurvel amor por mim, provado na cruz em que Seu filho santo
morreu a minha morte para que eu, imerecidamente, vivesse a vida Dele.
Aos meus pais Marta e Sebastio, por terem sido to presentes, mesmo estando to distantes fisicamente. Minhas oportunidades e conquistas so frutos dos sonhos que vocs sonham
comigo.
Aos meus avs, pelo amor e pelas constantes oraes.
Agradeo minha orientadora Maria da Graa C. Pimentel pelas timas ideias, pela ajuda
para preparar a Metodologia de Pesquisa deste trabalho, pelas oportunidades de ministrao de
minicursos no Instituto e por outros desafios impostos a mim. Sua experincia em pesquisa e
orientao me deram uma segurana mpar para a realizao destre mestrado.
Ao CnPQ, pelo aporte financeiro.
Aos meus amigos aparterrneos, obrigado por terem sido uma tima famlia.
Aos meus tios Val e Maria, por sempre me receberem de braos abertos em casa e por terem
me ajudado a me manter forte mesmo estando longe de tantos que amo.
Agradeo aos meus amigos da Primeira Igreja Batista de So Carlos, aos das equipes de
voleibol da USP e de So Carlos e aos do Laboratrio de Pesquisa, pelo companheirismo.
vi
Resumo
Do ponto de vista do usurio, a interface uma das partes mais importantes dos sistemas
computacionais, porque por meio dela o usurio v, ouve e sente. Essa relevncia motiva pesquisadores da rea de Interao Humano-Computador a estudarem maneiras de se criarem
interfaces com design focado em usabilidade. A avaliao da usabilidade de interfaces visa verificar se elas atendem aos requisitos do usurio de forma que as funcionalidades do sistema
sejam realizadas de modo efetivo, eficiente e que satisfaa as expectativas do usurio. Tendo em
vista que o ciclo de desenvolvimento de software costuma ser longo, avaliaes da usabilidade
de diferentes verses de interfaces devem ser realizadas no decorrer do processo, como forma de
minimizar erros e reduzir custos de produo do sistema. Uma das avaliaes de usabilidade
mais conhecidas a avaliao heurstica, criada por Jacob Nielsen, que se destaca pelo baixo
custo e rapidez de aplicao. Nela, especialistas avaliam as interfaces e os dilogos do sistema
com base em um conjunto de regras gerais, as heursticas, que lhes permitem identificar problemas de usabilidade. Apesar de respeitadas e amplamente usadas, as heursticas de Nielsen
foram criadas sem foco em interfaces de dispositivos mveis, muito difundidos atualmente. Por
meio deste trabalho, verificou-se que as heursticas de Nielsen tm limitaes para encontrarem problemas de usabilidade em interfaces de dispositivos mveis. Por conta disso, props-se
um conjunto de heursticas para avaliao de interfaces de dispositivos mveis e se definiu um
conjunto de diretrizes para o desenvolvimento dessas interfaces. A validao das heursticas
propostas indicou que elas foram mais efetivas que as de Nielsen para encontrarem problemas
de usabilidade considerados pelos especialistas como catastrficos ou de baixa gravidade.
Palavras-chaves: Avaliao heurstica, Design de Interfaces, Avaliao de Usabilidade de
Interfaces de Dispositivos mveis.
vii
viii
Abstract
From the users point of view, the interface is one the most important part of computer systems, because everything he sees, hears and feels are contained therein. This relevance motivates researchers of Human-Computer Interaction to study ways to create interfaces with design
focused on usability. The usability evaluation of interfaces aims to determine whether the interfaces meet the requirements of the system so that its functionalities are carried out effectively,
efficiently and satisfying the users expectations. Considering that the software development
lifecycle is often long, usability evaluations of different versions of interfaces should be made
during the process, in order to minimize errors and reduce production costs of the final system. Heuristic evaluation, created by Jacob Nielsen, is one of the most used usability evaluation
methods, because of it low cost and ease of implementation. In this evaluation method, experts
evaluate interfaces and systems dialogues based on a set of general rules, called heuristics,
which enable them to identify usability problems. Although respected and widely used, Nielsens
heuristics were not created having mobile devices interfaces in mind. Through this work, it was
verified that Nielsens heuristics have limitations in finding usability problems in mobile devices
interfaces. Because of this, we proposed a set of heuristics for evaluating interfaces for mobile
devices and defined a set of guidelines for the development of these interfaces. The validation of
the proposed heuristics indicated that they were more effective than Nielsens to find usability
problems considered by experts as catastrophic or of low gravity.
Keywords: Heuristic Evaluation, Interface Design, Usability Evaluation of Mobile Devices
Interfaces.
ix
Sumario
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix
Sumrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Lista de Quadros
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
1 Introduo
1.1 Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Identificao do problema
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Questo de pesquisa
2 Recursos para construo de interfaces com usabilidade
2.1 Diretrizes (Guidelines) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Diretrizes para criao de interfaces de dispositivos computacionais em geral
10
2.1.2 Diretrizes para criao de interfaces de dispositivos mveis . . . . . . . . . . . 13

2.2 Heursticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Outros princpios de design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Consideraes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3 Metodologia de Pesquisa
29
3.1 Elaborao das heursticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.1 Anlise de aplicativos para Android . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.2 Acerca dos aplicativos inspecionados . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.3 Brainstorming com especialistas . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Validao das heursticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.1 Avaliaes heursticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.2 Testes com usurios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.3 Avaliaes em outros dispositivos mveis . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Elaborao das guidelines (diretrizes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
xi
xii
SUMARIO
4 Resultados obtidos
41
4.1 Proposio das heursticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.1 Anlise de aplicativos para Android . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.2 Brainstorming com especialistas . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Validao das heursticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.1 Avaliaes heursticas do aplicativo de anotaes multimdia . . . . . . . . . . 50
4.2.2 Avaliao com usurios finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2.3 Avaliao heurstica do UOL Notcias . . . . . . . . . . . . . . . . . . . . . . . . 73
4.3 Criao das diretrizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5 Concluso
91
A Arquivo de registros do usurio novato
103
B Arquivo de registros do usurio intermedirio
107
C Ilustraes dos componentes de interface para dispositivos mveis
111
Referncias bibliogrficas
102
Lista de Figuras
2.1
Exemplo de questo fechada de mltipla escolha que permite mais de uma resposta. Elaborada eletronicamente por meio de caixas de mltipla escolha. . . . . . . 10
2.2
Exemplo de componente de texto contendo informaes como dicas ao usurio no

prprio componente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3
Aplicativo agenda com interface fazendo analogia a uma agenda de papel [Apple,
2010]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4
Tela criada com elementos com pelo menos 48dp de altura e de largura. O esquema
grfico est esquerda, enquanto que a interface final est direita [Google, 2012a]. 17
2.5
Exemplo de mensagem de erro bem-humorada. . . . . . . . . . . . . . . . . . . . . . . 23
2.6
Exemplo de interface desmistificada [Moraveji e Soesanto, 2012]. . . . . . . . . . . . 24
2.7
Exemplo bem sucedido de aplicao do princpio CARP de alinhamento a uma pgina Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8
Exemplo bem sucedido de aplicao do princpio CARP de repetio a uma pgina

Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.9
Processo de design. [Dix et al., 2004] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1
Dispositivos usados na fase de uso de aplicativos baseados em Android. esquerda, smartphone I5500 da Samsung. direita, tablet XOOM da Motorola. . . . . 31
3.2
Tela inicial do aplicativo de anotao multimdia em vdeos. . . . . . . . . . . . . . . 34
3.3
Tela para seleo de usurio que ir navegar pelo aplicativo de anotao multimdia. 35
3.4
Tela para seleo de vdeo a ser anotado. . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5
Tela em que o usurio escolhe o autor do vdeo a ser anotado. . . . . . . . . . . . . . 36
3.6
Tela principal da aplicao de anotao de vdeos. . . . . . . . . . . . . . . . . . . . . 36
3.7
Formato das diretrizes para criao de interfaces de dispositivos mveis. . . . . . . . 39
4.1
Relao entre o nmero de problemas encontrados por cada grau de severidade. . . 63
4.2
Percentual de problemas encontrados com cada grau de severidade. . . . . . . . . . 64
4.3
Quantidade de problemas associados a cada heurstica de Nielsen. . . . . . . . . . . 64
4.4
Quantidade de problemas associados a cada heurstica para avaliao de interfaces

de dispositivos mveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.5
Cdigo-fonte responsvel pela criao e gravao do arquivo de registros de aes

de usurios do aplicativo de anotaes multimdias. . . . . . . . . . . . . . . . . . . . 66
4.6
Trecho de um dos arquivos gravados no carto SD do dispositivo mvel. . . . . . . . 67

xiii
xiv
4.7
LISTA DE FIGURAS
Quantidade de erros cometidos por cada usurio para realizar cada atividade a ele
requerida.Trecho de um dos arquivos gravados no carto SD do dispositivo mvel. . 68
4.8
Tempo gasto por cada usurio para realizar cada atividade a ele requerida.Trecho
de um dos arquivos gravados no carto SD do dispositivo mvel. . . . . . . . . . . . 68
C.1
Barra de Abas. A) Android; B) iOS; C) Windows Phone. . . . . . . . . . . . . . . . . . 112
C.2
Barra de Atividades. A) Android; B) iOS. . . . . . . . . . . . . . . . . . . . . . . . . . . 112
C.3
Barra de navegao. A) Android; B) iOS. . . . . . . . . . . . . . . . . . . . . . . . . . . 113
C.4
Barra de progresso. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . 113
C.5
Barra de status. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
C.6
Barra deslizante de ajuste. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . 113
C.7
Barra inferior. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . . 114
C.8
Boto. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . . . . . . 114
C.9
Caixa de mltipla escolha. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . 114
. . . . . . . 113
C.10 Caixa de seleo. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . 114

C.11 Campo de busca. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . 114
C.12 Campo de texto. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
. . . . . . . 115
C.13 Dilogo. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . . . . . 115

C.14 Girador de progresso. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . 115
C.15 Link. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . . . . . . . 115
C.16 Lista. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . . . . . . . 116
C.17 Menu popup. A) Android; B) Blackberry. . . . . . . . . . . . . . . . . . . . . . . . . . . 116
C.18 Radio button. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . . 116
C.19 Seletor de arquivos. A) Blackberry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
C.20 Seletor de data. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . 117
C.21 Seletor de hora. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . 117
C.22 Seletor numrico. A) Android; B) iOS; C) Windows Phone. . . . . . . . . . . . . . . . . 117
C.23 Submenu. A) Android; B) Windows Phone. . . . . . . . . . . . . . . . . . . . . . . . . 117
C.24 Switch. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . . . . . . 118
C.25 Tabela. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . . . . . . 118
Lista de Tabelas
3.1
Relao entre aplicativos avaliados e principais funcionalidades que cada um deles

oferece. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1
Categorizao dos problemas encontrados nas interfaces do Facebook. . . . . . . . . 41
4.2
Categorizao dos problemas encontrados nas interfaces do Foursquare. . . . . . . 43
4.3
Categorizao dos problemas encontrados nas interfaces do Gmail. . . . . . . . . . . 43
4.4
Categorizao dos problemas encontrados nas interfaces do Twitter. . . . . . . . . . 44
4.5
Associao das categorias encontradas s heursticas de Nielsen. . . . . . . . . . . . 45
4.6
Primeira verso das heursticas para avaliao da usabilidade de interfaces de dispositivos mveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.7
Segunda verso das heursticas para avaliao de usabilidade de interfaces de dispositivos mveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.8
Heursticas revisadas de Nielsen traduzidas por Rocha e Baranauskas [2003]. . . . 51
4.9
Avaliao heurstica pelo primeiro especialista, com base nas heursticas de Nielsen. 52
4.10 Avaliao heurstica pelo segundo especialista, com base nas heursticas de Nielsen. 52
4.11 Avaliao heurstica pelo terceiro especialista, com base nas heursticas de Nielsen.
53
4.12 Avaliao heurstica pelo quarto especialista, com base nas heursticas de Nielsen.
53
4.13 Avaliao heurstica pelo quinto especialista, com base nas heursticas de Nielsen. . 54
4.14 Avaliao heurstica pelo primeiro especialista, com base nas heursticas para dispositivos mveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.15 Avaliao heurstica pelo segundo especialista, com base nas heursticas para dispositivos mveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.16 Avaliao heurstica pelo terceiro especialista, com base nas heursticas para dispositivos mveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.17 Avaliao heurstica pelo quarto especialista, com base nas heursticas para dispositivos mveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.18 Avaliao heurstica pelo quinto especialista, com base nas heursticas para dispositivos mveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.19 Categorizao dos problemas encontrados nas interfaces do Twitter. . . . . . . . . . 60
4.20 Sumarizao das quantidades de problemas encontrados com cada grau de severidade, por cada avaliador que usou as heursticas de Nielsen. . . . . . . . . . . . . . . 62
xv
xvi
LISTA DE TABELAS
4.21 Sumarizao das quantidades de problemas encontrados com cada grau de severidade, por cada avaliador que usou as heursticas para interfaces de dispositivos
mveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.22 Resultado da avaliao heurstica do UOL Notcias utilizando-se o iPhone 4S . . . . 73
4.23 Resultado da avaliao heurstica do UOL Notcias utilizando-se o Motorola Blur . . 74
4.24 Resultado da avaliao heurstica do UOL Notcias utilizando-se o Motorola XOOM.
74
4.25 Mapeamento da terminologia de componentes usada pelas empresas Google, Blackberry, Apple e Microsoft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Lista de Quadros
4.1
Barra de Abas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2
Barra de Atividades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.3
Barra de Navegao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.4
Barra de Progresso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.5
Barra de Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.6
Barra Deslizante de Ajuste.
4.7
Barra Inferior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.8
4.9
Boto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Caixa de mltipla escolha. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.10 Caixa de seleo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.11 Campo de busca.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.12 Campo de texto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.13 Dilogo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.14 Girador de progresso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.15 Link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.16 Lista.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.17 Menu Popup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.18 Radio Button.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.19 Seletor de Arquivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.20 Seletor de data.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.21 Seletor Numrico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.22 Submenu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.23 Switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.24 Tabela. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.25 Texto (Rtulo). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
xvii
xviii
LISTA DE QUADROS
Captulo
1
Introducao
Neste captulo so apresentadas a motivao para a pesquisa e a descrio do problema abordado, os objetivos do trabalho e a estruturao do restante do documento.
1.1
Contextualizao
A evoluo das tecnologias de informao (TIs) contribuiu grandemente para a agregao de

valor a processos e servios [Torres, 1995]. Por conta disso, as TIs se tornaram fundamentais para aperfeioar os processos organizacionais em geral [Goodman e Lawless, 1994] e as
estratgias competitivas de empresas e pessoas [Lai e Mahapatra, 1997]. O computador pessoal
popularizou-se e, com ele, cresceu o nmero de pessoas que acessam a internet.
Paralelamente ao crescimento e mudanas constantes da internet, aumentou tambm o nmero de dispositivos capazes de acessar a rede de computadores. Hoje comum ter internet no
notebook, no netbook e em dispositivos mveis, como smartphones, tablets e PDAs.
Essa popularizao da Internet, aliada ao interesse de se usarem aparelhos mveis em lugares diversos enquanto se realizam tarefas cotidianas, contribuiu para que os dispositivos evolussem tecnologicamente. Pode-se dizer que eles se tornaram tecnologias multimdia poderosas,
capazes de disponibilizar diferentes tipos de contedo a boas taxas de processamento. Entretanto, apesar de cada vez mais onipresente no dia-a-dia das pessoas que os utilizam, ainda h
carncia de estudos de design de interface especficos para tais dispositivos.
O design de interfaces de sistemas interativos uma tarefa to relevante que se tornou
uma das subreas da Interao Humano-Computador (IHC) que, por sua vez, visa estudar,
planejar e entender como pessoas e dispositivos computacionais podem interagir de forma que as
necessidades delas sejam contempladas da forma mais efetiva possvel [Galitz, 2003]. De modo
geral, essa efetividade de interao obtida quando o usurio percebe o sistema e consegue
se comunicar com ele da forma mais natural possvel. Evidentemente, para interagem com o
usurio, dispositivos computacionais devem dispor de meios captadores de reaes sinestsicas
dos humanos, como tato, viso ou adio. Esse meio de captao em sistemas computacionais
chamado de interface e, para que ela possa maximizar a comunicao entre humanos e
1
INTRODUC
AO
1.1
computadores, necessrio que ela possua boa usabilidade.

Gatica-Perez e Montoliu [2010] observam que a evoluo dos dispositivos mveis tem feito
com que eles se tornem dispositivos multimdia naturais por serem capazes de adquirir, acessar, gerenciar e transmitir mltiplos tipos de mdia como vdeo, imagens, udio e mapas. Os
autores identificam a demanda por pesquisas associadas a interfaces com usurios que lhes
garantam usabilidade e por estudos relativos anlise de comportamentos de usurios, para
desenvolvimento de tais interfaces, como realizado por Bigonha et al. [2010].
O conceito de usabilidade antigo e no se aplica apenas ao contexto computacional. Segundo Galitz [2003], Bennett [1979] foi o primeiro pesquisador a usar o termo usabilidade,
referindo-se a ela como a efetividade com que o usurio realiza suas atividades. Nos anos seguintes, Shackel [1981] props uma definio um pouco mais formal para o termo. Finalmente,
Shackel [1991] divulgou uma definio que, segundo Galitz [2003], simples e pertinente: algo
apresenta grande usabilidade quando humanos conseguem us-lo com facilidade e efetividade,
sendo facilidade uma mtrica de avaliao subjetiva e efetividade o desempenho humano ao
us-lo.
Existem variadas definies de usabilidade na Literatura Cientfica. Dentre elas, so famosas as elaboradas pela Organizao Internacional de Padronizao (ISO), por elas parecerem
mais abrangentes que as demais. O padro ISO [1998] define usabilidade como um objetivo
descrito em alto nvel de abstrao: a capacidade de um produto poder ser usado por usurios
especficos para atingir metas especficas com efetividade, eficincia e satisfao, com base em
um contexto de utilizao especfico. Apesar de a definio ser abrangente, segundo Seffah et al.
[2001] o relacionamento entre os parmetros efetividade, eficincia e satisfao e os objetivos
da usabilidade nebuloso, difcil de ser definido. A ISO/IEC [2001], por sua vez, especifica
usabilidade em um contexto estritamente computacional como a capacidade de o software ser
entendido, aprendido e usado de forma que o usurio se sinta atrado pelo sistema. Entretanto,
essa definio no expe claramente as mtricas segundo as quais se devem concentrar os esforos de design, falhando do ponto de vista prtico porque atrao no uma mtrica fcil de
ser aferida [Kunjachan, 2011].
Shneiderman e Plaisant [2009] foram capazes de especificar um conjunto de mtricas que
podem ser aferidas do ponto de vista prtico para facilitar que os objetivos de eficincia e satisfao no contexto de usabilidade de dispositivos computacionais sejam atingidos. Tais fatores
so os seguintes:
Tempo de aprendizagem.
Tempo necessrio para que um usurio tpico do sistema
aprenda as aes relevantes que devem ser executadas, a fim de que sejam realizadas
as principais atividades disponibilizadas pelo sistema.
Desempenho (performance). Tempo necessrio para que o usurio execute as tarefas
principais do sistema.
Taxa de erros cometidos pelo usurio. Contagem do nmero de erros que os usurios
cometem para executar cada tarefa fundamental do sistema e respectiva listagem desses
erros. Apesar de o tempo gasto pelo usurio para identificar um erro e em seguida se
recuperar dele tambm ser contabilizado na mtrica de desempenho, a taxa de erros uma
preocupao capital que precisa ser tratada de forma separada.
Sedimentao do conhecimento por experincia. Visa analisar a facilidade para que um
usurio tpico execute as funcionalidades principais do sistema uma hora, um dia ou uma
semana depois de t-las realizado pela primeira vez. Esta mtrica tem um relacionamento

CONTEXTUALIZAC
AO
1.1
estreito com a medida tempo de aprendizagem e diretamente afetada pela frequncia

com a qual o usurio interage com as interfaces do sistema.
Satisfao subjetiva. Mtrica para analisar o quanto os usurios gostaram de utilizar as
interfaces do sistema. Essa pergunta pode ser respondida por meio de entrevistas com
os usurios ou com questionrios contendo questes na forma de escalas de satisfao
ou mesmo na forma aberta, em que os usurios se sentem completamente livres para
responderem com as prprias palavras.
Evidentemente, impossvel criar um sistema com interfaces que permitam excelentes resultados em todas as mtricas expostas, porque elas se influenciam: se a taxa de erros for muito
pequena, provavelmente o desempenho ser afetado; se o tempo de aprendizagem no for um
fator crtico, possvel ganhar desempenho pelo uso de abreviaes, macros ou atalhos [Shneiderman e Plaisant, 2009]. Efetividade e satisfao normalmente so obtidas quando todas as
mtricas forem planejadas com bom senso, ou seja, de acordo com as necessidades do sistema
e dos usurios.
De fato, atualmente os designers de interface desenvolvem sua capacidade criativa de acordo
com as funcionalidades que o sistema deve disponibilizar e de acordo com os diferentes grupos
de usurios que o utilizaro. Diferentes conjuntos de recomendaes para desenvolvimento
de interfaces foram desenvolvidos [Shneiderman e Plaisant, 2009] [Gong e Tarasewich, 2011]
[Bertini et al., 2006] [Moraveji e Soesanto, 2012], mas se nota que eles so completamente
dependentes do contexto da aplicao, do ponto de vista de suas funcionalidades e de seus
usurios [Shneiderman e Plaisant, 2009]. De qualquer forma, inegvel que, do ponto de vista
do usurio, a interface a parte mais importante dos sistemas computacionais, porque nela est
contido tudo que o usurio consegue fazer. Isso significa que, apesar de no tornar o sistema
funcional por si s, a interface , para a maioria dos usurios, o prprio sistema em si. Todas
as demais camadas de cdigo-fonte necessrias para fazerem o sistema funcionar so invisveis
a quem utiliza sistemas computacionais.
As interfaces evoluram de terminais baseados em comandos de texto para as interfaces
grficas atuais, amplamente difundidas principalmente por conta da World Wide Web e da popularizao da internet. De acordo com a Agncia de Telecomunicaes das Naes Unidas, o
nmero de pessoas que acessam a rede passou de 1,6 bilho para mais de dois bilhes entre
os anos de 2010 e 2011, um crescimento expressivo que permitiu a consolidao das atuais
interfaces grficas como os principais meios de interao do usurio com o computador.
Alguns entusiastas acreditam que os dispositivos computacionais e suas interfaces evoluiro
a ponto de se tornarem invisveis, embutidas no prprio ambiente do usurio de forma que a interao seja imperceptvel [Weiser, 1993]. Embora os conservadores afirmem que essa evoluo
utpica, nota-se que o uso de dispositivos mveis para interagir com usurios em diferentes
ambientes tm auxiliado que as interfaces se tornem imperceptveis, porque os dispositivos so
capazes de identificar algumas informaes acerca do ambiente e dos usurios automaticamente
[Krumm, 2010], respondendo a eventos diversos. De qualquer forma, existe um grande interesse
em desenvolver interfaces mais inteligentes e com mais usabilidade. Neste trabalho, o design de
interfaces ser tratado com foco em usabilidade e no contexto de dispositivos mveis.
As principais motivaes para o desenvolvimento de interfaces com boa usabilidade so a
existncia de inmeras interfaces com design pobre, que no facilitam a interao e que precisam de melhorias, e o grande benefcio que interfaces robustas e elegantes proporcionam aos
usurios, em termos das mtricas de usabilidade apresentadas. Shneiderman e Plaisant [2009]
enumeram alguns ambientes que necessitam de interfaces com boa usabilidade para o contexto
INTRODUC
AO
1.1
de dispositivos eletrnicos em geral. Algumas das aplicaes levantadas por esses autores podem ser estendidas ao contexto de aplicativos para dispositivos mveis como motivaes deste
estudo, e seguem:
Uso comercial e industrial. Aplicativos tpicos de uso comercial e industrial incluem
sistemas bancrios, sistemas de controle de estoque, sistemas controle de inventrios, de
controle de reservas de hotis, dentre outros. Nesses casos, geralmente o oramento o
fator mais limitante e os gastos com treinamento de pessoal so normalmente altos, de
forma que as interfaces devam ser desenvolvidas com foco em facilidade de aprendizagem.
Alm disso, comum que as interfaces para esses tipos de sistema necessitem de bom
desempenho, por conta do nmero grande de transaes que so processadas em pouco
tempo.
Sistemas para lares, escritrios e para entretenimento. Aplicativos desta seo incluem
e-mail, jogos, sistemas de gerenciamento de arquivos, sistemas de propsito educativo e
mecanismos de buscas. Normalmente, facilidade de aprendizagem, baixa taxa de erros e
satisfao subjetiva so fatores de usabilidade importantes a serem considerados no design
dessas interfaces, principalmente porque tais aplicativos costumam no ter restries de
usurios e normalmente existem concorrentes no mercado. Usurios incapazes de executar
as funcionalidades desses sistemas com facilidade tendem a procurar aplicativos concorrentes ou a parar de usar o aplicativo.
Interfaces colaborativas, criativas ou exploratrias. Interfaces exploratrias incluem
navegadores Web, simuladores de experimentos e sistemas de apoio a negcios. Sistemas
destinados ao estmulo da capacidade criativa incluem interfaces para aplicativos artsticos
e de design arquitetnico. Normalmente, interfaces que se enquadram nessa seo so
operadas por usurios com grande domnio das funcionalidades realizadas, mas com pouco
conhecimento dos conceitos computacionais envolvidos. Interfaces colaborativas permitem
que duas ou mais pessoas operem uma mesma funcionalidade, simultaneamente ou no.
Interfaces de carter sociopoltico. Aplicativos dessa seo geralmente so criados por
entidades governamentais e incluem sistemas de votao popular, de monitoramento de
sade de pacientes ou de criao de perfis para investigaes criminais. Desses, nota-se
que o uso para fins mdicos est mais difundido para o caso de aplicativos de dispositivos
mveis, por conta de a segurana e a privacidade ainda serem problemas capitais no caso
desses dispositivos.
A usabilidade de interfaces de dispositivos mveis muito peculiar, porque eles possuem
limitaes que inexistem no caso de computadores pessoais. As limitaes mais evidentes so
de carter fsico. Por exemplo, as telas dos dispositivos mveis so consideravelmente menores
que as dos computadores pessoais. No caso, oportuno lembrar que dois fatores devem ser
considerados quando se cita a tela de um dispositivo como fator importante para usabilidade de
interfaces: o comprimento da diagonal da tela do aparelho, que define o nmero de polegadas
que ela possui, e a resoluo da tela, ou seja, a quantidade de pixels existentes em proporo
rea da tela.
Em seus estudos sobre desenvolvimento de aplicativos para dispositivos mveis, OinasKukkonen e Kurkela [2003] constataram que os aplicativos bem sucedidos possuem design focado no s na limitao fsica da tela, mas tambm em outras limitaes destes aparelhos, tais
como bandas de acesso menores, eventuais gargalos com processamento e memria e diferenas
DO PROBLEMA
IDENTIFICAC
AO
1.2
entre os mtodos de entrada de dados, quando comparados aos computadores pessoais. Alm
disso, existem preocupaes igualmente importantes que fazem parte de outros contextos, como
o social e o cognitivo.
No contexto social, as limitaes esto centradas principalmente na diversidade cultural das
pessoas de diferentes regies, mas que eventualmente utilizam as mesmas interfaces. Pessoas
de diferentes locais geogrficos tendem a ter expectativas diferentes acerca dos aplicativos que
utilizam. O mesmo ocorre quando se comparam pessoas com idades muito discrepantes (crianas em relao a idosos, por exemplo). Finalmente, o prprio propsito da aplicao pode gerar
em um determinado usurio uma expectativa diferente da gerada para outro usurio [Galitz,
2003].
Do ponto de vista cognitivo, existem evidncias cientficas que comprovam que o crebro
humano extremamente sensvel a interferncias, que fazem com que o usurio se distraia
enquanto interage com um dispositivo mvel. Isso significa que, ao interagir com um aplicativo,
o usurio perde parte da ateno quando eventos externos ocorrem e essa desconcentrao
influencia no tempo de aprendizagem e na velocidade com que as funcionalidades so executadas
[Gazzalley, 2012]. Pode-se notar esse fenmeno com o exemplo de um passageiro em um metr,
que precisa prestar ateno s informaes que acabaram de serem passadas a ele pela cabine
de controle de estaes enquanto ele utiliza um aparelho smartphone.
Todas as caractersticas citadas com relao ao modo com que usurios interagem com dispositivos mveis servem como grandes motivadores de pesquisas relacionadas ao design de interfaces. De maneira genrica, pode-se afirmar que a disseminao de dispositivos mveis diversos
representa um grande desafio aos pesquisadores da rea de Interao Humano-Computador,
porque os usurios desejam que seus aplicativos sejam capazes de serem acessados de forma
prtica nos vrios aparelhos que eles utilizam, mesmo que os sistemas computacionais e os
ambientes de utilizao desses aparelhos mudem constantemente. com base nesse anseio do
usurio que este projeto de pesquisa til. A seguir, a identificao do problema a ser tratado
ser realizada.
1.2
Identificao do problema
Apesar de o tema usabilidade ter-se intensificado com a preocupao de se criarem interfaces melhores para computadores em geral, nota-se que a Literatura Cientfica no conta
com muitos estudos que vinculam as principais contribuies sobre o design de interfaces com
usabilidade para dispositivos mveis, tomando-se como base os princpios e guias consolidados para o design de interfaces de dispositivos em geral. Os estudos referentes ao contexto de
design de interfaces para aparelhos mveis parecem, portanto, desconexos de algumas concluses tericas consolidadas cientificamente. Esse desvnculo poderia ter gerado estudos que no
identificassem problemas de usabilidade da forma que poderiam.
Historicamente, Galitz [2003] foi o primeiro estudioso a propor ideias gerais de como se construrem interfaces grficas com usabilidade [Shneiderman e Plaisant, 2009]. Nesse estudo, princpios importantes de design foram levados em considerao, mas Galitz [2003] no expe claramente um conjunto de regras a serem analisadas pelos envolvidos no processo de design.
Posteriormente, os prprios Shneiderman e Plaisant [2009] propuseram um novo guia de como
se realizar a mesma tarefa, que resultaram em uma lista de recomendaes para interessados
em criar interfaces com usabilidade. Apesar de a lista proposta ser mais aplicvel do ponto de
vista prtico, Shneiderman e Plaisant [2009] no consideraram fatores psicolgicos que influenciam o usurio quando ele utiliza dispositivos computacionais. Ademais, nenhum desses trs
autores levou em considerao o design de interfaces para dispositivos mveis.
INTRODUC
AO
1.2
Tanto Shneiderman e Plaisant [2009] quanto Galitz [2003] apresentam guias de design que
parecem influenciados por estudos anteriores realizados por Nielsen (1994), responsvel pelo
conjunto de heursticas para avaliao de usabilidade de interfaces de dispositivos computacionais mais conhecido pelos pesquisadores de Interao Humano-Computador [Moraveji e Soesanto, 2012], e seus estudos so base para outras contribuies no mbito de design de interface. Embora esses estudos sejam relevantes, eles compartilham a mesma limitao existente
nos estudos de Shneiderman e Plaisant [2009] e de Galitz [2003]: design de interface sem foco
em dispositivos mveis. A avaliao de interfaces uma atividade indispensvel ao processo de
desenvolvimento de sistemas interativos, porque ela permite que os designers verifiquem se a
interface do sistema atende aos requisitos do usurio de modo que as funcionalidades sejam
realizadas de modo efetivo. Na avaliao heurstica, um conjunto de especialistas avalia se a
interface est de acordo com um conjunto de regras, capazes de identificar potenciais problemas
de usabilidade [Nielsen, 1994].
Aparentemente Bertini et al. [2006] foram os poucos autores a tentarem propor heursticas
para avaliao de interfaces de dispositivos mveis. Eles criaram esse conjunto de heursticas
com base no conhecimento de trs pesquisadores experientes da rea de Interao HumanoComputador, os quais identificaram problemas de usabilidade que consideravam importantes
de serem tratados em interfaces de dispositivos mveis. Tais problemas foram colocados em
uma planilha, que foi discutida entre os trs na forma de um brainstorming. O resultado foi
um conjunto de oito heursticas para avaliao de interfaces de dispositivos mveis geradas a
partir das heursticas de [Nielsen, 1994], as quais foram analisadas e aprovadas por mais oito
especialistas da rea. Apesar de as heursticas serem focadas em interfaces de contexto de dispositivos mveis, os resultados das avaliaes no foram enumerados explicitamente no estudo e
no se fez uma descrio detalhada do aplicativo avaliado. Alm disso, a metodologia usada no
considera alguns conceitos tericos para o design, como as regras bsicas de design elaboradas
por Williams [2005] ou teorias de caractersticas de interface que incomodam psicologicamente
o usurio [Moraveji e Soesanto, 2012].
Com propsitos semelhantes aos de Bertini et al. [2006], Gong e Tarasewich [2011] revisitaram os estudos de Shneiderman e Plaisant [2009] e os adaptaram para criarem um novo
conjunto de regras que, segundo aqueles autores, seriam pertinentes para o contexto de interfaces de dispositivos mveis. Contudo, a metodologia utilizada para chegarem a tais diretrizes
no foi encontrada nas fontes pesquisadas, de modo que o valor cientfico do estudo ficou comprometido. Os autores tambm no descreveram nenhum experimento cientfico que validasse
as heursticas propostas por eles.
importante ressaltar que existem sistemas operacionais especficos para dispositivos mveis e que as empresas detentoras de alguns desses sistemas divulgam em seus websites oficiais
diretrizes para a elaborao de interfaces de forma que os elementos de interao sejam utilizados de maneira adequada, a fim de maximizar a usabilidade do aplicativo final. As empresas
pesquisadas para esta dissertao que divulgam essas guidelines so: Apple, criadora do sistema iOS; Blackberry, criadora do sistema Blackberry; Google, criador do sistema Android, e
Microsoft, criadora do sistema Windows Phone.
A divulgao dessas guidelines por meio dessas grandes empresas evidencia que a criao
de interfaces com adequao aos princpios bsicos de usabilidade conhecidos transcendeu o
contexto cientfico e atingiu o contexto comercial. Contudo, as documentaes so baseadas
nos componentes de interfaces existentes em cada sistema operacional que, apesar de terem
propsitos semelhantes entre os sistemas, possuem terminologias distintas. Em alguns casos,
at a localizao dos componentes de interfaces variam de sistema para sistema.
DE PESQUISA
QUESTAO
1.6
Essas diferenciaes dificultam que pessoas sem conhecimento tcnico na linguagem de programao usada no sistema operacional sigam tais recomendaes. Por conta disso, esta dissertao prope um conjunto de diretrizes, o qual poder ser usado por designers sem conhecimentos tcnicos em Computao criarem prottipos de interfaces.
Alm dessa motivao, outro fator que norteou o trabalho foi a dificuldade de econtrar referncias cientficas que disponibilizassem diretrizes ou heursticas especficas para interfaces
de dispositivos mveis. Portanto, so objetivos deste trabalho criar um conjunto de guidelines
genrico que complemente as recomendaes oficiais das empresas detentoras dos sistemas
operacionais existentes, e propor um conjunto de heursticas para avaliao de usabilidade de
interfaces de dispositivos mveis. Em particular, o conjunto de heursticas baseado nas heursticas tradicionais j consolidadas, nas guidelines para criao de interfaces e em princpios
de usabilidade que, at onde foi possvel verificar, no so citados nos estudos relacionados na
Literatura Cientfica. Todos esses tpicos tericos sero explanados no Captulo 2.
Finalmente, cabe ressaltar que o conceito de usabilidade inevitavelmente vinculado s funcionalidades do sistema, seja ele elaborado para computadores pessoais tradicionais, baseado
na Web ou desenvolvido para dispositivos mveis, porque ela abrange no somente a interface,
mas tambm vrios outros fatores, como utilidade e confiabilidade [Nielsen, 1993]. Por conta
disso, comum encontrar referncias com dicas de como tratar a usabilidade de sistemas de
forma atrelada s funcionalidades. As questes a serem respondidas neste projeto podem ser
verificadas no subcaptulo 1.3.
1.3
Questo de pesquisa
Este trabalho de pesquisa pretende responder seguinte questo:

As heuristicas de Nielsen so deficientes em identificar problemas de usabilidade de aplicaes de dispositivos mveis?
As atividades descritas na Seo 3.1.2 indicaram que a resposta pergunta acima sim.
Por conta disso, o mestrando identificou a oportunidade de estender as heursticas de Nielsen
para elaborar heursticas para a avaliao de interfaces de dispositivos mveis.
1.4
Objetivos
Aps verificar que as heuristicas de Nieslen no eram facilmente associadas a determinadas

categorias de problemas de usabilidade encontrados em quatro aplicativos de dispositivos mveis
inspecionados, este trabalho teve por objetivo propor um conjunto de heursticas para avaliao
de interfaces de dispositivos mveis por meio do uso de tais categorias de problemas e das
heursticas j existentes. O objetivo secundrio do trabalho foi definir um conjunto de diretrizes
para o desenvolvimento dessas interfaces, por meio da anlise de recomendaes para o design
de interfaces disponibilizadas por empresas dententoras de sistemas de dispositivos mveis.
1.5
Resultados
Os resultados indicaram que, apesar de as heursticas propostas terem se baseado nas heursticas de Nielsen, elas encontraram um nmero maior de problemas quando comparadas quelas heursticas. O nmero de problemas considerados pelos avaliadores como de baixa prioridade tambm foi maior. Alm disso, o nmero de problemas considerados catastrficos foi mais
que o dobro do encontrado pelas heursticas de Nielsen.

INTRODUC
AO
1.6
1.6
Estrutura do trabalho
O restante deste documento est estruturado da seguinte forma: no Captulo 2 so explanados os principais resultados acerca do tema abordado neste trabalho, os quais sero usados
como base para a criao dos documentos citados como objetivos na Seo 1.4. Em seguida, no
Captulo 3, ser abordada a Metodologia de Pesquisa utilizada. No Captulo 4, descrever-se-o
os resultados obtidos ao longo ao longo do estudo. O Captulo 5 contm as concluses do projeto de pesquisa, que visam responder s questes sumarizadas na Subseo 1.3. Por fim, so
apresentadas as Referncias Bibliogrficas utilizadas.
Neste trabalho, o termo mestrando ser usado para referir-se ao aluno que realizou este
trabalho.
Captulo
2
Recursos para construcao de interfaces com
usabilidade
Este captulo contm informaes que servem de subsdio para pessoas interessadas na criao de interfaces com boa usabilidade. Trata-se de um apanhado de ideias que so aceitas na
Literatura Cientfica para auxiliar neste processo de criao e se destina a estudantes e jovens
pesquisadores que desejem iniciar uma pesquisa nessa rea e a demais interessados em criao
de interfaces, tais como webdesigners, desenvolvedores de software e publicitrios. Os estudos no so necessariamente independentes, no sentido de que um conjunto de recomendaes
pode ter-se baseado noutras recomendaes elaboradas por outrem. Por completude, todos os
estudos relacionados utilizados neste trabalho sero expostos neste captulo. Entretanto, algumas recomendaes expostas tornaram-se obsoletas. Uma ressalva ser realizada nas Seo 2.4
para elucidar tais recomendaes.
2.1
Diretrizes (Guidelines)
Diretrizes so conjuntos de regras para o design de interfaces, que permitem que os envolvidos nesse processo de design tenham uma documentao para prevenir e corrigir erros
de usabilidade que j so conhecidos por conta da experincia de outrem ou por conta de conhecimentos oriundos da Psicologia [Preece, 1994]. Estas regras representam, portanto, uma
linguagem comum que facilita o trabalho em equipe e uniformiza as interfaces sendo criadas, em
termos de terminologias, de sequncias de aes necessrias para se completar determinadas
tarefas e de aparncias [Shneiderman e Plaisant, 2009]. Apesar de ainda se criarem guidelines
para o design de interfaces, essa uma prtica relativamente antiga entre os pesquisadores
da rea de Interao Humano-Computador. Em 1995, Mullet e Sano [1995] criaram um conjunto de recomendaes que se acredita serem as primeiras regras voltadas para o design de
criao de interfaces grficas (ou simplesmente GUIs, do Ingls Graphical User Interfaces) em
dispositivos computacionais, de modo geral. Mais tarde, Lynch e Horton [2001] criaram um
novo conjunto de regras para esse mesmo tipo de interface, as quais foram atualizadas por Ga9
DE INTERFACES COM USABILIDADE

RECURSOS PARA CONSTRUC
AO
10
2.1
Figura 2.1: Exemplo de quest

ao fechada de m
ultipla escolha que permite mais de uma resposta. Elaborada eletronicamente por meio de caixas de m
ultipla escolha.
litz quatro anos depois. Hoje, as interfaces grficas ainda desempenham um papel importante
na interao com usurios, j que a maioria dos formulrios de sistemas atuais baseada em
componentes grficos, principalmente por conta da expanso da World Wide Web.
Provavelmente, as guidelines mais conhecidas para o design de interfaces foram propostas
por Shneiderman e Plaisant [2009]. Embora elas no tenham sido elaboradas especificamente
para a criao de interfaces de dispositivos mveis, elas so usadas como base para que pesquisadores criem novas guidelines para avaliarem interfaces de aparelhos mveis [Gong e Tarasewich, 2011].
2.1.1
Diretrizes para criao de interfaces de dispositivos computacionais em geral
O conjunto de diretrizes elaborado por Shneiderman e Plaisant [2009] permitem que se precavejam erros de usabilidade de interfaces de dispositivos computacionais, de modo geral. Em
seu estudo, esses autores organizaram as recomendaes de acordo com quatro interesses, considerados por eles de grande importncia para o processo de design. So eles: navegabilidade
da interface, organizao do contedo exibido, captura da ateno do usurio e facilitao de
entrada de dados.
A navegabilidade da interface um fator de preocupao importante para o processo de design porque muitos usurios apresentam problemas para navegar por determinadas interfaces
computacionais [Koyani et al., 2003]. Com o propsito de melhorar a navegao pela interface
por parte do usurio, Shneiderman e Plaisant [2009] criaram o seguinte conjunto de recomendaes:
Padronize a sequncia de tarefas. Funcionalidades semelhantes devem ser executadas
seguindo-se uma mesma sequncia de atividades, de maneira anloga.
Assegure que os links da pgina sejam descritivos. Quando um link criado, o texto
descritivo associado a ele deve explicar com preciso a ao a ser realizada caso ele seja
ativado.
Use cabealhos distintos para funcionalidades distintas. Cabealhos devem ser associados ao contedo sendo apresentado. Contedos diferentes devem ter cabealhos diferentes.
Use caixas de mltipla escolha (checkboxes) para escolhas que possuam apenas duas
possveis respostas. Escolhas referentes a perguntas que permitem apenas duas respostas claras e distintas devem ser exibidas na forma de checkboxes, como se mostra na
Figura 2.1.
Permita que o usurio imprima a pgina adequadamente. Desenvolva as interfaces em
medidas adequadas para a impresso, para que todos os componentes da tela impressa
apaream corretamente no papel.
2.1
DIRETRIZES (GUIDELINES )
11
Figura 2.2: Exemplo de componente de texto contendo informac

oes como dicas ao usu
ario no pr
oprio componente.
Use imagens pequenas como forma de pr-visualizar as imagens no tamanho original.

Em interfaces em que a visualizao da imagem no tamanho original no seja necessria,
providencie uma imagem menor ao usurio.
A organizao da informao a ser exibida um ponto de ateno porque contedos mal
exibidos acarretam em interpretaes erradas dos usurios. Alm disso, a disposio dos componentes pode comprometer a visualizao deles pelo usurio e associao de cada informao
a componentes diversos da interface. As recomendaes de Shneiderman e Plaisant [2009] para
melhoria da organizao da informao derivam de contribuies feitas bem antes, por Smith e
Mosier [1986], e seguem:
Consistncia dos dados sendo exibidos. A terminologia, abreviaes, formatos, cores e
capitalizaes de termos devem ser documentados na forma de um dicionrio de significados, para que todos os designers saibam como e quando utiliz-los.
Facilidade de assimilao da informao pelo usurio. A linguagem deve ser familiar
ao usurio, o formato de exibio de dados deve permitir que os dados sejam facilmente
assimilados. Esto inclusas nessa recomendao espaamento correto, alinhamento esquerda de palavras, alinhamento de casas decimais de nmeros em ponto flutuante, dentre
outros aspectos.
Minimizao da carga de memria do usurio. Deve-se evitar que o usurio tenha que
se lembrar de informaes entre interfaces diferentes da aplicao. Cada atividade deve
ser planejada de forma que o usurio a complete em um pequeno nmero de passos. Em
casos de grandes quantidades de informaes, deve-se separar a atividade em partes independentes, cada qual contendo um conjunto pequeno de informaes s quais o usurio
deve prestar ateno.
Compatibilidade entre a entrada de dados e o contedo exibido. Elementos de informao exibidos ao usurio devem associar-se de forma precisa e sem ambiguidades com
os componentes de entrada de dados. Eventualmente, elementos de entrada de texto podem exibir informaes ao usurio nos prprios espaos de entrada, como se pode notar
na Figura 2.2.
Flexibilidade do acesso e uso das informaes. Os usurios devem ser capazes de assimilar as informaes das interfaces de diferentes formas, para que eles mesmos escolham
o modo com que devero realizar determinadas atividades. Ordenaes de linhas e colunas
de tabelas so bons exemplos de como tornar dados tabulares flexveis ao usurio.
Informaes so exibidas ao usurio ao longo de toda a interao com interfaces do sistema.
Isso torna necessrio que elementos de cada interface sejam exibidos de forma distintiva, simplesmente para captar a ateno de quem interage e mant-lo estimulado at que as funcionalidades sendo realizadas finalizem [Wickens e Hollands, 2000]. possvel chamar a ateno do
12

AO
2.1
usurio por meio de vrias tcnicas, enumeradas a seguir na forma de guidelines [Shneiderman
e Plaisant, 2009]:
Intensidade dos elementos. Varie a intensidade de elementos na tela. Entretanto,
recomendvel que apenas dois nveis de intensidade sejam usados em uma mesma tela.
Marcao. Sublinhe elementos, coloque-nos bordas, aponte-os com setas ou com indicadores que no fazem parte do texto, como asteriscos, numerais e outros smbolos.
Tamanho. Use at quatro tamanhos diferentes em uma mesma tela. Evidentemente, os
elementos de maior tamanho chamaro mais ateno.
Escolha das fontes. Use at trs fontes diferentes para escrever mensagens.
Efeito de vdeo inverso. Inverta a cor do fundo com as do componente.
Efeito pisca-pisca. Use esse efeito em componentes pequenos e em locais secundrios da
tela.
Cores. Use at quatro cores diferentes, exceto quando o propsito da interface depende
do uso de um nmero maior de cores. Imagens coloridas no so consideradas nessa
contagem.
udio. Use sons sutis para indicar respostas positivas s aes do usurio e sons mais
chamativos para alertar sobre condies adversas.
O ltimo fator de preocupao identificado por Shneiderman e Plaisant [2009] o de facilitao de entrada de dados. Esses autores acreditam que a entrada de dados seja uma das
atividades que mais demanda tempo dos usurios e que, caso seja realizada de forma incorreta,
causa frustraes que podem fazer com que o usurio desista de usar o sistema. As guidelines
elaboradas para amenizar os erros nesse contexto so:
Consistncia das transaes que exigem entrada de dados. As condies de entrada de
dados podem mudar ao longo das interfaces, mas as sequncias de aes necessrias para
que o usurio realize a tarefa devem ser semelhantes no que se referem a delimitadores,
abreviaes, espaamentos, dentre outros fatores.
Minimizao do nmero de aes a serem realizadas pelo usurio. As interfaces devem
ser criadas para que os usurios finalizem a entrada dos dados necessrios com um nmero mnimo de interaes, a fim de que ele no se canse. Substituir aes de digitao de
frases por comandos de cliques em opes e sentenas pr-definidas so formas de atingir
esse objetivo. Contudo, essa pode ser uma soluo ruim caso o usurio precise mover a
mo para outro dispositivo que esteja distante. Em casos de usurios com boa percia da
tecnologia sendo utilizada, a digitao de 6 a 8 caracteres priorizada em relao s atividades de cliques de mouse ou joystick, por exemplo. Em casos que uma mesma informao
deve ser fornecida pelo usurio em diferentes locais da interface, o sistema deve copiar a
primeira resposta dada para a localizao corrente do formulrio.
As guidelines de minimizao da carga de memria do usurio, compatibilidade entre a entrada de dados e o contedo exibido e flexibilidade do acesso e uso das informaes devem ser
repensados no fator de facilitao de entrada de dados, porque eles tambm esto fortemente
relacionados a ele. A documentao por guidelines, embora sirva como uma boa base para designers criarem interfaces que previnam erros com base nas experincias de outrem, deve ser
2.1
13
analisada minuciosamente de acordo com os usurios e com as funcionalidades a serem realizadas no sistema computacional, para que eventuais conflitos sejam desfeitos [Preece, 1994]. A
regra de consistncia, por exemplo, importante do ponto de vista de facilidade de aprendizagem, mas pode ser considerada irrelevante para usurios avanados do sistema [Preece, 1994].
A identificao do perfil do usurio uma tarefa a ser confrontada com as guidelines propostos porque os indivduos possuem suas peculiaridades, que podem variar inclusive entre
pessoas de uma mesma regio ou cultura. Por exemplo, algumas pessoas preferem visualizar
dados tabulados a enxerg-los sob uma perspectiva grfica; outras preferem lidar com palavras
a lidar com dados numricos.
Alm do conhecimento sobre as preferncias dos usurios que devem ser suportadas pela
interface para promover flexibilidade de uso, importante que os designers conheam o grau
de percia do usurio com a aplicao sendo desenvolvida. Existem usurios que no sabem
usar menus com dados apresentados em hierarquias, por exemplo. Um usurio idoso que esteja enviando um email para o seu neto pela primeira vez ter um nvel mnimo de percia de
utilizao dos componentes de interface, de forma que ela dever permitir que ele tenha fcil
acesso a um conjunto de instrues que o auxiliem a utilizar o sistema. Para usurios novatos,
o nmero de aes para completar atividades deve ser muito pequeno e os formulrios devem ser
preenchidos de forma gradual com instrues, para que ele se acostume com a forma pela qual
dever fornecer os dados requeridos, a qual dever ser mantida ao longo de todas as interfaces
da funcionalidade [McGrenere et al., 2002].
A definio das funcionalidades a serem suportadas pelo sistema importante por conta de
as funcionalidades definirem o conjunto de tarefas a serem realizadas pelo usurio. Portanto, as
funcionalidades permitem que a consistncia de navegao seja planejada pelos designers antes
de eles criarem efetivamente a interface. Por meio de entrevistas elaboradas com os usurios,
podem-se identificar as funcionalidades mais importantes e se criarem atalhos para resolv-las.
Somente as funcionalidades menos utilizadas podero exigir uma sequncia maior de interaes
pelo usurio e, com base no conhecimento de usurios e das funcionalidades, os designers
podero definir o modo pelo qual se interagir com a interface (uso de menus, uso da linguagem
natural, comandos de voz, preenchimento de formulrios e por manipulao direta1 ).
Finalmente, vlido destacar que as regras citadas devem ser analisadas de acordo com as
peculiaridades de hardware de cada dispositivo computacional. Alm de as configuraes computacionais variarem bastante, os dispositivos de entrada e sada de dados podem ser distintos
entre dispositivos, de modo que uma guideline praticvel para um conjunto de aparelhos se
torne impraticvel para outro conjunto.
2.1.2
Diretrizes para criao de interfaces de dispositivos mveis
As pesquisas de usabilidade de interfaces para dispositivos mveis esto alguns passos atrs
daquelas relacionadas s interfaces de computadores pessoais, por fatores diversos: a interao
em dispositivos mveis muito peculiar e diferente da interao com computadores pessoais
[Robertson et al., 2005]; o mercado de dispositivos mveis aqueceu aps o mercado de computadores pessoais j estar consolidado [Ji et al., 2006]; dispositivos mveis possuem caractersticas
e limitaes fsicas distintas [Kunjachan, 2011].
Todos os estudos analisados ao longo deste projeto de mestrado que divulgam guidelines para
criao de interfaces de dispositivos mveis com usabilidade foram publicados pelos fabricantes
desses prprios dispositivos mveis. Essas documentaes esto integralmente disponveis em
1 Manipula
c
ao direta
e uma t
ecnica em que o designer consegue criar uma interface que tenha grande similaridade com o
contexto de uso no ambiente real. Geralmente se obt
em esse efeito quando se consegue mapear graficamente as representac
oes
de objetos em ac
oes, por meio de met
aforas visuais.
14

AO
2.1
pginas oficiais desses fabricantes na Internet e uma sntese delas ser feita neste subcaptulo.
Os demais estudos usados como bases tericas desta dissertao, no contexto de interfaces com
usabilidade em aparelhos mveis, so direcionados principalmente avaliao dessas interfaces, por meio de princpios de design e de heursticas, que sero descritos posteriormente, na
Subseo 2.2. As guidelines encontradas com o propsito de auxiliar o design de interfaces de
dispositivos mveis so listadas a seguir:
1. Destaque a principal atividade da aplicao e garanta os subsdios necessrios para
que o usurio complete qualquer tarefa. Quando o foco da aplicao estabelecido
e mantido na tarefa principal da aplicao, o nvel de satisfao do usurio tende a ser
maior [Apple, 2010]. Em cada tela exibida, verifique a se toda informao sendo exibida
necessria no momento para que o usurio finalize a atividade sendo realizada [Apple,
2010] [Microsoft, 2013]. Em caso negativo, verifique se haver algum momento em que a
informao se tornar crtica. Em caso afirmativo, exiba a informao [Apple, 2010]. Toda
informao necessria para completar uma atividade deve estar visvel na tela [Blackberry,
2012]. Alm disso, a estrutura do contedo deve ser agrupada em pores pequenas e
homogneas de informao [Grasso e Roselli, 2005].
2. Invista os maiores esforos nos fatores da aplicao mais importantes do ponto de
vista do usurio. Em um jogo de videogame, os usurios no esto interessados em
gerenciar contas pessoais ou em gerar e compartilhar contedos, mas sim em interagir com
o jogo com baixos tempos de resposta por meio de um roteiro que os fascinem e por meio
de cenrios atrativos. Contedos que prendem a ateno de usurio podem ser destacados
por meio de efeitos de esmaecimento de controles que no esto sendo usados no momento
[Apple, 2010]. Por exemplo, se o usurio estiver vendo uma imagem no seu dispositivo
mvel, os botes de interao com aplicao podem desaparecer aps certo tempo sem
atividade do usurio, e reaparecerem somente quando a tela do dispositivo tocada.
3. Pense no design da interface como uma atividade a ser preenchida de cima para
baixo. Em smartphones, o topo da tela o local mais visualizado pelo usurio, porque a
interao com o aparelho ocorre enquanto o usurio o segura: com a mo no dominante,
enquanto interage com um dos dedos da outra mo; com mo dominante enquanto interage
com o polegar dessa mo; entre as duas mos, enquanto interage com ambos os polegares
[Hayhoe, 2001]. Por conta disso, as informaes genricas mais importantes devem ser
dispostas no topo de modo que, medida que o usurio desliza a tela para baixo, ele
encontra informaes mais especficas [Apple, 2010]. No disponibilize as funcionalidades
mais frequentemente usadas na parte inferior da tela, tampouco em locais que no estejam
visveis sem que o usurio deslize a tela para baixo [Blackberry, 2012]. Idealmente, toda a
informao deve ficar visvel na tela de uma s vez (Grasso e Roselli, 2005). A quantidade
de operaes de deslizamento para realizar tarefas deve ser limitada, para que o usurio
no se sinta incomodado [Hayhoe, 2001].
4. Disponibilize um caminho lgico para o usurio. Usurios gostam de saber em que
ponto esto da aplicao, por meio de caminhos apresentados na tela. Opes de voltar
so sempre importantes e, sempre que possvel, permita que apenas uma sequncia lgica
seja usada para que uma tela seja acessada [Apple, 2010]. Os relacionamentos entre telas
diferentes devem ser feitos por meio de transies visveis e reas com propsitos diferentes
devem ter aparncias distintas [Google, 2012a].
2.1
15
5. Torne a interao fcil e bvia. O usurio deve entender imediatamente o que deve ser
feito com o aplicativo por meio da interface. O uso de cores pode ser benfico, mas o usurio
tende a assimilar que cores iguais indicam aes anlogas. Datas devem ser exibidas corretamente de acordo com o fuso horrio do usurio, para evitar confuses e interpretaes
erradas [Google, 2012a]. Facilitar o entendimento de texto em dispositivos mveis implica
em exibir frases curtas [Apple, 2010]. Use interaes padres do dispositivo para executar
funcionalidades que sejam consistentes com tais interaes, como a operao de deslizamento lateral para mudar fotos de um lbum. [Blackberry, 2012]. Se possvel, explore
o uso de udio para substituir contedos textuais extensos [Dimakopoulos e Magoulas,
2009], mas d ao usurio a opo de desligar o udio no momento que preferir [Hayhoe,
2001].
6. Facilite a entrada de dados. A entrada de dados costuma demandar muito tempo de interao, de forma que, caso o usurio tenha que fornecer uma grande quantidade de dados
antes que qualquer ao relevante ocorra, provvel que ele se desestimule. Balanceie a
quantidade de dados requeridos com o que a aplicao pode fornecer por meio da interface.
Utilize o componente correto para cada tipo de informao a ser coletada, para minimizar
o tempo de interao e evitar erros do usurio [Apple, 2010]. Os elementos usados na
interface devem sugerir ao usurio como eles devem ser usados [Luchini et al., 2002].
7. Estimule a conectividade e o comportamento colaborativo. Sempre que oportuno, permita que o usurio compartilhe informaes com outras pessoas, tais como a localizao
atual, opinies, resultados, dentre outras. A interface pode permitir que o dispositivo se comunique com outros dispositivos mveis [Apple, 2010]. O design da interface deve levar em
considerao as capacidades tecnolgicas dos aparelhos [Grasso e Roselli, 2005] [Hayhoe,
2001].
8. Torne a interface mais realista possvel. Usurios se sentem mais motivados a interagirem com interfaces que se assemelham com artefatos do mundo real. Por exemplo, o
aplicativo agenda mostrado na Figura 2.3 de fcil entendimento por parecer com uma
agenda de papel. Pense nos objetos do mundo real como oportunidades de comunicao
simples e efetiva com o usurio [Apple, 2010]. Sempre que possvel, permita que aes
sejam assimiladas por meio de metforas, para facilitarem o entendimento [Blackberry,
2012]. Objetos reais so mais divertidos de serem manipulados pelo usurio, o que torna a
interao mais natural por reduzir o esforo cognitivo necessrio para realizar as atividades
[Google, 2012a]. Um exemplo de metfora na Figura 2.3 o boto com o smbolo +, que
sugere a adio de um novo contato agenda eletrnica.
9. D suporte mudana de orientao. As pessoas possuem diferentes preferncias de orientao, que podem se alterar de acordo com a tela com a qual elas interagem. Por conta
disso, crie interfaces que mantenham foco nas atividades e nas informaes mais importantes, independentemente da orientao do dispositivo mvel (retrato ou paisagem). Em
casos que o aplicativo deve funcionar apenas em uma orientao, exibe a interface nessa
orientao, mesmo que o dispositivo esteja noutra orientao, para que o usurio entenda
que ele deve girar o aparelho para interagir com a interface. A mudana de orientao nem
sempre deve significar um simples redimensionamento de contedo. s vezes, ela deve
acarretar em uma total reorganizao do contedo exibido, para atender as expectativas do
usurio.
16

AO
2.1
Figura 2.3: Aplicativo agenda com interface fazendo analogia a uma agenda de papel [Apple, 2010].
10. Mantenha o usurio ciente de qualquer ao. Jamais termine um aplicativo sem avisar o
usurio ou sem que ele tenha escolhido explicitamente encerrar a interao, porque ele tender a imaginar que a aplicao parou de funcionar [Apple, 2010]. Casos excepcionais em
que aes devem ser abortadas devem ser explicados ao usurio por meio de uma interface
clara e elegante que no s explane o problema, mas tambm sugira aes para corrigi-lo
[Blackberry, 2012]. Dilogos e informaes de alerta devem ser exibidos apenas quando o
usurio seleciona uma opo que inicia uma funcionalidade com problemas [Apple, 2010].
11. D controle ao usurio. A interface deve exibir automaticamente o mximo de informao possvel, para evitar que o usurio fornea seus dados dispendiosamente [Apple, 2010]
[Google, 2012a]. Entretanto, deixe claro que o usurio est no controle no aplicativo, permitindo que ele explicite suas preferncias de utilizao e que ele desfaa operaes realizadas
recentemente [Blackberry, 2012].
12. Crie uma pgina de ajuda. importante que haja interfaces especficas para opes de
ajuda ao usurio. Os problemas abordados nessa seo devem ser facilmente encontrados
por meio de buscas. A interface deve permitir a exibio adequada dos passos necessrios
para corrigir os problemas [Blackberry, 2012]. Organize os tpicos de ajuda em uma tabela
de contedos, a partir da qual o usurio possa selecionar um tpico de interesse [Hayhoe,
2001].
13. Aposte em um design minimalista. Elabore uma interface simples, mas de fcil entendimento, por meio de um uso balanceado de elementos e de cores. Use grficos e animaes
para melhorar o entendimento [Blackberry, 2012], mas os evite no momento da inicializao
do aplicativo [Apple, 2010]. Manter a interface simples facilita que diferentes dispositivos
acessem o contedo de forma menos discrepante [Blackberry, 2012].
14. Use imagens e grficos em alta definio e editados profissionalmente. Dedique um
bom tempo de trabalho para a criao do cone do aplicativo, que aparecer ao longo de toda
a interao, porque ele a imagem que ficar na mente do usurio associada aplicao
[Apple, 2010]. Edite imagens e grficos para que gerem impacto visual [Apple, 2010] e
surpreenda o usurio com a beleza das animaes e imagens utilizadas [Google, 2012a].
Efeitos grficos inesperados costumam surpreender o usurio e fazer com que ele pense
que est usando um aplicativo mais robusto do que a mdia [Google, 2012a].
2.2
17
15. Use componentes na medida adequada. Os componentes que precisam ser acessados
com toque precisam ter no mnimo 48dp de altura e de largura, para acomodar o dedo
do usurio adequadamente [Google, 2012a]. Segundo Apple [2010], os componentes para
dispositivos no sistema iOS devem ter 44x44 pontos2 . Um exemplo de design com base nas
medidas propostas por Google [2012a] pode ser visualizado na Figura 2.4.
Figura 2.4: Tela criada com elementos com pelo menos 48dp de altura e de largura. O esquema gr
afico est
a a
`
esquerda, enquanto que a interface final est
aa
` direita [Google, 2012a].
A preocupao de empresas detentoras de sistemas operacionais para dispositivos mveis

divulgarem guidelines para construo de interfaces demonstra que essas documentaes so
importantes para que aplicativos sejam competitivos e desenvolvidos de forma atrativa aos usurios. Entretanto, nota-se que cada conjunto divulgado tem suas particularidades por conta de os
sistemas operacionais serem diferentes, no que se refere aos componentes de interfaces. As empresas Apple, Google (empresa responsvel pelo Android), Microsoft (responsvel pelo Windows
Phone), Blackberry e Nokia (responsvel pelo sistema operacional Symbian) possuem guidelines
para uso dos componentes grficos existentes, os quais possuem nomes e layouts diferentes,
que dificultam o entendimento da documentao por pessoas que no possuem conhecimentos
tcnicos de cada sistema operacional. Um mapeamento desses componentes poder ser contemplado no Captulo 4 deste trabalho de pesquisa, a fim de que um conjunto de guidelines
unificado para design de interfaces possa ser divulgado.
Por serem imperativos, as guidelines so diretos e fceis de serem interpretados, ainda que
difceis de serem seguidos. Outra limitao deles a existncia de fatores subjetivos, de forma
que no se sabe, por exemplo, o grau de sucintez das informaes a serem exibidas ou o grau de
exuberncia das imagens. O bom senso e experincia do designer so fundamentais para que
esses parmetros sejam elucidados.
Guidelines tm uma relao estreita com heursticas de avaliao de usabilidade de interfaces
e, muitas vezes, so escritas com base em heursticas. Entretanto, as heursticas so elaboradas
como subsdio para avaliar uma interface j pronta ou esquematizada (no papel, por exemplo) e
s podem ser usadas por especialistas, ao contrrio das guidelines, que podem ser usadas por
qualquer interessado em criar interfaces com usabilidade. No subcaptulo seguinte, sero realizadas uma sntese do funcionamento da avaliao heurstica e um levantamento das principais
heursticas de usabilidade utilizadas atualmente.
2 As
documentac
oes consultadas n
ao revelam como essas empresas chegaram a esses n
umeros.
18

AO
2.2
Heursticas
2.2
A computao enfrenta grandes desafios relativos a metodologias de design e de avaliao

de interfaces que auxiliem no processo de desenvolvimento de software de qualidade [Bertini
et al., 2006]. Em particular, os mtodos de avaliao de interfaces propem tcnicas diversas
por meio das quais se podem medir a usabilidade, sendo que algumas j parecem consolidadas
[Kjeldskov e Stage, 2004]. Dessas, podem-se citar: avaliaes de desempenho ao se executar
atividades [Gonalves et al., 2011]; avaliaes empricas de tempo [Arhippainen e Thti, 2003]
[Balagtas-Fernandez e Hussmann, 2009] ou de nmero de teclas acessadas ao longo do tempo
[MacKenzie e Zhang, 1999]; entrevistas com usurios [Jones e Marsden, 2006]; questionrios
distribudos aos usurios [Vtj e Roto, 2010] [Bradburn et al., 2004]; avaliaes por meio de
percursos cognitivos no contexto de atividade com o usurio [Blackmon et al., 2002]; observaes
gravadas de interaes realizadas em ambientes reais de utilizao do sistema [Matera et al.,
2006]; simulaes [Hagen et al., 2005]; avaliaes de regras subjetivas por meio de especialistas
[Bertini et al., 2006], dentre outras.
Avaliaes de usabilidade de interfaces so processos que visam garantir, por meio da anlise
dessas interfaces, que o sistema funciona adequadamente e satisfaz as expectativas dos usurios e os requisitos de software elicitados nas fases iniciais do processo de desenvolvimento do
software. Os objetivos dessas avaliaes so examinar a experincia do usurio ao utilizar as
interfaces, avaliar a acessibilidade das funcionalidades disponibilizadas e identificar problemas
de design [Sharp et al., 2007].
Tipicamente, problemas de design identificados precocemente so mais baratos e mais fceis de serem corrigidos do que os identificados em longo prazo [Bertini et al., 2006]. Por conta
disso, avaliaes peridicas de usabilidade devem ser realizadas ao longo do processo de desenvolvimento, cada vez que uma nova verso da interface tiver que ser lanada (por conta de
mudanas de requisitos de sistema, de mudanas de usurio ou de adio de funcionalidades).
A maioria das avaliaes de usabilidade conhecidas realizada na presena dos usurios finais
da aplicao. Nesse modelo de avaliao, podem-se identificar parmetros importantes sobre
o modo pelo qual o usurio final utiliza o sistema, porque os experimentos so conduzidos no
ambiente real de utilizao da interface. Contudo, eles costumam demandar muito tempo para
serem planejados e os custos de realizao dessas avaliaes costumam ser maiores [Kantore,
2011]. Em casos de questionrios serem usados na avaliao, ainda existe o problema de formulao correta das questes, para que as respostas obtidas sejam relevantes para o objetivo
da avaliao [Rothwell, 1993] [Brace, 2004] [Siniscalco e Auriat, 2005]. Apesar de os estudos
sobre avaliaes de interfaces continuarem em aberto, h um consenso de que um dos mtodos
de avaliao mais baratos e rpidos, e que obtm resultados relevantes, a avaliao heurstica
[Bonifcio et al., 2010].
A avaliao heurstica realizada por meio de um conjunto pequeno de especialistas de design
que, separadamente, avaliam a interface confrontando-as com regras, conhecidas como heursticas, para identificar eventuais erros de design que comprometam a usabilidade. Acredita-se
que de trs a cinco avaliadores especialistas sejam capazes de identificar de 75% a 80% dos problemas de usabilidades de interfaces computacionais [Nielsen e Molich, 1990] [Nielsen, 1994].
Provavelmente o conjunto de heursticas mais conhecido pelos estudiosos de mtodos de avaliao de usabilidade de interfaces seja o elaborado por Nielsen [1994], e segue:
1. Visibilidade do status do sistema. O usurio deve estar completamente informado do
que est acontecendo, por meio de feedback imediato da interface.
2. Compatibilidade do sistema com o mundo real. A terminologia deve ser adequada
HEURISTICAS
2.2
19
linguagem do usurio e no orientada ao sistema. As informaes devem ser organizadas

de acordo com o modelo mental do usurio. Segundo Helander [1997], o modelo mental se
refere expectativa que um usurio possui em relao ao comportamento do computador.
3. Controle e liberdade do usurio. Disponibilize sadas de emergncia ao usurio, para
que ele possa desfazer ou refazer aes, a fim de que ele se situe em um ponto recente da
interao.
4. Consistncia e padres. Nunca identifique uma mesma ao por cones ou metforas
diferentes. Elementos similares devem ser usados para propsitos semelhantes, assim
como funcionalidades semelhantes devem possuir uma sequncia de aes semelhantes.
5. Preveno de erros. Idealmente, interfaces no precisam de mensagens de erro por serem
capazes de prevenir que erros ocorram. Aes definitivas podem ter um tratamento anterior
para que o usurio as confirme por meio de checkboxes, por exemplo.
6. Reconhecimento ao invs de lembrana. O usurio no deve precisar memorizar o que
est realizando. Permita que a interface atue como um meio de dialogar com o usurio, em
tempo de execuo.
7. Flexibilidade e eficincia de uso. O sistema deve ser fcil de ser operado por usurios
novatos, mas tambm robusto o suficiente para permitir eficincia de uso a usurio avanados. Teclas de atalho e de comandos por voz podem ser alternativas para tornarem
a interface flexvel. Noutras palavras, flexibilidade implica em permitir que uma mesma
funcionalidade seja realizada por comandos distintos.
8. Esttica e design minimalista. As informaes devem ser sucintas e no devem informar
mais do que os usurios necessitam para realizar a funcionalidade corrente. Os dilogos
do sistema precisam ser diretos e naturais e devem aparecer nos momentos adequados.
9. Ajuda para usurio identificar, diagnosticar e corrigir erros. As mensagens de erros
devem ser claras e simples e no podem intimidar o usurio. Ao contrrio, devem estimullo ao oferecer formas de corrigir o erro.
10. Ajudas (Help) e documentao. Um bom design evita que o usurio tenha que usar opes
de ajuda com frequncia. Entretanto, fundamental que o sistema possua telas especficas
de ajuda, para orientar o usurio em casos de dvidas.
Nitidamente, existe uma dependncia estreita entre as heursticas criadas por Nielsen [1994]
e as diretrizes divulgadas por empresas detentoras de sistemas operacionais para dispositivos
mveis. Entretanto, vlido ressaltar que as heursticas apresentadas no foram criadas tendose a usabilidade de interfaces para computao mvel em mente.
A heurstica que trata a compatibilidade do sistema com o mundo real cita que o design
deve ser elaborado com base no modelo mental do usurio. O modo de pensar do ser humano
objeto de estudo de muitas reas de pesquisa, no s da Interao Humano-Computador, e
fundamental para se entender como se deve desenvolver interfaces com foco no usurio. Rocha
e Baranauskas [2003] explicam que humanos compartilham muitas caractersticas fsicas e psicolgicas, mas so bastante heterogneos em termos de qualidades como habilidades cognitivas
e motivao e acrescentam que essas diferenas individuais tm importncia fundamental no
design da interface de um sistema computacional.
20

AO
2.2
Segundo Sutcliffe [1995], modelos mentais podem tanto ser fsicos como conceituais. Os
primeiros descrevem o relacionamento de objetos no mundo real em termos de distribuio espacial de eventos em um perodo. Podem ser visualizados, especialmente se o problema envolve
raciocnio espacial. Os modelos conceituais, por sua vez, existem em diferentes manifestaes.
So expresses lingusticas superficiais e em uma linguagem interna que, embora baseada na
lingustica, representa uma abstrao futura. Modelos conceituais seriam, portanto, uma espcie de linguagem mental interna que representa valores reais sobre objetos e suas relaes.
Norman [1988] sugere que a forma dos modelos mentais difere entre pessoas e depende de estilos cognitivos pessoais e essa a principal dificuldade ao se tratar de processos mentais para
design de interfaces com usurios.
?] destacam que, em particular, o termo ora se refere ao modelo que o usurio tem do sistema,
outrora ao modelo que o projetista tem do sistema, e outras vezes ao modelo que o projetista ou o
sistema tem do usurio. Portanto, modelo mental do usurio compreende o modelo do sistema,
formado pelos usurios, atravs de experincias e interaes com o sistema e a partir de sua
imagem do sistema.
Segundo Bertini et al. [2006], o conjunto de heursticas elaborado por Jacob Nielsen utilizado como forma de precaver erros de usabilidade e satisfazer requisitos de qualidade de interfaces em vrios domnios de aplicao. Por conseguinte, esperado que tais heursticas tambm
sejam usadas como base cientfica para avaliao de interfaces de dispositivos mveis. Entretanto, os autores ressaltam que, por conta de a interao nesses dispositivos ser muito peculiar,
o ideal que se usem heursticas apropriadas para eles. Por conta dessa necessidade, Bertini
et al. [2006] elaboraram regras prprias para esse fim. O conjunto de heursticas elaborado por
Bertini et al. [2006] como refinamento das regras de Nielsen e adaptao delas para o contexto
de interfaces de computadores mveis contm oito regras, e segue:
1. Visibilidade do status do sistema e facilidade de encontrar o dispositivo mvel. O
sistema deve sempre manter o usurio informado sobre o que est ocorrendo. Alm disso,
o sistema deve dar prioridade a mensagens relativas a aspectos crticos do sistema, como
capacidade da bateria, condies do ambiente de utilizao e informaes de conectividade.
Tendo em vista que dispositivos mveis so perdidos com certa facilidade, medidas de
encriptao de dados devem ser consideradas e o sistema deve prover formas de o usurio
encontrar o dispositivo, caso ele tenha sido esquecido fora de lugar.
2. Compatibilidade entre o sistema e o mundo real. Permita que o usurio entenda a
informao sendo exibida de forma correta, por meio de uma disposio de elementos em
ordem natural e lgica. Sempre que possvel, o sistema deve permitir identificar condies
ambientes locais e informaes de uso automaticamente e exibi-las de forma adequada ao
usurio.
3. Consistncia e mapeamento. O modelo conceitual que o usurio possui acerca da relao
entre funo e interao deve ser consistente com o contexto de utilizao. crucial que
haja um mapeamento adequado entre ao a ser realizada e modo de realizar esta mesma
ao no mundo real.
4. Boa ergonomia e design minimalista. Dispositivos mveis devem ser fceis de manusear
com apenas uma das mos e ser resistentes a degradao por aes do ambiente, como
umidade. Alm disso, nenhuma informao desnecessria deve ser exibida ao usurio.
5. Facilidade de entrada de dados, legibilidade e capacidade de assimilao. Os dispositivos mveis devem prover modos simples para que o usurio informe dados de entrada,
HEURISTICAS
2.2
21
preferencialmente sem que o usurio precise usar as duas mos para executar tal tarefa.
A tela deve possuir todas as informaes visveis ao usurio, independentemente das condies de luminosidade do ambiente. Idealmente, o usurio deve ser capaz de assimilar a
informao sendo exibida imediatamente.
6. Flexibilidade, eficincia de uso e personalizao. Permita que os usurios personalizem
as aes de acordo com as necessidades deles. Sempre que possvel, o sistema deve ser
capaz de sugerir ao usurio formas de personalizar aes que porventura sejam benficas
em algum contexto de utilizao.
7. Convenes estticas, sociais e de privacidade. Leve em considerao aspectos emocionais e estticos dos usurios que utilizaro o dispositivo. Assegure que as informaes
do usurio sero mantidas com segurana e privacidade. As interaes devem respeitar
convenes sociais dos usurios.
8. Gerenciamento de erros realstico. Proteja o usurio dos erros de interao. Se no for
possvel faz-lo, permita que o usurio identifique o erro, o diagnostique e, se possvel,
o corrija. Mensagens de erros devem ser claras e sucintas. Se o erro for irreversvel,
certifique-se que o usurio entender a condio em que ele ocorreu.
Como se percebe, as heursticas de Bertini no consideram apenas aspectos de usabilidade
da interface dos dispositivos, mas tambm aspectos sistmicos e de hardware, o que difere o
trabalho deles do proposto nesta dissertao. Um ponto importante a destacar o aspecto
humano presente na heurstica nmero 7, o qual citado pelos autores no estudo, mas no
aprofundado.
Um trabalho interessante e que aborda heursticas com base em fatores humanos foi realizado por Moraveji e Soesanto [2012], no qual os autores aliam conhecimentos de anos de estudos
empricos acerca de fatores que estressam o usurio quando ele interage com uma interface de
dispositivo mvel aos estudos de Nielsen [1994]. O resultado um conjunto de dez heursticas
que viabilizam que especialistas avaliem interfaces com base em dois propsitos: usabilidade
e potencialidade estressora. Os autores ainda salientam que este provavelmente o nico trabalho com esse propsito que trata de uma metodologia que pode ser seguida na ausncia de
usurios finais.
Por conta de estresse ser muitas vezes um fator subjetivo, algumas interfaces parecem difceis
de serem avaliadas sob a perspectiva de fatores estressores ao usurio. Entretanto, estudos da
Psicologia identificaram alguns padres que auxiliam a identificao desses fatores, o quais
foram sumarizados por Lupien et al. [2007], resultando em quatro caractersticas de elementos
estressores, as quais sero numeradas de C1 a C4 neste documento.
A primeira caracterstica (C1) levantada por Lupien et al. [2007] a de que elementos estressores parecem imprevisveis, incertos ou no familiares em algum contexto. A segunda (C2)
deriva de estudos realizados por Henry e Grim [1990] e diz respeito sensao de que a pessoa
est perdendo o controle da situao. A caracterstica seguinte (C3), identificada por Dienstbier
[1989], a propenso de algo causar perda ou dano ao indivduo, ou seja, o indivduo perde o
sentimento de posse dele por algo. Por fim (C4), Lupien et al. [2007] citam a capacidade de o
elemento representar uma ameaa identidade ou autoestima do indivduo, quando julgada
do ponto de vista social [Dickerson, 2004].
Ao usar as quatro caractersticas estressoras sumarizadas por Lupien et al. [2007] para criar
as dez heursticas para avaliao de interfaces de usurio, Moraveji e Soesanto [2012], assim
22

AO
2.2
como Bertini et al. [2006], acabam sobrepondo algumas heursticas de Nielsen [1994]. Entretanto, ntida a preocupao dos autores em elaborarem regras que mitiguem os aspectos
estressores das interfaces. As dez regras levantadas por Moraveji e Soesanto [2012] so acompanhadas da listagem das caractersticas estressores que elas combatem, e seguem:
1. Capacidade de controlar interrupes (combate C1 e C2). Interrupes imprevisveis
comprometem o controle do usurio sobre a interface. Esse um fator to importante de
ser considerado que existe um ramo da Interao Homem-Computador que estuda especificamente os problemas causados por interrupes [Iqbal e Horvitz, 2007]. Essa heurstica
visa verificar se a interface dispe de formas de bloquear, controlar, ou desabilitar temporariamente interrupes durante apresentaes, ligaes telefnicas, ou durante outras
funcionalidades que demandam ateno do usurio. Opes como No mostrar essa mensagem novamente ou Lembrar-me dessa preferncia no futuro so boas formas de o
usurio controlar interrupes.
2. No sobrecarregar o usurio (combate C2 e C4). Grandes quantidades de dados so
comuns em aplicativos usados por muitos usurios ou que possuam dados armazenados
em servidores Web. Nesses casos, o estresse do usurio est em sentir que ele no capaz
de lidar com a quantidade de informao, de modo que a interao parece que no ter fim.
O usurio pode imaginar que no est usando o aplicativo da forma correta, que no est
conseguindo se comunicar com outros usurios (em casos de programas colaborativos) ou
que no ofereceu a quantidade de dados suficiente para o aplicativo funcionar. Ademais, o
usurio pode se sentir sobrecarregado por telas com muitas opes para serem visualizadas
e/ou preenchidas. Em aplicativos de email, por exemplo, deve-se evitar mostrar vrias
mensagens no lidas de uma s vez.
3. Considerar a percepo de tempo dos seres humanos (combate C1 e C2). A barra de
progresso indica ao usurio o tempo a transcorrer de uma determinada atividade, do ponto
de vista do sistema. Entretanto, a percepo de tempo humana no linear, porque o indivduos tendem a imaginar que o tempo passa mais devagar quanto mais eles esperam por
algo [Harrison et al., 2007]. Esse comportamento da barra de progressos pode gerar imprevisibilidade e falta de controle do momento em que o usurio poder usar o sistema. Uma
forma de amenizar esse problema permitir que processos mais longos iniciem o processamento mais cedo, em paralelo com outras interaes mais leves. Outra alternativa distrair
o usurio com elementos ldicos ou informaes adicionais que sejam interessantes.
4. Usar entonao apropriada (combate C1 e C4). Usurios simpatizam com aplicativos com
comportamento baseados em polidez e reciprocidade [Nass et al., 1994]. Quando o sistema
no capaz de gerar esse comportamento, os usurios tendem a se sentirem constrangidos
pelo tom das mensagens. Por conta disso, importante que os designers se valham de
comunicao que se aproxime da humana, em termos de entonao e de emoo. Alguns
exemplos incluem uso de mensagens bem-humoradas e que fazem apologia ao aplicativo,
como se pode visualizar na Figura 2.5. Pedidos com polidez devem ser preferidos s mensagens imperativas que indicam obrigatoriedade de aes.
5. Prover feedback positivo entrada do usurio e eventos de interao (combate C1 e
C4). Feedback negativo pode causar estresse no sentido de que os usurios podem sentir
que no so capazes de fornecer ao sistema as informaes das quais ele necessita. Esse
tipo de feedback tende a negligenciar a forma natural de conversao entre indivduos, o
HEURISTICAS
2.2
23
Figura 2.5: Exemplo de mensagem de erro bem-humorada.
que pode causar estranheza. O sistema pode informar o usurio de que o problema ocorrido
comum, com mensagens como Outras pessoas cometeram este mesmo equvoco. Sem
problemas. e mostrar mensagens positivas quando o usurio completa uma determinada
tarefa, como Obrigado por preencher nosso formulrio..
6. Estimular interaes sociais (combate C4). Dispor de elementos simples como botes de
curtir ou retwittar ajudam a usurios quebrar barreiras de interao social, por serem
diretas e estarem embutidas na prpria interface.
7. Amenizar a presso ao usurio em relao ao tempo (combate C1, C2 e C4). A maneira
pela qual o usurio se sente estressado por conta da presso imposta pelo tempo bem
documentada por Maule e Hockey [1993], mas ainda no foi aplicada a dispositivos computacionais de modo geral, tampouco para dispositivos mveis. Ao contrrio da heurstica
3, que trata do tempo enquanto o usurio aguarda, essa heurstica considera o tempo enquanto o usurio interage por meio da interface. Usurios tendem a se incomodar e perder
o controle da situao quando so pressionados por tempo para realizarem as atividades.
Em contextos competitivos, eles podem se frustrar ao pensarem que esto realizando as
tarefas mais demoradamente do que outros usurios.
8. Usar elementos naturalmente calmantes (combate C1). Chamar a ateno ou gerar
fascnio ao usurio de forma involuntria por meio de elementos naturais tende a fazer com
que ele se sinta bem, porque os nveis de atividade fisiolgicas do indivduo so alterados de
forma positiva [Ulrich et al., 1991]. Essa heurstica valida se a interface embute elementos
naturais (sons, imagens ou animaes) de forma que o usurio as assimile e as utilize com
facilidade.
9. Esclarecer as aes ao usurio (combate C1 e C2). Em cada interface navegada, o
usurio espera poder resolver uma determinada atividade que, caso esteja desabilitada,
pode gerar irritao e estresse. Nesses casos em que o sistema no pode disponibilizar uma
determinada funcionalidade, a interface deve esclarecer ao usurio o motivo pelo qual a
funcionalidade no pode ser realizada, ou sugerir formas alternativas de o usurio realizar
a atividade.
10. Desmistificar a interface. Usurios podem se estressar quando interfaces o apresentam
uma mirade de escolhas a fazer de uma nica vez. Alm disso, sugerir ao usurio que ele
procure ajuda no sistema pode prejudicar a autoestima dele. De modo a complementar a

AO
24
2.3
heurstica de Ajuda e Documentao proposta por Nielsen [1994], o sistema deve desmistificar os elementos da interface ao usurio, antes que ele tenha que recorrer opo de
Ajuda, como pode ser visto na Figura 2.6.
Figura 2.6: Exemplo de interface desmistificada [Moraveji e Soesanto, 2012].
O ideal seria que os especialistas envolvidos na avaliao tivessem conhecimentos de aspectos

fisiolgicos humanos, que muitas vezes no so dominados por profissionais da Computao.
De qualquer forma, alguns aspectos dos estudos elaborados pelos autores podem ser de grande
importncia para a criao de heursticas mais completas para avaliao de interfaces de dispositivos mveis. Espera-se, nos Resultados desta dissertao, que as heursticas propostas
aliem os pontos positivos de cada heurstica apresentada neste subcaptulo com os demais princpios de usabilidade consolidados na Literatura Cientfica em Interao Humano-Computador,
as quais sero apresentadas no prximo subcaptulo.
2.3
Outros princpios de design
Princpios de design so, a rigor, conjuntos de guidelines genricos para guiar o design. Segundo Preece [1994], guidelines podem ser tanto regras especficas a serem seguidas, quanto
conjuntos genricos de princpios a serem aplicados nos mais diversos domnios. Normalmente,
regras especficas para criao de interfaces com usabilidade derivam de princpios de design
mais genricos, apesar de a relao entre as heursticas apresentadas na subseo 2.2 e os
princpios de design consagrados em Interao Humano-Computador no ser muito especificada em cada heurstica. Neste subcaptulo sero apresentados alguns dos princpios de design
mais conhecidos nessa rea de pesquisa.
Dix et al. [2004] dividem os princpios de design de sistemas interativos, que incluem no
s a interface com o usurio, mas tambm aplicativos comerciais de software e dispositivos
computacionais [Santos, 2008], em trs categorias: aprendizibilidade, flexibilidade e robustez.
Para cada categoria, os autores enumeram um conjunto de princpios menos genricos que
as compem. O princpio de aprendizibilidade se refere capacidade de o sistema interativo
permitir que o usurio aprenda a utiliz-lo em um primeiro momento, para que ele seja capaz
de explorar todas as funcionalidades do sistema com relativa facilidade. Como o tempo de
aprendizagem varia de acordo com o usurio, normalmente a aprendibilidade analisada de
acordo com a eficincia de execuo de atividades pelo usurio [Tullis e Albert, 2010]. Os cinco
princpios especficos que compem a aprendizibilidade so:
1. Previsibilidade. O desejo maior dos usurios de sistemas interativos obter do sistema
OUTROS PRINCIPIOS DE DESIGN
2.3
25
as respostas que eles desejam em relao ao realizada por eles. Geralmente, esse objetivo pode ser alcanado por meio de um planejamento de quais atividades contemplaro
um determinado anseio dos usurios. Em geral, as pessoas so capazes de predizer aes
de acordo com determinadas vivncias que elas tiveram no mundo real. Estendendo-se
esse comportamento humano ao contexto de interao entre pessoas e sistemas interativos, diz-se que sistemas com boa previsibilidade so os que deixam claro ao usurio as
consequncias das aes realizadas por eles.
2. Capacidade de sintetizao. Depois que o usurio executa uma determinada ao,
indispensvel (e crtico) que o sistema o retorne algum feedback. Existem vrias formas de
se realizar esse feedback, mas imprescindvel que ele seja confivel e efetivo no sentido
de que o usurio perceba claramente que mudanas ocorreram no sistema.
3. Familiaridade. Esse princpio diz respeito capacidade de o sistema criar elos entre objetos
ou situaes exibidas ao usurio com objetos ou situaes conhecidas por ele no mundo
real.
4. Consistncia. O uso de elementos de entrada/sada deve ser anlogo para situaes anlogas. O mesmo vale para o comportamento de todo o sistema para situaes parecidas.
5. Generalizao. Esse princpio se refere capacidade de o usurio tomar pores pequenas
do sistema e generaliz-las, para deduzir funcionalidades mais amplas. possvel que em
uma aplicao para desenhar quadrados, o usurio generalize a opo de desenho para
tentar desenhar retngulos, por exemplo.
O conceito de flexibilidade est relacionado multiplicidade de formas com que o sistema e
o usurio trocam informaes, ou seja, o usurio deve dispor de caminhos alternativos para
chegar a um mesmo resultado. Dix et al. [2004] enumeram os cinco princpios a seguir como
formadores do princpio de flexibilidade:
1. Iniciativa de dilogo. evidente que todo sistema deve possuir alguma forma de interagir
com o usurio, a qual caracteriza a forma pela qual eles se comunicam. O cerne desse princpio est em decidir se o sistema ir iniciar esse dilogo, ou se essa tarefa ser realizada
pelo usurio. No existe recomendao formal que opte por uma abordagem em detrimento
da outra. Entretanto, fundamental que o usurio seja capaz de abandonar, suspender ou
continuar uma atividade do sistema a partir de qualquer ponto. comum que abordagens
hbridas de iniciativa de dilogo sejam adotadas em sistemas interativos, para satisfazer
requisitos de funcionalidades e garantir flexibilidade de uso.
2. Multithreading. Relaciona-se capacidade de o usurio realizar mais de uma tarefa concomitantemente. Geralmente o termo mais usado em Interao Humano-Computador para
designar esse comportamento multimodalidade. Usurios podem realizar diferentes tarefas em locais diferentes, abrindo abas distintas para operaes distintas, por exemplo, ou
realiz-las em uma mesma tela de um mesmo dispositivo.
3. Migrao de atividades. Permitir que usurios realizem tarefas rotineiras pode fazer com
que eles se desestimulem por perderem a concentrao, o que aumenta a probabilidade
de erros ao longo da interao. A migrao de atividades se relaciona capacidade de
o sistema realizar atividades que corriqueiramente so de responsabilidade do usurio.
Esse comportamento economiza tempo e diminui a probabilidade de erros. Novamente,
26

AO
2.3
necessrio que se estime quo migrvel pode ser uma determinada funcionalidade, j que
muitas vezes no possvel dispensar totalmente as aes realizadas pelo usurio.
4. Substitutividade. Esse conceito se relaciona possibilidade de usar termos equivalentes
para valores de entrada/sada como, por exemplo, permitir visualizao de temperatura
tanto em graus Celsius quanto em Fahrenheit.
5. Personalizao. Muitos usurios desejam que as interfaces sejam capazes de se adaptarem s suas necessidades. Essa adaptao pode ocorrer tanto por parte do usurio
(adaptabilidade) quanto por parte do sistema (adaptatividade). As customizaes de sistema mais comuns atualmente so a possibilidade de escolha de caractersticas pessoais
ou de criao de atalhos para funcionalidades.
O princpio de robustez enumerado por Dix et al. [2004] se refere ao nvel de suporte oferecido
ao usurio para que ele obtenha sucesso na interao. Esse princpio foi dividido em quatro
princpios menores:
1. Observabilidade. O usurio deve ser capaz de identificar o estado atual da aplicao rapidamente por meio da representao perceptvel da interface. Para tanto, as informaes
contidas na interface devem ser intuitivas e relevantes.
2. Recuperabilidade. Capacidade de o usurio se recuperar de situaes de erros ou desfazlos. O sistema deve permitir que o usurio efetue uma operao de correo sempre que
um erro ocorrer. Alm disso, o usurio deve ser capaz de voltar a uma situao anterior ao
erro. As mensagens de erro devem ser concisas, informativas, especficas e construtivas.
3. Capacidade de resposta. Para efeito de estabilidade, o sistema deve garantir o oferecimento
de respostas rpidas ao usurio, a fim de que ele no se sinta confuso enquanto realiza uma
determinada atividade. Alm disso, espera-se que o sistema notifique o usurio de alguma
forma, aps ele ter solicitado uma determinada ao. Esse comportamento importante
para que o usurio tenha a garantia de que o sistema est cuidando da solicitao por ele
enviada.
4. Conformidade de realizao de atividades. Refere-se ao grau de suporte que o sistema
oferece ao usurio em relao s tarefas que ele pode realizar e maneira pela qual ele
pretende realiz-las.
Em um contexto mais genrico, no se limitando apenas ao design de sistemas interativos,
Williams [2005] elaborou um conjunto de princpios que ele considera bsicos em qualquer obra
de design, aos quais ele abreviou como CARP: contraste, alinhamento, repetio e proximidade.
O princpio de contraste prega que elementos importantes devem ter contraste em relao
aos demais, principalmente em relao ao fundo. O olho humano tem tendncia a repousar
sobre elementos que esto deslocados do padro e esse pode ser um fator importante de se
explorar quando se elabora uma interface. O contraste de um elemento pode ocorrer por meio
da alterao do seu tamanho, da adio de textura, da mudana da sua orientao ou da sua
forma, da colorizao ou da alterao do posicionamento padro entre outros.
O princpio de alinhamento atenta para que elementos visuais no sejam dispostos de qualquer forma, mas sim de maneira alinhada. Elementos anlogos colocados de forma alinhada
facilitam a compreenso porque permitem que o usurio visualize os elementos de forma linear, de forma mais confortvel aos olhos. Um exemplo de interface com bom alinhamento de
elementos pode ser verificado na Figura 2.7.
OUTROS PRINCIPIOS DE DESIGN
2.3
27
Figura 2.7: Exemplo bem sucedido de aplicaca

o do princpio CARP de alinhamento a uma p
agina Web.
A repetio utilizada no design para criar uma ncora visual. Ela responsvel pela facilidade de se mudar de um elemento para outro, em uma determinada interface. Alm disso,
elementos repetidos sugerem que eles fazem parte de um mesmo grupo, o que facilita a interpretao. Os blocos com ttulo do texto e resumo, imagens direita e links no cabealho de
cada bloco da interface presente na Figura 2.8 formam um exemplo de repetio bem sucedido,
porque o usurio consegue identificar os elementos principais de cada mensagem da mesma
forma. Por esse exemplo, nota-se que o conceito de repetio tem ligao com o princpio de
consistncia de interfaces, abordado por Dix et al. [2004].
Figura 2.8: Exemplo bem sucedido de aplicaca

o do princpio CARP de repetic
ao a uma p
agina Web.
Por fim, o princpio de proximidade visa garantir que elementos relacionados estejam prximos, ao passo que a distncia entre elementos sem relao deve ser maior. Esse princpio ajuda
a manter a unidade e ordem do layout.
Novamente, os princpios devem ser aplicados em conformidade com o contexto de aplicao. O contraste no pode, por exemplo, interromper o processo natural de leitura de um texto
por meio da alterao do tamanho das letras utilizadas em determinadas palavras. O design
sempre deve levar em considerao as restries dos usurios e do dispositivo a ser utilizado.
A complexidade do processo de criao de interfaces deve ser gerenciada ao longo do processo

AO
28
2.4
Figura 2.9: Processo de design. [Dix et al., 2004]
de desenvolvimento, por meio de prottipos com interfaces por meio das quais se avalia a usabilidade. Uma sumarizao do processo de design elaborada por Dix et al. [2004] pode ser
visualizada na Figura 2.9.
2.4
Consideraes finais
Algumas das tcnicas para destacar elementos da interface citadas por Shneiderman e Plaisant [2009] podem ser consideradas contorversas atualmente, porque a aplicao delas pode
atrair a ateno do usurio para pontos secundrios da interface. So os casos do efeito de
vdeo inverso e do pisca-pisca. Inverter as cores do elemento com o fundo da interface pode
causar uma grande estranheza ao usurio e gerar falhas de consistncia na interface. O efeito
pisca-pisca em elementos pouco sutis da interface causam irritao ao usurio e deve ser evitado.
Shneiderman e Plaisant [2009] explicam que a entrada de dados uma das tarefas que mais
demanda tempo ao usurio, mas essa no uma informao vlida para todos os casos. Alguns
aplicativos precisam de poucos dados para funcionarem corretamente e a entrada de dados
uma tarefa rpida de ser realizada. Da mesma forma, a entrada de dados tem relao direta com
a experincia do usurio.
As heursticas propostas neste trabalho tm relao com as recomendaes propostas neste
captulo, mas nenhum mapeamento explcito entre as heursticas e as recomendaes realizado.
Captulo
3
Metodologia de Pesquisa
Neste captulo explicam-se as atividades realizadas para que os resultados da pesquisa fossem obtidos. A metodologia de pesquisa inicial para a execuo deste trabalho foi exploratria.
Trata-se de uma modalidade de pesquisa em que o pesquisador visa aprofundar seus conhecimentos sobre o tema estudado atravs de leituras de artigos, peridicos e livros relacionados
[Mattar, 1999].
A leitura desses estudos muito importante para a formao terica do pesquisador e permite
que ele enriquea seu potencial crtico-cientfico. Tendo em vista que estudos so divulgados
ao longo dos anos, importante que o estudante esteja ciente das atualizaes referentes a
trabalhos relacionados pesquisa dele. Logo, a primeira atividade da Metodologia de Trabalho
tambm a mais extensa e compreende essa anlise bibliogrfica. Os estudos mais importantes
acerca do tema pesquisado esto reportados no Captulo 2.
Por meio da leitura dos trabalhos relacionados, nota-se que a criao de heursticas e de diretrizes para construo de interfaces com usabilidade para aplicativos mveis uma contribuio
importante para a Interao Humano-Computador. Entretanto, apenas um conhecimento terico atualizado acerca do tema de usabilidade dessas interfaces no suficiente para que se
comece a planejar novas heursticas. A experincia de uso de programas em dispositivos mveis
igualmente importante e serve como base prtica para confrontar as teorias aprendidas. Por
conta disso, realizou-se um perodo de experimentao de quatro aplicativos baseados em Android, por um perodo de um ms, para identificar alguns problemas comuns de usabilidade das
interfaces desses aplicativos. A experimentao desses aplicativos foi realizada por inspeo em
dois dispositivos mveis distintos, a fim de encontrar problemas de usabilidade e de categorizlos. Algumas dessas categorias no eram claramente identificadas nas heursticas de Nielsen e
justificavam a criao de novas heursticas para a avaliao de interfaces de dispositivos mveis.
Em mtodos de inspeo de usabilidade os avaliadores examinam aspectos relacionados a
usabilidade de uma interface com objetivo de encontrar problemas de usabilidade. Os avaliadores podem ser especialistas em usabilidade, consultores de desenvolvimento de software,
especialistas em um determinado padro de interface, usurios finais, dentre outros [Rocha e
Baranauskas, 2003].
29
30
METODOLOGIA DE PESQUISA
3.1
A verso de heursticas criada aps a etapa de inspeo foi discutida juntamente com outros
cinco especialistas de usabilidade em uma sesso de brainstorming, a fim de verificar possveis
melhorias do conjunto por meio de modificaes das descries ou de incluso de princpios de
usabilidade que no haviam sido considerados para a proposio das heursticas iniciais. Em
seguida uma nova sesso de brainstorming foi marcada com os mesmos espcialistas para que
uma segunda verso das heursticas fosse criada.
A segunda verso de heursticas foi validada por meio de avaliaes heursticas de um aplicativo criado para o sistema operacional Android por cinco especialistas de usabilidade. Para
analisar a efetividade dessas avaliaes, esse mesmo aplicativo foi avaliado por meio de avaliaes heursticas que usaram as heursticas de Niesen, por outros cinco especialistas.
A ordem das atividades realizadas ao longo deste projeto de pesquisa a seguinte:
1. Inspeo de quatro aplicativos baseados no sistema operacional Android, para identificar
problemas de usabilidade, verificar que as heuristicas de Nielsen no permitem identificar
todos esses problemas, e propor um conjunto inicial de heursticas;
2. Brainstorming com especialistas em usabilidade para refinar o conjunto inicial de heursticas e propor melhorias para uma segunda verso;
3. Nova sesso de brainstorming com os mesmos especialistas em usabilidade para refinar a
segunda verso de heursticas;
4. Avaliao heurstica de um aplicativo de dispositivo mvel baseado no sistema operacional
Android em um tablet de 10,1, utilizando as heursticas tradicionais de Nielsen;
5. Avaliao heurstica desse mesmo aplicativo utilizando a segunda verso de heursticas
para avaliao de usabilidade de interfaces de dispositivos mveis, proposta aps a segunda
sesso de brainstorming;
6. Anlise dos resultados das avaliaes heursticas para decidir por melhorias no conjunto
de heursticas proposto;
7. Teste desse mesmo aplicativo baseado em Android com usurios finais utilizando o tablet
usado pelos especialialistas, para confrontar os problemas desses usurios com os problemas de usabilidade encontrados nas avaliaes heursticas realizadas;
8. Avaliao heurstica de outro aplicativo para dispositivo mvel em diferentes dispositivos
mveis, utilizando as heursticas para avaliao de usabilidade de interfaces de dispositivo
mvel;
9. Criao de diretrizes genricas para design de interfaces de dispositivos mveis com base
em seus componentes de entrada.
A listagem de tarefas propostas permitiu dividir o trabalho do projeto em trs grandes etapas: proposio das heursticas para avaliao de interfaces de dispositivos mveis com base
no fato de as heursticas de Nielsen terem se mostrado falhas para este propsito, validao
dessas heursticas, e criao das diretrizes para design de interfaces de dispositivos mveis. O
detalhamento das atividades realizadas, separados de acordo com cada etapa do processo, ser
dado nas prximas sees.
DAS HEURISTICAS
ELABORAC
AO
3.1
3.1
3.1.1
31
Elaborao das heursticas

Anlise de aplicativos para Android
Incialmente, o mestrando atuou como usurio de quatro aplicativos famosos da loja virtual
de produtos para Android ao longo de quinze dias, a fim de listar as dificuldades encontradas
acerca da usabilidade da interface. Os aplicativos escolhidos foram instalados no incio de agosto
de 2012 em dois dispositivos baseados em Android: um smartphone Samsung Galaxy 5 I5500
com tela de 2.8 e um tablet Motorola XOOM com tela de 10.1, ambos com tecnologia sensvel
ao toque. Esses dispositivos podem ser visualizados na Figura 3.1.
` esquerda, smartphone I5500

Figura 3.1: Dispositivos usados na fase de uso de aplicativos baseados em Android. A
` direita, tablet XOOM da Motorola.
da Samsung. A
Os aplicativos escolhidos para anlise foram Facebook, Twitter, Gmail e Foursquare, por
conta de o propsito de cada um deles divergir e por conta da popularidade que eles possuem.
Na ocasio da instalao, todos esses aplicativos estavam entre os 10 mais instalados por meio
da loja de aplicativos Android, o Google Play [Google, 2012b].
A avaliao da usabilidade dos aplicativos foi realizada por inspeo, a partir de listagens das
funcionalidades principais de cada aplicativo testado. Essa listagem foi obtida das pginas Web
oficiais dos aplicativos. A relao entre cada aplicativo e as funcionalidades principais que ele
oferece pode ser visualizada na Tabela 3.1. Evidentemente, cada funcionalidade listada abrange
uma srie de passos necessrios para que ela seja realizada. Analogamente, possvel que na
mesma tela da funcionalidade existam opes de realizar atividades menores.
O mtodo de inspeo utilizado conhecido como simulao de uso, tambm chamado de
reviso por especialista. Nesse mtodo, especialistas simulam o comportamento de usurios
com menos experincia a fim de antecipar-se aos problemas de usabilidade que possam encontrar ou de identific-los medida que eles aparecem [Preece, 1994].
A primeira semana da quinzena de avaliao caracterizou-se pela utilizao dos aplicativos
no tablet. vlido destacar que o avaliador j tinha conhecimento acerca do funcionamento das
verses Web do Facebook, do Gmail e do Twitter antes de test-los nas suas respectivas verses
para Android. Contudo, nenhum dos aplicativos havia sido usado pelo especialista no contexto
de dispositivos mveis, de forma que o primeiro dia da anlise fora usado apenas para navegao
pelos aplicativos, a fim de que se aprendesse a usar as funcionalidades principais. O mestrando
j tinha utilizado celulares e tablets sensveis ao toque no momento da avaliao. medida que
problemas de usabilidade eram encontrados, eles eram anotados como forma de documentao,
pelo prprio avaliador.
Na segunda semana, as mesmas atividades foram realizadas por meio dos aplicativos instalados no smartphone. A documentao com os problemas encontrados no tablet foram revisitados
para validar se eles tambm ocorriam nas interfaces do smartphone.
32
3.1
Ao fim das duas avaliaes, obteve-se um documento nico com os problemas encontrados, o
qual foi analisado de modo a categorizar problemas de usabilidade encontrados. As categorias de
problemas encontrados por meio da inspeo por simulao dos aplicativos foram confrontadas
com as heursticas de Nielsen para identificar que havia dificuldade de associar algumas dessas
categorias a heursticas de Nielsen.
3.1.2
Acerca dos aplicativos inspecionados
O Facebook uma rede social que, de acordo com sua pgina oficial na Internet, conecta
mais de um bilho de usurios desde dezembro de 2012. O objetivo inicial dessa rede social
era criar um ambiente colaborativo de envio e recebimento de mensagens, mas ela se expandiu
e hoje basicamente qualquer contedo multimdia pode ser compartilhado pela rede, alm de
ser possvel criar e navegar por grupos com propsitos especficos e por pginas de eventos. O
aplicativo conta ainda com uma opo de chat para troca de mensagens instantneas entre
usurios conectados.
O Twitter se define em sua pgina Web oficial como uma rede de informaes em tempo real,
por meio da qual os usurios se conectam com as ltimas histrias, ideias, opinies e notcias
sobre o que eles achem mais interessantes. Ao contrrio do que ocorre no Facebook, os usurios
no tm um sistema prtico de trocas de mensagens e as mensagens publicadas tm tamanho
limitado de caracteres (Twitter Inc, 2013).
O Gmail, por sua vez, um servio de correio eletrnico que permite que vrias contas sejam
gerenciadas simultaneamente, por meio de notificaes do prprio aplicativo. o servio de
email mais popular da loja do Google Play [Google, 2012b].
Por fim, escolheu-se o aplicativo do Foursquare, rede social que permite que pessoas compartilhem informaes diversas sobre locais. Essas informaes incluem espao fsico, endereo,
recomendaes dos servios, custos dos servios prestados pelo estabelecimento, dentre outros.
O ponto forte desse aplicativo o uso de recursos de localizao geogrfica do dispositivo (por
meio de GPS ou pela Internet) para sugerir locais prximos ao usurio que lhe oferecem servios dos quais ele gosta. Por meio desse sistema de localizao, ele permite reunir pessoas
geograficamente prximas.
Como se percebe, os propsitos dos aplicativos so variados: a primeira d acesso a uma
rede social abrangente que permite compartilhar basicamente contedo; a segunda uma rede
social que permite compartilhar mensagens rpidas; a terceira um servidor de emails; a ltima
d acesso a uma uma rede social que permite reunir pessoas fisicamente.
Tabela 3.1: Relaca
o entre aplicativos avaliados e principais funcionalidades que cada um deles oferece.
Aplicativo
Principais funcionalidades
Facebook
Adicionar um amigo; curtir a postagem de outrem; compartilhar a postagem

de outrem; comentar uma postagem; visualizar arquivos de um grupo; visualizar fotos de um amigo; adicionar fotos a um lbum; visualizar postagens
no prprio mural; visualizar postagens no mural de outra pessoa; buscar pessoas; usar servio de chat.
Twitter
Seguir um usurio; visualizar seu prprio mural de informaes; visualizar

o mural de informaes de um usurio que voc segue; visualizar o mural de
um usurio qualquer; escrever uma mensagem para seus seguidores; escrever
uma mensagem para uma pessoa que voc segue; buscar informaes acerca
de uma hashtag; visualizar assuntos mais comentados na rede.
Continua na pgina seguinte. . .
DAS HEURISTICAS
VALIDAC
AO
3.2
33
Tabela 3.1 Continuao.

Aplicativo
Gmail
Principais funcionalidades
Visualizar contedo dos emails; marcar email como no-lido; remover email;
arquivar email; buscar email; encaminhar um email; criar filtros.
Foursquare
Realizar check-in, para informar a prpria localizao; adicionar amigos; adicionar lugares; adicionar comentrios a lugares; visualizar pessoas nos arredores; visualizar lugares nos arredores.
3.1.3 Brainstorming com especialistas

As categorias de problemas encontrados por meio da inspeo por simulao dos aplicativos
motivaram a proposio de heursticas para a avaliao de interfaces de dispositivos mveis,
por conta das dificuldades de se associarem determinadas categorias s heursticas de Nielsen.
As associaes categoria/heurstica realizadas sem dificuldades resultaram em heursticas para
interfaces de dispostivos mveis parecidas com as heursticas de Nielsen equivalentes. Por outro
lado, as categorias isoladas deram origem a heursticas especficas com descries especficas. O
resultado desse processo foi um conjunto inicial de heursticas, o qual foi discutido na primeira
sesso de brainstorming.
Uma sesso de brainstorming caracterizada pela reunio de um grupo de at 20 pessoas,
na qual todos os envolvidos sabem os objetivos da discusso e os problemas a serem resolvidos.
Trata-se de uma discusso informal em que todas as pessoas apresentam sugestes e as discutem, a fim de que se obtenham solues para o problema acordado. O mtodo muito usado
em ambientes corporativos, mas podem ser estendidos ao mbito educacional [Coyne e Coyne,
2011] deste trabalho.
Os especialistas envolvidos nas sesses de brainstorming para a criao das heursticas tinham conhecimento dos principais estudos de usabilidade conhecidos. Trs deles eram doutorandos e dois eram mestrandos no mesmo laboratrio de pesquisa do mestrando.
Os primeiros 15 minutos da primeira sesso de discusso foram utilizados na exposio dos
resultados das avaliaes obtidas pelo uso dos quatro aplicativos nos dois dispositivos mveis
citados. Cada heurstica proposta foi explicada e discutida entre os membros da sesso para
se decidir pela validade dela no contexto desejado. Algumas heursticas foram fundidas, outras
foram mudadas e algumas simplesmente foram eliminadas. Ao fim dessa sesso, os especialistas
ajudaram o avaliador com sugestes leitura de novos artigos.
Os princpios abordados nos artigos sugeridos foram usados para elaborar a segunda verso
das heursticas. Em seguida, uma nova sesso de brainstorming foi agendada com os mesmos
especialistas presentes primeira sesso. Analogamente ao que j havia sido discutido na
primeira sesso, as heursticas sofreram novas mudanas, que as deixaram preparadas para
serem avaliadas com outros aplicativos por outros especialistas. Por preparadas, entende-se
que as heursticas foram levadas a um patamar no qual a pesquisa bibliogrfica acerca do tema
se tornara exaustiva e nenhum problema adicional pudera ser identificado pelos especialistas
que participaram da discusso.
Com o fim da segunda sesso de brainstorming, finaliza-se a primeira etapa desta Metodologia
de Pesquisa.
3.2
3.2.1
Validao das heursticas

Avaliaes heursticas
Essa etapa se caracteriza pela aplicao de avaliaes heursticas em aplicativos de dispositivos mveis, para validar a adequao (ou no) das heursticas propostas para avaliao de
34
3.2
usabilidade de interfaces desses dispositivos. Foram escolhidos dois aplicativos para serem avaliados, sendo que um deles foi desenvolvido no Laboratrio de Sistemas Web e Multimdia do
Instituto de Cincias Matemticas e de Computao (ICMC), da Universidade de So Paulo em
So Carlos, ao passo que o outro foi obtido da loja virtual de aplicativos para Android.
O aplicativo desenvolvido no ICMC tem por objetivo realizar anotaes multimdia em vdeo.
Ele funciona da seguinte maneira:
1. Identifica-se o usurio que ir navegar pelo aplicativo. Os nomes que aparecem para o
usurio so relativos s contas do Google sincronizadas com o dispositivo.
2. Escolhe-se o vdeo que se deseja visualizar.
3. Identificam-se os autores dos quais se desejam ver as anotaes desse vdeo.
4. Anota-se o vdeo.
As anotaes de um autor so disponibilizadas a outrem caso o autor compartilhe suas anotaes por meio do aplicativo. Ao selecionar a opo de compartilhamento, o autor envia um
arquivo com suas anotaes a um ou mais destinatrios, a fim de que eles possam visualiz-las
em seus prprios dispositivos mveis.
As anotaes realizadas pelo usurio podem ser textuais, de udio ou de tinta eletrnica.
Para realizar uma anotao textual, o usurio tecla sobre uma rea de texto, que ativa o teclado
do sistema operacional para que a mensagem seja digitada. A anotao de tinta feita passandose o dedo na rea do prprio vdeo, mas precisa ser habilitada teclando-se sobre o boto Ink
Annotation is Off que, aps a habilitao, passa a se chamar Ink Annotation is On. O udio
ambiente gravado como anotao depois de o usurio habilitar essa funcionalidade no aplicativo, teclando o boto Audio Annotation is Off. Todo o aplicativo est em Ingls e no se pode
trocar o idioma. As telas desse sistema podem ser visualizadas nas Figuras 3.2, 3.3, 3.4, 3.5
e 3.6.
Figura 3.2: Tela inicial do aplicativo de anotaca

o multimdia em vdeos.
A avaliao heurstica do aplicativo de anotaes multimdia foi realizada por dez especialistas
em usabilidade, todos com conhecimento do sistema operacional Android e com experincia
com dispositivos touchscreen. Cinco especialistas avaliaram o aplicativo usando o conjunto de
heursticas tradicionais de Nielsen, enquanto que os outros cinco o avaliaram usando o conjunto
de heursticas proposto para interfaces de dispositivos mveis. Apenas dois especialistas nunca
DAS HEURISTICAS
VALIDAC
AO
3.2
35
Figura 3.3: Tela para selec

ao de usu
ario que ir
a navegar pelo aplicativo de anotaca
o multimdia.
Figura 3.4: Tela para selec

ao de vdeo a ser anotado.
haviam usado um tablet. Desses dois, um avaliou o sistema usando as heursticas de Nielsen e
o outro o avaliou com novas heursticas.
As sesses de avaliao foram agendadas individualmente com cada especialista. Antes de
iniciar a avaliao, explicava-se sobre o aplicativo a ser avaliado, deixava-se o especialista navegar pelas interfaces e, ento, uma tabela contendo as heursticas a serem usadas e suas
respectivas descries era oferecida ao especialista. Os problemas reportados pelo especialista
ao longo da navegao pelas telas do sistema, bem como as heursticas com as quais esses
problemas se relacionavam, eram anotados pelo mestrando em uma tabela.
Os especialistas ficaram livres para executarem a avaliao no tempo que quisessem. Caso
eles no tivessem passado por todas as telas no aplicativo, o mestrando intervinha e os mostrava
os fluxos de atividades que remanesciam inexplorados, para garantir que todas as interfaces
seriam visualizadas pelo especialista.
Todos os problemas reportados pelo especialista foram anotados pelo mestrando. Aps cada
avaliao, o especialista era convidado pelo mestrando a responder, para cada problema encontrado, o grau de severidade associado a ele. O grau de severidade uma escala de 0 a 4
elaborada por Nielsen [1994], que visa aferir a gravidade dos problemas encontrados de acordo
com as seguintes descries:
1. Eu no concordo que isso seja um problema de usabilidade;
2. Problema cosmtico: deve ser corrigido apenas em caso de haver tempo extra no projeto
para tal;
3. Problema de usabilidade menor: a correo desse problema uma tarefa de baixa priori-
36
3.2
Figura 3.5: Tela em que o usu

ario escolhe o autor do vdeo a ser anotado.
Figura 3.6: Tela principal da aplicaca

o de anotaca
o de vdeos.
dade;
4. Problema de usabilidade maior: importante que esse problema seja corrigido e tratado
com grande prioridade;
5. Catstrofe de usabilidade: obrigatrio corrigir o problema antes que o produto seja liberado.
Segundo Nielsen [1994], no se pode ocupar o especialista questionando-o acerca dos graus
de severidade de cada problema encontrado durante a avaliao heurstica, porque ele tende a
perder a concentrao no processo e encontra menos erros do que encontraria caso no tivesse
que se preocupar em indicar as severidades dos problemas. Por conta disso que se optou por
perguntar os graus de severidade apenas depois de o especialista ter terminado a avaliao
heurstica.
Os resultados obtidos nas avaliaes foram separados de acordo com o conjunto de heursticas utilizado, a fim de que eles fossem comparados. Esse processo de comparao e os
resultados obtidos sero expostos no prximo captulo.
DAS HEURISTICAS
VALIDAC
AO
3.2
3.2.2
37
Testes com usurios
A anlise dos resultados das heursticas foi importante para identificar se elas poderiam
ser melhoradas. Completado esse procedimento, dois experimentos foram realizados com dois
usurios da aplicao, que tentaram executar as principais funcionalidades do aplicativo sem
nunca t-lo visto antes.
Um dos usurios escolhido era novato e o outro era intermedirio. O usurio novato escolhido
nunca havia usado dispositivo mvel sensvel ao toque. A nica tela com essa tecnologia que
ele conhecia era a do terminal de autoatendimento bancrio que ele utilizava. Alm disso, esse
usurio nunca havia usado tablets ou smartphones. O usurio intermedirio, por sua vez,
possua um smartphone sensvel ao toque equipado com o sistema operacional Windows Phone
e j havia utilizado smartphones e tablets equipados com Android. Ambos os usurios tinham
fluncia em Ingls, idioma no qual o aplicativo foi escrito.
O objetivo desses experimentos com usurios calcular o desempenho e a taxa de erros cometidos pelos usurios ao executar cada uma das funcionalidades principais, a fim de confrontar
os problemas encontrados pelos usurios com os problemas levantados pelos especialistas nas
avaliaes heursticas. As aes dos usurios foram escritas em um arquivo no carto de memria do dispositivo, para que as mtricas sejam calculadas com exatido. Alm disso, as sesses
experimentais foram gravadas em vdeo, para que se identificassem erros que o arquivo no reporta e para que se tivesse noo exata do tempo que o usurio levou para finalizar uma tarefa,
j que cada tarefa era ditada pelo avaliador e o tempo desse ditado no pde ser identificado
pelo arquivo na memria do dispositivo, devendo ser descontado da interao para clculo do
desempenho do usurio.
O arquivo de gravao contm informaes textuais referentes s aes realizadas pelo usurio em cada momento da interao, tais como cliques sobre botes, realizao de anotaes,
cancelamento de aes, etc. O procedimento para gravao dessas informaes, assim como de
outras informaes necessrias para o clculo das mtricas, foi implementado pelo mestrando e
ser mostrado no Captulo 4, assim como a estruturao dos arquivos usados.
O ambiente de experimentao dos usurios foi formado apenas por uma cadeira, na qual
o usurio se sentava enquanto tentava realizar as funcionalidades que lhe eram ditadas pelo
avaliador, que tambm realizava a filmagem. O aplicativo j estava aberto na pgina inicial para
que o usurio pudesse utiliz-lo. Antes de se iniciar o experimento, a nica informao que o
usurio recebeu foi a seguinte:
O aplicativo que voc ir utilizar tem o propsito de realizar anotaes de tinta, de udio e
de texto em um vdeo que voc escolher. Por anotao de tinta, entenda um desenho que voc ir
adicionar a uma determinada cena desse vdeo. Anotaes de udio so gravaes de udio que
voc poder fazer em uma determinada cena. Uma anotao de texto se refere a uma legenda
textual que voc poder adicionar a uma cena do vdeo escolhido.
Ciente do propsito do aplicativo, o usurio era orientado a tentar realizar cada funcionalidade que lhe era requisitada, a saber:
1. Escolher um vdeo qualquer;
2. Inserir uma legenda em uma cena do vdeo;
3. Desenhar sobre uma cena do vdeo;
4. Realizar uma gravao de udio em uma cena do vdeo;
5. Visualizar a cena que contm a legenda que foi inserida;
38
3.3
6. Editar a legenda feita cena do vdeo;

7. Inserir um novo desenho sobre uma cena;
8. Realizar uma nova gravao de udio;
9. Ouvir um dos udios gravados;
10. Apagar o ltimo desenho realizado;
11. Apagar a legenda inserida;
12. Apagar um dos udios gravados.
3.2.3
Avaliaes em outros dispositivos mveis
O mestrando no teve contato com o aplicativo de anotaes no momento da criao das heursticas. Contudo, entende-se que a fundamentao cientfica das novas heursticas se tornaria
mais forte caso outro aplicativo fosse avaliado em diferentes dispositivos, inclusive de diferentes
sistemas computacionais. O estudo de Bertini et al. [2006], por exemplo, revelou que as heursticas propostas por esses autores revelaram mais problemas que as heursticas de Nielsen, mas
no se consegue concluir se as heursticas foram elaboradas com foco no propsito do aplicativo
avaliado, o que certamente teria acrescentado vis aos resultados.
Por conta disso, terminada a etapa de experimentao com o usurio, passou-se para a
fase de realizao de uma avaliao heurstica usando as heursticas novas para analisar as
interfaces de um aplicativo externo ao laboratrio de pesquisa do ICMC, consolidado em verses
para dispositivos mveis. O aplicativo escolhido para essa anlise foi o UOL Notcias, criado
pelo portal de notcias brasileiro UOL como uma alternativa do usurio para acompanhar as
principais notcias do Brasil e do mundo. A escolha dele para o experimento se justifica pela
relevncia do portal no Brasil e pelo fato de ele possuir verses nos sistemas operacionais iOS,
Android e Windows Phone. A popularidade do aplicativo tamanha que sua verso para Android
j foi instalada em mais 500 mil dispositivos equipados com esse sistema operacional [Google,
2012b].
O UOL Notcias foi avaliado com as heursticas novas nos smartphones iPhone 4S com tela
de 3,5 e Motorola Blur com tela de 3,7 e no tablet Motorola XOOM de 10,1. Aps a etapa de
avaliao heurstica do UOL Notcias, iniciou-se a etapa de criao de diretrizes para a criao de
interfaces com bom uso dos componentes existentes para interagir com o usurio. Esse processo
ser discutido no subcaptulo 3.3.
3.3
Elaborao das guidelines (diretrizes)
As guidelines foram elaboradas utilizando-se as documentaes oficiais presentes nas pginas Web das empresas detentoras dos sistemas operacionais Android, Blackberry, iOS e WindowsPhone.
Cada uma dessas empresas disponibiliza um conjunto de guidelines para o design de aplicativos com base no uso adequado dos componentes de interface existentes nos respectivos
sistemas operacionais, a fim de que o usurio disponha do mximo de usabilidade possvel. Por
exemplo, para o design de um componente de dilogo com o usurio, a documentao do Android explicita as seguintes recomendaes: evite usar barras de ttulos em dilogos; mostre ao
usurio perguntas completas acerca da atividade a ser elucidada.
interessante que as empresas produtoras dos sistemas operacionais mais usados da atualidade se preocupem em documentar por meio de recomendaes o que se deve e o que no se
DAS GUIDELINES (DIRETRIZES)

ELABORAC
AO
3.3
39
deve fazer ao escolher um componente para uma interface. Contudo, nota-se que a terminologia
usada para designar esses componentes varia sensivelmente de acordo com cada fabricante, o
que dificulta que pessoas sem conhecimento especfico em um sistema operacional use os componentes corretos para criar uma interface com o usurio. Alm disso, alguns elementos de
um dado sistema operacional simplesmente no existem em outro sistema, o que pode levar um
designer a criar interfaces inconsistentes ou impossveis de serem implementadas.
Por conta desses problemas, uma anlise das documentaes supracitadas foi realizada. Para
cada elemento abordado em uma documentao, procurou-se o seu equivalente na documentao dos demais sistemas operacionais. Por exemplo, botes so chamados de Buttons em
todas as referncias encontradas. Entretanto, barras de progresso possuem nomes diferentes
de acordo com os sistemas operacionais.
Aps a etapa de mapeamento dos componentes, realizou-se a fuso das diretrizes para cada
componente, para gerar as diretrizes gerais. Houve casos de alguns componentes que s possuam recomendaes em um ou em alguns sistemas, mas no em todos. Nesses casos, o
componente foi considerado de forma que apenas as recomendaes existentes fossem usadas
para as diretrizes finais.
Para facilitar o entendimento do documento de diretrizes gerais, optou-se por expor cada
recomendao de acordo com um nico formato. Dessa forma, o documento final ficou com
uma estrutura bem definida e fcil de ser consultada.
Alguns componentes possuem potencialidades maiores em um dado sistema operacional do
que em outro. Isso significa que eventualmente impossvel criar interfaces idnticas para todos
os sistemas operacionais consultados. Por conta disso, acrescentou-se ao documento final, para
cada componente de interface que possusse distines de comportamentos entre sistemas, uma
seo intitulada Casos especficos, na qual as peculiaridades desse componente so expostas,
assim como as diretrizes que so intrnsecas a ele. Essa distino possibilita que o designer tome
cincia de formas de potencializar a usabilidade da interface de acordo com o sistema operacional
para o qual ele deseja criar as interfaces. As diretrizes para um determinado componente seguem
o formato da Figura 3.7.
Figura 3.7: Formato das diretrizes para criaca

o de interfaces de dispositivos m
oveis.
Tendo em vista que neste ponto do estudo os resultados das avaliaes heursticas j so
conhecidos, novas diretrizes foram elaboradas para serem usadas de acordo com cada compo-
40
3.4
nente, a fim de enriquecer o documento final. O documento resultante desse processo pode ser
contemplado no Captulo 4. Por fim, ressalva-se que as documentaes individuais de cada componente de cada sistema operacional estudado no foram embutidas no captulo terico deste
trabalho, porque elas o estenderiam desnecessariamente, j que todas elas seriam reexibidas no
Captulo 4.
3.4
Consideraes finais
A categorizao de problemas de usabilidade levou em considerao os problemas relacionados interface encontrados pelo mestrando, que possui limitaes e potencialidades que outros
avaliadores eventualmente no teriam. Quando avaliaes de usabilidade so realizadas, o prprio avaliador pode representar um agente de vis aos resultados, por conta de vrios aspectos
que so difceis de serem analisados no momento dessas avaliaes, como alteraes de humor, cansao, conhecimento tcnico acerca do assunto, experincia em avaliao de aplicativos
anlogos, etc. Apesar de o mestrando ter-se preparado por meio de um forte embasamento
torico obtido pela metodologia exploratria de pesquisa e de os fatores de cansao e de humor
no terem afetado os resultados obtidos por conta do longo perodo de dias de experimentao,
no possvel afirmar que as categorias obtidas so as melhores possveis. Provavelmente, a
colaborao de outro espacialista pudesse resultar na identificao de outras categorias. De
qualquer forma, os resultados que sero apresentados no Captulo 4 evidenciaram que as heursticas propostas foram eficazes para a identificao de problemas de usabilidade de interfaces
de dispositivos mveis.
Captulo
4
Resultados obtidos
Neste captulo so mostrados os resultados obtidos ao longo da execuo das atividades

expostas na Metodologia de Pesquisa (captulo 3). Para facilitar o entendimento, as informaes
esto estruturadas de forma anloga estruturao da Metodologia utilizada.
4.1
4.1.1
Proposio das heursticas

Anlise de aplicativos para Android
Os aplicativos analisados neste estudo para a verificao da inadequao das heursticas de

Nielsen para a avaliao de usabilidade de interfaces de dispositivos mveis foram Facebook,
Foursqure, Gmail e Twitter para que se encontrassem problemas de usabilidade que deram
origem s heursticas a propostas neste trabalho. Ao longo da interao com cada aplicativo, os
problemas encontrados foram documentados e associados a uma categoria de problema. Essas
informaes esto documentadas nas Tabelas 4.1, 4.2, 4.3 e 4.4. As letras que aparecem frente
da descrio de cada problema indicam o dispositivo no qual ele foi verificado. Nesse sentido,
a letra S indica que o problema foi identificado no smartphone Galaxy I5500, ao passo que a
letra T indica que ele foi verificado enquanto se usava o aplicativo no tablet Motorola XOOM.
Tabela 4.1: Categorizaca
o dos problemas encontrados nas interfaces do Facebook.
FACEBOOK
Problema
Categoria
Na tela Find friends, o boto skip que aparece antes da mensagem
Facilidade de acesso funciona-
principal, no canto superior direito, to pequeno que pode passar
lidade; Visibilidade da informa-
despercebido. (S)
o presente na tela.
Na tela Find freinds, o boto skip, no canto superior direito, apa-
Disposio do componente de
rece antes da mensagem principal, que importante. O usurio pode
interface; visibilidade da infor-
pressionar o boto sem ter lido a mensagem. (S, T)
mao presente na tela.

41
42
4.1
RESULTADOS OBTIDOS

Problema
Categoria
Na tela principal do usurio, as opes de navegao visveis so
Visibilidade das interaes pos-
About, Photos e Friends, obrigando que o usurio deslize o dedo
sveis.
sobre os itens para descobrir que existem outros disponveis, mas que
no esto sendo mostrados. (S)
As fotos publicadas no mural do usurio so ampliadas quando ele toca
Visibilidade da informao pre-
sobre elas, mas no se pode mover a imagem para ver pontos espec-
sente na tela (no caso, a ima-
ficos, o que eventualmente impossibilita a visualizao de detalhes da
gem).
imagem. (S, T)
necessrio que as letras das mensagens no celular sejam menores,
por conta do tamanho da tela.
lidade.
Contudo, quando a mensagem re-
presenta um linktextual para outra pgina, tal como ocorre na Web

quando se usa computadores pessoais, o usurio tem dificuldade de
assimilar que a mensagem tem funcionalidade de um link, porque
no diferenciao do texto com as mensagens meramente informativas.
(S)
Geralmente so colocadas quatro miniaturas de fotos na tela do celu-
Visibilidade da informao pre-
lar, tornando impossvel que o usurio as identifique com clareza. Em
sente na tela; aproveitamento de
paisagem, elas so visualizadas corretamente, mas em paisagem elas
espao de acordo com a orienta-
se tornam ilegveis. (S)
o.
O menu de opes lateral contm muitas opes em listas separadas
por categorias. Acontece que cada categoria contm 3 subcategorias
lidade.
mostra, fazendo com que os ltimos registros sejam encontrados com

dificuldade, apenas depois de vrias operaes de rolagem. Os submenus poderiam estar ocultos e aparecerem apenas quando o usurio
tocasse sobre os respectivos menus. (S)
A notificao de nova mensagem adequadamente discreta e acompa-
nhada de uma vibrao do aparelho. Contudo, caso a notificao seja
lidade; Feedback visvel e fcil
de uma conversa que est acontecendo, a conversa no atualizada
de ser interpretado; preveno
automaticamente, causando dvidas. Alm disso, a notificao some
de erros.
em instantes, permitindo que o usurio nem leia a mensagem. (S)

A opo de carregar uma foto do sistema operacional ou da mquina
Facilidade de acesso funcio-
definitivamente no se parece com um boto, porque ele se confunde
nalidade; adequao do compo-
com o restante da mensagem. (S)
nente funcionalidade.
O aplicativo informa quantas atualizaes o usurio ainda no viu, mas
Feedback fcil de ser interpre-
quando o usurio visualiza uma delas, todas as outras ficam desmarca-
tado e com escopo local (apenas
das, como se ele j as tivesse visto. O usurio precisa memorizar quais
na atualizao que foi vista); Mi-
atualizaes ele j viu, para executar corretamente essa funcionalidade.
nimizao da carga de memria
(S, T)
do usurio.
Ao comentar sobre uma atualizao do mural, o teclado do sistema
Visibilidade
oculta a atualizao, fazendo com que o usurio perca o contato visual
presentes na tela; bom aprovei-
com a mensagem sobre a qual ele est comentando. (S)
tamento do espao da tela.
Documentos postados em grupos no possuem barras de rolagem. Esse
comportamento impede que o usurio estime o tamanho do documento.
tado.
das
informaes
(S, T)
Documentos postados no grupo no permitem aumento do tamanho da
letra. (S, T)
tado.
DAS HEURISTICAS
PROPOSIC
AO
4.1
43

Problema
Categoria
O feedback do sistema quando se curte uma mensagem muito dis-
creto, porque o boto sequer muda de cor e nenhuma mensagem apa-
tado; facilidade de acesso fun-
rece. (S, T)
cionalidade.
As fotos do mural aparecem picotadas e o zoom permitido no capaz
Visibilidade
de exibir o que falta da imagem. (S, T)
presentes na tela.
No tablet, sobra espao em todas as bordas do aplicativo. Mesmo assim,
Bom aproveitamento do espao
todas as imagens do mural aparecem cortadas. (T)
da tela.
necessrio realizar uma operao de deslizamento com o dedo sobre
Visibilidade das interaes pos-
o comentrio para que a opo de remoo aparea. O usurio tem que
sveis; Facilidade de acesso
adivinhar que esta interao possvel. (S, T)
funcionalidade.
Existem pginas que possuem barra de rolagem e pginas que no as
Padronizao da interface.
das
informaes
possuem. (S, T)
Tela de mensagens mostra uma miniatura da foto para cada mensagem,
Design minimalista; bom apro-
ao invs de mostrar uma nica vez para um grupo de mensagens feitas
veitamento de espao.
pelo mesmo usurio. (S)

O campo para escrever comentrio a respeito de uma mensagem
Bom aproveitamento de espao
muito distante da mensagem e fora de onde o usurio est observando.

(T)

o dos problemas encontrados nas interfaces do Foursquare.
FOURSQUARE
Problema
Categoria
Campo de senha no permite que o usurio a visualize. (S, T)
Facilidade da entrada de dados.
O boto Learn more in our policy deveria ser mais chamativo. Apesar
de no ter um bom tamanho, ele no possui bordas e o contraste em
lidade; facilidade de entrada de
relao ao fundo muito pequeno. (S, T)
dados.
Opo de logout extremamente difcil de ser encontrada. (S, T)
Facilidade de acesso funcionalidade.
As solicitaes de amizade no podem ser aceitas todas de uma vez.
Adequao do componente
Opes anlogas devem aparecer em componentes de mltipla escolha
funcionalidade.
para facilitar a atividade. (S, T)

O problema anterior agravado porque a pgina atualizada comple-
Facilidade de entrada de da-
tamente toda vez que o usurio toca sobre um dos botes de Accept,
dos; Feedback sem escopo lo-
para aceitar as amizades. Isso implica que, quando o usurio tem mais
cal (atualiza-se toda a pgina, ao
de uma solicitao para aprovar, ele precisa encontrar o ponto em que
invs de se atualizar apenas o
estava a cada atualizao. (S, T)
componente selecionado).
O corao para sinalizar a operao anloga ao Like do Facebook no
Linguagem do usurio; compa-
uma boa metfora. (S, T)
tibilidade entre componente e

funcionalidade.

o dos problemas encontrados nas interfaces do Gmail.
GMAIL
Problema
O campo escrever email muito pequeno. (S)
Categoria
Facilidade de entrada de dados.
44
4.1
RESULTADOS OBTIDOS

Problema
Categoria
Falta informar o usurio que ele realizou determinada tarefa, com uma
mensagem de rodap. (S)
tado.
O nome do remetente muitas vezes no cabe na tela e, mesmo quando o
Visibilidade de toda a informa-
usurio tecla sobre o nome para visualiz-lo, o nome no exibido por
o da tela; ajuda e documenta-
completo. (S)
o.
Telas que aparecem com mensagens de texto muito pequenas precisam
Personalizao; Visibilidade de
de uma opo de aumento ou de personalizao pelo usurio. (S)
toda informao da tela.
Os botes para alternar entre mensagens so muito prximos e podem
Aproveitamento de espao da
ser tocados erroneamente. (T)
tela.
Boto Inbox acima do cabealho da mensagem para direcionar para
a caixa de entrada, mas na verdade um indicador do filtro ao qual a
funcionalidade; clareza e objeti-
mensagem pertence. (T)
vidade da mensagem.
Usurio no sabe a funcionalidade do boto mute, porque no h
Ajuda e documentao;
explicao sobre isso. (S, T)
back fcil de ser interpretado.
Aps executar a funcionalidade mute, o usurio s consegue revert-
Preveno de erros; recuperao
la por alguns segundos seguintes. Depois a opo desaparece. (S, T)
do estado anterior do sistema.
Ao mostrar as mensagens mais antigas, a tela desorganiza a ordem de
Padronizao da interface; con-
mensagens lidas/no-lidas que aparecia anteriormente. As mensagens
sistncia da interface.
feed-
ficam embaralhadas. (S, T)

Quando se abre uma mensagem recebida, aparecem trs botes acima
da mensagem. Os dois primeiros exibem exatamente a mesma tela. No
funcionalidade; design minima-
entendi a diferena entre eles. (S, T)
lista; ajuda e documentao.
Alm do movimento de deslizamento de dedo para exibir mensagem se-
Clareza da interao; facilidade
guinte, aplicativo poderia disponibilizar dois botes, para evitar que o
de entrada de dados; minimi-
usurio volte para tela principal vrias vezes, caso ele no perceba a
zao da carga de memria do
possibilidade dessa interao. (S, T)
usurio.
Ao arquivar uma mensagem, o boto de desfazer aparece no rodap da
pgina sem muito contraste e com transparncia em relao ao fundo.
tado; preveno de erros; reto-
(S,T)
mada ao estado anterior do sistema.
O boto que volta para a caixa de entrada um desenho que no au-
Preveno de erros; retomada ao
toexplicativo. O usurio direcionado quela tela, mas tem dificuldade
estado anterior do sistema; ade-
para retomar a mensagem que estava lendo. (S, T)
quao do componente funcionalidade.
O boto Show all labels no mostra nada quando os rtulos (labels)
j esto na tela. O usurio pode no saber o que o aplicativo chama
tado.
de label. Portanto, seria vlido que um destaque sobre os elementos

fosse realizado. (T)

o dos problemas encontrados nas interfaces do Twitter.
TWITTER
Problema
Categoria
Na tela de login, o boto sign up fica no canto superior direito. Nessa
Clareza do mapeamento entre
posio, parece que ele no est relacionado ao contedo central, como
componente e informao.
ocorre com o boto de login abaixo do contedo, como deve ser. (S, T)
DAS HEURISTICAS
PROPOSIC
AO
4.1
45

Problema
Categoria
O boto de busca do Twitter no busca informaes da pgina corrente,
mas sim de todo o twitter, mesmo que eu estja na tela que mostra o
componente e informao; dis-
mural de outra pessoa. (S, T)
posio dos componentes da interface.
Quando se marca uma pessoa em uma mensagem, a lista de dicas de
pessoas a serem marcadas impossvel de manusear porque s possui

duas linhas e o dispositivo no capaz de interpretar a operao de
deslizamento de dedo com to pouco espao. (S, T)
A metfora do pssaro com o smbolo + frente no significa nada ao
Adequao do componente ao
usurio novato. Ele pode teclar sobre esse boto sem querer e seguir
usurio; Adequao do compo-
uma pessoa que ela no gostaria de seguir. (S, T)
A tela Retweeted by tem o boto do canto direito muito distante do
nome ao qual ele se associa, no canto esquerdo. A noo de alinha-
componente e informao; bom
mento fica prejudicada. (T)
aproveitamento de espao da
tela.
O boto ao lado do boto Follow abre um popup que no possui boto
Preveno de erros; minimiza-
para voltar. (S, T)
o da carga de memria do
usurio.
Quando um usurio no possui nenhuma lista de pessoas que seguem,
o aplicativo deveria informar que no h o que mostrar, ao invs de
tado; preveno de erros.
mostrar uma tela branca sem interao alguma como o usurio. (S, T)
Algumas informaes solicitam que o usurio escolha um aplicativo ex-
Aplicao deve ser autocontida.
terno para que a mensagem seja lida. (S, T)
Os resultados das Tabelas 4.1 a 4.4 foram agrupados para se identificarem as categorias
distintas de problemas encontrados. Ao todo, 19 categorias foram identificadas.
Evidentemente, no sensato que um conjunto com tantas heursticas seja considerado para
uma avaliao, porque os especialistas levariam muito tempo para associar os problemas das interfaces s heursticas. Alm disso, algumas das categorias possuem similaridades, que podem
causar redundncia. Tendo em vista que, em uma avaliao heurstica, cada regra acompanhada por uma descrio textual, conveio que essas redundncias fossem suprimidas por meio
do agrupamento das heursticas e redao precisa das descries. As categorias distintas, resultantes das anlises das Tabelas 4.1 a 4.4, esto associadas s heursticas de Nielsen que
as identificam na Tabela 4.5 a seguir. Por meio dessa tabela, nota-se que algumas categorias
no puderam ser associadas s heursticas de Nielsen (clulas em branco). Outras foram associadas com dificuldade, de forma que a associao foi aproximada. Essas dificuldades indicam
que existem limitaes das heursticas de Nielsen para a avaliao de interfaces de dispositivos
mveis.
Tabela 4.5: Associaca
o das categorias encontradas a
`s heursticas de Nielsen
Categoria
Heurstica de Nielsen
Aproveitamento de espao na tela, de acordo com a
6. Reconhecimento ao invs de lembrana (Associa-
orientao.
o aproximada).
Consistncia da interface.
4. Consistncia e padres.
Padronizao da interface.
4. Consistncia e padres.
Visibilidade da informao presente na tela.
6. Reconhecimento ao invs de lembrana.

46
4.1
RESULTADOS OBTIDOS

Categoria
Heurstica de Nielsen
Adequao do componente funcionalidade.

Clareza do mapeamento entre componente e informao.
Disposio do componente de interface.
8. Esttica e design minimalista.
Clareza e objetividade da mensagem.
2. Compatibilidade do sistema com o mundo real.
Linguagem do usurio.
2. Compatibilidade do sistema com o mundo real.
Preveno de erros.
9. Ajudar o usurio a reconhecer, diagnosticar e

corrigir erros.
Recuperao do estado anterior do sistema.
3. Controle e liberdade do usurio.

9. Ajudar o usurio a reconhecer, diagnosticar e
corrigir erros.
6. Reconhecimento ao invs de lembrana (Associao aproximada).
Facilidade de acesso funcionalidade
Visibilidade das interaes possveis

Feedback fcil de ser interpretado e com escopo lo-
1. Visibilidade do status do sistema.
cal.
Aplicao deve ser autocontida.
Ajuda e documentao.
10. Ajuda e documentao.
Minimizao da carga de memria do usurio.
5. Preveno de erros.
Personalizao
7. Flexibilidade e eficincia de uso.
O mapeamento realizado entre categoria e heurstica de Nielsen revelou que algumas cateorias se relacionavam s mesmas heursticas. Por conta disso, notou-se a necessidade de agrupar
algumas das categorias obtidas. Da mesma forma, algumas categorias compartilharam as mesmas solues para a resoluo de problemas associados a elas e, por conta disso, tambm foram
agrupadas para a proposio de uma mesma heurstica. Os resultados desses agrupamentos
esto expostos a seguir. frente de cada categoria obtida, identifica-se a heurstica para interfaces de dispositivos mveis qual ela foi associada, de forma abreviada (a letra H abreviao
para heurstica).
1. Aproveitamento de espao na tela, de acordo com a orientao (H1);
2. Consistncia da interface (H2);
3. Padronizao da interface (H2);
4. Visibilidade da informao presente na tela (H3);
5. Adequao do componente funcionalidade (H4);
6. Clareza do mapeamento entre componente e informao (H4);
7. Disposio do componente de interface (H4);
8. Clareza e objetividade da mensagem (H5);
9. Linguagem do usurio (H5);
10. Preveno de erros (H6);
DAS HEURISTICAS
PROPOSIC
AO
4.1
47
11. Recuperao do estado anterior do sistema (H6);

12. Facilidade de entrada de dados (H7);
13. Facilidade de acesso funcionalidade (H8);
14. Visibilidade das interaes possveis (H8);
15. Feedback fcil de ser interpretado e com escopo local (H9);
16. Aplicao deve ser autocontida (H10);
17. Ajuda e documentao (H11);
18. Minimizao da carga de memria do usurio (H12);
19. Personalizao (H13).
Agrupadas as categorias encontradas, apenas se redigiram as respectivas descries das heursticas propostas. Esse processo deu origem primeira verso das heursticas para avaliao
de usabilidade de interfaces de dispositivos mveis, presentes na Tabela 4.6.
Tabela 4.6: Primeira vers
ao das heursticas para avaliaca
o da usabilidade de interfaces de dispositivos m
oveis.
Heurstica
1.
Descrio
Bom aproveitamento
do espao da tela,
de
O design deve ser realizado de forma que os itens no fiquem muito distantes,
nem muito colados. Espaamentos de margens no podem ser grandes, para
acordo com a orientao.
melhorar a visibilidade das informaes.
2. Padronizao dos com-
A aplicao deve manter os componentes no mesmo lugar ao longo de toda a
ponentes da interface.
interao, para facilitar a aprendizagem do usurio ao estimular a memria

de curto prazo. A metfora de cada componente ou funcionalidade deve ser
nica ao longo da aplicao.
3. Visibilidade de toda a
Todas as informaes devem ser visveis e legveis, mesmo em retrato e em pai-
informao existente.
sagem. Isso tambm vale para mdias, que devem de ser vistas ou executadas
na ntegra.
4. Adequao do compo-
O usurio deve saber exatamente o que ele deve colocar como entrada a um
componente, sem que haja ambiguidades ou dvidas. Metforas de funcionalidades devem ser compreendidas sem dificuldades.
5. Adequao da mensa-
A aplicao deve falar a linguagem do usurio. As instrues para executar as
gem.
funcionalidades devem ser claras e objetivas.
6.
Preveno de erros
O sistema deve ser capaz de se antecipar a uma situao que leve a algum erro
e retomada rpida ao l-
por parte do usurio com base em alguma atividade j realizada pelo usurio.
timo estado estvel.
Quando um erro ocorrer, a aplicao deve avisar o usurio prontamente e

retornar ao ltimo estado estvel do aplicativo.
7. Facilidade de entrada
A forma com que o usurio fornece os dados pode se basear em tecnologias
de dados.
assistivas, mas a aplicao deve sempre mostrar com legibilidade o que est
sendo digitado, para que o usurio tenha total controle da situao. O usurio
deve conseguir fornecer os dados requeridos de forma prtica.
8. Facilidade de acesso a
As funcionalidades principais da aplicao devem ser realizadas com maior
todas as funcionalidades.
facilidade possvel, preferencialmente em apenas uma interao. Nenhuma

funcionalidade deve ser difcil de encontrar na interface da aplicao. Todos
os componentes de entrada devem ser assimilados com facilidade.
48
4.1
RESULTADOS OBTIDOS

Heurstica
Descrio
9. Feedback fcil de ser
O feedback deve ser fcil de ser notado, para que no haja dvidas de que a
notado e com escopo lo-
operao foi realizada ou ela ainda est em andamento. Atualizaes locais
cal.
na pgina devem ser priorizadas, para evitar recarregamento e perda do ponto

em que o usurio estava.
10. Aplicao deve ser au-
A aplicao deve conter todas as funcionalidades e informaes embutidas
tocontida.
nela, sem a necessidade de encaminhar o usurio para programas externos.
11. Ajuda e documenta-
O aplicativo deve possuir opo de Ajuda para especificar os problemas co-
o.
muns e as formas de solucion-los. Os assuntos considerados nessa opo

devem ser fceis de serem encontrados.
12. Minimizao da carga
A interface no pode exigir que o usurio se recorde de aes realizadas ante-
de memria do usurio.
riormente. Tudo que o usurio precisa para finalizar uma atividade deve estar
contido na interface sendo visualizada.
13. Personalizao.
A interface deve permitir opes de configuraes pessoais dos usurios, como

aumentos do tamanho das letras, disposio de elementos na tela, etc.
4.1.2 Brainstorming com especialistas

A primeira atividade da primeira sesso de brainstorming com cinco especialistas foi uma
exposio do contedo pesquisado. Esses estudos foram os mesmos expostos no Captulo 2,
com exceo dos trabalhos de aspectos estressores de interfaces [Moraveji e Soesanto, 2012] e
de aspectos de design criados por Williams [2005], que no foram expostos.
As discusses subsequentes exposio da teoria usada para a primeira verso das heursticas resultaram em algumas alteraes importantes dessa verso inicial. As heursticas foram
analisadas individualmente, na ordem em que aparecem na Tabela 4.6.
Na primeira heurstica, decidiu-se que a descrio seria mudada para Bom aproveitamento
do espao da tela e que a instruo de adequao entre as vises em retrato e em paisagem
seriam transferias para a coluna de descrio da heurstica.
O nome da segunda heurstica foi mudado para Consistncia e padres da interface, para
que se criasse uma concordncia perfeita com a heurstica de Nielsen que trata desse mesmo
aspecto. Alm disso, adicionou-se descrio a informao de que funcionalidades anlogas
devem ser realizadas de formas anlogas, para facilitao do aprendizado.
A terceira heurstica foi mudada para Visibilidade e acesso fcil a toda informao existente,
para enfatizar que a visualizao de componentes no suficiente para a boa usabilidade da
interface.
Na sexta heurstica, acrescentou-se descrio a informao de que, caso o aplicativo no
consiga retomar ao ltimo estado estvel, ele deve passar o controle ao usurio, para que ele
decida o que fazer.
A oitava heurstica teve a sentena Todos os componentes de entrada devem ser assimilados
com facilidade retirada da descrio, porque se concluiu que essa instruo estava implcita
na heurstica Adequao do componente funcionalidade. Ademais, o nome da heurstica foi
alterado para Facilidade de acesso s funcionalidades.
A preferncia por um feedback local foi retirada da descrio da heurstica 9 e mantida
apenas em sua respectiva descrio.
A heurstica 10 foi descartada. Os envolvidos no brainstorming destacaram que aplicativos de
dispositivos mveis corriqueiramente precisam de permisso do usurio para se comunicarem
com aplicativos externos e que esse um comportamento tpico da prpria interao, especialmente em casos de aplicativos gratuitos que possuem referncias a contedos publicitrios.
DAS HEURISTICAS
PROPOSIC
AO
4.1
49
A heurstica 13 foi descartada, porque se considerou que as informaes pertinentes a ela

poderia ser acrescida heurstica Visibilidade e acesso fcil de toda informao existente.
As heursticas 4, 5, 7, 11 e 12 se mantiveram inalteradas aps a primeira reunio.
Uma deciso dos especialistas afetou a criao da segunda verso das heursticas. Segundo
eles, seria imprescindvel que os estudos de Moraveji e Soesanto [2012] e de Williams [2005]
acerca de estressores de interfaces e de boas prticas para o design, respectivamente, fossem
considerados para a nova verso.
A segunda sesso de brainstorming se caracterizou pela discusso dos aspectos importantes
de cada uma das pesquisas sugeridas pelos especialistas, que foram acrescidas pelo mestrando
aps a primeira reunio. Aps essa discusso, decidiu-se acrescentar a informao de que uma
mesma funcionalidade poderia ser acessada e executada de mais de uma forma, para facilitar
a usabilidade por usurios mais experientes, heurstica Facilidade de acesso s funcionalidades. Ao fim das discusses, obteve-se a Tabela 4.7, a qual foi usada para as avaliaes
heursticas pelos especialistas, na etapa de validao. Nessa tabela, as partes negritadas das
descries correspondem aos aspectos tericos dos estudos sugeridos pelos especialistas e que
complementaram a verso anterior das heursticas.
Tabela 4.7: Segunda vers
ao das heursticas para avaliaca
o de usabilidade de interfaces de dispositivos m
oveis.
Heurstica
1.
Bom aproveitamento
do espao da tela
Descrio
Independentemente da orientao do dispositivo, o design deve ser realizado
de forma que os itens no fiquem muito distantes, nem muito juntos. Elementos relacionados devem estar prximos e os sem relacionamento devem
estar mais afastados. Interfaces no devem estar carregadas com muitos
elementos.
2. Consistncia e padres
A aplicao deve manter os componentes no mesmo lugar e na mesma confi-
da interface.
gurao ao longo de toda a interao, para facilitar a aprendizagem. Funcionalidades anlogas devem possuir interaes anlogas, por meio de atividades
parecidas. As caractersticas de cada componente (seu tamanho, fonte, cor,
etc.) devem permanecer os mesmos em toda a aplicao.
3.
Visibilidade e acesso
Todas as informaes devem ser visveis e legveis, tanto em retrato quanto
fcil a toda informao
em paisagem. O usurio no deve se esforar para encontrar ou entender
existente.
qualquer informao sendo transmitida. Isso tambm vale para mdias, que
devem de ser vistas ou executadas na ntegra. Os elementos da interface
devem possuir contraste e elementos de um mesmo grupo de informaes
devem ter alinhamento adequado.
4.
Adequao entre o
O usurio deve saber exatamente o que ele deve colocar como entrada a um
componente e sua funcio-
componente, sem que haja ambiguidades ou dvidas. Metforas de funciona-
nalidade.
lidades devem ser compreendidas sem dificuldades.
5. Adequao de mensa-
A aplicao deve falar a linguagem do usurio e as instrues para executar
gem funcionalidade e ao
as funcionalidades devem ser claras e objetivas. A leitura deve ser natural e
usurio.
a linguagem no deve ser invasiva no sentido de obrigar o usurio a fazer

algo.
50
4.2
RESULTADOS OBTIDOS

Heurstica
Descrio
Preveno de erros
O sistema deve ser capaz de se antecipar a uma situao que leve a algum erro
e retomada rpida ao l-
por parte do usurio com base em alguma atividade j realizada pelo usurio.
timo estado estvel.
Quando um erro ocorrer, a aplicao deve avisar o usurio prontamente e
6.
retornar ao ltimo estado estvel. Em casos em que o retorno ao ltimo

estado seja difcil, o sistema pode transferir o controle para o usurio,
para que este decida o que fazer (para onde ir).
7. Facilidade de entrada
A forma com que o usurio fornece os dados pode se basear em tecnologias
de dados.
assistivas (dispositivos que se conectam ao dispositivo mvel para garantirem

acessibilidade a usurios), mas a aplicao deve sempre mostrar claramente
o que est sendo solicitado, por meio de texto, udio, vdeo etc., para que o
usurio tenha total controle da situao.
8. Facilidade de acesso s
As funcionalidades principais da aplicao devem ser realizadas com maior
funcionalidades.
facilidade possvel, preferencialmente em apenas uma interao. Alm disso,

Elas devem ter evidncia na interface. As funcionalidades mais frequentes podem ser realizadas por mais de um caminho ou por meio de atalhos. Nenhuma
funcionalidade deve ser difcil de encontrar na interface da aplicao.
9.
Feedback imediato e
fcil de ser notado.
O feedback deve ser fcil de ser notado, para que no haja dvidas de que
a operao foi realizada ou est em andamento. Atualizaes locais na pgina devem ser priorizadas, para evitar recarregamento e perda do ponto em
que o usurio estava. Mensagens que aparecem muitas vezes devem ter
opo de serem ocultadas pelo usurio. Barras de progresso demoradas
devem permitir que o usurio continue executando outras atividades.
Feedbacks positivos devem ser visveis, mas no exigir interao redundante com o usurio, para no estress-lo.
O aplicativo deve possuir opo de Ajuda para especificar os problemas co-
o.
muns e as formas de solucion-los. Os assuntos considerados nessa opo

devem ser fceis de serem encontrados.
11. Minimizao da carga
Aplicaes devem permitir que o usurio obtenha a informao de que precisa
de Memria do usurio.
com facilidade, sem exigir que o usurio memorize passos anteriores para
completar uma atividade.
4.2
4.2.1
Validao das heursticas

Avaliaes heursticas do aplicativo de anotaes multimdia
As heursticas foram validadas por meio de avaliaes heursticas com 10 especialistas, sendo
que cinco deles utilizaram as heursticas tradicionais de Nielsen para validao de interfaces
interativas e os demais usaram as novas heursticas propostas na Seo 4.1.2.
Os resultados referentes s avaliaes heursticas do aplicativo de anotaes multimdia desenvolvido no ICMC esto estruturados em tabelas deste subcaptulo. Cada tabela possui um
cabealho que identifica o avaliador. Alm disso, relacionam-se o problema encontrado, as heursticas com as quais ele foi relacionado e o grau de severidade. Os primeiros resultados a serem
mostrados compreendem os especialistas que usaram os princpios de Nielsen para avaliarem o
aplicativo de anotaes. Antes de cada sesso de avaliao, cada especialista recebeu uma tabela com as 10 heursticas de Nielsen, para que elas pudessem ser relacionadas aos problemas
encontrados. A tabela mostrada a esses avaliadores idntica Tabela 4.8 e representa uma
transcrio das heursticas revisadas de Nielsen [1994], tal qual se encontra na obra de Rocha e
Baranauskas [2003].
DAS HEURISTICAS
VALIDAC
AO
4.2
51
Tabela 4.8: Heursticas revisadas de Nielsen traduzidas por Rocha e Baranauskas [2003].
Heurstica
Descrio
1. Visibilidade do status
Sistema precisa manter os usurios informados sobre o que est acontecendo,
do sistema.
fornecendo um feedback adequado dentro de um tempo razovel.
2.
Compatibilidade do
Sistema precisa falar a linguagem do usurio, com palavras, frases e concei-
sistema com o mundo
tos familiares ao usurio, ao invs de termos orientados ao sistema. Seguir
real.
convenes do mundo real, fazendo com que a informao aparea em uma

ordem natural e lgica.
3. Controle e liberdade do
Usurios frequentemente escolhem por engano funes do sistema e precisam
usurio.
ter claras sadas de emergncia para sair do estado indesejado sem ter que
percorrer um extenso dilogo. Prover funes undo e redo.
4.
Consistncia e pa-
dres.
5. Preveno de erros.
Usurios no precisam adivinhar que diferentes palavras, situaes ou aes

significam a mesma coisa. Seguir convenes de plataforma computacional.
Melhor que uma boa mensagem de erro um desgin cuidadoso que previne o
erro antes que ele acontea.
6. Reconhecimento ao in-
Tornar objetos, aes e opes visveis. Usurio no deve lembrar informaes
vs de lembrana.
de uma para outra parte do dilogo. Instrues para uso do sistema devem
estar visveis e facilmente recuperveis quando necessrio.
7. Flexibilidade e eficin-
Usurios novatos se tornam peritos com o uso. Prover aceleradores de forma
cia de uso.
a aumentar a velocidade da interao. Permitir a usurios experientes cortar

caminho em aes frequentes.
8. Esttica e design mini-
Dilogos no devem conter informaes irrelevantes eu raramente necess-
malista.
rias. Qualquer unidade de informao extra no dilogo ir competir com unidades relevantes de informao e diminuir sua visibilidade relativa.
9. Ajudar o usurio a re-
Mensagens de erros devem ser expressas em linguagem clara, indicando pre-
conhecer, diagnosticar e
cisamente o problema e construtivamente sugerindo uma soluo.
corrigir erros.
Embora seja melhor um sistema que possa ser usado sem documentao,
o.
necessrio prover Help e documentao. Essas informaes devem ser fceis

de encontrar, focalizadas na tarefa do usurio e no muito extensas.
Os perfis dos cinco especialistas que utilizaram a Tabela 4.8 para avaliarem o aplicativo de
anotaes so os seguintes:
Avaliador 1: especialista que estuda anotaes multimdia em vdeos. Possui celular sensvel ao toque e equipado com Android e j utilizou tablet em disciplinas da Ps-graduao.
Avaliador 2: especialista com experincia em desenvolvimento de aplicativos Android para
dispositivos mveis. Utiliza celular sensvel ao toque com Android e utilizou tablet em
disciplinas da Ps-graduao.
Avaliador 3: especialista com experincia profissional em avaliaes heursticas de programas interativos para computadores. Utiliza celular sensvel ao toque com sistema operacional Android. Entretanto, nunca havia utilizado tablets.
Avaliador 5: utiliza com frequncia dispositivos mveis sensveis ao toque, tanto com Android quanto com iOS. programador espordico de aplicativos simples para Android.
52
4.2
RESULTADOS OBTIDOS
Os resultados obtidos por esses avaliadores podem ser verificados nas Tabelas 4.9, 4.10, 4.11, 4.12
e 4.13.
Tabela 4.9: Resultados da avaliaca
o heurstica do aplicativo de anotaco
es realizada pelo primeiro especialista, com
base nas heursticas de Nielsen.
AVALIADOR 1
Problema
Heurstica
Severidade
No entendi porque a conta do usurio foi perguntada novamente.
Ao invs das opes On e Off, poderia haver alguma outra instruo
Seria bom anotar com outras cores de tinta.
Aplicativo devia possuir os controles tradicionais do playback (play/-
mais visvel.
pause), ao invs de um boto simples.

Na tela de navegao por tinta, a opo de remover est como clear,
mas logo em seguida ela aparece como remove, na caixa de dilogo.
Na navegao por texto, o usurio pode no saber que possvel remover a anotao, porque essa funcionalidade acessada apenas depois
que o usurio clica em Edit.
Os nomes dos comandos devem ser iguais em todas as telas. Numa tela
est Edit, noutra est Clear, noutra est Remove. . .
No modo paisagem, os controles somem. Poderia haver uma opo para
ativ-los nesse modo de visualizao.
Tabela 4.10: Avaliac

ao heurstica pelo segundo especialista, com base nas heursticas de Nielsen.
AVALIADOR 2
Problema
Heurstica
Texto da barra de ttulo se repete na instruo das telas de escolha de
Severidade
A tela de escolha de vdeo no mostra as miniaturas de todos os vdeos.
Tela de escolha de autor est estranha, porque eu j escolhi o usurio
2, 4
Falta feedback avisando que meu udio foi gravado.
A anotao de tinta no sumiu da tela, mesmo depois que escolhi Ink
3, 4, 5
10
usurio, logo em seguida.
anteriormente.
Os botes esto difceis de serem reconhecidos. A interface poderia ser
mais enxuta.
Annotation is off.
As opes de editar e remover poderiam estar na mesma tela, porque a
opo de remoo aparece de surpresa, depois de o usurio selecionar
Edit.
Poderia haver uma forma de ver todas as anotaes de um determinado
momento. Ver uma de cada vez d muito trabalho.
Falta uma opo de ajuda ao usurio. Eu gostaria de saber se possvel
apagar a anotao de tinta, por exemplo.
As anotaes no esto sendo persistidas. Quando volto para a tela
inicial e tento rever o vdeo, as anotaes no esto l.
Falta mostrar qual usurio eu selecionei, na tela principal do vdeo.
DAS HEURISTICAS
VALIDAC
AO
4.2
Problema
Heurstica
No anotei nada e, mesmo assim, o aplicativo me deixa compartilhar
Severidade
2, 3, 4
anotaes.
Ao voltar da tela de compartilhamento, o dilogo perguntando se quero
compartilhar o contedo reaparece.

ao heurstica pelo terceiro especialista, com base nas heursticas de Nielsen.
AVALIADOR 3
Problema
Heurstica
Falta informao do caminho que j percorri, para que eu saiba onde
Severidade
A tela de contexto carece de um boto para voltar.
Mensagem indicando que a anotao foi editada aparece quase no ro-
Aplicao precisa de uma opo de ajuda, para tirar dvidas do usurio.
10
Se eu for pra tela inicial do Android e voltar pra aplicao, o vdeo re-
1, 10
3, 5
1, 4, 10
estou na aplicao.
As mensagens temporrias esto muito discretas, difceis de serem enxergadas.
dap, onde o usurio no est olhando.

Feedback indicando que udio est gravando est muito ruim. A mudana on/off no boto no suficiente. Poderia aparecer um cone
avisando o usurio ou at mesmo um popup.
comea, ao invs de continuar de onde eu havia parado. Poderia haver

uma opo de salvar o estado do trabalho.
No vejo a utilidade da tela de escolha de usurio, j que ela sincroniza
com a conta do Google.
Tela de escolha de autor muito parecida com a tela de usurio. No sei
se prossegui ou se voltei pra tela anterior. Novamente, poderia haver
um caminho percorrido pelo usurio.
No entendo como se cria um autor novo, e o aplicativo no me esclarece
isso.
Os comandos de anotao desaparecem quando estou no modo paisagem.
A tela com o boto de start est esquisita. Pra qu ela serve? Esse
boto isolado nem parece boto.

ao heurstica pelo quarto especialista, com base nas heursticas de Nielsen.
AVALIADOR 4
Problema
Heurstica
O feedback depois de a anotao de udio ser realizada no sufici-
Severidade
ente. Poderia aparecer uma mensagem informando que a anotao foi

realizada.
Caso eu deseje fazer multianotaes, o aplicativo no facilita essa funcionalidade. difcil identificar quais anotaes esto disponveis.
O espao poderia ser mais bem aproveitado.
53
54
4.2
RESULTADOS OBTIDOS

Problema
Heurstica
A anotao de tinta no desaparece, mesmo depois de ser removida na
Severidade
Os botes de navegao poderiam estar agrupados.
Poderia haver a possibilidade de discriminar quais anotaes foram fei-
10
tela de navegao.
Os botes de anotao de tinta e de udio poderiam ser cones diferenciados, ao invs de botes.
tas por quais autores.

O boto de navegao de Ink Navigation e Ink Annotation so muito
parecidos. Errei algumas vezes.
Ao compartilhar um contedo, a caixa de dilogos poderia conter os
botes yes e no, ao invs de ok e cancel. Na tela seguinte, a
mensagem poderia ser outra, ao invs de Choose Application.
Mensagem temporria do sistema operacional poderia aparecer sempre
centralizada e chamar mais ateno.
Os botes de funcionalidades somem quando estou no modo paisagem.
Poderia haver uma documentao desse comportamento.

ao heurstica pelo quinto especialista, com base nas heursticas de Nielsen.
AVALIADOR 5
Problema
Heurstica
Severidade
Botes esto muito prximos.
Botes de anotao de tinta e de udio deixam usurio confuso quanto
O vdeo no pausa para que eu faa a anotao de tinta.
Falta dar opo ao usurio de visualizar mltiplos autores.
Falta de Padro no tamanho dos botes com funcionalidades semelhan-
aos seus status (ligado/desligado).

Tela de vdeos no possui informao do local onde esses vdeos esto
armazenados, dificultando a usabilidade por parte do usurio inexperiente.
tes, afetando a visualizao dos mesmos.

Modo paisagem poderia possuir barra vertical com botes de visualizao de anotaes de tinta, de udio e de texto.
Falta de padro quanto ao nome dos botes de remoo das anotaes
em tinta e udio.
Usurio no tem opo de escolher quais anotaes ele gostaria de visualizar.
Falta opo de visualizar informaes bsicas dos vdeos, tais como:
numero de anotaes de texto, udio e tinta que o mesmo possui e
shares.
Mostrar nome do usurio ativo que est gerando as anotaes.
A seguir so expostos os perfis dos cinco avaliadores que realizaram a avaliao heurstica
do aplicativo de anotaes multimdias utilizando as heursticas propostas neste trabalho, para
avaliao de interfaces de dispositivos mveis.
Avaliador 1: especialista possui celular sensvel ao toque e equipado com Android e j
utilizou tablet em disciplinas da Ps-graduao.
DAS HEURISTICAS
VALIDAC
AO
4.2
55

dispositivos mveis. No possui celular nem tablet, mas utilizou muitas vezes os dois
dispositivos em disciplinas da Ps-graduao e em minicursos de programao bsica para
Android ministrados por ele.
Avaliador 4: possui smartphone sensvel ao toque equipado com Android. programador
espordico de aplicativos simples para Android.
Avaliador 5: especialista com experincia profissional em avaliaes heursticas de programas interativos para computadores. Utiliza celular sensvel ao toque com sistema operacional Android. Entretanto, nunca havia utilizado tablets.
Os resultados obtidos por esses avaliadores so apresentados nas Tabelas 4.14, 4.15, 4.16, 4.17
e 4.18.
es realizada pelo primeiro especialista,
utilizando as heursticas para dispositivos m
oveis.
AVALIADOR 1
Problema
Heurstica
Boto start desnecessrio na primeira tela.
No identifi-
Severidade
1
cada.
Boto play/pause difcil de entender porque no possui a metfora co-
3, 5
Boto play/pause muito prximo dos demais.
Letra dos botes muito pequena.
3, 7
A tela de navegao deveria parar a execuo do vdeo.
Informaes de contexto devem permitir que o usurio volte tela prin-
5, 6
4, 5, 10
7, 10
nhecida com os desenhos de play e de pause.
cipal apenas por tocar qualquer parte que no seja a caixa de informao. Clicar no boto voltar do sistema operacional no intuitivo.
Botes Share e Context Information tm propsitos diferentes e deveriam estar destacados de forma diferente dos demais botes.
Botes com funcionalidades anlogas parecem desconexos na interface.
Anotar texto e ver anotaes de texto deveriam estar prximos, um em
frente ao outro, por exemplo. Idem para as demais anotaes.
Anotao de tinta no sai do vdeo, mesmo depois que a anotao de
tinta est desabilitada. Boto no est fazendo o que deveria.
Anotao de udio deveria ter um feedback aps o clique, algo como
Talk.
Boto Cancel na tela de navegao deveria se chamar Exit, porque o
usurio no comeou a executar nenhuma ao neste ponto da interao.
Ao ir para a tela anterior, selecionar o mesmo autor do mesmo vdeo, as
anotaes desaparecem. A aplicao deveria voltar ao estado anterior.
Username deveria ser considerado o autor, em minha opinio. A tela de
autor parece desnecessria.
56
4.2
RESULTADOS OBTIDOS

Problema
Heurstica
Em paisagem, o vdeo aparece com os botes de navegao de vdeo com
Severidade
2, 5, 10
as metforas conhecidas, ao contrrio do que ocorrem em retrato.

Na tela de navegao, o formato da hora considera horas, minutos e
segundos, mas no player o formato aparece apenas com minutos e segundos.
Como no h informao dizendo que em paisagem o app no funciona
da mesma forma que em retrato, o usurio no sabe dessa distino.

es realizada pelo segundo especialista,
oveis.
AVALIADOR 2
Problema
Heurstica
Severidade
Boto Play/pause largo demais.
Botes agrupados, quando h muito espao livre na tela.
No h opo de Help.
10
Botes de navegao poderiam ser agrupados em um nico boto.
3, 8
Lista de navegao no d ideia ao usurio de que ela pode ser rolada.
A tela de visualizao de informaes de contexto carece de um boto
Para remover, necessrio clicar em editar, e isso dificulta o acesso.
A tela de navegao de tinta tem opo clear, diferentemente do que
2, 5
7, 11
Falta opo clear all, para limpar todos os campos preenchidos.
Para cada vdeo, deve-se colocar o autor novamente. Essa informao
8, 11
Ok, para voltar para a tela principal.
acontece nas outras telas.

Aps compartilhar uma anotao, a caixa de dilogo aparece mais de
uma vez.
Anotar texto poderia deixar o vdeo tocando, assim como ocorre nas
demais anotaes.
Falta opo de salvar as anotaes, porque elas somem depois que se
volta uma tela.
poderia ser salva.

o heurstica do aplicativo de anotac
oes realizada pelo terceiro especialista,
oveis.
AVALIADOR 3
Problema
Heurstica
Boto start est em uma posio no usual. Ele poderia estar ou no
Severidade
1, 11
4, 5, 10
topo ou mais embaixo, com mais destaque.

estranho pedir autor quando j se solicitou o usurio. A diferena de
papis no clara. Tela no deveria existir ou uma mensagem esclarecendo poderia ser providenciada.
Os comandos em retrato no so possveis de serem vistos em paisagem, mesmo quando se toca no vdeo.
DAS HEURISTICAS
VALIDAC
AO
4.2
57

Problema
Heurstica
Na tela principal, sobra muito espao abaixo dos botes. 1 2 O boto
Severidade
10
6, 7, 9
11
Compartilhar contedo replica mensagem de dilogo.
O vdeo deveria pausar enquanto o usurio compartilha o contedo.
2, 9
A marcao de tinta gravada de tempos em tempos, mas essa fun-
1, 6
10
11
2, 8, 10, 11
Add aparentemente adiciona mensagem em branco na cena, porque

os botes so deslocados quando a anotao de texto aparece.
Marcao de tinta no desaparece. No sei o que o aplicativo espera
que eu faa.
Boto cancel na tela de navegao est com nome imprprio. Poderia
ser close.
Usurio tem que memorizar qual o boto de voltar na tela de informaes de contexto, porque ele carece de um boto para voltar.
Botes esto menores que deveriam. Apertei boto share sem querer,
por ele estar prximo demais do boto Textual navigation.
Dois botes poderiam ocupar a mesma largura na tela principal. Olhar
share/context em relao a ink annotation/udio annotation. Eles esto desalinhados.
Quando se aperta em udio annotation, o usurio deve adivinhar que
tem que falar alguma coisa, porque no h instruo.
cionalidade deveria ocorrer de uma s vez, quando o usurio tirasse o

dedo da tela.
Botes na tela de navegao para edio/remoo possuem nomes diferentes em cada funcionalidade.
As informaes anotadas no so salvas quando se seleciona o vdeo
novamente.
Smbolo bsico play/pause (universal) poderia utilizados, ao invs do
boto comum.
Ausncia de boto Close Application na aplicao.

es realizada pelo quarto especialista,
oveis.
AVALIADOR 4
Problema
Heurstica
A tela de navegao exibe mensagem para que o usurio selecione o ins-
Severidade
2, 4, 6
1, 6
3, 7, 8, 9,
tante a ser navegado mesmo quando no h nenhuma anotao feita.

O boto de Add parece adicionar qualquer anotao, mas ele s adiciona a anotao de texto.
Falta uma mensagem avisando que a gravao de udio est ocorrendo.
10, 11
Seria interessante saber quanto tempo tem a anotao de udio, na tela
7, 10
de navegao de anotao de udio.

Poderia haver uma forma de controlar o volume da anotao de udio
em relao ao volume do vdeo, porque o usurio pode querer que sua
voz tenha mais evidncia que o som do vdeo.
Como h muito espao livre abaixo dos botes principais, pensei que a
anotao deveria ser feita nesse espao, e no no prprio vdeo.
58
4.2
RESULTADOS OBTIDOS

Problema
Heurstica
Severidade
Em paisagem, os comandos no aparecem.
A anotao de tinta no vdeo no desaparece.
2, 6
Falta boto sair.
5, 6, 8
Os botes deveriam estar mais alinhados e aproveitar melhor o espao
Deveria haver opo de sair na tela de contextos.
5, 6, 8
Informao de contexto um termo inadequado ao usurio.
Os botes poderiam estar prximos de acordo com a funcionalidade que
6, 9, 11
11
O nome navigation no muito intuitivo. Poderia ser annotation list.
4, 5
A partir de um nmero de anotaes com tintas, impossvel anotar
6, 7
da tela.
eles possuem.
No momento de compartilhar um texto no Orkut, aps clicar no boto
share, apareceu uma tela preta.
Ao clicar em voltar, depois da tela preta, a mensagem de compartilhar
anotao reapareceu.
Ao clicar em voltar, depois que a tela preta apareceu, o vdeo volta no
incio.
formas curvas.
Um usurio comum no sabe o que um arquivo XML, no momento em
que escolhe compartilhar o contedo.

es realizada pelo quinto especialista,
oveis.
AVALIADOR 5
Problema
Heurstica
Severidade
Boto start est em uma posio no usual. Poderia estar embaixo.
Uma tela inteira s com um boto start. Por que no inicia o aplicativo
de uma vez?
Fiquei perdido quando a segunda tela pedindo usurio apareceu.
Usurio deve apertar duas vezes em Edit para poder editar anotao
Em paisagem, no h como fazer anotaes.
2, 8
Senti falta de opo de pausar o vdeo clicar sobre ele.
Com o vdeo parado, fiz anotao de tinta e fui para a tela de navegao.
Falta uma ajuda nesse aplicativo. Estou confuso.
10
H duas formas de realizar anotaes: cena a cena, com o vdeo parado;
7, 8
2, 9
de texto. (Uma vez na tela de navegao, outra vez no dilogo).

Poderia permitir que o usurio editasse a cena no prprio campo de
texto, ao passar pela legenda desejada.
Removi a anotao, ela saiu da tela de navegao, mas no saiu do

vdeo, na tela principal.
e ao longo da execuo do vdeo. Entretanto, a anotao de texto s

permitida com o vdeo parado. Poderia ser um comportamento anlogo.
Geralmente players possuem o tempo no formato <tempo corrente>/<tempo final>, ao invs do formato usado no sistema.
DAS HEURISTICAS
VALIDAC
AO
4.2
59

Problema
Ao compartilhar as anotaes de texto, a interface no deixa claro se
Heurstica
Severidade
5, 9
7, 9
Ao terminar o vdeo, ele poderia parar.
Play/pause so separados por barra, enquanto que On e Off so alter-
9, 11
todas as anotaes realizadas sero compartilhadas ou se ser apenas

uma.
A tela de informao de contexto no permite voltar para a tela anterior.
Em todas as outras telas, eu pude voltar.
Poderia haver um feedback ao clicar em fazer anotao de udio. Algo
do tipo Iniciando gravao em 3..2. . . 1. Esse problema ocorre tambm
para a anotao de tinta, porque o usurio pode pensar que deve anotar
onde aparece o teclado, ou nem perceber que pode anotar.
nados no prprio boto.

Como h espao na tela, os botes poderiam estar mais espaados.
Botes de navegao poderiam estar mais distantes dos demais.
Usurio no entende o que o aplicativo considera informao de contexto. Apaguei todas as anotaes e eles continuam aparecendo. Coloquei anotao nova e ela no apareceu, ou seja, o comportamento est
confuso.
Ao longo do caminho at a tela principal, poderia haver um feedback
das opes preenchidas anteriormente.
O aplicativo tenta exibir as informaes de contexto mesmo quando no
h nenhuma.
A barra de controle do aplicativo exibe a mesma informao sendo exibida na antes da lista de opes, nas telas de seleo de usurio. Poderia ser uma informao diferente.
Para qu serve o logo, se ele no aparece em todas as telas? Analogamente ao logo, a barra de informaes do aplicativo desaparece na tela
principal.
Os resultados de cada avaliador que usou as heursticas tradicionais de Nielsen foram agrupados. Evidentemente, alguns problemas foram encontrados por mais de um avaliador, embora
as descries textuais deles no tenham sido idnticas. Nestes casos, o problema foi considerado apenas uma vez. Esse mesmo processo de agrupamento foi realizado com os resultados
obtidos pelos especialistas que utilizaram as heursticas propostas para interfaces de dispositivos mveis. Esses dois agrupamentos permitiram identificar os problemas que puderam ser
identificados pelos dois conjuntos de heursticas. Ao todo, os 10 avaliadores identificaram 75
problemas de usabilidade distintos, os quais esto reportados na Tabela 4.19. Nessa tabela,
cada problema descrito acompanhado das letras N, M ou NM. A letra N indica que o
problema foi encontrado apenas pela heurstica de Nielsen, ao passo que a letra M caracteriza
um problema encontrado apenas por avaliadores que usaram as heursticas para interfaces de
dispositivos mveis. A sigla NM, por sua vez, indica que o problema foi encontrado por ambas
as heursticas.
60
4.2
RESULTADOS OBTIDOS

o dos problemas encontrados nas interfaces do Twitter.
Problema
N1
Descrio
Funcionalidade faltante: ver todas as anotaes de um instante qualquer. Ver uma a uma
d trabalho.
N2
Funcionalidade faltante: discriminar quais anotaes foram feitas por quais autores.
N3
Funcionalidade faltante: mudar cor da anotao de tinta.
N4
Na tela de navegao por tinta, a opo de remover est como clear, mas logo em seguida
ela aparece como remove, na caixa de dilogo.
N5
Funcionalidade faltante: realizar multianotaes (habilitar todas ao mesmo tempo).
N6
Mensagem indicando que a anotao foi editada aparece quase no rodap, onde o usurio
N7
As fotos miniaturas deveriam pegar um frame significativo do vdeo.
N8
Os botes esto difceis de serem reconhecidos.
N9
Sistema no informa o usurio de que o udio foi gravado.
N10
O sistema no informa o usurio o que selecionei na tela principal.
N11
O aplicativo deixa a opo de compartilhamento habilitada mesmo quando o usurio ainda
N12
Se eu for pra tela inicial do Android e voltar pra aplicao, o vdeo recomea, ao invs
no est olhando.
no realizou nenhuma anotao.

de continuar de onde eu havia parado. Poderia haver uma opo de salvar o estado do
trabalho.
N13
No vejo a utilidade da tela de escolha de usurio, j que ela sincroniza com a conta do
Google.
N14
Os botes de navegao poderiam estar agrupados.
N15
Ao compartilhar um contedo, a caixa de dilogos poderia conter os botes sim e no,

ao invs de ok e cancel. Na tela seguinte, a mensagem poderia ser outra, ao invs de
Choose Application.
N16
Tela de vdeos no possui informao do local onde esses vdeos esto alocados, dificultando a usabilidade por parte do usurio inexperiente.
N17
O vdeo no est pausando para criao da anotao de tinta.
N18
Dar opo ao usurio de visualizar mltiplos autores.
N19
Falta opo de visualizar informaes bsicas dos vdeos, tais como: numero de anotaes
de texto, udio e tinta e de compartilhamentos que o mesmo possui.
N20
Na tela de navegao por tinta, a opo de remover est como clear, mas logo em seguida
ela aparece como remove, na caixa de dilogo.
M1
Boto play/pause muito prximo dos demais.
M2
Letra nos botes est muito pequena.
M3
A tela de navegao deveria parar a execuo do vdeo.
M4
Botes de Share e de Infos de contexto tm propsitos diferentes e deveriam estar destaca-
M5
Boto Cancel na tela de navegao deveria se chamar Exit, porque o usurio no come-
dos de forma diferente dos demais botes.

ou a executar nenhuma ao neste ponto da interao.
M6
Em paisagem, o vdeo aparece com os botes de navegao de vdeo com as metforas

conhecidas, ao contrrio do que ocorrem em retrato.
M7
Na tela de navegao, o formato da hora considera horas, minutos e segundos, mas no

player o formato aparece apenas com minutos e segundos.
M8
Boto play/pause est muito largo.
M9
Botes de navegao poderiam ser agrupados em um nico boto.
M10
Lista de navegao no d ideia ao usurio de que ela pode ser rolada.

DAS HEURISTICAS
VALIDAC
AO
4.2
61

Problema
Descrio
M11
Falta opo de clear all, para limpar todos os campos preenchidos.
M12
Para cada vdeo, deve-se colocar o autor novamente. Essa informao poderia ser salva.
M13
O boto Add aparentemente adiciona mensagem em branco na cena, porque os botes

so deslocados quando a anotao de texto aparece.
M14
Dois botes poderiam ocupar a mesma largura na tela principal. Olhar share/context em
relao a ink annotation/udio annotation. Eles esto desalinhados.
M15
O vdeo deveria pausar enquanto o usurio compartilha o contedo.
M16
A marcao de tinta gravada de tempos em tempos, mas essa funcionalidade deveria
M17
Ausncia de boto Close Application na aplicao.
M18
A tela de navegao exibe mensagem para que o usurio selecione o instante a ser navegado
ocorrer de uma s vez, quando o usurio tirasse o dedo da tela.
mesmo quando no h nenhuma anotao feita.

M19
O boto de Add parece adicionar qualquer anotao, mas ele s adiciona a anotao de
texto.
M20
Seria interessante saber quanto tempo tem a anotao de udio, na tela de navegao de
anotao de udio.
M21
Funcionalidade faltante: poderia haver uma forma de controlar o volume da anotao de

udio em relao ao volume do vdeo, porque o usurio pode querer que sua voz tenha mais
evidncia que o som do vdeo.
M22
Como h muito espao livre abaixo dos botes principais, pensei que a anotao deveria
ser feita nesse espao, e no no prprio vdeo.
M23
Context information um termo inadequado ao usurio.
M24
No momento de compartilhar um texto no Orkut, aps clicar no boto share, apareceu
M25
Ao clicar em voltar, depois que a tela preta apareceu, o vdeo volta no incio.
M26
O nome navigation na tela que lista as anotaes no muito intuitivo.
M27
A partir de um nmero de anotaes com tintas, impossvel anotar formas curvas.
M28
Um usurio comum no sabe o que um arquivo XML, no momento em que escolhe com-
uma tela preta.
partilhar o contedo.
M29
Boto start est em uma posio no-usual. Poderia estar embaixo.
M30
Usurio deve apertar duas vezes em Edit para poder editar anotao de texto. (Uma vez
M31
Funcionalidade faltante: Senti falta de opo de pausar o vdeo clicar sobre ele.
M32
H duas formas de realizar anotaes: cena a cena, com o vdeo parado; e ao longo da
na tela de navegao, outra vez no dilogo).
execuo do vdeo. Entretanto, a anotao de texto s permitida com o vdeo parado.

Poderia ser um comportamento anlogo.
M33
Geralmente players possuem o tempo no formato <tempo corrente>/<tempo final>, ao invs
M34
Ao compartilhar as anotaes de texto, a interface no deixa claro se todas as anotaes
M35
O vdeo poderia parar quando terminasse de ser executado.
M36
Play/pause so separados por barra, enquanto que On e Off so alternados no prprio
do formato usado no sistema.

realizadas sero compartilhadas ou se ser apenas uma.
boto.
M37
O aplicativo tenta exibir as informaes de contexto mesmo quando no h nenhuma.
M38
Para qu serve o logo, se ele no aparece em todas as telas? Analogamente ao logo, a barra
NM1
Tela inicial poderia ser desconsiderada.
de informaes do aplicativo desaparece na tela principal.

62
4.2
RESULTADOS OBTIDOS

Problema
Descrio
NM2
Deveria ter usado os controles tradicionais do playback (play/pause) ao invs de um boto

simples.
NM3
A tela de contexto carece de um boto para voltar.
NM4
Botes com funcionalidades anlogas parecem desconexos na interface.
NM5
A anotao de tinta no desapareceu da tela.
NM6
Dificuldade de entender se as funcionalidades de anotaes de udio e de vdeo esto pron-
NM7
As anotaes no esto sendo persistidas.
NM8
Dificuldade de entender a distino de usurios.
NM9
O espao da tela poderia ser mais bem aproveitado.
NM10
Falta Ajuda para que o usurio saiba o que e o que no possvel realizar com o aplicativo.
NM11
A opo de remoo est escondida. Poderia ser mais evidente.
NM12
Os rtulos dos botes de remoo no esto iguais nas telas de navegao.
NM13
Ao voltar da tela de compartilhamento, o dilogo perguntando se quero compartilhar o
NM14
No modo paisagem, os controles desaparecem.
NM15
Deveria ter usado os controles tradicionais do playback (play/pause) ao invs de um boto
tas para uso.
contedo reaparece.
simples.
NM16
No sei o que j preenchi quando estou em uma tela qualquer.
NM17
Texto da barra de ttulo se repete na instruo das telas de escolha de usurio.
A Tabela 4.19 permite concluir que 20 problemas foram encontrados exclusivamente pelas
heursticas de Nielsen (26,67% dos 75 problemas encontrados), ao passo que 38 problemas
foram identificados exclusivamente pelas heursticas novas (50,66% do total). Dezessete problemas foram encontrados por ambas as heursticas e representam 22,67% do total.
Os resultados dos avaliadores em relao aos graus de severidade associados a cada problema
esto dispostos nas Tabelas 4.20 e 4.21. Na primeira delas constam as informaes obtidas por
meio das avaliaes utilizando as heursticas de Nielsen. Os resultados encontrados por meio
da avaliao com as novas heursticas esto na segunda tabela.
Tabela 4.20: Sumarizaca
o das quantidades de problemas encontrados com cada grau de severidade, por cada
avaliador que usou as heursticas de Nielsen.
Quantidade de problemas encontrados
Avaliador
Grau 1
Grau 2
Grau 3
Grau 4
Total
21
20
Mdia (%)
12,73
38,18
36,36
12,73
Desvio
2,42
1,60
1,67
2,49
dro
pa-
DAS HEURISTICAS
VALIDAC
AO
4.2
63
Tabela 4.21: Sumarizaca

o das quantidades de problemas encontrados com cada grau de severidade, por cada
avaliador que usou as heursticas para interfaces de dispositivos m
oveis.
Quantidade de problemas encontrados
Avaliador
Grau 1
Grau 2
Grau 3
Grau 4
Total
22
31
19
16
Mdia (%)
25,00
35,23
21,59
18,18
Desvio
2,72
1,47
0,75
1,47
pa-
dro
Do ponto de vista absoluto, os resultados obtidos pelas heursticas novas foram consideravelmente melhores que os obtidos pelas heursticas tradicionais, com exceo de problemas com
gravidade alta (3), que tiveram 20 problemas em Nielsen e 19 nas novas heursticas. Essa comparao pode ser visualizada na Figura 4.1. Comparativamente aos valores percentuais obtidos,
ou seja, s contribuies que cada grau de severidade teve em relao aos problemas de cada
abordagem de heursticas, nota-se que as heursticas tradicionais foram menos efetivas para encontrarem problemas catastrficos. Contudo, os problemas considerados catastrficos tiveram
maior contribuio percentual em relao ao total nas heursticas novas, como se constata na
Figura 4.2.
Figura 4.1: Relac

ao entre o n
umero de problemas encontrados por cada grau de severidade.
64
RESULTADOS OBTIDOS
4.2
Figura 4.2: Percentual de problemas encontrados com cada grau de severidade.
Outro resultado que se pode obter das avaliaes heursticas realizadas a quantidade de
problemas encontrados com cada heurstica, de acordo com cada modalidade utilizada (tradicional ou para dispositivos mveis). Pelas Figuras 4.3 e 4.4, percebe-se que a heurstica de
Consistncia e Padres foi a que mais encontrou problemas nos experimentos realizados.
Figura 4.3: Quantidade de problemas associados a cada heurstica de Nielsen.
DAS HEURISTICAS
VALIDAC
AO
4.2
65
Figura 4.4: Quantidade de problemas associados a cada heurstica para avaliaca

o de interfaces de dispositivos
m
oveis.
H de se ressaltar que o primeiro avaliador que usou as heursticas para interfaces de dispositivos mveis no conseguiu associar o problema a nenhuma das heursticas. Contudo, todos
os demais especialistas que encontraram esse mesmo problema utilizando o mesmo conjunto
de heursticas conseguiram fazer essa associao. De qualquer forma, tendo em vista que o
problema se refere ao boto start ser desnecessrio, pertinente esclarecer na descrio da
heurstica Bom aproveitamento do espao da tela que apenas os componentes necessrios
para realizar a funcionalidade devem ser exibidos.
4.2.2
Avaliao com usurios finais
A avaliao do aplicativo para anotao multimdia pelos dois usurios finais teve registro
automtico das atividades realizadas por eles ao longo das interaes. Este registro foi implementado em Java juntamente com o cdigo-fonte da aplicao. As informaes so salvas em
um arquivo do tipo HTML (Hyper Text Markup Language) no carto SD do tablet Motorola XOOM
usado nos experimentos. O trecho de cdigo-fonte responsvel pela criao deste arquivo e
pela gravao dos dados est apresentado na Figura 4.5. Por questes didticas, as linhas do
cdigo-fonte foram numeradas.
Na linha 1 da Figura 4.5, especifica-se o cabealho da funo responsvel pela criao do
arquivo e gravao dos dados nele. O primeiro parmetro da funo o nome do arquivo a ser
criado. O segundo parmetro a mensagem a ser gravada. Como as mensagens so referentes
s interaes do usurio enquanto ele utiliza o aplicativo, vrias solicitaes funo da linha 1
foram feitas, com mensagens diferentes.
A linha 2 responsvel pela identificao do diretrio em que o carto SD do dispositivo
mvel se encontra e pela associao deste diretrio ao arquivo intitulado file dessa mesma
linha. Identificado o diretrio de gravao, o arquivo efetivamente criado com o nome desejado,
na linha 3.
Na linha 6 cria-se uma instncia do gravador dos dados do arquivo. O segundo parmetro
66
RESULTADOS OBTIDOS
4.2
Figura 4.5: C
odigo-fonte respons
avel pela criaca
o e gravaca
o do arquivo de registros de ac
oes de usu
arios do
aplicativo de anotaco
es multimdias.
da funo dessa linha especifica se os dados a serem escritos no arquivo sero acrescentados
aos dados que j existem nele. Como a funo saveToFile() chamada diversas vezes ao longo
da utilizao do aplicativo, importante que os dados gravados em cada instante no sejam
apagados para gravao de novos dados.
A gravao da mensagem ocorre na linha 7, juntamente com a hora em que a mensagem foi
gravada em horas, minutos, segundos e milissegundos. As linhas 8 e 9 seguintes so responsveis pela liberao do gravador de dados do arquivo, para liberao de memria e garantia de
que os dados foram gravados adequadamente. A formatao da hora de gravao feita pela
funo getNow(), na linha 17.
Note-se que a funo da linha 1 no exige que o arquivo tenha formato HTML. Contudo,
todos os arquivos usados neste trabalho foram escritos nesse formato. Na Figura 4.6, podese verificar como se estruturam esses arquivos HTML. O primeiro caractere de cada linha do
arquivo identifica a tela em que a interao ocorreu. No caso do aplicativo de anotaes, caixas
de dilogo podem aparecer quando o usurio interage na tela principal. Esses dilogos so
representados por nmeros em forma de subitens. A segunda informao de cada linha a ao
executada pelo usurio, seguida pelo instante em que o usurio a realizou. As aes possveis
de serem executadas so as seguintes:
ADD: pressionamento o boto Add;
Audio_Ann_Disabled: finalizao de gravao de udio;
Audio_Ann_Enabled: indicao de que o udio est pronto para ser gravado;
AUDIO_ANNOTATION: realizao de anotao de udio;
CANCEL: cancelamento da operao anterior (retorno tela anterior);
CHOOSE_AUTHOR: escolha do autor do vdeo;
DAS HEURISTICAS
VALIDAC
AO
4.2
67
Figura 4.6: Trecho de um dos arquivos gravados no cart

ao SD do dispositivo m
ovel.
CHOOSE_USERNAME: escolha do nome do usurio associado conta do Google;

CHOOSE_VIDEO: escolha do vdeo a ser anotado;
CONTEXT_INFO: visualizao de informaes sobre as anotaes realizadas;
EditText_FOCUSED ou EdiText_TOUCH: seleo da caixa de texto para realizar anotao
de texto;
EditText_UnFOCUSED: trmino da utilizao da caixa de texto;
Ink_Ann_Disabled: desativao da anotao de texto;
Ink_Ann_Enabled: indicao de que a anotao de tinta eletrnica est pronta para uso;
INK_ANNOTATION: realizao da anotao de vdeo;
Navigate to: busca do usurio por um trecho do vdeo por meio da barra de busca;
Pushed PAUSE: pausa do vdeo;
Pushed PLAY: liberao do video, que estava pausado;
START: pressionamento do boto start;
TEXT ANNOTATION: realizao de anotao de texto.
Na Figura 4.7, podem-se confrontar as quantidades de erros que cada usurio cometeu para
realizar cada funcionalidade requerida ou at desistir de realiz-la. Em seguida, na Figura 4.8,
realiza-se um comparativo do tempo que cada usurio demorou para realizar cada uma das
atividades ou at ele desistir de realiz-la.
Os arquivos de registros dos usurios novato e intermedirios esto includos nos Apndices A e B, respectivamente. Pelo Grfico 5, nota-se que o usurio intermedirio realizou um
nmero bem maior de erros que ao usurio novato quando as atividades lhes eram solicitadas
pela primeira vez. A Figura 4.8 permite concluir que o usurio intermedirio tambm demora
68
RESULTADOS OBTIDOS
4.2
Figura 4.7: Quantidade de erros cometidos por cada usu

ario para realizar cada atividade a ele requerida.Trecho de
um dos arquivos gravados no cart
ovel.
Figura 4.8: Tempo gasto por cada usu

ario para realizar cada atividade a ele requerida.Trecho de um dos arquivos
gravados no cart
ovel.
consideravelmente mais tempo para realizar as funcionalidades pela primeira vez, exceto no caso
da escolha de vdeos, que contm apenas um fluxo de interao no aplicativo e praticamente no
permite que o usurio erre.
necessrio ressaltar que o usurio novato simplesmente no conseguiu realizar gravaes
de udio e desistiu de realizar essa funcionalidade, ao passo que o usurio intermedirio conseguiu realizar todas as funcionalidades requeridas. Os grficos permitem concluir que, apesar
de o usurio intermedirio ter demorado mais tempo para realizar as atividades pela primeira
vez, ele gastou menos tempo para realiz-las pela segunda vez, em comparao com o usurio
novato. Isso um indcio de que o usurio intermedirio aproveita melhor as interaes iniciais
com o aplicativo para aprender por experincia.
Pela anlise dos vdeos dos experimentos, notvel o motivo pelo qual o usurio intermedirio
erra mais e demora mais tempo para realizar as funcionalidades pela primeira vez: enquanto o
usurio novato visualizou os componentes da tela e leu os comandos antes de realizar cada
ao, o usurio intermedirio simplesmente pressionou os botes aleatoriamente at encontrar
a tela que apresentava corretamente a funcionalidade que ele desejava realizar. O experimento
permitiu, portanto, concluir que o usurio intermedirio assumiu que ele conseguiria operar
DAS HEURISTICAS
VALIDAC
AO
4.2
69
a interface antes mesmo de conhec-la, apoiando-se no fato de que ele poderia voltar para a
tela anterior cada vez que uma tela indesejada aparecesse por consequncia da escolha de um
componente errado.
Tendo em vista que os experimentos com usurios foram realizados como forma de validar
as avaliaes heursticas conduzidas pelos especialistas, a especificao dos erros cometidos
por cada usurio ao longo das interaes se torna necessria. Para fins de comparao com os
resultados esperados no cenrio ideal, as aes corretas para concluir cada atividade requisitada
sero apresentadas seguidas dos erros cometidos por cada usurio.
1. Escolher vdeo:
(a) Cenrio ideal:
i. Pressionar o boto start;
ii. Selecionar algum elemento da lista de usurios;
iii. Selecionar vdeo na lista de vdeo.
(b) Erros cometidos pelo usurio novato: no houve.
(c) Erros cometidos pelo usurio intermedirio: no houve.
2. Inserir legenda:
(a) Cenrio ideal:
i. Pressionar o campo de texto;
ii. Digitar a legenda;
iii. Pressionar a tecla Enter ou o boto Add.
(c) Erros cometidos pelo usurio intermedirio:
i. Pressionar o boto Ink Navigation is Off.
3. Desenhar sobre uma cena:
(a) Cenrio ideal:
i. Pressionar o boto Ink Navigation is Off;
ii. Passar o dedo sobre o prprio vdeo;
iii. Pressionar o boto Ink Navigation is On (etapa no obrigatria, mas desejvel).
(b) Erros cometidos pelo usurio novato:
i. Pressionar o boto Video Context Information;
ii. Pressionar o boto Ink Navigation.
i. Pressionou o boto Ink Navigation;
ii. Tentou desenhar passando o dedo sobre o espao preto livre na tela Ink Navigation, entre a mensagem no cabealho e o boto Cancel no rodap;
iii. Pressionou a mensagem esttica que solicita que ele selecione uma miniatura de
figura, na tela Ink Navigation;
iv. Repetiu o erro ii;
v. Pressionou o boto Add;
70
RESULTADOS OBTIDOS
4.2
vi. Pressionou o boto Video Context Information;

vii. Repetiu o erro i;
viii. Repetiu o erro v;
ix. Repetiu o erro vi;
x. Pressionou o boto Share;
xi. Repetiu o erro i;
xii. Repetiu o erro ii. Em seguida, pediu para tentar mais tarde e pulou para a prxima
atividade;
xiii. Repetiu o erro i;
xiv. Repetiu o erro v;
xv. Repetiu o erro i;
xvi. Repetiu o erro x;
xvii. Pressiona o campo de texto. Diz novamente que quer tentar mais tarde;
xviii. Repetiu o erro i;
xix. Repetiu o erro ii. Em seguida, realiza a atividade.
4. Gravar udio sobre uma cena:
(a) Cenrio ideal:
i. Pressionar o boto Audio Annotation is Off;
ii. Falar a mensagem;
iii. Pressionar o boto Audio Annotation is On.
i. Pressionou o boto Video Context Information;
ii. Pressionou o boto Audio Navigation;
iii. Pressiona o boto de informaes sobre o dispositivo (bateria, wi-fi, data e hora,
etc.) para procurar alguma informao que o ajude. Em seguida desiste.
i. Pressionou o boto Add;
ii. Pressionou o boto Audio Navigation;
iii. Pressionou o boto Ink Annotation is On;
iv. Pressionou o campo de texto;
v. Pressionou o boto de comando de voz do teclado, imaginando que o udio poderia
ser gravado por esse boto;
vi. Repetiu erro ii. Em seguida, pediu para realizar a atividade mais tarde;
vii. Repetiu o erro iv;
viii. Repetiu o erro v. Em seguida, finalizou a atividade corretamente.
5. Visualizar cena que contm a legenda inserida:
(a) Cenrio ideal:
i. Pressionar o boto Textual Navigation;
ii. Pressionar sobre a imagem correspondente legenda ou sobre a prpria legenda.
(b) Erro cometido pelo usurio novato:
DAS HEURISTICAS
VALIDAC
AO
4.2
71
i. Pressionou o boto Edit, mas percebeu o erro rapidamente. Em seguida, finaliza

com sucesso.
i. Pressionou o boto Ink Annotation;
ii. Tentou visualizar a legenda assistindo ao vdeo e procurando a legenda pela barra
de progresso do prprio vdeo. Em seguida, finaliza a atividade com sucesso.
6. Editar legenda:
(a) Cenrio ideal:
i. Pressionar o boto Ink Navigation;
ii. Pressionar o boto Edit;
iii. Pressionar o novo boto Edit que aparece na caixa de dilogo;
iv. Digitar o novo texto;
v. Pressionar o boto Ok.
(c) Erro cometido pelo usurio intermedirio:
i. Pressionou o boto que o enviava para a cena que continha a legenda. Em seguida,
realiza corretamente a funcionalidade.
7. Desenhar sobre uma cena, pela segunda vez:
(a) Erros cometidos pelo usurio novato: no houve.
(b) Erros cometidos pelo usurio intermedirio: no houve.
8. Gravar um novo udio:
(a) Erro cometido pelo usurio novato:
i. Pressiona o boto de informaes sobre o dispositivo (bateria, wi-fi, data e hora,
etc.) para procurar alguma informao que o ajude. Em seguida desiste novamente
e se irrita.
(b) Erros cometidos pelo usurio intermedirio: no houve.
9. Ouvir um dos udios gravados:
(a) Cenrio ideal:
i. Pressionar o boto Audio Navigation;
ii. Pressionar sobre a mensagem de udio ou sobre a imagem equivalente.
10. Apagar o ltimo desenho:
(a) Cenrio ideal:
i. Pressionar o boto Ink Navigation;
ii. Pressionar o ltimo boto Clear da lista;
iii. Pressionar o boto Ok na caixa de dilogo.
72
RESULTADOS OBTIDOS
4.2

11. Apagar uma das legendas:
(a) Cenrio ideal:
i. Pressionar o boto Textual Navigation;
ii. Pressionar o boto Edit;
iii. Pressionar o boto Remove;
(b) Erro cometido pelo usurio novato:
i. Pressionou o boto Share sem querer. Logo depois completou com o sucesso a
atividade.
ii. Erros cometidos pelo usurio intermedirio: no houve.
12. Apagar uma das gravaes de udio:
(a) Cenrio ideal:
i. Pressionar o boto Audio Navigation;
ii. Pressionar o boto Remove;
iii. Pressionar o boto Ok.
i. Usurio tenta iniciar a atividade, um pouco irritado. Pressiona corretamente o
boto Audio Navigation, mas acha que errou e volta para a tela principal;
ii. Pressiona o boto Audio Annotation is On;
iii. Pressiona a descrio do udio e navega para a cena que o contm. Em seguida,
realiza corretamente a atividade.
Como se percebe pelo Grfico 4.7, as atividades relacionadas gravao de udio foram
problemticas para ambos os usurios, porque nenhum dos dois percebeu que o udio estava
sendo gravado logo depois de eles terem pressionado o boto correto. O usurio novato realizou
duas gravaes de udio involuntariamente quando lhe foi solicitada essa atividade. Contudo,
pela ausncia de aviso do sistema, ele pensou que nenhuma mensagem havia sido gravada.
Quando lhe foi solicitado que ouvisse um udio gravado, ele percebeu pela tela de navegao
que havia gravaes feitas. Essa concluso o permitiu remover o ltimo udio, operao que
ele realizou sem erros, mas ficou na dvida se o udio era de fato o ltimo, porque no havia
informao sobre a hora da gravao.
Desenhar sobre uma cena foi uma atividade interrompida pelo usurio intermedirio por
duas vezes at que ele a acertasse.
Ao ser solicitado para realizar o segundo desenho, o usurio novato reclamou que o primeiro
desenho que ele havia feito no havia sado da tela. Alm disso, ele reclamou que os botes da
tela principal estavam muito prximos.
Analisando-se os erros cometidos pelos usurios, nota-se que apenas um deles no seria
evitado pelos resultados das avaliaes heursticas para interfaces de dispositivos mveis realizadas: quando o usurio intermedirio pressionou o boto de comando de voz, ele pensou
por um momento que estivesse realizando a funcionalidade de gravao corretamente, mas logo
DAS HEURISTICAS
VALIDAC
AO
4.2
73
percebeu que havia se enganado. Apesar de ele ter conseguido se recuperar do estado de erro,
nenhum dos especialistas das avaliaes heursticas percebeu que o boto de comando de voz
poderia causar essa ambiguidade. No sistema Android, o comando de voz simplesmente permite
que o usurio preencha um campo de texto por meio da fala, ao invs preench-lo por meio da
digitao da mensagem pelo teclado. Tendo em vista que esse problema poderia ter sido identificado pela heurstica Adequao do componente funcionalidade, nenhuma alterao das
heursticas foi realizada aps os experimentos com os usurios.
4.2.3
Avaliao heurstica do UOL Notcias
Os resultados da avaliao heurstica realizada com o aplicativo UOL Notcias nos dispositivos
iPhone 4S, Motorola Blur e Motorola XOOM esto apresentados nas Tabelas 4.22, 4.23 e 4.24,
respectivamente.
Tabela 4.22: Resultado da avaliaca
o heurstica do UOL Notcias utilizando-se o iPhone 4S
Problema
Heurstica
Severidade
No existe ferramenta de busca de noticias.
Na tela de Noticias, existe uma barra horizontal que especifica o tipo
de noticia que estamos acessando. Nela para trocarmos o tipo visualizado, devemos clicar sobre ele, no existindo a possibilidade de arraste
horizontal (prtica muito comum em celulares touchscreen).
Na aba ler depois no existe a possibilidade de remover mais de uma
noticia ao mesmo tempo, sendo necessrio realizar a operao para
cada noticia existente.
Informaes referentes ao vdeo na aba Vdeos esto muito pequenas,
d3ificultando a visualizao das mesmas.
Lista de cidades est com informaes mal ordenadas, dificultando a
busca do usurio.
Banner localizado em cima da barra de guias est dificultando a visualizao das informaes.
No existe a possibilidade de visualizao em modo paisagem das fotos
apresentadas na guia Fotos.
No existe a possibilidade de visualizao em modo tela-cheia dos vdeos apresentados na guia Vdeos.
Na tela inicial, as informaes esto mal orientadas, dificultando sua
visualizao.
74
4.2
RESULTADOS OBTIDOS

o heurstica do UOL Notcias utilizando-se o Motorola Blur
Problema
Heurstica
Severidade
As notcias esto muito prximas.
No existe um padro de interao na tela inicial. A notcia em destaque
No encontrei o boto ler depois que o aplicativo cita nas notcias.
O aplicativo no d opo de selecionar mais de uma notcia offline de
mudada rolando a tela horizontalmente, ao contrrio do que ocorre

com as demais notcias.
Os nomes das cidades so carregados todos de uma vez. Poderiam ser
carregados aos poucos, medida que o usurio procura por elas.
Os nomes das cidades no esto ordenados no padro que o usurio
conhece.
A barra de progresso fica girando sem que se exiba uma mensagem
para o usurio. Conexes lentas podem levar o usurio a pensar que o
aplicativo travou.
A barra de status do dispositivo desaparece quando o vdeo solicitado
para ser carregado.
uma s vez.
Falta a possibilidade de buscar notcia offlines no aplicativo. 8 3 O
vdeo no est aparecendo. S consigo ouvir o som, porque a imagem
no aparece.
As abas no so alternadas pelo movimento de deslizamento lateral.

o heurstica do UOL Notcias utilizando-se o Motorola XOOM.
Problema
Heurstica
Interface est inconsistente, porque a tela de visualizao da notcia
Severidade
Informao sobre o vdeo que est sendo visualizado est ilegvel.
As notcias esto difceis de serem encontradas, porque no encontrei
11
diferente quando se pressiona no texto, em relao a quando se pressiona a prpria imagem.

Elementos da tela esto muito desalinhados. A impresso que se tem
de que os elementos esto jogados na tela.
A interface carece de flexibilidade. Nada personalizvel e as potencialidades do dispositivo no so exploradas.
nenhuma possibilidade de busc-las.

Usurio precisa acessar vrias telas para visualizar um contedo qualquer, como texto, vdeo, etc.. Nesse processo, ele precisa lembrar o que
preencheu no incio da interao.
Na tela de fotos, o desenho do boto de miniaturas pouco intuitivo,
pouco esclarecedor.
As notcias esto dividas por data, mas quando se rola a tela, o usurio
mal percebe as datas que aparecem, porque elas so pequenas e sem
contraste.
Em retrato, as informaes da imagem parecem estar desvinculadas
dela, porque esto muito distantes.
A informao da foto em que o usurio est muito pequena em relao
ao tamanho da tela. Passa despercebida.
DAS DIRETRIZES
CRIAC
AO
4.3
75

Problema
Heurstica
Na tela inicial, as fotos no contm a data, como ocorrem nas notcias.
Severidade
1
Falta padronizao das informaes exibidas.
Pelas Tabelas 4.22, 4.23 e 4.24, contabilizam-se 31 problemas de usabilidade, sendo que
todos eles puderam ser associados a alguma heurstica para avaliao de interfaces de dispositivos mveis. Essa anlise individual permitiu concluir que as heursticas propostas puderam ser
usadas para a avaliao de interfaces de dispositivos de diferentes resolues e tamanhos de tela
e de diferentes sistemas operacionais. Os estudos encontrados na Literatura Cientfica que propunham heursticas para o contexto mvel no consideraram dispositivos com caractersticas
to discrepantes nas avaliaes realizadas.
4.3
Criao das diretrizes
A primeira atividade realizada para a criao do documento unificado de diretrizes para o

design de interfaces de dispositivos mveis, com foco nos componentes de interface disponveis,
foi o mapeamento desses componentes com base na terminologia de cada empresa detentora de
cada documento. Esse mapeamento foi realizado por meio da leitura dos documentos disponibilizados por essas empresas para dispositivos equipados com Android, Blackberry, iOS e Windows
Phone e enumerao de cada elemento de interface citado ou ilustrado em cada documento. A
representao visual do componente associada ao seu funcionamento permitiu afirmar que um
dado elemento de uma documentao anlogo a outro elemento de outra documentao.
O mapeamento dos componentes de interface de cada sistema operacional est sumarizado
na Tabela 4.25. Por meio dele, concluiu-se que a terminologia diferenciada no o nico problema que os interessados no design de interfaces para esses sistemas operacionais enfrentam,
porque existem componentes que no esto disponveis em todos os sistemas analisados, como
se percebem nas clulas em branco da Tabela 4.25.
Os elementos de interfaces da Tabela 4.25 possuem nomes em Ingls, porque todas as documentaes encontradas estavam escritas neste idioma. Por conta disso, optou-se pela criao
de um nome em Portugus para caracteriz-lo no documento unificado, exceto em casos em que
a terminologia do elemento era a mesma para todos os sistemas e para os quais a traduo era
difcil de ser realizada.
Tabela 4.25: Mapeamento da terminologia de componentes usada pelas empresas Google, Blackberry, Apple e
Microsoft.
Componente
Android
Blackberry
iOS
Windows Phone
Barra de abas
Top Bar/ Tab Bar
Tab Bar
Barra de atividades
Main Action Bar
Navigation Bar
Pivot Control
Barra de navegao
Navigation Bar
Barra de progresso
Progress Bar
Progress Indicator
Progress View
Progress Bar
Barra de Status
Status Bar
Status Bar
Status Bar
Status Bar
Barra deslizante de
Seekbar/ Slider
Slider
Slider
Slider
Barra inferior
Bottom Bar
Toolbar
Toolbar
Application Bar
Boto
Button
Button
Button
Button
Caixa de mltipla
Spinner
Drop-down List
Simulado com Ta-
Simulado com List-
bleView
Picker
Navigation Bar
ajuste
escolha
76
4.3
RESULTADOS OBTIDOS

Componente
Caixa de seleo
Android
Blackberry
Checkbox
Checkbox
iOS
Checkbox
Windows Phone
Simulado com Toggle Switch
Campo de busca
Search View
Search Field
Search Bar
Autocomplete Box
Campo de texto
Textfield
Textfield
Textfield
TextBox
Dilogo
Dialog
Dialog Box
Alert
Message Box
Progress Bar
Activity Indicator
Activity indicator
Link
Checked Textview
Hyperlink
Link
Hyperlink Button
Lista
List View
List
Picker
ListBox
Menu popup
Popup Menu
Pop-up menu
Radio Button
Radio Button
Radio Button
Radio Button
Radio Button
Girador
de
pro-
gresso
Seletor de arquivos
Filepicker
Seletor de data
Datepicker
Datepicker
Datepicker
Datepicker
Seletor de hora
Timepicker
Timepicker
Timepicker
Timepicker
Seletor numrico
Number Picker
Stepper
Numeric Up Button
Submenu
Submenu
Switch
Toggle Button
Context Menu
Simulado com La-
Switch
Toggle Switch
beled Switch
Tabela
Simulado com Grid
Table
Table View
Simulado com Grid
Texto (Rtulo)
TextView
Label
Label
Label
A associao dos componentes da Tabela 4.25 permitiu a criao das diretrizes para os componentes que sero mostrados nos Quadros 4.1 a 4.25 a seguir. As ilustraes de cada componente presente neste documento podem ser encontradas no Apndice C.
BARRA DE ABAS
UTILIDADE: permitir que o usuario alterne sobre diferentes viso es ou modos de exibic a o do
aplicativo .
DIRETRIZES GERAIS:
Nao coloque o ttulo do aplicativo na barra de abas ;
Se voce nao usar uma barra de atividades , coloque o logo do aplicativo à esquerda das abas da barra
de abas .
Nao disponibilize controles ao usuario por meio das abas . Elas devem apenas alternar modos de
exibic a o , alternar entre tarefas , etc . , mas nao devem disponibilizar funcionalidades do
aplicativo , como busca ou cadastro de pessoas .
Mantenha todas as abas na tela , mesmo que nao haja visa o a ser mostrada por uma delas em um
determinado contexto . Se necessa rio , desabilite a aba, mas nunca a remova da interface .
Nao mude a localizac a o ou orientacao das abas quando o dispositivo for alterado da posicao retrato
para paisagem (e viceversa) .
Tente nao usar mais do que 4 abas , porque os usua rios podem se perder quando muitas abas sao
disponibilizadas .
Use ate duas palavras para descrever cada aba.
DIRETRIZES ESPECIFICAS:
ANDROID:
O Android disponibiliza dois tipos de abas : fixas e rola veis . Use abas fixas quando o aplicativo
possui no maximo 3 vis
o es . Caso contra rio , use abas rola veis .
Quadro 4.1: Barra de Abas.
DAS DIRETRIZES
CRIAC
AO
4.3
77
BARRA DE ATIVIDADES
UTILIDADE: identificar o aplicativo e prover acoes ou modos de navegacao ao usuario .
DIRETRIZES GERAIS:
Coloque o logo do aplicativo à esquerda na barra de atividades .
`
A direita do logo , identifique a tela em que o usuario esta por meio de um ttulo .
Mantenha a barra de atividades consistente ao longo de todas as telas do aplicativo .
Disponibilize na barra de atividades apenas funcionalidades que sao fundamentais à interacao , com
verbos autoexplicativos , como Buscar ou Compartilhar .
Se voce quiser permitir que o usuario alterne entre diferentes viso es , coloque as viso es em uma
caixa de m
u ltipla escolha na barra de atividades .
ANDROID:
Porc
oes da barra de atividades que nao cabem na tela sao colocadas em uma area adicional
identificada por . . . . Nunca deixe que uma funcionalidade importante esteja disponvel nesse
menu adicional .
Em paisagem, a barra inferior e unida automaticamente à barra de atividades , para melhor
aproveitamento de espaco . Analise a interface para evitar que funcionalidades importantes sejam
colocadas no menu adicional .
Quadro 4.2: Barra de Atividades.
BARRA DE NAVEGA
CAO
UTILIDADE: permitir a navegacao por diferentes telas e gerenciar o conte
udo de telas do aplicativo .
DIRETRIZES GERAIS:
Use o titulo da tela atual como titulo da barra de navegacao.
A fontepadrao prove o maximo de facilidade de leitura , mas isso nao impede que ela seja mudada.
Neste caso , certifiquese que o texto da barra de navegacao esta legvel .
Evite preencher a barra de navegacao com muitos controles adicionais , mesmo que haja espaco
suficiente .
A barra de navegacao pode ser formada por diferentes componentes. Use cada componente de acordo com
a documentacao que ele possui .
iOS:
A barra de navegacao deve conter um ttulo , um botao para voltar para a tela anterior e um botao
para controlar o conte
udo da tela sendo usada.
Se voce usar a barra de atividades para colocar botoes em abas , nao use ttulo . Use apenas os
bot
oes que formam tais abas .
Se apropriado , adapte a aparencia da barra de navegacao de acordo com seu aplicativo . Por exemplo,
voce pode fornecer a imagem customizada do seu plano de fundo ou a tonalidade da barra e tambem
especificar a translucidez . Em alguns casos , pode ser uma boa ide ia exibir uma imagem de fundo
redimensionada . Tenha certeza de que a aparencia da customizacao da sua barra de navegacao e
consistente com a aparencia e estilo do seu aplicativo . Se voce usar a barra de navegacao
transl
u cida , por exemplo, nao a combine com uma barra de ferramentas opaca.
Analise os elementos da barra de navegacao tanto em retrato quanto em paisagem, porque a barra
sobre redimensionamento de acordo com a mudanca da orientacao .
Quadro 4.3: Barra de Navegaca
o.
78
4.3
RESULTADOS OBTIDOS
BARRA DE PROGRESSO
UTILIDADE: informar ao usuario de que o sistema esta executando uma tarefa e quando essa tarefa ira
finalizar .
DIRETRIZES COMUNS:
Use a barra de progresso em atividades para as quais se pode estimar o tempo de finalizac a o .
Informe o usuario sobre o progresso de qualquer atividade que demore mais que dois segundos.
Disponibilize ao usuario informac
oes importantes sobre o progresso da tarefa sendo realizada . Por
exemplo, caso a instalac a o de um sistema esteja ocorrendo no dispositivo , mostre ao usuario o
percentual da instalac a o que ja foi completado.
Em casos de atividades longas realizadas em mais de uma fase , separe as atividades em barras de
progresso distintas , cada qual com uma descric a o relevante , tal como Baixando o aplicativo
ou Instalando .
Use verbos no ger
undio para indicar atividades em andamento. Por exemplo, Conectando .
Use verbos no particpio passado para indicar que a atividade parou. Por exemplo, Cancelado .
BLACKBERRY:
Permita que o usuario omita o componente da tela , caso ele queira .
Quadro 4.4: Barra de Progresso.
BARRA DE STATUS
UTILIDADE: exibe informac
oes importantes sobre o dispositivo , como data , hora e nvel de carga da
bateria .
DIRETRIZES GERAIS:
Nao oculte a barra de status a menos que seu aplicativo seja um jogo ou exiba elementos em tela
cheia .
Oculte a barra de status e todos os demais elementos da interface quando o usuario deseja ampliar
um elemento especfico para visualizalo em tela cheia . Por exemplo, caso o usuario queira
visualizar uma imagem em tela cheia , exiba apenas a imagem e disponibilize os comandos quando o
usuario colocar o dedo sobre a tela .
Nao customize a barra de status .
A barra de status pode ser formada por diferentes componentes. Use cada componente de acordo com a
documentacao que ele possui .
iOS:
Escolha a cor da barra de status dentre as seguintes possveis : cinza (cor padrao) , preto opaco e
preto transl
u cido .
Quadro 4.5: Barra de Status.
DAS DIRETRIZES
CRIAC
AO
4.3
79
BARRA DESLIZANTE DE AJUSTE

UTILIDADE: permitir que o usuario ajuste de valores dentre uma escala de valores possveis .
Diretrizes gerais :
Coloque imagens como cones em cada lado da barra para mostrar ao usuario os extremos da escala .
Em caso de os valores extremos serem numericos , prefira usar um seletor numerico à barra deslizante
de ajuste .
Quadro 4.6: Barra Deslizante de Ajuste.
BARRA INFERIOR
UTILIDADE: permitir que os usua rios acessem com facilidade funcionalidades frequentes de um
aplicativo .
DIRETRIZES COMUNS:
Use a barra inferior para exibir ao usuario acoes frequentes do aplicativo ou da tela com a qual
ele esta interagindo .
Coloque mensagens positivas ou referentes a acoes menos desastrosas à esquerda , antes dos demais.
Por exemplo, opc
oes Salvar
e Enviar devem aparecer à esquerda da opcao Remover .
Nao seja redundante . Se uma acao estiver explcita no conte
udo principal da tela , nao a replique na
barra inferior .
Use no maximo 5 itens caso a tela seja exibida em retrato . Use ate 7 itens caso a tela esteja
exibida em paisagem.
A barra inferior pode ser formada por diferentes componentes. Use cada componente de acordo com a
documentacao que ele possui .
BLACKBERRY:
Apenas os dispositivos Storm Series e Torch 9800 dispoem de barras inferiores .
Use cones com tamanho aproximado de 33x33 pixels .
iOS:
Personalize a aparencia da barra de ferramentas para que ela combine com a aparencia geral da sua
aplicac a o . Use cones com tamanho medio de 44x44 pixels .
Quadro 4.7: Barra Inferior.
BOTAO
UTILIDADE: Sao usados para selecionar itens ou opcoes .
DIRETRIZES COMUNS:
Nao inclua smbolos de marcas em bot
oes .
Use verbos para indicar as ac
oes dos bot
oes e seja sucinto na escolha .
Nao use ttulos de bot
oes que nao tenham significado relevante para a funcionalidade sendo
realizada .
A mensagem que especifica o botao nunca deve possuir mais do que suas palavras .
Sempre use a fonte padrao do dispositivo , a menos que voce esteja referenciando fontes especficas
de marcas ou de convenc
oes formais ( sociais , etnogra ficas , etc .) para um dado contexto .
Quadro 4.8: Bot
ao.
80
4.3
RESULTADOS OBTIDOS
CAIXA DE MULTIPLA
ESCOLHA
UTILIDADE: permite que o usuario selecione um item de uma l i s t a de itens mutuamente exclusivos .
DIRETRIZES COMUNS:
Use caixas de m
u ltipla escolha quando se tem dois ou mais elementos que podem ser escolhidos e
quando o espaco na tela for uma limitac a o do design .
Caso espaco na tela nao seja um problema, prefira usar radio buttons .
O valorpadrao, que aparece no componente antes de o usuario pressionar sobre ele , deve ser o valor
mais provavel de ser selecionado pelo usuario .
Destaque o item que esta sendo selecionado para o usuario .
Nunca exija que o usuario selecione uma resposta que ele eventualmente nao queira . Disponibilize
opc
oes Outro ou Nenhum , por exemplo.
Opcao de escape como Outro e Nenhum devem ser o primeiro item da lista , logo apos o valor
padrao.
Evite textos muito longos para os valores do campo, porque eles podem ser truncados em telas
menores, dificultando a compreensao.
Nao use opc
oes dicot
omicas , como Sim e Nao , em campos de m
u ltipla escolha . Use caixas de
selec a o para esse prop
o sito .
Quadro 4.9: Caixa de m
ultipla escolha.
CAIXA DE SELE
CAO
UTILIDADE: permitir que o usuario escolha dentre duas opcoes bina rias , facilmente diferencia veis .
Normalmente, caixas de selec a o sao usadas em grupo, para que o usuario selecione mais de uma
resposta a uma mesma pergunta .
DIRETRIZES COMUNS:
Nao in ic i e uma atividade quando o usuario selecionar uma caixa de selec a o . Por exemplo, nao abra
uma nova tela ap
os a selec a o ocorrer .
Alinhe as caixas de selec a o verticalmente .
Agrupe as caixas de selec a o de maneira lo gica , colocando os itens relacionados proximos e os itens
mais frequentemente usados primeiro .
Associe cada caixa de selec a o a mensagens formatadas em uma ou duas linhas , de forma padronizada
por toda a interface . Essa padronizacao ajuda o usuario a localizar as informacoes que lhe
interessam .
A descric a o da caixa de selec a o deve ter um antonimo facilmente identificado . Por exemplo, nao use
uma caixa de selec a o associada à palavra Retrato para indicar se um componente sera usado
em retrato ou em paisagem, porque a diferenciac a o desses termos nao e clara para todos os
usua rios .
Quadro 4.10: Caixa de selec
ao.
DAS DIRETRIZES
CRIAC
AO
4.3
81
CAMPO DE BUSCA
UTILIDADE: buscar aplicativos a partir da area de trabalho ou buscar informacoes de um aplicativo
em uso. Tratase de um tipo especial de campo de texto .
DIRETRIZES COMUNS:
O campo de busca pode ser usado tanto parte do conte
udo principal da tela , quanto em menus ou
barras de atividades .
O conte
udo que podera ser buscado devera ser relevante para o escopo da busca. Informacoes
irrelevantes nao devem aparecer como resultados da busca.
Se possvel , exiba os resultados mais relevantes no topo da l i s t a de resultados .
Nos resultados da busca , negrite as palavras que correspondem aos caracteres digitados pelo usuario
.
Caso queira u t i l i z a r um r
o tulo antes do campo de busca, coloque dois pontos (:) ao final do ro tulo .
Voce pode incluir um texto no campo de busca , para indicar ao usuario a acao a ser realizada (por
exemplo, Buscar ) ou para indicalo o contexto da busca (por exemplo, Google ) .
iOS:
Voce pode acrescentar à barra de busca do iOS um botao de favoritos . Esse botao funciona como um
atalho para informac
oes que os usua rios querem encontrar mais facilmente .
Voce pode escolher uma imagem para fundo da caixa de pesquisa , ou escolher uma cor de fundo dentre
as seguintes possibilidades : azul , preto e preto transl
u cido . Em caso da escolha de imagem,
certifiquese de que ela e redimensionavel de acordo com a orientacao .
Quadro 4.11: Campo de busca.
CAMPO DE TEXTO
UTILIDADE: permitir digitac a o de texto para entrada de dados.
DIRETRIZES COMUNS:
Use um campo de texto com suporte à funcionalidade que se deseja . Por exemplo, campos de email
devem ser associados a campos de texto pro prios para preenchimento de email , que incluem
caracteres @ e .com facilmente acessados . Alem dos campos de texto comuns (para
preenchimento de nomes, por exemplo) , existem campos de texto especficos para os seguintes
tipos de dados: data , hora , n
umero, senha, n
umero de telefone e enderecos \textit{Web}.
Caso o espaco na tela seja uma limitac a o , coloque uma dica no pro prio campo de texto , que
desaparece quando o usuario seleciona o campo. Nesse caso , use uma dica concisa , com a primeira
letra em mai
usculo .
Os r
o tulos que identificam campos de texto devem ter dois pontos (:) como u
ltimo caractere .
Caso prefira , coloque imagens como cones no lado esquerdo do campo de texto , como substituic a o do
r
o tulo convencional . As imagens devem conter metaforas facilmente identifica veis .
Associe o campo de texto a um botao Limpar sempre que necessa rio .
Certifiquese de que o texto sendo fornecido pelo usuario esta legvel no componente.
Quadro 4.12: Campo de texto.
82
4.3
RESULTADOS OBTIDOS
DIALOGO
UTILIDADE: mostrar ao usuario informac
oes necessa rias para completar uma atividade . informar ao
usuario mensagens emergenciais ou que esclarecam o estado da atividade sendo realizada . avisar
usuario sobre condic
oes e situac
o es adversas .
DIRETRIZES COMUNS:
Use bot
oes para confirmar ou cancelar acoes do usuario . Nao use links ou outros componentes.
Use ate tre s opc
oes de respostas em dia logos . Caso sejam necessa rias mais opcoes , opte por uma nova
tela . Idealmente , os alertas possuem dois botoes .
Permita que o dialogo desapareca quando o usuario pressionar a tecla voltar do dispositivo .
Centralize o componente de dialogo na tela .
Use dia logos que ocupem no maximo 90% da altura da tela do dispositivo .
Use bot
oes de confirmacao e relativos a acoes menos dra sticas antes dos demais. Por exemplo, use a
opcao Salvar antes de Remover ou Cancelar .
Centralize os bot
oes do dia logo .
Caso seja necessa rio incluir uma caixa de selec a o ao dialogo , alinhe a caixa de selec a o à mensagem
do dialogo . A caixa de dialogo deve estar preselecionada , a menos que ela referencie uma acao
crtica do aplicativo .
Seja sucinto , mas use mensagens completas .
Fale a linguagem do usuario . Por exemplo, prefira a frase O arquivo nao foi salvo porque nao ha
espaco disponvel no cartao de mem
oria. à frase Erro de gravacao de dados .
Use mensagens positivas e nunca culpe o usuario . Em casos de erros , foque nas atividades que o
usuario pode fazer para sair do estado de erro .
Nao
Use retice ncias (\ldots) apenas para indicar o progresso de atividades , ao final dos ro tulos .
Certifiquese de minimizar o n
umero de dia logos da sua aplicac a o . Eles interrompem a interac a o e
devem ser usados apenas para exibir informacoes realmente u
teis em contextos isolados .
Tente manter a mensagem curta o suficiente para ser exibida em uma u
nica linha .
Evite o uso de voce , seu , eu ou meu tanto quanto possvel , porque as pessoas podem
se sentir constrangidas ou inibidas por essas mensagens.
Caso a mensagem seja um ttulo ou uma frase afirmativa e curta , use a primeira letra de cada
palavra em caixa alta . Por exemplo: Atividade De Remocao .
Caso a mensagem seja uma pergunta , coloque apenas a primeira letra da primeira palavra em caixa
alta e acrescente ponto de interrogacao ao final .
Use a palavra tocar ao inves de toque ou clique ou escolha para descrever a acao de
selec a o .
Teste a aparencia do dialogo nas duas orientac o es possveis , porque em paisagem a altura e limitada
em relac a o ao que se nota em retrato .
Evite bot
oes com significados bina rios em dia logos (botao Sim e botao Nao , por exemplo) .
Prefira bot
oes com as ac
oes possveis , como Salvar e Cancelar .
Quadro 4.13: Di
alogo.
DAS DIRETRIZES
CRIAC
AO
4.3
83
GIRADOR DE PROGRESSO
UTILIDADE: informar ao usuario de que o sistema esta executando uma tarefa .
DIRETRIZES COMUNS:
Use o girador de progresso quando voce lida com uma atividade para a qual nao se consegue estimar o
tempo de finalizac a o .
Use o girador de progresso quando e mais importante mostrar ao usuario que a atividade que ele
solicitou esta em andamento do que mostralo quando a atividade ira finalizar .
Informe o usuario sobre o progresso de qualquer atividade que demore mais que dois segundos.
Associe o componente a uma mensagem relevante ao usuario em casos de atividades complexas, que
podem demorar um tempo considera vel para serem executadas .
BLACKBERRY:
Permita que o usuario omita o componente da tela caso ele queira .
Quadro 4.14: Girador de progresso.
LINK
UTILIDADE:
Diretrizes gerais :
Use a primeira letra do link em caixa alta (mai
uscula) , a menos que o link esteja no fim de uma
sentenca .
Nao use links no meio de uma mensagem. Faca da frase inteira um link ou useo usalo no final da
sentenca . Por exemplo, prefira frases como Para maiores informacoes , use o seguinte endereco :
<link > a Use o endereco <link> para maiores informacoes .
Use contraste no link em relac a o ao fundo e em relac a o ao restante da frase (em casos em que eles
sejam parte da frase ) .
Nao use smbolos de marcas em links .
Nao use mais do que duas palavras para identificar um link .
Nunca use dois ou mais links pr
oximos uns do outro , porque a diferenciac a o entre eles e d i fc i l de
ser notada visualmente .
Nunca desabilite um link , a menos que o aplicativo esteja esperando que uma atividade do sistema
seja completada.
Quadro 4.15: Link.
84
4.3
RESULTADOS OBTIDOS
LISTA
UTILIDADE: exibir uma listagem de elementos , da qual o usuario seleciona um elemento para ser usado
em uma funcionalidade . A l i s t a exibe os elementos em linhas .
Diretrizes gerais :
R
otulos de l i s t a s devem aparecer à esquerda da lista , terminado com o caractere dois pontos (:) .
Use uma l i s t a quando os usua rios tem ideia de que valores ira o encontrar , porque em l i s t a s grandes
a maioria dos valores s
o e visualizada quando a tela e rolada .
Use divisores horizontais em l i s t a s para especificar o fim de uma secao , de um grupo de elementos .
Mantenha o mesmo alinhamento de elementos em todas as linhas da l i s t a .
Certifiquese de que os itens da l i s t a estao legveis tanto em retrato quanto em paisagem.
Use fontes com bom contraste e sem serifa .
Nao use efeitos de iluminacao ou animac
oes em itens de l i s t a s . Use iluminacao apenas para indicar o
item que foi selecionado pelo usuario .
BLACKBERRY:
Use bot
oes Anterior e Pr
oximo em casos de l i s t a s muito grandes .
Permita que os usua rios naveguem pelos elementos da l i s t a por meio das teclas N (next) e P
(previous) , no caso de l i s t a s de aplicativos em Ingle s .
iOS:
Use uma tabela para exibir muitos valores , porque as l i s t a s no iOS sao uma generalizac a o dos
componentes seletores , que tem altura e largura fixas , fazendo com que poucos elementos sejam
exibidos por vez . Usando tabelas os usua rios tendem a encontrar a informacao que desejam mais
rapidamente.
Quadro 4.16: Lista.
MENU POPUP
UTILIDADE: e uma maneira fa c i l de acessar as acoes mais comuns acerca de um item da interface .
Diretrizes gerais :
Use menus popup apenas se eles forem agregar valor à funcionalidade .
Inclua no menu popup somente as ac
oes mais comuns acerca do componente.
Inclua um cone e um r
o tulo textual para identificar cada item do menu.
Opcao de Ajuda deve estar distante das funcionalidades principais .
BLACKBERRY:
Voce pode criar menus popup com nove ac
oes , cinco acoes ou tre s acoes .
Os cones do menu devem possuir em media 33x33 pixels de tamanho.
O item mais importante do menu deve estar com foco na interface . Os demais itens devem ser
ordenados dos mais acessados para os menos acessados .
Quadro 4.17: Menu Popup.
DAS DIRETRIZES
CRIAC
AO
4.3
85
RADIO BUTTON
UTILIDADE: indica um conjunto de itens mutuamente exclusivos , mas relacionados entre s i .
DIRETRIZES COMUNS:
Use radio buttons para exibir duas ou mais opcoes ao usuario , quando o espaco da tela nao for um
fator limitante para a interface . Em caso de espaco ser uma limitac a o , prefira usar uma l i s t a .
O conte
udo de radio buttons nao deve mudar de acordo com o contexto . Portanto , assegure que os
valores relativos a eles serao esta ticos ao longo de toda interac a o .
Nao in ic ie uma atividade nova quando o usuario selecionar uma opcao em um radio button . Por exemplo
, nao abra uma nova tela .
Alinhe radio buttons verticalmente .
Agrupe os radio buttons de acordo com a relac a o que eles possuem entre s i .
Prefira deixar os itens mais comuns antes dos demais.
Use r
o tulos do lado direito dos radio buttons .
Coloque as mensagens dos radio buttons com a primeira letra em mai
usculo .
Nao use ponto final nos r
o tulos de radio buttons .
Use no maximo 8 radio buttons em um u
nico grupo. Caso sejam necessa rios mais opcoes , prefira uma
lista .
Nunca use radio buttons para exibir resultados de buscas a banco de dados, a menos que se saiba que
a busca nunca retornara mais do que 8 valores .
Nao use radio buttons para iniciar ac
oes na interface , como desabilitar componentes ou mostrar um
dialogo .
Quadro 4.18: Radio Button.
SELETOR DE ARQUIVOS
UTILIDADE: oferecer ao usuario uma opcao pra tica de navegar pelos arquivos de aplicativos
Blackberry .
Diretrizes :
Mostre ao usuario itens de acordo com o contexto buscado. Por exemplo, se o usuario estiver
navegando por um diret
o rio que contem imagens, mostre miniaturas das imagens que existem nesse
diret
o rio .
Permita que os usua rios naveguem a partir de um direto riopadrao, para que eles encontrem o arquivo
que desejam com mais facilidade .
Quadro 4.19: Seletor de Arquivos.
86
4.3
RESULTADOS OBTIDOS
SELETOR DE DATA
UTILIDADE: permitir que o usuario selecione com facilidade um dia , mes ou ano de uma data
especfica .
DIRETRIZES COMUNS:
Use valores que serao usados no aplicativo . Por exemplo, se voce sabe que dias da segunda quinzena
de um mes nao serao selecionados , excluaos dos valores possveis .
Seletores de data devem ser usados preferencialmente em dia logos , porque eles ocupam muito espaco
da tela .
Seletor de hora
UTILIDADE: permitir que o usuario selecione uma hora , minuto e segundo de um instante qualquer .
DIRETRIZES COMUNS:
Limite os valores a serem preenchidos se nao for necessa rio saber com exatidao a hora do evento .
Por exemplo, organize os minutos de 10 em 10 minutos.
Seletores de data devem ser usados preferencialmente em dia logos , porque eles ocupam muito espaco
da tela .
Quadro 4.20: Seletor de data.
SELETOR NUMERICO
UTILIDADE: incrementar ou decrementar o valor de um n
umero.
Diretrizes gerais :
Use seletores numericos quando os usua rios querem selecionar dentre poucos valores numericos
possveis .
Nao use seletores numericos caso os n
umeros possveis variem constantemente de acordo com o
contexto .
iOS:
No iOS, o seletor nao e automaticamente associado a um n
umero sendo exibido , porque ele so possui
os bot
oes e + . Por isso , deixe claro que valor esta sendo modificado por meio de
destaque no elemento sendo modificado .
Quadro 4.21: Seletor Numerico.
DAS DIRETRIZES
CRIAC
AO
4.3
87
SUBMENU
UTILIDADE: permitir que o usuario encontre itens frequentemente usados ou importantes , que sao um
subconjunto de um item do menu.
Diretrizes gerais :
Use submenus para reduzir o n
umero de itens que aparecem no menu. Por exemplo, se o usuario
precisar rolar a tela para visualizar os itens de um menu, agrupe os itens do menu e coloque
opc
oes em submenus.
Agrupe itens relacionados em submenus. Por exemplo, deixe a opcao Ordenar por no menu principal
e oferec a opc
oes Data , Nome e Assunto no submenu.
Use pelo menos tre s itens em um submenu.
Caso sejam necessa rios mais do que seis itens em um submenu, separeos por linhas separadoras .
Coloque os itens mais frequentemente usados primeiro e os separe dos demais com linhas de
separacao .
Ac
oes importantes e gerais nao devem ser colocadas em submenus.
Evite usar submenus de submenus. Mantenha apenas um nvel de diferenc a em relac a o ao menu principal
.
Prefira usar verbos para descrever as ac
oes no menu e substantivos nos submenus.
Nunca repita o texto no menu no submenu. Por exemplo, jamais coloque Ordenar por no menu e
Ordenar por data , Ordenar por nome , etc . no submenu.
Coloque a primeira letra do menu e do submenu em mai
uscula , mesmo que o submenu complete a frase
iniciada no menu. Por exemplo, coloque Enviar no menu e Por email no submenu.
Evite usar o termo Mais como item de um menu. Geralmente, e d i fc i l saber o que consta nos
submenus de itens identificados por esse termo.
Quadro 4.22: Submenu.
SWITCH
UTILIDADE: fornecer uma maneira visual de se alternar entre dois estados mutuamente exclusivos .
Diretrizes gerais :
Escolha dois valores que tenham significados opostos . Por exemplo, Ligado e Desligado .
Voce pode usar um switch para alternar o estado de outros componentes da interface . Dependendo da
escolha , alguns elementos podem aparecer e outros podem ser desabilitados , por exemplo.
Quadro 4.23: Switch.
88
4.3
RESULTADOS OBTIDOS
TABELA
UTILIDADE: apresentar informac
oes em colunas e linhas . Em iOS, as tabelas so possuem uma u
nica
coluna .
DIRETRIZES COMUNS:
Use cabecalhos para ajudar o usuario a navegarem por tabelas muito grandes .
Use tabelas para exibir grandes ou pequenas quantidades de informacoes .
Esclarec a ao usuario qual item foi selecionado por ele , por meio de destaque da linha selecionada e
/ou incio de uma nova acao.
Caso muitas informac
oes necessitem ser carregadas , disponibilize algumas informacoes textuais
i n i c i a i s imediatamente ao usuario e carregue os demais itens ao poucos.
Nao use tamanhos varia veis para as linhas da tabela .
Use textos sucintos para evitar que eles sejam truncados .
iOS:
Use ndices flutuantes para auxiliar o usuario a localizar itens em tabelas grandes . Esses itens
sao geralmente letras que aparecem flutuando na extremidade direita da tabela e que permitem
acesso direto a elementos que iniciem com a letra selecionada pelo usuario . Nesse caso , nao use
elementos no canto direito da tabela , para que eles nao sejam sobrepostos pelos ndices .
Quadro 4.24: Tabela.
TEXTO (ROTULO)
UTILIDADE: Exibir sentencas textuais ao usuario . Rotulos sao textos usados identificar um
componente da interface ou para simplesmente mostrar uma mensagem.
DIRETRIZES COMUNS:
O texto deve ser fa c i l de entender , conciso e claro .
R
otulos que aparecem à esquerda de componentes devem possuir dois pontos (:) como u
ltimo caractere .
Se voce deseja usar diferentes fontes na interface , prefira fontes de uma mesma famlia , porque
elas possuem similaridades entre s i e tendem a criar interfaces mais atrativas .
Evite usar negrito para dar enfase a textos .
Nao use letras pequenas.
Evite usar ita lico e sublinhado . Esses efeitos podem deixar os textos d i fc e i s de serem lidos .
Certifique que o texto estara v i sv e l mesmo em ambientes com pouca luminosidade .
De contraste ao texto em relac a o ao fundo, para aumentar a legibilidade .
Pontue r
o tulos de listas , campos de texto e campos de busca com dois pontos (:) .
Nao use dois pontos quando o r
o tulo for um ttulo .
Nao use aspas simples , nem use pontos de exclamacao em textos .
Nao escreva sentencas em letra mai
uscula , porque elas podem constranger ou i n i b i r o usuario .
Coloque a primeira letra em caixa alta para referenciar sentencas e ro tulos de caixas de selec a o e
de radio buttons .
Evite usar abreviac
o es , a menos que o espaco seja um fator limitante e a abreviacao seja facilmente
interpretada .
Use uma terminologia com a qual o usuario esta familiarizado .
Evite jarg
o es , termos tecnicos ou coloquialismos . Fale a linguagem do usuario .
Evite usar smbolos para substiturem textos . Por exemplo, nao u t i l i z e & no lugar de e .
Quadro 4.25: Texto (R
otulo).

CONSIDERAC
OES
FINAIS
4.4
89
As diretrizes presentes nos Quadros 4.1 e 4.25 acima certamente auxiliam na tomada de decises de design de interfaces, mas elas no apresentam recomendaes de acordo com contexto
do aplicativo que se deseja desenvolver. Usurios interessados em jogos, por exemplo, desejaro
dispor de interfaces com elementos que facilitem o entretenimento, os quais podem ser obtidos
pelo uso de contedos multimdia associados aos componentes de interface comuns. Alm disso,
o processo de design envolve a avaliao de prottipos para que as escolhas corretas sejam tomadas ao se liberar o produto final. De qualquer forma, as diretrizes ajudam a direcionar o
processo de criao de cada interface, para posterior avaliao.
Um ponto importante a destacar com relao s diretrizes que os componentes se relacionam de formas diversas em interfaces. Textos podem ser associados a praticamente todo
componente, por exemplo. Logo, a utilizao da documentao de um componente deve levar
em considerao a documentao de todos os demais componentes que se associam a ele.
4.4
Consideraes finais
O mapeamento entre uma determinada categoria de problema e a heurstica de Nielsen equivalente foi realizado com base nas dificuldades encontradas pelo prprio mestrando. Tendo em
vista que a associao de problemas a heursticas um processo que gera resultados que variam
de acordo com cada avaliador, os resultados expostos na Tabela 4.5 poderiam ter sido diferentes
caso outros avaliadores tivessem sido recrutados para associarem as categorias s heursticas.
Bertini et al. [2006] propuseram um conjunto de heursticas para avaliao de dispositivos mveis, considerando aspectos como privacidade e ergonomia desses dispositivos, os quais
no foram considerados neste trabalho. Apesar dessa diferena, os dois trabalhos possuem
propsitos semelhantes e seria vlido realizar avaliaes heursticas do aplicativo de anotaes
multimdia com as heursticas de Bertini et al. [2006], a fim de comparar os resultados dessas
avaiaes com os descritos neste Captulo.
90
RESULTADOS OBTIDOS
4.4
Captulo
5
Conclusao
A inspeo por simulao realizada com os quatro aplicativos em Android selecionados identificou 19 categorias de problemas, sendo que algumas delas no puderam ser facilmente relacionadas a alguma heurstica de Nielsen. Como exemplos, podem-se citar as categorias ,
aproveitamento do espao da tela, de acordo com a orientao, adequao do componente
funcionalidade e visibilidade das interaes possveis.
As avaliaes heursticas deste trabalho evidenciaram que as heursticas para avaliao de
usabilidade de interfaces de dispositivos mveis, levando-se em considerao apenas a camada
de visualizao, capaz de identificar uma grande quantidade de problemas de usabilidade em
interfaces de dispositivos mveis. Assim como os resultados expostos por Bertini et al. [2006],
as heursticas propostas foram capazes de encontrar uma quantidade maior de problemas em
relao abordagem de Nielsen [1994], com o diferencial de que os perfis dos avaliadores deste
trabalho foram claramente expostos e escolhidos de forma a equilibrar os dois grupos de avaliadores.
Apesar de compartilhar o mesmo resultado em termos de quantidade de problemas, este
trabalho obteve resultados sensivelmente diferentes dos de Bertini et al. [2006] em relao aos
problemas cosmticos. As heursticas de Bertini et al. [2006] no foram capazes de identificar
muitos problemas cosmticos, ao passo que, em nosso estudo, o nmero de problemas cosmticos obtido foi mais que o triplo que o obtido pelas heursticas de Nielsen (vide Grfico 4.1). Alm
disso, nos experimentos de Bertini et al. [2006], as heursticas propostas por eles encontraram
um nmero menor de problemas catastrficos que as heursticas tradicionais, ao passo que as
heursticas elaboradas neste trabalho encontraram mais que o dobro de problemas catastrficos
em relao abordagem tradicional. Contudo, ambos os estudos concluram que problemas
graves (de graus 3 a 4) so mais bem encontrados utilizando-se Nielsen, quando analisados em
termos percentuais em relao quantidade total de problemas encontrados por cada conjunto
de heursticas.
Pelos resultados obtidos neste estudo, sugere-se que as heursticas propostas so mais adequadas que as de Nielsen para encontrarem problemas de menor severidade (graus 1 e 2). Os
problemas catastrficos tambm foram mais efetivamente encontrados, ao passo que o nmero
91
92
CONCLUSAO
5.0
de problemas de grau 3 encontrados por cada conjunto de heursticas analisado foi praticamente
o mesmo. Tendo em vista que o processo de desenvolvimento de software composto por etapas
que evoluem o sistema com o passar do tempo, pode ser uma abordagem interessante a grupos
de desenvolvimento realizar avaliaes heursticas com as heursticas propostas neste trabalho
em etapas iniciais de desenvolvimento para encontrarem um nmero maior de problemas, bem
como os problemas catastrficos, e executar a avaliao tradicional em etapas posteriores, caso
desejem encontrar problemas graves que no tiverem sido encontrados anteriormente. Contudo, pelos resultados obtidos, sugere-se que o nmero de problemas novos encontrados pelas
avaliaes de Nielsen no seria expressivo.
Os resultados das avaliaes utilizando-se as heursticas propostas foram expressivos, mas
no foram ideais, porque alguns problemas s foram detectados utilizando-se as heursticas de
Nielsen. Por conta disso, levantou-se possibilidade de se reestruturarem as heursticas com
base nesses problemas. Contudo, observou-se que todos os problemas encontrados por Nielsen
poderiam ter sido associados em pelo menos uma heurstica para avaliao de interfaces de
dispositivos mveis.
Em relao ao nmero de heursticas associadas a um nico problema, notou-se uma variao maior no caso das novas heursticas, ou seja, para um dado problema, normalmente
mais heursticas novas foram associadas a ele que heursticas de Nielsen. Essa caracterstica
agrega ao novo conjunto de heursticas uma vantagem e uma limitao em relao ao conjunto
tradicional: especialistas tendem a levar menos tempo para associar um problema a uma heurstica, mas provavelmente as heursticas tradicionais so mais bem elaboradas no sentido de
no darem margem associao de muitas heursticas a um nico problema.
As heursticas propostas neste trabalho podem ser usadas para avaliar a interface de dispositivos mveis de diversos tamanhos de tela e, em nossos experimentos, todas as dificuldades
encontradas pelos usurios finais que usaram o aplicativo criado no Laboratrio de Sistemas
Web e Multimdia Interativos do ICMC poderiam ter sido identificadas pelas heursticas propostas. Alm disso, apenas uma dificuldade no teria sido suprimida caso uma nova verso do
aplicativo que contemplasse as correes dos problemas encontrados por tais heursticas tivesse
sido criada.
As diretrizes propostas renem as recomendaes de design dos componentes bsicos de
interface que se encontram nos aplicativos de dispositivos mveis diversos. O formato do documento facilita a leitura e a compreenso de cada componente, explanando as especificidades de
cada item de acordo com os sistemas operacionais estudados. O mestrando acredita que no
haja documentao semelhante disponvel, especialmente no idioma Portugus.
Como um possvel trabalho futuro, pode-se citar a incluso de novos parmetros humanos
relativos forma com a qual usurios interagem com dispositivos computacionais de forma geral, e com dispositivos mveis de forma especfica, que esto em constante evoluo e possuem
a dificuldade da interdisciplinaridade, j que eles dependem de resultados da Psicologia, Sociologia, entre outras reas. Da mesma forma, os componentes de interface podem mudar com o
passar dos anos, tornando-se necessria a revisitao das diretrizes expostas neste trabalho.
Outra atividade futura seria a realizao de avaliaes heursticas com o aplicativo de anotaes multimdia descrito na Seo 3.2.1 com as heursticas propostas por Bertini et al. [2006], a
fim de comparar os resultados obtidos com essas avaliaes com os obtidos neste trabalho.
As avaliaes heursticas deste trabalho foram realizadas separadamente em dias distintos
com cada especialista, mas os resultados obtidos foram analisados numa mesma verso do
aplicativo e em paralelo de acordo com cada grupo de 5 especialistas. Seria interessante analisar
o impacto de se realizarem avaliaes heursticas usando as heursticas propostas em verses
5.0
93
iniciais de interfaces e as heursticas de Nielsen em verses posteriores e vice-versa.

Este trabalho levou em considerao aspectos intrnsecos camada de visualizao de software. Existem, porm, pesquisas que visam criao de heursticas que abranjam outras questes, como economia de energia e integrao com tecnologias assistivas para suporte a acessibilidade, por exemplo.
94
CONCLUSAO
5.0
Referencias bibliograficas
Apple (2010). iOS UI Element Usage Guidelines. Technical report. [Accessed March 2013].
Available from:
http://developer.apple.com/library/ios/#documentation/UserExperience/
Conceptual/MobileHIG/UIElementGuidelines/UIElementGuidelines.html#//apple_ref/doc/uid/
TP40006556-CH13-SW1.
Arhippainen, L. and Thti, M. (2003). Empirical Evaluation of User Experience in Two Adaptive
Mobile Application Prototypes. pages 2734. ACM. [Accessed March 2013]. Available from:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.99.7147&rep=rep1&type=pdf.
Balagtas-Fernandez, F. and Hussmann, H. (2009).
Evaluation of User-Interfaces for Mo-
bile Application Development Environments. In Proceedings of the 13th International Conference on Human-Computer Interaction. Part I: New Trends, pages 204213, Berlin, Heidelberg. Springer-Verlag. [Accessed March 2013]. Available from: http://dx.doi.org/10.1007/
978-3-642-02574-7_23.
Bennett, J. L. (1979). The Commercial Impact of Usability in Interactive Systems. HumanComputer Communication, volume 2.
Bertini, E., Gabrielli, S., and Kimani, S. (2006). Appropriating and Assessing Heuristics for
Mobile Computing. In Proceedings of the Working Conference on Advanced Visual Interfaces,
AVI 06, pages 119126, New York, NY, USA. [Accessed March 2013]. Available from: http:
//doi.acm.org/10.1145/1133265.1133291.
Bigonha, C., Cardoso, T. N. C., Moro, M. M., Almeida, V. A. F., and Gonalves, M. A. (2010).
Detecting Evangelists and Detractors on Twitter. In Simpsio Brasileiro de Sistemas Multimdia
e Web.
Blackberry (2012).
Blackberry Smartphones: UI Guidelines.
Technical report.
[Accessed
March 2013]. Available from: http://docs.blackberry.com/en/developers/deliverables/17964/

BlackBerry_Smartphones-UI_Guidelines-T893501-980426-0721013746-001-6.0-US.pdf.
Blackmon, M. H., Polson, P. G., Kitajima, M., and Lewis, C. (2002). Cognitive Walkthrough for
the Web. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems:
Changing our World, Changing Ourselves, CHI 02, pages 463470, New York, NY, USA. ACM.
[Accessed March 2013]. Available from: http://dx.doi.org/10.1145/503376.503459.
Bonifcio, B., Viana, D., Vieira, S., Arajo, C., and Conte, T. (2010). Aplicando tcnicas de
inspeo de usabilidade para avaliar aplicaes mveis. In Proceedings of the IX Symposium on
95
96
REFERENCIAS
BIBLIOGRAFICAS
5.0
Human Factors in Computing Systems, IHC 10, pages 189192, Porto Alegre, Brazil. Brazilian
Computer Society. [Accessed March 2013]. Available from: http://dl.acm.org/citation.cfm?
id=1999593.1999615.
Brace, I. (2004). Questionnaire Design: How To Plan, Structure And Write Survey Material For
Effective Market Research. Kogan Page Business Books, Creative Print and Design, United
Kingdom.
Bradburn, N., Sudman, S., and Wansink, B. (2004). Asking Questions: The Definitive Guide to
Questionnaire Design For Market Research, Political Polls, and Social and Health Questionnaires. Research Methods for the Social Sciences. Wiley. [Accessed March 2013]. Available from:
http://books.google.com.br/books?id=YXKbTx2j9i4C.
Cooper, A. (1995). About Face: The Essentials of User Interface Design. John Wiley & Sons.
Available from: http://books.google.com.br/books?id=htxQAAAAMAAJ.
Coyne, S. and Coyne, K. (2011). Seven Steps to Better Brainstorming. Accessed March 2013. Available from: http://www.mckinseyquarterly.com/Seven_steps_to_better_brainstorming_2767.
Dickerson, S. (2004). Acute Stressors and Cortisol Responses: A Theoretical Integration and
Synthesis of Laboratory Research. Psychological Bulletin, 130(3):355391.
Dienstbier,
R. A. (1989).
Physical
Arousal and Physiological Toughness:
Mental
and
Health.
100.
[Accessed March 2013].
Psychiatry
and
Available from:
Psychology
Implications for
Commons,
96(1):84
http://www.biomedsearch.com/nih/
Arousal-physiological-toughness-implications-mental/2538855.html.
Dimakopoulos, D. N. and Magoulas, G. D. (2009). Interface Design and Evaluation of a Personal
Information Space for Mobile Learners. International Journal of Mobile Learning and Organisation, 3(4):440463. [Accessed March 2013]. Available from: http://dx.doi.org/10.1504/IJMLO.
2009.027458.
Dix, A., Finlay, J. E., Abowd, G. D., and Beale, R. (2004). Human-Computer Interaction. PrenticeHall, Upper Saddle River, NJ, USA, 3rd edition.
Galitz, W. O. (2003). The Essential Guide to User Interface Design: An Introduction to GUI Design
Principles and Techniques. John Wiley & Sons, New York, NY, USA, 2nd edition.
Gatica-Perez, D. and Montoliu, R. (2010). Discovering Human Places of Interest from Multimodal
Mobile Phone Data. In Proceedings of the 9th International Conference on Mobile and Ubiquitous
Multimedia, MUM 10, pages 12:112:10, New York, NY, USA. ACM. Available from: http:
//doi.acm.org/10.1145/1899475.1899487.
Gazzalley, A. (2012). How Mobile Tech Can Influence Our Brain. [Part of Complete Coverage on
Our Mobile Society. Special to CNN. Online: Accessed on 03-2013].
Gonalves, V. P., Neris, V. P. A., Morandini, M., Nakagawa, E. Y., and Ueyama, J. (2011). Uma
Reviso Sistemtica sobre Mtodos de Avaliao de Usabilidade Aplicados em Software de
Telefones Celulares. In Proceedings of the 10th Brazilian Symposium on on Human Factors in
Computing Systems and the 5th Latin American Conference on Human-Computer Interaction,
IHC e CLIHC 11, pages 197201, Porto Alegre, Brazil. Brazilian Computer Society. [Accessed
March 2013]. Available from: http://dl.acm.org/citation.cfm?id=2254436.2254470.
5.0
REFERENCIAS
BIBLIOGRAFICAS
97
Gong, J. and Tarasewich, P. (2011). Guidelines for Handheld Mobile Device Interface Design.
In Proceedings of the 2004 DSI Annual Meeting. Accessed March 2013. Available from: http:
//citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.87.5230.
Goodman, R. and Lawless, M. (1994). Technology and Strategy: Conceptual Models and Diagnostics. Oxford University Press, United Kingdom. Available from: http://books.google.com.br/
books?id=ii3SmAEACAAJ.
Google (2012a). Design: Android Developers. Technical report. [Accessed March 2013]. Available
from: http://developer.android.com/design/index.html.
Google (2012b). Google Play. [Accessed March 2013]. Available from: https://play.google.com/
store.
Grasso, A. and Roselli, T. (2005). Guidelines for Designing and Developing Contents for Mobile
Learning. In Proceedings of the IEEE International Workshop on Wireless and Mobile Technologies in Education, WMTE 05, pages 123127, Washington, DC, USA. IEEE Computer Society.
[Accessed March 2013]. Available from: http://dx.doi.org/10.1109/WMTE.2005.27.
Hagen, P., Robertson, T., Kan, M., and Sadler, K. (2005). Emerging Research Methods for
Understanding Mobile Technology Use. In Proceedings of the 17th Australia conference on
Computer-Human Interaction: Citizens Online: Considerations for Today and the Future, OZCHI 05, pages 110, Narrabundah, Australia. [Accessed March 2013].
http://dl.acm.org/citation.cfm?id=1108368.1108417.
Available from:
Harrison, C., Amento, B., Kuznetsov, S., and Bell, R. (2007). Rethinking the progress bar. In
Proceedings of the 20th Annual ACM Symposium on User Interface Software and Technology,
UIST 07, pages 115118, New York, NY, USA. ACM. [Accessed March 2013]. Available from:
http://doi.acm.org/10.1145/1294211.1294231.
Hayhoe, G. (2001). From Desktop to Palmtop: Creating Usable Online Documents for Wireless
and Handheld Devices. In Professional Communication Conference, 2001. IPCC 2001. IEEE
International, pages 111.
Helander, M. (1997). Handbook of Human-Computer Interaction. North-Holland, 2nd edition.
Available from: http://books.google.com.br/books?id=2-FQAAAAMAAJ.
Henry, J. P. and Grim, C. (1990). Psychosocial Mechanisms of Primary Hypertension. J Hypertens, 8(9):783793. [Accessed March 2013]. Available from: http://www.biomedsearch.com/
nih/Psychosocial-mechanisms-primary-hypertension/2172367.html.
Iqbal, S. T. and Horvitz, E. (2007). Disruption and recovery of computing tasks: Field study,
analysis, and directions. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI 07, pages 677686, New York, NY, USA. ACM. [Accessed March 2013].
Available from: http://doi.acm.org/10.1145/1240624.1240730.
ISO (1998). ISO 9241-11: Ergonomic Requirements for Office Work with Visual Display Terminals (VDTs) - Part 11 : Guidance on Usability. Technical report, International Organization for
Standardization, Geneva.
ISO/IEC (2001). ISO/IEC 9126. Software Engineering Product Quality. Technical report,
International Organization for Standardization, Geneva.
98
REFERENCIAS
BIBLIOGRAFICAS
5.0
Ji, Y. G., Park, J. H., Lee, C., and Yun, M. H. (2006). A Usability Checklist for the Usability Evaluation of Mobile Phone User Interface. International Journal of Human-Computer Interaction,
20(3):207231. [Accessed March 2013]. Available from: http://www.leaonline.com/doi/abs/
10.1207/s15327590ijhc2003_3?journalCode=ijhc.
Jones, M. and Marsden, G. (2006). Mobile Interaction Design. Proceedings of the 7th international
conference on Human computer interaction with mobile devices services MobileHCI 05, 1:369.
[Accessed March 2013]. Available from: http://portal.acm.org/citation.cfm?doid=1085777.
1085872.
Kantore, A. (2011).
User-Interface Evaluation Metrics for a Typical M-Learning Application.
The School of Information Communication and Technology. Nelson Mandela Metropolitan

University. [Accessed March 2013]. Available from: http://books.google.com.br/books?id=
YXKbTx2j9i4C.
Kjeldskov, J. and Stage, J. (2004). New Techniques for Usability Evaluation of Mobile Systems.
International Journal of Human-Computer Studies, 60:599620.
Koyani, S. J., Bailey, R. W., and Nall, J. R. (2003). Research-Based Web Design & Usability Guidelines. Computer Psychology. Available from: http://www.amazon.com/exec/obidos/redirect?
tag=citeulike07-20&path=ASIN/0974996904.
Krumm, J. (2010). Processing Sequential Sensor Data. In Ubiquitous Computing Fundamentals,
pages 353380. Chapman & Hall/CRC, Boca Raton, FL, 1st edition.
Kunjachan, C. (2011). Evaluation of Usability on Mobile User Interface. University of Washington, Bothell, USA.
Lai, V. S. and Mahapatra, R. K. (1997). Exploring the Research in Information Technology Implementation. Information & Management, 32(4):187201. [Accessed February 2013]. Available
from: http://dx.doi.org/10.1016/S0378-7206(97)00022-0.
Luchini, K., Quintana, C., Krajcik, J., Farah, C., Nandihalli, N., Reese, K., Wieczorek, A., and
Soloway, E. (2002). Scaffolding in the Small: Designing Educational Supports for Concept
Mapping on Handheld Computers. In CHI 02 Extended Abstracts on Human Factors in Computing Systems, CHI 02, pages 792793, New York, NY, USA. ACM. [Accessed January 2013].
Available from: http://dx.doi.org/10.1145/506443.506600.
Lupien, S. J., Maheu, F., Tu, M., Fiocco, A., and Schramek, T. E. (2007). The effects of stress and
stress hormones on human cognition: Implications for the field of brain and cognition. Brain
and Cognition, 65(3):209237. Available from: http://www.ncbi.nlm.nih.gov/pubmed/17466428.
Lynch, P. and Horton, S. (2001). Web Style Guide: Basic Design Principles for Creating Web Sites.
Yale University Press. [Accessed March 2013]. Available from: http://books.google.com.br/
books?id=gGbCQgAACAAJ.
MacKenzie, I. S. and Zhang, S. X. (1999). The Design and Evaluation of a High-Performance Soft
Keyboard. In Proceedings of the SIGCHI conference on Human Factors in Computing Systems,
CHI 99, pages 2531, New York, NY, USA. ACM. [Accessed March 2013]. Available from:
http://doi.acm.org/10.1145/302979.302983.
5.0
REFERENCIAS
BIBLIOGRAFICAS
99
Matera, M., Rizzo, F., Carughi, G. T., and Milano, P. (2006). Web Usability: Principles and
Evaluation Methods. In Mendes, E. and Mosley, N., editors, Web engineering, pages 144
166. Springer. [Accessed March 2013]. Available from: http://www.springerlink.com/index/
hp5t836gxxv33m47.pdf.
Mattar, F. (1999). Pesquisa de Marketing: Metodologia e Planejamento. Pesquisa de marketing.
Atlas. Available from: http://books.google.com.br/books?id=Jcr1PgAACAAJ.
Maule, A. and Hockey, G. (1993). State, Stress, and Time Pressure. In Time Pressure and Stress
in Human Judgment and Decision Making, pages 83101. Springer US. [Accessed March 2013].
Available from: http://dx.doi.org/10.1007/978-1-4757-6846-6_6.
McGrenere, J., Baecker, R. M., and Booth, K. S. (2002). An Evaluation of a Multiple Interface
Design Solution for Bloated Software. In Proceedings of the SIGCHI Conference on Human
Factors in Computing Systems, CHI 02, pages 164170, New York, NY, USA. ACM. [Accessed
March 2013]. Available from: http://doi.acm.org/10.1145/503376.503406.
Microsoft (2013). User Experience Design Guidelines for Windows Phone. Technical report. [Accessed March 2013]. Available from: http://msdn.microsoft.com/en-us/library/windowsphone/
design/hh202915(v=vs.92).aspx.
Moraveji, N. and Soesanto, C. (2012). Towards Stress-Less User Interfaces: 10 Design Heuristics
Based on the Psychophysiology of Stress. In Extended Abstracts on Human Factors in Computing Systems, CHI EA 12, pages 16431648, New York, NY, USA. ACM. [Accessed March 2013].
Available from: http://doi.acm.org/10.1145/2212776.2223686.
Mullet, K. and Sano, D. (1995). Designing Visual Interfaces: Communication Oriented Techniques.
Communication oriented techniques. SunSoft Press. Available from: http://books.google.com.
br/books?id=LCYPAQAAMAAJ.
Nass, C., Steuer, J., and Tauber, E. R. (1994). Computers are Social Actors. In Proceedings of
the SIGCHI Conference on Human Factors in Computing Systems, CHI 94, pages 7278, New
York, NY, USA. ACM. [Accessed March 2013]. Available from: http://doi.acm.org/10.1145/
191666.191703.
Nielsen, J. (1993). Usability Engineering. Morgan Kaufmann Publishers, San Francisco, CA,
USA.
Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J. and Mack, R. L., editors, Usability Inspection Methods, pages 2562. John Wiley & Sons, New York, NY, USA. [Accessed March 2013].
Available from: http://dl.acm.org/citation.cfm?id=189200.189209.
Nielsen, J. and Molich, R. (1990). Heuristic evaluation of User Interfaces. In Proceedings of the
SIGCHI Conference on Human Factors in Computing Systems, CHI 90, pages 249256, New
York, NY, USA. ACM. [Accessed March 2013]. Available from: http://doi.acm.org/10.1145/
97243.97281.
Norman, D. (1988). The Design of Everyday Things. Number 842 in The Design of Everyday
Things. Bantam Doubleday Dell Publishing Group. Available from: http://books.google.com.
br/books?id=b09jQgAACAAJ.
Oinas-Kukkonen, H. and Kurkela, V. (2003). Developing Successful Mobile Applications. In
Computer Science and Technology. Available from: http://en.scientificcommons.org/42316819.
100
REFERENCIAS
BIBLIOGRAFICAS
5.0
Preece, J. (1994). Human-Computer Interaction. Concepts And Design. Ics Series. Addison-Wesley
Pub. Co. Available from: http://books.google.com.br/books?id=p99QAAAAMAAJ.
Robertson, G., Czerwinski, M., Baudisch, P., Meyers, B., Robbins, D., Smith, G., and Tan, D.
(2005). The large-display user experience. IEEE Computer Graphics and Applications, 25(4):44
51. [Accessed March 2013]. Available from: http://dx.doi.org/10.1109/MCG.2005.88.
Rocha, H. V. and Baranauskas, M. C. C. (2003). Design e Avaliao de Interfaces HumanoComputador.
EdUnicamp.
Available from:
http://pan.nied.unicamp.br/download_livro/
livrodownload.html.
Rothwell, A. (1993). Questionnaire Design. De Montfort University. Kogan Press. Available from:
http://books.google.com.br/books?id=rnZ0MwEACAAJ.
Santos, P. J. N. (2008). Usabilidade em sistemas de realidade virtual: Estudos com utilizadores.
Masters thesis, Universidade de Aveiro, Portugal. [Acessed March 2013. Available from:
http://hdl.handle.net/10773/2059.
Seffah, A., Kececi, N., and Donyaee, M. (2001). QUIM: A Framework for Quantifying Usability
Metrics in Software Quality Models. In Asia-Pacific Conference on Quality Software, pages
311318.
Shackel, B. (1981). The Concept of Usability. In Proceedings of IBM Software and Information
Usability Symposium, pages 130, New York, NY, USA. IBM Corporation.
Shackel, B. (1991). Usabilitycontext, Framework, Definition, Design and Evaluation. In Human
Factors for Informatics Usability, pages 2137. Cambridge University Press, New York, NY, USA.
[Accessed March 2013]. Available from: http://dl.acm.org/citation.cfm?id=117829.117833.
Sharp, H., Rogers, Y., and Preece, J. (2007). Interaction Design: Beyond Human-Computer Interaction. Wiley, 2nd edition. [Accessed March 2013]. Available from: http://www.amazon.com/
exec/obidos/redirect?tag=citeulike07-20&path=ASIN/0470018666.
Shneiderman, B. and Plaisant, C. (2009). Designing the User Interface: Strategies for Effective
Human-Computer Interaction. Addison-Wesley Longman, Boston, MA, USA, 5th edition.
Siniscalco, M. T. and Auriat, N. (2005). Questionnaire Design. Sabine Lebeau, International
Institute for Educational Planning/UNESCO.
Smith, S. L. and Mosier, J. N. (1986). Guidelines for Designing User Interface Software. Technical report, The MITRE Corporation Bedford, Massachusetts, USA. [Prepared for Deputy
Commander for Development Plans and Support Systems, Electronic Systems Division, AFSC,
United States Air Force, Hanscom Air Force Base, Massachusetts].
Sutcliffe, A. (1995). Human-Computer Interface Design. Macmillan Computer Science Series.
Macmillan Press. Available from: http://books.google.com.br/books?id=gOVQAAAAMAAJ.
Torres, N. (1995). Competitividade Empresarial com a Tecnologia de Informao. Makron Books,
So Paulo. Available from: http://books.google.com.br/books?id=QBCiAQAACAAJ.
Tullis, T. and Albert, W. (2010). Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics. Morgan Kaufmann series in interactive technologies. Elsevier Science.
Available from: http://books.google.com.br/books?id=KsjpuMJ6T-YC.
REFERENCIAS
BIBLIOGRAFICAS
5.0
101
Ulrich, R. S., Simons, R. F., Losito, B. D., Fiorito, E., Miles, M. A., and Zelson, M. (1991).
Stress Recovery during Exposure to Natural and Urban Environments. Journal of Environmental Psychology, 11(3).
Available from: http://www.sciencedirect.com/science/article/
B6WJ8-4GK8NPT-1/2/aca5972eb250c78fd991457187117cc2.
Vtj, H. and Roto, V. (2010). Mobile Questionnaires for User Experience Evaluation. In
Extended Abstracts on Human Factors in Computing Systems, CHI EA 10, pages 33613366,
New York, NY, USA. ACM. [Accessed March 2013]. Available from: http://doi.acm.org/10.
1145/1753846.1753985.
Weiser, M. (1993). Some Computer Science Issues in Ubiquitous Computing. Communications of
the ACM, 36(7):7584. [Accessed March 2013]. Available from: http://doi.acm.org/10.1145/
159544.159617.
Wickens, C. D. and Hollands, J. G. (2000). Engineering Psychology and Human Performance,
volume 27. Prentice Hall. [Accessed March 2013]. Available from: http://webfiles.ita.
chalmers.se/~mys/HumanAspects/WickensHollands/0_Wickens_Index_Preface.pdf.
Williams, R. (2005). The Non-designers Design Book: Design and Typographic Principles for the
Visual Novice. Non Designers Design Book. Peachpit Press. Available from: http://books.
google.com.br/books?id=8IlqSMtWCk0C.
102
REFERENCIAS
BIBLIOGRAFICAS
Apendice
A
Arquivo de registros do usuario novato
1 START: 13:30:07 Brasilia Time

2 CHOOSE_USERNAME 1: 13:30:19 Brasilia Time
3 CHOOSE VIDEO 1: 13:30:30 Brasilia Time
4 CHOOSE AUTHOR 1: 13:30:40 Brasilia Time
5 EditText_TOUCH 13:30:53 Brasilia Time
5 ADD: 13:31:04 Brasilia Time
5 TEXT ANNOTATION: 13:31:04 Brasilia Time
5 INK_Ann_Enabled: 13:31:26 Brasilia Time
5 CONTEXT_INFO 13:31:31 Brasilia Time
IA: 13:31:42 Brasilia Time
5.1 Cancel: 13:31:53 Brasilia Time
5 INK ANNOTATION: 13:31:57 Brasilia Time
5 INK ANNOTATION: 13:31:58 Brasilia Time 5 INK ANNOTATION: 13:31:59 Brasilia Time
5 Audio_Ann_Enabled: 13:32:14 Brasilia Time
AA13:32:32 Brasilia Time
5.1 Navigate to108 at: 13:32:38 Brasilia Time
103
104
APENDICE
A

5 Audio_Ann_Disabled: 13:34:35 Brasilia Time
5 AUDIO ANNOTATION: 13:34:35 Brasilia Time
5.1 Remove: 13:35:10 Brasilia Time
5.2 OK: 13:35:13 Brasilia Time
5 TA 13:36:03 Brasilia Time
5.1 Edit:13:36:06 Brasilia Time
5.1 Navigate to 10 at: 13:36:10 Brasilia Time
5 SHARE: 13:36:28 Brasilia Time
5.1 Clear:13:36:49 Brasilia Time
5.2 OK:13:36:50 Brasilia Time
5.1 Edit: 13:36:56 Brasilia Time

ARQUIVO DE REGISTROS DO USUARIO
NOVATO

105
106
APENDICE
A
Apendice
B
Arquivo de registros do usuario intermediario

5 EditText_ENTER ADD: 20:35:03 Brasilia Time
107
108
APENDICE
B

5 INK_Ann_Disabled: 20:37:41 Brasilia Time
5 SeekBar: 136202277357820:39:33 Brasilia Time
5 AUDIO ANNOTATION: 20:39:33 Brasilia Time
5 Pushed PLAY: 136202277750220:39:37 Brasilia Time
ARQUIVO DE REGISTROS DO USUARIO

INTERMEDIARIO

5.1 Navigate to1804 at:20:43:25 Brasilia Time
5.1 Clear: 20:44:05 Brasilia Time
109
110
APENDICE
B
Apendice
C
Ilustracoes dos componentes de interface para
dispositivos moveis
Seo 4.3 foram descritas recomendaes de uso dos componentes de interface para o
design de interfaces para dispositivos mveis com foco em usabilidade. Um paralelo das
diferentes terminologias usadas por cada empresa que disponibiliza essas recomenda-
es foi realizado, mas no se mostrou o aspecto visual de cada componente, de acordo com cada
empresa. Esse apndice contm ilustraes de cada componente, para que o interessado no design dessas interfaces consiga elaborar layouts que possam ser implementados na tecnologia
escolhida.
Cada ilustrao de componente acompanhada por uma letra, que indica o sistema operacional refente a ele.
111
112
APENDICE
C
Figura C.1: Barra de Abas. A) Android; B) iOS; C) Windows Phone.
Figura C.2: Barra de Atividades. A) Android; B) iOS.
ILUSTRAC
OES
DOS COMPONENTES DE INTERFACE PARA DISPOSITIVOS MOVEIS
Figura C.3: Barra de navegaca

o. A) Android; B) iOS.
Figura C.4: Barra de progresso. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.5: Barra de status. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.6: Barra deslizante de ajuste. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
113
114
APENDICE
C
Figura C.7: Barra inferior. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.8: Bot

ao. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.9: Caixa de m

ultipla escolha. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.10: Caixa de selec

ao. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.11: Campo de busca. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
ILUSTRAC
OES
Figura C.12: Campo de texto. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.13: Di
alogo. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.14: Girador de progresso. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.15: Link. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
115
116
APENDICE
C
Figura C.16: Lista. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.17: Menu popup. A) Android; B) Blackberry.
Figura C.18: Radio button. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.19: Seletor de arquivos. A) Blackberry.
ILUSTRAC
OES
Figura C.20: Seletor de data. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.21: Seletor de hora. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.22: Seletor numerico. A) Android; B) iOS; C) Windows Phone.
Figura C.23: Submenu. A) Android; B) Windows Phone.
117
118
APENDICE
C
Figura C.24: Switch. A) Android; B) Blackberry; C) iOS; D) Windows Phone.
Figura C.25: Tabela. A) Android; B) Blackberry; C) iOS; D) Windows Phone.

Disser Tac A Ool I Bario

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Disser Tac A Ool I Bario

Uploaded by

Copyright:

Available Formats

Usabilidade da interface de dispositivos mveis:

heursticas e diretrizes para o design

Olibrio Jos Machado Neto

Usabilidade da interface de dispositivos mveis:

Olibrio Jos Machado Neto

Orientadora: Profa. Dra. Maria da Graa Campos Pimentel

Dissertao apresentada ao Instituto de Cincias

Ficha catalogrfica elaborada pela Biblioteca Prof. Achille Bassi

Jos Machado Neto, Olibrio

1.2 Identificao do problema

1.6 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 Questo de pesquisa

2 Recursos para construo de interfaces com usabilidade

2.1 Diretrizes (Guidelines) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1 Diretrizes para criao de interfaces de dispositivos computacionais em geral

2.1.2 Diretrizes para criao de interfaces de dispositivos mveis . . . . . . . . . . . 13

3.1 Elaborao das heursticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Proposio das heursticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

A Arquivo de registros do usurio novato

B Arquivo de registros do usurio intermedirio

C Ilustraes dos componentes de interface para dispositivos mveis

Exemplo de componente de texto contendo informaes como dicas ao usurio no

Exemplo de mensagem de erro bem-humorada. . . . . . . . . . . . . . . . . . . . . . . 23

Exemplo de interface desmistificada [Moraveji e Soesanto, 2012]. . . . . . . . . . . . 24

Exemplo bem sucedido de aplicao do princpio CARP de repetio a uma pgina

Processo de design. [Dix et al., 2004] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Tela inicial do aplicativo de anotao multimdia em vdeos. . . . . . . . . . . . . . . 34

Tela para seleo de vdeo a ser anotado. . . . . . . . . . . . . . . . . . . . . . . . . . 35

Tela em que o usurio escolhe o autor do vdeo a ser anotado. . . . . . . . . . . . . . 36

Tela principal da aplicao de anotao de vdeos. . . . . . . . . . . . . . . . . . . . . 36

Formato das diretrizes para criao de interfaces de dispositivos mveis. . . . . . . . 39

Relao entre o nmero de problemas encontrados por cada grau de severidade. . . 63

Percentual de problemas encontrados com cada grau de severidade. . . . . . . . . . 64

Quantidade de problemas associados a cada heurstica de Nielsen. . . . . . . . . . . 64

Quantidade de problemas associados a cada heurstica para avaliao de interfaces

Cdigo-fonte responsvel pela criao e gravao do arquivo de registros de aes

Trecho de um dos arquivos gravados no carto SD do dispositivo mvel. . . . . . . . 67

Barra de Abas. A) Android; B) iOS; C) Windows Phone. . . . . . . . . . . . . . . . . . 112

Barra de Atividades. A) Android; B) iOS. . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Barra de navegao. A) Android; B) iOS. . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Barra de progresso. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . 113

Barra de status. A) Android; B) Blackberry; C) iOS; D) Windows Phone.

Barra deslizante de ajuste. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . 113

Barra inferior. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . . 114

Boto. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . . . . . . 114

Caixa de mltipla escolha. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . 114

C.10 Caixa de seleo. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . 114

C.13 Dilogo. A) Android; B) Blackberry; C) iOS; D) Windows Phone. . . . . . . . . . . . . 115

Relao entre aplicativos avaliados e principais funcionalidades que cada um deles

Categorizao dos problemas encontrados nas interfaces do Facebook. . . . . . . . . 41

Categorizao dos problemas encontrados nas interfaces do Foursquare. . . . . . . 43

Categorizao dos problemas encontrados nas interfaces do Gmail. . . . . . . . . . . 43

Categorizao dos problemas encontrados nas interfaces do Twitter. . . . . . . . . . 44

Associao das categorias encontradas s heursticas de Nielsen. . . . . . . . . . . . 45

Heursticas revisadas de Nielsen traduzidas por Rocha e Baranauskas [2003]. . . . 51

Barra Deslizante de Ajuste.

4.10 Caixa de seleo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.12 Campo de texto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.17 Menu Popup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.19 Seletor de Arquivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.21 Seletor Numrico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

A evoluo das tecnologias de informao (TIs) contribuiu grandemente para a agregao de

computadores, necessrio que ela possua boa usabilidade.