estudo da usabilidade em sistemas web para tablet · o trabalho de campo realizado neste estudo foi...
TRANSCRIPT
M 2014
ESTUDO DA USABILIDADE EM SISTEMAS WEB
PARA TABLET
DIANA FILIPA FERREIRA DE OLIVEIRA DISSERTAÇÃO DE MESTRADO APRESENTADA À FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO EM 23 DE JULHO DE 2014 MULTIMÉDIA
RESUMO
O objetivo principal deste estudo passa pela análise e contribuição para a melhoria da
usabilidade do SIGARRA, sistema de informação da UP. Na sequência desse objetivo surgem
outros importantes como a definição de boas práticas de usabilidade e enumeração dos
diferentes métodos de avaliação de usabilidade. O estudo focou-se nas funcionalidades do
sistema disponíveis para estudantes, em tablets.
A principal motivação para a realização do estudo relaciona-se com a contribuição para a
comunidade. Sendo o SIGARRA usado diariamente pela vasta comunidade da Universidade do
Porto, qualquer sugestão que permita a melhoria da utilização do mesmo por parte dos seus
utilizadores deve ser recebida positivamente. Outras motivações, relativas ao autor, dizem
respeito ao gosto pelo conhecimento assim como o interesse na área em que o estudo se
enquadra.
O trabalho de campo realizado neste estudo foi divido em duas fases. Na primeira fase, foi
avaliado o estado em que o sistema se encontrava no início do estudo e, na segunda fase, foram
elaboradas e avaliadas as soluções propostas para as situações problemáticas encontradas na
primeira fase.
Os resultados encontrados indicam que o estudo propôs diversas soluções válidas para o website
do SIGARRA de modo a ser visualizado em tablet, embora alguns aspetos ainda precisem de ser
melhor estudados e adaptados às necessidades dos utilizadores.
O estudo foi realizado segundo normas e documentação oficial com o objetivo de manter o
maior rigor e nível de profissionalismo possível.
ABSTRACT
The main goal of this study is contributing to the improvement of SIGARRA's usability. Other
goals include the definition of good practices for usability and the enumeration of methods for
evaluating usability. The study focused on the system's functionalities used primarily by students
on tablets.
The main motivation for this study is the possibility to contribute to the University of Porto’s
community. Since SIGARRA is used daily by a large academic community, any improvement to
the interaction between it and its users will be positive. Other author’s motivations are related
to passion for knowledge and this being an area of interest.
The field work in this study had two phases. In the first phase we evaluated the current system
status. In the second phase, solution proposals were created and evaluated to solve the issues
detected in the first phase.
Results show that the study had achieved some valid solutions for SIGARRA’s mobile website for
tablet. However, some issues can still be corrected to attend the user's needs.
The study was conducted by official standards and documentation so it could be as professional
and accurate as possible.
AGRADECIMENTOS
A realização desta dissertação não seria possível sem o contributo de diversas pessoas. Gostaria
de expressar o meu reconhecimento e os meus mais sinceros agradecimentos.
Em primeiro lugar, quero agradecer aos meus pais por me terem proporcionado condições para
que eu pudesse ter uma boa formação dentro das áreas que eu sempre gostei e por me terem
apoiado em todas as minhas decisões.
De seguida, quero agradecer a ambos os orientadores, Professores Bruno Giesteira e Miguel
Carvalhais, por todo o acompanhamento durante a dissertação. Os vossos conhecimentos,
conselhos e orientações foram indispensáveis.
Quero ainda agradecer ao colega Luís Mendes que esteve presente em diversas situações ao
longo do estudo. Teria sido bem mais complicado gerir o tempo disponível para a realização do
estudo sem diversas situações de entreajuda.
Por último, quero expressar o meu agradecimento à Dra. Lígia Ribeiro por ter dispensado algum
do seu precioso tempo para colaborar no nosso estudo com o seu imenso conhecimento do
SIGARRA, assim como aos diversos estudantes da UP que colaboraram no nosso estudo nas
diferentes etapas do mesmo.
ÍNDICE
Introdução ..................................................................................................................................... 1
1 SIGARRA ................................................................................................................................... 3
1.1 O Que é e Como Surgiu? ............................................................................................... 3
1.2 Arquitetura e Módulos .................................................................................................. 6
1.3 Estatísticas ..................................................................................................................... 9
1.4 Futuro do Sistema ....................................................................................................... 10
1.4.1 Usabilidade .......................................................................................................... 10
1.4.2 O SIGARRA como Ferramenta de Trabalho ......................................................... 12
1.5 Importância da Adaptação a Sistemas Móveis ........................................................... 12
2 Design de Interação ............................................................................................................... 14
2.1 Interação Humano-Computador ................................................................................. 14
2.1.1 Primeiras Interfaces ............................................................................................ 14
2.1.2 Interfaces Gráficas ............................................................................................... 16
2.1.3 Interfaces Gestuais .............................................................................................. 19
2.1.4 First Person User Interfaces ................................................................................. 23
2.1.5 Usabilidade .......................................................................................................... 24
2.2 Design Centrado no Utilizador .................................................................................... 39
2.3 Design de Interfaces Móveis ....................................................................................... 41
2.3.1 Tipos de Interação ............................................................................................... 42
2.3.2 Layout e Conteúdos ............................................................................................. 44
2.3.3 Diferenças entre Sistemas Operativos ................................................................ 53
2.3.4 Acessibilidade ...................................................................................................... 54
3 Métodos ................................................................................................................................. 57
3.1 Avaliação Heurística (Incluindo Estrutura de Lavery) ................................................. 58
3.2 Inquéritos .................................................................................................................... 62
3.2.1 Inquéritos SUS ..................................................................................................... 62
3.2.2 Vantagens e Desvantagens ................................................................................. 65
3.3 Entrevistas ................................................................................................................... 65
3.3.1 Vantagens e Desvantagens ................................................................................. 66
3.4 Personas ...................................................................................................................... 66
3.4.1 Tipologia .............................................................................................................. 67
3.4.2 Benefícios e Riscos .............................................................................................. 69
3.5 Cenários ....................................................................................................................... 71
3.5.1 Tipologia .............................................................................................................. 72
3.6 Prototipagem .............................................................................................................. 74
3.6.1 Tipos de Protótipos ............................................................................................. 74
3.6.2 Benefícios e Riscos Gerais ................................................................................... 76
3.6.3 Ferramentas de Prototipagem ............................................................................ 77
3.7 Testes de Usabilidade .................................................................................................. 78
3.7.1 Condições para a Realização dos Testes ............................................................. 81
3.7.2 Vantagens e Desvantagens ................................................................................. 82
3.7.3 Ferramentas de Análise de Dados ....................................................................... 83
3.8 Conversa Filmada ........................................................................................................ 84
3.8.1 Vantagens e Desvantagens ................................................................................. 84
3.9 Codescoberta .............................................................................................................. 85
3.9.1 Vantagens e Desvantagens ................................................................................. 85
3.10 Grupos de Foco ........................................................................................................... 86
3.10.1 Vantagens e Desvantagens ................................................................................. 86
3.11 Workshops de Utilizadores .......................................................................................... 87
3.11.1 Vantagens e Desvantagens ................................................................................. 87
3.12 Pensamento em Voz Alta ............................................................................................ 87
3.12.1 Vantagens e Desvantagens ................................................................................. 88
3.13 Listas de Verificação de Funcionalidades .................................................................... 88
3.13.1 Vantagens e Desvantagens ................................................................................. 88
3.14 Pesquisa de Campo ..................................................................................................... 89
3.14.1 Vantagens e Desvantagens ................................................................................. 89
4 Trabalho de Campo ................................................................................................................ 90
4.1 Fase Inicial ................................................................................................................... 90
4.1.1 Entrevistas ........................................................................................................... 90
4.1.2 Testes de Usabilidade e Inquéritos SUS .............................................................. 91
4.1.3 Análise Heurística ................................................................................................ 91
4.1.4 Personas e Cenários de Contexto ........................................................................ 92
4.2 Fase Final ..................................................................................................................... 93
4.2.1 Protótipos Passo-a-Passo .................................................................................... 93
4.2.2 Testes de Usabilidade e Inquéritos SUS ............................................................ 102
4.3 Conclusões Finais ...................................................................................................... 103
Conclusão .................................................................................................................................. 105
Trabalho Futuro ..................................................................................................................... 105
Referências Bibliográficas ......................................................................................................... 107
Apêndices .................................................................................................................................. 112
Apêndice 1 – Análise Comparativa de Ferramentas de Prototipagem ................................. 112
Apêndice 2 – Análise Comparativa de Ferramentas de Análise de Dados ............................ 117
Apêndice 3 – Entrevistas ....................................................................................................... 127
Apêndice 4 – Análise Heurística ............................................................................................ 132
Apêndice 5 – Personas e Cenários de Contexto .................................................................... 148
Apêndice 6 – Sistema Atual (Julho de 2014) ......................................................................... 154
Apêndice 7 – Protótipos em PowerPoint .............................................................................. 165
Apêndice 8 – Protótipos Finais .............................................................................................. 176
Apêndice 9 – Plano de Testes de Usabilidade ....................................................................... 187
Apêndice 10 – Protocolo de Testes de Usabilidade .............................................................. 190
Apêndice 11 – Relatório de Testes de Usabilidade ............................................................... 193
ÍNDICE DE FIGURAS
Figura 1. Arquitetura do SIGARRA ................................................................................................. 7
Figura 2. Gráfico de acessos na página de Estatísticas do SIGARRA ............................................. 9
Figura 3. Interface de Linha de Comandos do Windows 98........................................................ 15
Figura 4. IBM Sterling Gentran:Server Communications Module Interface ............................... 16
Figura 5. Sketchpad ..................................................................................................................... 16
Figura 6. Estação de Trabalho do NLS ......................................................................................... 17
Figura 7. GUI do XEROX 8010 Star ............................................................................................... 17
Figura 8.GUI Aqua no Mac OS X Leopard (10.5) – Outubro de 2007 .......................................... 18
Figura 9. Evolução das Interfaces segundo Reyes (2008) ........................................................... 20
Figura 10. Apple Newton ............................................................................................................. 20
Figura 11. Uma das várias tarefas possíveis de realizar no Videoplace ...................................... 20
Figura 12. Barbara Buchholz a tocar num Theremin................................................................... 21
Figura 13. Ciclo de vida do produto aplicado às interfaces (Wrobleski, 2011) ........................... 24
Figura 14. Exemplo de uma escala para inquéritos de satisfação (Nielsen, 1993) ..................... 27
Figura 15. Estrutura de Usabilidade (ISO 9241-11, 1998) ........................................................... 29
Figura 16. Relação entre os diferentes conceitos (Lowdermilk, 2013) ....................................... 39
Figura 17. Gestos básicos em interfaces tácteis (Wroblewski, 2011) ......................................... 43
Figura 18. Zona abrangida pelo polegar da mão direita ............................................................. 46
Figura 19. Botão "Edit" longe da zona de conforto do polegar .................................................. 46
Figura 20. Comparação da App Foursquare entre dispositivos Android (esquerda) e iPhone
(direita) ........................................................................................................................................ 47
Figura 21. Layout do website Ad Age Mobile como é visualizado no dispositivo e o seu
verdadeiro layout ........................................................................................................................ 48
Figura 22. Controlos principais situados na zona de conforto do polegar, conteúdos relevantes
no centro do ecrã ........................................................................................................................ 49
Figura 23. App do The Sydney Morning Herald .......................................................................... 50
Figura 24. Normas estabelecidas pela Microsoft em relação a tamanhos e distâncias entre
elementos .................................................................................................................................... 51
Figura 25. Tamanho recomendado (em pixéis) pela Apple para os elementos da UI ................ 52
Figura 26. Grelha de localizações de testes utilizada por Leitão (2012) ..................................... 52
Figura 27. Menu de Acessibilidade em Android (v4.1.1) ............................................................ 54
Figura 28. Exemplificação do VoiceOver em funcionamento ..................................................... 55
Figura 29. Utilização do atalho "Cyl" para escrever a expressão "Call You Later” ...................... 56
Figura 30. Fases de Desenvolvimento de um Novo Produto ...................................................... 57
Figura 31. Conjunto de funcionalidades disponibilizadas pela FUSAMI ..................................... 84
Figura 32. Botão de lupa com função de consulta de percurso académico ............................... 91
Figura 33. Página de erro na consulta de horário pessoal .......................................................... 92
Figura 34. Exemplo de opções do menu não filtradas ................................................................ 92
Figura 35. Ambiente de trabalho da FUSAMI para desenvolvimento de Apps ........................... 95
Figura 36. Código QR gerado ....................................................................................................... 96
Figura 37. Menu de criação de Apps ........................................................................................... 96
Figura 38. Barra de ferramentas da FUSAMI na criação de protótipos ...................................... 96
Figura 39. Opções de personalização dos ecrãs na elaboração de protótipos na FUSAMI ........ 97
Figura 40. Página inicial com menu expandido ........................................................................... 99
Figura 41. Página Pessoal .......................................................................................................... 100
Figura 42. Página de Cursos - Mestrados .................................................................................. 101
Figura 43. Lista Parcial de Elementos da UI do iOS Retina disponibilizados pela Proto.io ....... 112
Figura 44. Lista Parcial de Elementos de UI para iPhone disponibilizados pela Fluid UI .......... 113
Figura 45. Ambiente de trabalho da Moqups ........................................................................... 114
Figura 46. Ambiente de trabalho da Flinto ............................................................................... 115
Figura 47. Google Analytics ....................................................................................................... 117
Figura 48. Heat maps gerados pela ferramenta Heatmaps ...................................................... 118
Figura 49. Informações fornecidas pela ferramenta Heatmaps ............................................... 119
Figura 50. Heat maps gerados pela ferramenta Appsee ........................................................... 120
Figura 51. Exemplo de dados recolhidos pela Appsee .............................................................. 120
Figura 52. Delight em funcionamento....................................................................................... 121
Figura 53. Captura de ecrã realizada pela Lookback ................................................................. 122
Figura 54. Heat maps gerados pela ferramenta Crazyegg ........................................................ 123
Figura 55. Quantos utilizadores acederam a determinada hiperligação e a percentagem
correspondente ......................................................................................................................... 123
Figura 56. Scroll maps gerados pela ferramenta Crazyegg ....................................................... 124
Figura 57. Funcionalidade Confetti ........................................................................................... 124
ÍNDICE DE TABELAS
Tabela 1. Data de Adesão ao SIGARRA .......................................................................................... 5
Tabela 2. Graus de Severidade (Nielsen, 1995) .......................................................................... 34
Tabela 3. Princípios que afetam a capacidade de aprendizagem (Dix et al., 2004) .................... 34
Tabela 4. Princípios que afetam a flexibilidade do sistema (Dix et al., 2004) ............................. 35
Tabela 5. Princípios que afetam a robustez (Dix et al., 2004) ..................................................... 36
Tabela 6. Resumo e comparação entre testes tradicionais e método alternativo proposto por
Krug (2006) .................................................................................................................................. 82
Tabela 7. Tabela Comparativa de Ferramentas de Prototipagem ............................................ 116
Tabela 8. Tabela Comparativa de Ferramentas de Análise de Dados ....................................... 126
ÍNDICE DE GRÁFICOS
Gráfico 1. Pontos fortes das Personas (Santos, 2012) ................................................................ 70
Gráfico 2. Pontos fracos das Personas (Santos, 2012) ................................................................ 70
Gráfico 3. Relação entre o número de utilizadores testados e a totalidade de erros de
usabilidade descobertos (Nielsen, 2000) .................................................................................... 81
ÍNDICE DE ABREVIATURAS
API - Application programming interface
app - aplicação
BI - Business Intelligence
CDUP – Centro Desportivo da Universidade do Porto
CEO – Chief Executive Officer
CRIS - Current Research Information System
CSS – Cascading Style Sheets
CSUQ - Computer System Usability Questionnaire
CVP – Ciclo de Vida do Produto
DCU – Design Centrado no Utilizador
ERASMUS - European Community Action Scheme for the Mobility of University Students
EUNIS - European University Information Systems
FADEUP – Faculdade de Desporto da Universidade do Porto
FAQ – Frequently Asked Questions
FAUP – Faculdade Arquitetura da Universidade do Porto
FBAUP - Faculdade de Belas Artes da Universidade do Porto
FCNAUP – Ciências da Nutrição e Alimentação
FCUP – Faculdade de Ciências da Universidade do Porto
FDUP - Faculdade de Direito da Universidade do Porto
FEP – Faculdade de Economia do Porto
FEUP - Faculdade de Engenharia da Universidade do Porto
FFUP - Faculdade de Farmácia da Universidade do Porto
FLUP – Faculdade de Letras da Universidade do Porto
FMDUP – Faculdade de Medicina Dentária da Universidade do Porto
FPCEUP - Faculdade de Psicologia e Ciências da Educação da Universidade do Porto
FPUI - First Person User Interfaces
FUSAMI - Fraunhofer Usage Mining
GA – Gestão Académica
GPS - Global Positioning System
GRH – Gestão de Recursos Humanos
HTML – HyperText Markup Language
ICBAS – Instituto de Ciências Biomédicas Abel Salazar
ID - Identificação
IG - Interfaces Gráficas
IHC - Interação Humano-Computador
ILC - Interfaces de Linha de Comandos
IN – Interfaces Naturais
IP - Internet Protocol
IRICUP – Instituto de Recursos e Iniciativas Comuns
ISO - International Organization for Standardization
JS - JavaScript
NLS - oN-Line System
PAD - Pedido de Autorização de Despesas
PARC - Palo Alto Research Center
QR - Quick Response
REIT – Reitoria
SASUP – Serviços de Ação Social da Universidade do Porto
SDK – Software Development Kit
SI – Sistema de Informação
SIADAP - Sistema Integrado de Avaliação de Desempenho da Administração Pública
SIADUP - Sistema Integrado de Avaliação de Desempenho da Universidade do Porto
SiFEUP – Sistema de Informação da Faculdade de Engenharia da Universidade do Porto
SIGARRA - Sistema de Informação para a Gestão Agregada dos Recursos e dos Registos
Académicos
SMA – Secretariado para a Modernização Administrativa
SO – Sistema Operativo
SPUP – Serviços Partilhados da Universidade do Porto
SQL - Structured Query Language
SUS - System Usability Scale
SWOT - Strenghts, Weaknesses, Opportunities, Threats
UI – User Interface
UO – Unidades Orgânicas
UP – Universidade do Porto
URL – Uniform Resource Locator
XML - Extensible Markup Language
WIMP - Windows, Icons, Menus, Pointer
1
INTRODUÇÃO
Se há algumas décadas atrás poucas pessoas tinham acesso a computadores e era necessário
ter conhecimentos relativamente à sua manipulação, hoje em dia uma boa parte da população
mundial possui um ou mais dispositivos deste tipo, sejam estes portáteis ou não. Esta realidade
leva a que as interfaces dos sistemas tenham evoluído de modo a facilitar a compreensão e
interação com os sistemas. Deste modo, o objetivo do design de interação é levar o utilizador
mais inexperiente a conseguir cumprir os seus objetivos sem encontrar obstáculos críticos e é
nesta linha de pensamento que surge o conceito de usabilidade, aliado ao design centrado no
utilizador.
Sendo uma ferramenta utilizada no dia-a-dia e com já algum tempo de existência, torna-se
particularmente interessante avaliar a usabilidade do SIGARRA da UP. Apesar da dimensão deste
sistema apenas permitir que nesta dissertação o foque recaia sobre a área dos estudantes, é do
interesse da comunidade a elaboração de uma avaliação da usabilidade do sistema e
apresentação de soluções a possíveis problemas encontrados. Os estudantes foram escolhidos
devido a serem a maior parte da comunidade académica que interage com o sistema, além de
possuir um nível de familiaridade maior e ser mais fácil de encontrar participantes para os testes.
O estudo foi ainda restringido a seis unidades orgânicas (FADEUP, FCUP, FEP, FEUP, FLUP e
FMDUP) da UP, não tendo existido nenhum critério em particular para a escolha das UO
mencionadas.
Com o surgimento dos dispositivos moveis como os smartphones e os tablets, novos tipos de
interação surgiram, levando à necessidade de explorar essas novas tecnologias e estudar quais
seriam os melhores métodos para facilitar a interação entre os sistemas e os utilizadores. O facto
de estes serem portáteis e poderem ser utilizados em qualquer lado, praticamente em qualquer
postura corporal, requer uma consideração adicional relativamente à área da ergonomia.
Também a nível de acessibilidade, novas técnicas foram implementadas para que estes
pudessem ser manipulados por qualquer indivíduo.
Atualmente, o SIGARRA da UP não suporta dispositivos móveis, ou seja, não existe nenhuma
versão online do website pensada para este tipo dispositivos, não existe design responsivo e não
existe nenhuma aplicação no mercado para nenhum dos sistemas operativos que permita
recolher informações do sistema. O estudo limita-se ao estudo do SIGARRA em tablets.
Enquanto uma abordagem mais alargada em termos de dispositivos móveis poderia trazer um
2
nível de rigor menor devido à duração prevista do estudo, focar apenas em tablets permite um
nível de rigor superior relativamente às conclusões retiradas.
Os testes de usabilidade e as opiniões sobre as variáveis relativas aos mesmos (número de
utilizadores, frequência, entre outros) foram variando com os tempos. Se, por exemplo,
inicialmente tinham de ser realizados com 1 grande amostra em locais especializados,
atualmente é perfeitamente aceitável estes serem realizados com uma amostra
consideravelmente mais reduzida, sem necessidade de recorrer a laboratórios indicados para o
fim. Mas a usabilidade não é só medida através dos testes de usabilidade. Outros métodos como
as personas, as entrevistas ou grupos de foco, contribuem para um aperfeiçoamento da mesma.
Esta dissertação irá abordar em primeiro lugar o SIGARRA da UP, seguido dos capítulos relativos
ao Design de Interação e Métodos. Por último, o destaque será para o trabalho de campo
realizado em todo o estudo.
3
1 SIGARRA
1.1 O QUE É E COMO SURGIU?
Os principais objetivos do SIGARRA da Universidade do Porto, Sistema de Informação para a
Gestão Agregada dos Recursos e dos Registos Académicos, passam pela promoção da eficiência
e eficácia das atividades em diversos níveis de administração e gestão, ensino, investigação e
desenvolvimento e extensão universitária. O SIGARRA é constituído por três componentes
principais: GA, SiFEUP e GRH.
A GA1, aplicação de Gestão Académica, surgiu em 1992 e foi desenvolvida na Reitoria para os
Serviços Académicos das Faculdades. Originalmente, a GA era utilizada por todas as unidades
orgânicas à exceção da FCUP2 que utilizava o seu próprio sistema, o Infociências3. A GRH,
aplicação de Gestão de Recursos Humanos, foi desenvolvida, tal como a GA, na Reitoria em
1999.
O SiFEUP, Sistema de Informação académico da FEUP4, surgiu em 1996 através de uma iniciativa
por parte do Reitor da FEUP à data, o Doutor Marques dos Santos. A Reitoria da FEUP, sendo ela
uma das unidades orgânicas de maior dimensão na UP, precisava constantemente de recolher
informação dos seus mais variados departamentos. Essa informação chegava com muito atraso
e não era uniforme, pois cada departamento tinha as suas próprias normas para tratamento de
informação. O desafio para melhorar esta situação foi lançado junto dos Doutores Gabriel David
e Lígia Ribeiro e alguns estudantes, surgindo assim o SiFEUP. O sistema tencionava, então, fazer
com que a informação chegasse de modo ágil e uniforme à Reitoria. A ideia foi criar o sistema
diretamente em cima do GAUP porque deste modo a componente backoffice podia ser
igualmente melhorada. O SiFEUP devia ser um sistema interno e providenciar apoio a nível
administrativo, além de mostrar à comunidade interna e externa o que estava a acontecer na
FEUP.
1 Conhecida originalmente por GAUP 2 Faculdade de Ciências da Universidade do Porto 3 https://info.fc.up.pt/info/ 4 Faculdade de Engenharia da Universidade do Porto
4
SiFEUP é um sistema reconhecido e premiado em 1998 com o Prémio Descartes SMA do
Instituto de Informática e em 2000 com o prémio EUNIS da Associação Europeia de Sistemas de
Informação Universitários. Este conseguia igualmente providenciar estatísticas e relatórios
adequados às necessidades da Reitoria da FEUP.
Durante o seu mandato como reitor da UP, o Doutor Novais Barbosa, reconheceu o SiFEUP como
sendo uma mais-valia para a UP e convidou todas as unidades orgânicas a adotarem o sistema
de informação. A partir de 2003, estes três componentes deram, então, vida ao SIGARRA, numa
cooperação entre a FEUP e a Universidade Digital. A Universidade Digital é um serviço da
Universidade do Porto cuja missão é “promover e generalizar a utilização das Tecnologias da
Informação e Comunicação em todas as atividades da Universidade do Porto, bem como
incentivar o desenvolvimento e a utilização de serviços inovadores nesta área”5. O nome do
sistema, SIGARRA, surgiria por sugestão do Doutor Marques dos Santos – este tinha de ser
modificado pois SiFEUP apenas mencionava uma das UO onde estava implementado. O nome
escolhido era também de fácil memorização.
As datas de adesão ao sistema por parte das diferentes unidades orgânicas variam visto
dependerem das equipas de gestão de cada uma delas, além da adaptabilidade do sistema à
realidade de cada uma das UO. As datas de adesão ao sistema podem ser verificadas na tabela
1. A grande recetibilidade ao sistema surgiu de este já se encontrar em funcionamento na FEUP
há algum tempo e ter dado provas do seu bom funcionamento.
Em Janeiro de 20066, o SIGARRA obtém uma boa classificação no Top 10 da Acessibilidade Web
da Administração Pública, conseguindo colocar sete das suas UO (Unidades Orgânicas) nessa
lista: FADEUP7, FAUP8, FBAUP9, FEUP, FMDUP10 e ICBAS11.
A FCUP demorou a adotar o sistema devido a possuir o Infociências, como foi referido
previamente. Embora numa primeira fase tenha sido feita uma tentativa de conciliação de
ambos os sistemas, em 2007 a UO acabou por reconhecer os benefícios de utilizar o SIGARRA,
acabando por o aceitar.
5 http://sigarra.up.pt/reitoria/pt/uni_geral.unidade_view?pv_unidade=5 in 14-05-2014 6 https://sigarra.up.pt/reitoria/pt/noticias_geral.ver_noticia?p_nr=405 in 14-05-2015 7 Faculdade de Desporto da Universidade do Porto 8 Faculdade de Arquitetura da Universidade do Porto 9 Faculdade de Belas Artes da Universidade do Porto 10 Faculdade de Medicina Dentária da Universidade do Porto 11 Instituto de Ciências Biomédicas Abel Salazar
5
No SIGARRA são registados processos relativos aos estudantes, docentes, funcionários não
docentes e utilizadores externos à Universidade do Porto. Este fornece informação completa
sobre registos académicos dos estudantes, planos de estudo dos cursos, horários e
disponibilidade de salas, localização de pessoas, projetos em curso, entre outros. Este tem,
ainda, a funcionalidade de fornecer resposta a pesquisas externas sobre os cursos oferecidos e
as atividades da instituição.
Organismo Sigla Estâncias (URL) Data de Início
Faculdade de Engenharia FEUP http://www.fe.up.pt Outubro de 1996
Instituto de Recursos e Iniciativas Comuns
IRICUP http://www.reit.up.pt Março de 2003
Faculdade de Letras FLUP http://www.letras.up.pt Setembro de 2003
Faculdade de Psicologia e de Ciências da Educação
FPCEUP http://www.fpce.up.pt Setembro de 2003
Faculdade de Ciências da Nutrição e Alimentação
FCNAUP http://www.fcna.up.pt Outubro de 2003
Faculdade de Economia FEP http://www.fep.up.pt Outubro de 2003
Faculdade de Medicina Dentária
FMDUP http://www.fmd.up.pt Outubro de 2003
Faculdade de Direito FDUP http://www.fd.up.pt Janeiro de 2004
Instituto de Ciências Biomédicas Abel Salazar
ICBAS http://www.icbas.up.pt Janeiro de 2004
Faculdade de Farmácia FFUP http://www.ff.up.pt Março de 2004
Faculdade de Belas Artes FBAUP http://www.fba.up.pt Julho de 2004
Faculdade de Desporto FADEUP http://www.fade.up.pt Julho de 2004
Faculdade de Arquitetura FAUP http://www.fa.up.pt Setembro de 2004
Faculdade de Medicina FMUP http://www.med.up.pt Janeiro de 2005
Reitoria REIT http://www.reit.up.pt Janeiro de 2005
Universidade do Porto UP http://www.up.pt Setembro de 2005
Serviços de Ação Social SASUP http://www.sas.up.pt Março de 2006
Reitoria/Institutos de Recursos e Iniciativas Comuns
REIT/IRICUP http://www.reit.up.pt Outubro de 2006
Faculdade de Ciências FCUP http://www.fc.up.pt Setembro de 2007
Serviços Partilhados da Universidade do Porto
SPUP http://www.sp.up.pt Março de 2013
Centro de Desporto CDUP http://www.cdup.up.pt Abril de 2013
Tabela 1. Data de Adesão ao SIGARRA
6
Uma vez que o SIGARRA é considerado a plataforma base de gestão de informação dentro da
UP, interage com outros sistemas e aplicações existentes nesse universo tais como os sistemas
de gestão de bibliotecas, de gestão de aprendizagem, de gestão financeira, de controlo de
assiduidade, de controlo de acesso a instalações, entre outros.
Por norma as outras universidades, a nível nacional e internacional, têm sistemas de informação
distintos para cada uma das suas subsidiárias, além de utilizarem sistemas CRIS12, sistemas
financeiros, entre outros, todos independentes. A grande vantagem do SIGARRA em relação a
outras universidades diz respeito ao modo de acesso, rapidez e consistência da informação
pretendida. Por exemplo, na avaliação de docentes é necessário reunir informação de
componentes pedagógicos, investigação, etc. e os sistemas independentes são mais lentos a
reunir informação, o grau de complexidade de reunião de toda a informação é superior e não
asseguram tão facilmente a consistência dos dados.
Atualmente, a manutenção do sistema é assegurada por uma equipa que conta com a
colaboração da Universidade Digital, a FCUP e a FEUP.
1.2 ARQUITETURA E MÓDULOS
O SIGARRA utiliza um servidor composto por uma base de dados relacional em Oracle13. Oracle,
propriedade da empresa Oracle Corporation, é um sistema de gestão de base de dados que
trabalha com a linguagem SQL14. A arquitetura do SIGARRA é gerida pela Universidade Digital e
está alojada em dois centros de dados da UP.
O sistema suporta ainda dados não-estruturados como, por exemplo, páginas complementares
dos cursos. Estas páginas complementares são de responsabilidade dos seus criadores, podendo
aplicar o design que julgarem ser o mais adequado. Deste modo, é permitida uma
personalização dessas páginas sem comprometer a interface principal do sistema.
12 Current Research Information System são sistemas de informação que têm como objetivo guardar e gerir informações acerca de pesquisas realizadas numa determinada instituição. 13 http://sigarra.up.pt/up/pt/web_base.gera_pagina?p_pagina=18236 14 Structured Query Language
7
Na figura 115, é possível exemplificar melhor visualmente a arquitetura do SIGARRA.
Como foi referido anteriormente, o SIGARRA é constituído por três componentes principais -
GA, SiFEUP e GRH. Enquanto o GA e o GRH são componentes de backoffice - destinam-se ao uso
exclusivo pelos respetivos serviços das diferentes Unidades Orgânicas da UP e Serviços da
Reitoria - o SI é um componente frontoffice, ou seja, pode ser acedido por elementos internos
ou externos à comunidade da UP, embora alguns elementos apenas possam ser acedidos
através da introdução das credenciais de acesso ao sistema.
No que diz respeito aos módulos em concreto, o SIGARRA é constituído por 11 áreas de
módulos16, sendo a ativação de alguns módulos de cariz opcional:
15 Página referente à arquitetura do SIGARRA - http://sigarra.up.pt/up/pt/web_base.gera_pagina?p_pagina=18236 16 Áreas dos Módulos do SIGARRA http://sigarra.up.pt/up/pt/web_base.gera_pagina?P_pagina=1000325
Figura 1. Arquitetura do SIGARRA
8
Ação Social;
Administração Financeira e Patrimonial – Engloba módulos de Deslocações, Gestão de
Encomendas e PAD (Pedido de Autorização de Despesas), entre outros;
Apoio Administrativo – Engloba módulos de Reserva de Recursos, Agenda e Trouble
Tickets17, entre outros;
Autenticação e Autorização – Engloba módulos referentes à autenticação no sistema
com credenciais ou através do cartão de cidadão como, por exemplo, Gestão de
Identidades;
Comunicação e Imagem – Inclui módulos de E-mail Dinâmico, WebForos18 e Noticias,
entre outros;
Gestão Académica (componente GA) – Engloba módulos referentes às Candidaturas,
Cursos/Ciclos de Estudos e Dados Pessoais, entre outros;
Gestão de Informação – Inclui módulos de Gestão de Correspondência, Gestão de
Fotografias e Gestão de Unidades, entre outros;
Gestão de Recursos Humanos – Engloba os módulos de Assiduidade, SIADUP (Avaliação
de Desempenho), SIADAP (Avaliação de Desempenho)19, entre outros.
Gestão de Recursos Humanos (componente GRH) – Engloba módulos de
Remunerações, Dados Biográficos e Situação Profissional, entre outros;
Investigação e Desenvolvimento – Inclui módulos de Publicações e Projetos;
Processo Pedagógico – Inclui o módulo Digitary, que disponibiliza acesso aos graduados
às respetivas certidões e suplementos ao diploma, Horários, Mobilidade, entre outros.
Na totalidade, o sistema é constituído por diversos módulos, podendo ser acedida uma listagem
da totalidade dos mesmos online20. À exceção dos módulos identificados como pertencentes
aos componentes GA ou GRH, todos os outros pertencem ao componente de SI do SIGARRA
sendo módulos de frontoffice.
17 Módulo responsável pelo registo de dúvidas ou problemas que os utilizadores possam encontrar quando interagem com o sistema. 18 Módulo em forma de fórum. 19 A diferença entre o SIADUP e o SIADAP diz respeito ao tipo de contrato dos colaboradores. O primeiro avalia o desempenho dos colaborados com contrato de direito privado enquanto o segundo os de contrato de trabalho em funções públicas. 20 Lista de Módulos do SIGARRA - https://sigarra.up.pt/up/pt/web_base.gera_pagina?p_pagina=1001239
9
1.3 ESTATÍSTICAS
O SIGARRA possui uma página de estatísticas21 onde o conteúdo varia conforme o utilizador. No
caso dos estudantes a estatística é relativamente pobre, que permite uma informação do
número de acessos ao sistema nos quinze dias anteriores, sob a forma de gráfico (figura 2),
relativamente ao dia em que a visitamos. Mencionámos que esta página é pobre visto esta
contagem ser relativa ao número de página geradas – por exemplo, uma simples atualização da
página acrescenta um número extra neste gráfico erradamente. Quando comparada com o
Google Analytics, por exemplo, podemos igualmente observar que esta página de estatísticas é
ainda fraca, pois não permite ver utilizadores ativos, locais de acesso, entre outras vantagens.
Outro tipo de utilizadores, como um diretor de curso ou um professor, podem ter acesso a dados
diferentes e mais completos, gerados pelo sistema. Atualmente, está a ser integrado um sistema
de Business Intelligence22, de modo a complementar as lacunas do sistema e obter estatísticas
para responder às necessidades de cada UO. Por exemplo, atualmente o sistema não consegue
elaborar uma estatística que permita apurar se existiu um aumento do número alunos
provenientes de um determinado distrito nos últimos cinco anos. Através da adoção dos BI,
evita-se recorrer a equipas de informática sempre que uma nova estrutura de relatório seja
necessária. Neste momento já estão em testes diversos protótipos para escolher qual o sistema
que mais se adequa.
21 http://sigarra.up.pt/up/pt/web_base.gera_pagina?P_pagina=1000327 22 Os BI são um conjunto de metodologias, arquiteturas e tecnologias que permitem a elaboração de relatórios e estatísticas de forma autónoma.
Figura 2. Gráfico de acessos na página de Estatísticas do SIGARRA
10
1.4 FUTURO DO SISTEMA
1.4.1 Usabilidade
Desde a criação do SiFEUP que a usabilidade do sistema de informação foi considerada
importante, acompanhando ao mesmo tempo as inovações tecnológicas e necessidades dos
utilizadores com o decorrer dos anos.
O SIGARRA é acompanhado, tecnicamente, por uma comissão de utilizadores que se reúne
frequentemente e acompanha o desenvolvimento do sistema, respondendo às necessidades do
mesmo. Dessa comissão fazem parte os gestores de informação para o SIGARRA, existindo um
por unidade orgânica. Esses gestores são indicados pelo órgão de gestão da UO em questão e
devem conhecer bem a estrutura orgânica, a missão, a visão, os objetivos da instituição e o
próprio SIGARRA. As tarefas desses gestores são, resumidamente, organizar os conteúdos do
SIGARRA, difundir internamente informação sobre o sistema, assegurar boas práticas de
utilização do mesmo, colaborar na validação de alterações ou novos desenvolvimentos a realizar
e colaborar na produção de manuais ou outros documentos de apoio do ponto de vista do
utilizador do SIGARRA.
Durante a entrevista realizada à Dra. Lígia Ribeiro (ver subcapítulo 4.1.1. Entrevistas), foi possível
descobrir que, em 2011, a comissão de utilizadores do SIGARRA elaborou um pedido à FBAUP
para a realização de um estudo de usabilidade centrado exclusivamente na instância do SIGARRA
da UP (up.pt). O estudo envolveu docentes, estudantes e colaboradores não docentes. Este
mostrou algumas debilidades mas também comprovou que na verdade as pessoas conseguiam
encontrar a informação que pretendiam mais rapidamente do que o que afirmavam.
Como consequência deste estudo, foi começado a ser desenvolvido um novo design para o
SIGARRA. Apesar de este já se encontrar concluído e os diretores das UO e os gestores de
informação terem conhecimento do mesmo, este ainda não se encontra disponível
publicamente. O novo design é constituído por duas camadas: uma comunicacional e uma
organizacional. A camada comunicacional é dirigida ao público externo, fornecendo informações
gerais sobre a universidade, de um modo apelativo. Esta foi pensada para investigadores
externos, potenciais alunos, alunos de mobilidade externa, entre outros. A camada
organizacional contém informações mais detalhadas relativamente à UO em questão. Por
exemplo, considerando a tarefa da consulta de cursos, a lista de cursos em si está presente na
camada comunicacional enquanto os detalhes sobre os respetivos cursos estão presentes na
11
camada organizacional. Com a eleição do novo reitor recentemente, Doutor Sebastião Azevedo
no dia 30 de Abril do presente ano, tenciona-se implementar o novo desenho para a instância
da UP em breve.
Recentemente, podemos observar que os ícones da FEUP foram alterados. Estas alterações
foram possíveis devido a uma alteração recente na infraestrutura23 do sistema, preparando-o
para providenciar suporte às novas funcionalidades. Esta alteração serviu para de certa forma
modernizar um pouco o sistema, até ser implementada uma interface mais apelativa. Este tipo
de alterações não podem ser forçadas, não se pode pedir a uma UO que implemente algo contra
a sua vontade – o gestor de informação de cada UO é sempre avisado previamente de uma
qualquer alteração planeada. Do mesmo modo, como referido anteriormente, alguns módulos
são de cariz opcional como, por exemplo, os módulos responsáveis pelos menus de cantina ou
pelas notícias. Nestes casos, cada universidade deve escolher se deseja ativar esses módulos.
É igualmente importante referir que cada universidade decide o seu design específico para o
SIGARRA, podendo inclusive recorrer a empresas externas à UP. Deste modo é possível justificar
por que a FMDUP utiliza uma breve página de carregamento enquanto as restantes UO não o
fazem ou por que o design do SIGARRA da FCUP é totalmente distinto das restantes UO.
Recentemente, a FAUP já “acolheu” a nova estrutura do sistema, tendo disponibilizado um novo
design para o seu SIGARRA.
No Plano de Atividades e Orçamento para 2014, assume-se a vontade de introduzir melhorias
no sistema que beneficiem a usabilidade do mesmo, através de um contacto mais próximo com
os vários tipos de utilizadores do sistema e do aumento da colaboração com professores da
Universidade do Porto que dominem esta área24.
23 framework 24https://sigarra.up.pt/up/pt/conteudos_service.conteudos_cont?pct_id=20139&pv_cod=189qrH2Ctaaa Plano de Atividades e Orçamento para 2014 consultado em 14-05-2014
12
1.4.2 O SIGARRA como Ferramenta de Trabalho
Como já foi referido, o SIGARRA é também uma ferramenta de trabalho devido ao seu
funcionamento na Intranet e apoio administrativo.
Por parte da equipa de acompanhamento do SIGARRA, existe uma grande preocupação em
acompanhar as mudanças legislativas ou regulamentares, por exemplo, regulamentos das
propinas ou do estudante, que vão acontecendo no país e preparar o sistema nesse sentido.
O próximo passo está relacionado com o investimento na assinatura digital, existindo já uma
requisição para implementar esta tecnologia a aguardar aprovação. Para compreender a
importância desta tecnologia, observemos o seguinte exemplo básico do lançamento de notas:
1. Lançamento das notas por parte do professor na componente de frontoffice;
2. Período de esclarecimentos;
3. O professor imprime o termo e assina para deixar junto dos serviços responsáveis;
4. A Informação é transmitida da camada frontoffice para a backoffice, bloqueando
possíveis alterações.
No exemplo, a introdução da assinatura digital evita a impressão do termo para o assinar, assim
como a deslocação do docente para entregar o mesmo. Esta tarefa é simples mas por vezes é
necessária a assinatura de duas ou mais pessoas em cada tarefa. De um modo geral, se num
workflow surgir necessidade de assinatura, é necessário garantir que as pessoas podem assinar
digitalmente. Com a implementação desta tecnologia, seria também criado um repositório para
os termos assinados digitalmente.
O SIGARRA tem a vantagem de ter sido desenhado de acordo com as necessidades da UP, por
isso, existe a preocupação de acompanhar as necessidades da mesma e utilizar a tecnologia de
modo a acrescentar valor ao sistema.
1.5 IMPORTÂNCIA DA ADAPTAÇÃO A SISTEMAS MÓVEIS
Cada vez mais os alunos têm facilidade em aceder a dispositivos móveis e utilizam-nos para
diversos fins, possivelmente consultas ao sistema. Apesar de não ter sido realizado nenhum
estudo no sentido de obter dados quantitativos relativamente a este aspeto, durante o trabalho
de campo realizado foi possível observar um número considerável de estudantes a interagir com
dispositivos móveis. O facto de estes dispositivos poderem ser utilizados em qualquer lado e a
13
quantidade de pontos de acesso à Internet disponíveis hoje em dia ser superior, faz com que
uma adaptação do SIGARRA a esta realidade comece a ser vista como uma necessidade.
Atualmente existe vontade de investir nos sistemas móveis por parte da equipa responsável
pelo SIGARRA. Várias empresas têm mostrado interesse em desenvolver diversas aplicações
para o SIGARRA, por isso é importante desenvolver um Hub que permite reunir todas as
aplicações que venham a ser desenvolvidas. No próximo ano, será possível já existirem
novidades neste assunto, através da criação de uma camada API25.
25 Application programming interface
14
2 DESIGN DE INTERAÇÃO
Este capítulo abordará a Interação Humano-Computador (IHC)26, e a evolução das Interfaces, a
Usabilidade, o Design Centrado no Utilizador e o Design de Interfaces Móveis Tácteis, sendo o
foco do estudo os tablets.
2.1 INTERAÇÃO HUMANO-COMPUTADOR
A IHC tem as suas raízes na Usabilidade e foca-se em como os humanos interagem com os
computadores (Lowdermilk, 2013). Embora a IHC seja estudada em várias áreas, é nas áreas das
ciências computacionais e do design de sistemas que o seu estudo é mais desenvolvido. A IHC
envolve o design, a implementação e a avaliação de sistemas interativos tendo em conta o
contexto das tarefas a serem levadas a cabo pelos utilizadores (Dix et al., 2004).
2.1.1 Primeiras Interfaces
No que diz respeito à estrutura das primeiras interfaces, estas eram consideradas como
orientadas à função27 uma vez que a interação era estruturada à volta de comandos introduzidos
pelo utilizador, através de diversas combinações, de modo a atingir o resultado pretendido.
Interfaces de Linha de Comandos
As interfaces de linha de comandos28, tal como o nome sugere, permitiam uma interação com o
sistema através de comandos digitados. O utilizador interagia com um computador através de
uma linha de instruções e, após a tecla Enter ser premida, as instruções não podiam mais ser
alteradas. Em geral, os outputs das ILC eram apresentados sob a forma de linhas textuais na
interface (figura 3).
Algumas das grandes desvantagens desta interface diziam respeito a ter de decorar os diversos
comandos, e a própria sintaxe específica do sistema, e aprender a como e quando deviam ser
utilizados. Além de serem relativamente abstratas quando comparadas com as IG 29, onde
podemos realmente ver o que estamos a fazer, a manipulação de objetos e as próprias ações
26 Em inglês, Human-Computer Interaction ou HCI 27 Em Inglês, function-oriented 28 Em inglês, Command-line Interface ou CLI 29 Em Inglês, Graphical User Interface ou GUI
15
estão escondidas por detrás de comados (Wrobleski, 2011). Até esta altura, as interfaces
possuíam apenas uma dimensão.
Interfaces Full-Screen
Antes das Interfaces Gráficas, surgiram as primeiras interfaces com duas dimensões, as
Interfaces Full-Screen. Este tipo de interfaces era usado, sobretudo, para o preenchimento de
formulários onde o utilizador se deparava com os campos a preencher, tendo a liberdade de os
preencher pela ordem que desejasse.
Estas interfaces introduziram hierarquias de menus e as teclas de função (figura 4). Segundo
Nielsen (1993), as principais vantagens destas teclas diziam respeito ao facto destas acelerarem
a interação com o sistema, uma vez que substituíam a introdução de determinados comandos,
e de serem tão poucas que permitiam a memorização das funções das mesmas rapidamente.
Figura 3. Interface de Linha de Comandos do Windows 98
16
2.1.2 Interfaces Gráficas
No que diz respeito à evolução das Interfaces Gráficas é
importante mencionar o Sketchpad (figura 5) de Ivan Sutherland
(1962) ou o sistema NLS30 (figura 6) desenvolvido por Douglas
Engelbart (1964). O Sketchpad foi importante devido a ser o
primeiro editor gráfico orientado a objetos, sendo possível a
manipulação de objetos como elementos distintos. Já o NLS foi
o primeiro sistema a utilizar o rato, hiperligações e janelas, e a
organizar conteúdo pela sua relevância, entre outros conceitos
atualmente utilizados na computação.
30 oN-Line System
Figura 4. IBM Sterling Gentran:Server Communications Module Interface
Figura 5. Sketchpad
17
Durante a década de 1970 foram desenvolvidas diversas pesquisas, entre as quais uma
elaborada por um grupo de investigadores da Xerox PARC, como Alan Kay, que apenas tiveram
impacto comercial a partir da década de 1980. Este tipo de interface recorre a diversos
elementos visuais para permitir ao utilizador executar comandos como abrir, apagar ou editar
ficheiros (figura 7). A combinação de elementos mais recorrente é conhecida como WIMP
(Windows, Icons, Menus, Pointer – Janelas, Ícones, Menus e Cursor, em português).
Figura 7. GUI do XEROX 8010 Star
Figura 6. Estação de Trabalho do NLS
18
É com este tipo de interfaces que surge, também, o conceito de interfaces com três dimensões
devido a ser possível fazer uma sobreposição de janelas, ainda que isso não corresponda
verdadeiramente a três dimensões. Por este motivo, Nielsen (1993) sugere que o mais correto
seria designá-las de interfaces de duas dimensões e meia31.
A maioria dos sistemas que utiliza as IG recorre a dispositivos apontadores, como o rato, como
principal meio de manipulação com os diversos elementos visuais que constituem a interface.
No que diz respeito à estrutura da interface, podemos afirmar que as IG são interfaces
orientadas a objetos32, ou seja, a informação é representada graficamente através de ícones ou
janelas (figura 8). Este tipo de interfaces utiliza a chamada metáfora Desktop33. Esta metáfora
consiste na utilização de elementos do mundo real na interface do utilizador como, por exemplo,
o caso do balde da reciclagem para os itens eliminados ou não desejados, ou ainda as pastas
que se assemelham a arquivos de ficheiros34. A metáfora, que surgiu inicialmente na Xerox PARC
em 1970, ainda serve hoje de base a modelos conceptuais do design de interação.
31 “…it would be more accurate to refer to these interfaces as having two-and-a-half dimensions.” (Nielsen, 1993) 32 Em inglês, object-oriented 33 Desktop Metaphor 34 http://www.research.ibm.com/people/k/koved/papers/rwavrc.pdf in 27-05-2014
Figura 8.GUI Aqua no Mac OS X Leopard (10.5) – Outubro de 2007
19
A maior parte dos especialistas em interfaces assumem que as IG apresentam melhores
características de usabilidade no geral que as interfaces baseadas apenas em texto,
especialmente no que diz respeito à aprendizagem de novos utilizadores. Além disso, nas IG é
possível efetuarmos todas as tarefas que era possível até então realizar nas interfaces prévias,
enquanto o contrário não é de todo possível (Nielsen, 1993). Para Norman (2010), o ponto forte
destas interfaces não é a sua vertente gráfica mas sim a facilidade com que memorizamos quais
ações são possíveis de efetuar e como as podemos de facto realizar.
2.1.3 Interfaces Gestuais
As Interfaces Gestuais35, também apelidadas de Interfaces Naturais36, referem-se a interfaces
que proporcionam uma interação mais próxima do natural para o ser humano como, por
exemplo, ecrãs de toque, sistemas de reconhecimento de voz ou leitores de sinais neurológicos.
Deste modo, podemos ter uma interação com a máquina mais intuitiva e mais perto de ações
que realizamos habitualmente no dia-a-dia, sem intermediários como, por exemplo, os teclados
ou os dispositivos apontadores. No entanto, Norman não considera estas interfaces intuitivas,
sendo este um tópico complexo37. Na opinião do autor, estas não são intuitivas porque algo que
é intuitivo requer muitos anos de prática, tal como aprender a falar uma determinada língua ou
andar de bicicleta.
2.1.3.1 Evolução
Augusto de Los Reyes (2008) defendeu que as Interfaces de Linha de Comandos, as Interfaces
Gráficas e as Interfaces Naturais estariam ligadas como uma evolução continua (figura 9). Na
verdade, esta linha de pensamento não é totalmente correta, especialmente se pensarmos que
as Interfaces Gestuais podem conter os elementos visuais característicos das Interfaces Gráficas.
35 Em inglês, Gestural Interfaces 36 Em inglês, Natural Interfaces ou NUI 37 http://permalink.gmane.org/gmane.comp.hci.phd-design/19144 consultado 29-07-2014;
20
Figura 9. Evolução das Interfaces segundo Reyes (2008)
Apesar da sua popularidade nos tempos correntes, as Interfaces Gestuais não são algo apenas
do presente. Senão lembremos o Apple Newton, desenvolvido em 1992 (figura 10) onde
interação era realizada com o toque de uma caneta no ecrã, ou o trabalho de Myron Krueger
durante as décadas de 70 e 80, o Videoplace38 (figura 11). Outro exemplo de um sistema multi-
-toque é o instrumento musical Theremin (figura 12). Este tipo de sistemas são capazes de
reconhecer vários pontos de contacto em simultâneo.
38 O Videoplace foi criado como um laboratório de realidade artificial que envolvia os utilizadores, respondendo aos seus movimentos e ações. O termo realidade artificial foi o escolhido por Krueger para descrever o ambiente característico do Videoplace. Este laboratório detetava os utilizadores através do uso de umas luvas especiais ou óculos de realidade virtual e utilizava projetores e câmaras de vídeo, entre outros, para colocar os utilizadores num ambiente interativo.
Figura 10. Apple Newton
Figura 11. Uma das várias tarefas possíveis de realizar no Videoplace
21
2.1.3.2 Última Década
Durante a última década, renomeados autores foram dando a sua opinião no que diz respeito a
este tipo de interação. Tal como Reyes (2008) constatou, este tipo de interface proporciona um
tipo de interação mais intuitiva. No entanto, para Norman (2010), a maioria dos gestos não são
nem naturais nem fáceis de aprender ou lembrar. Se pensarmos em termos culturais, os gestos
variam bastante conforme as diferentes culturas mundiais, podendo levar a interpretações
incorretas.
Saffer (2008) enumera uma série de vantagens das interfaces gestuais, como a existência de
uma interação mais natural, menos peso ou hardware visível, maior flexibilidade, maior
variedade e maior diversão. Por flexibilidade, o autor refere-se à possibilidade de proporcionar
configurações diferentes em ecrãs de toque, conforme a situação, ou um maior espaço de
trabalho noutros contextos. A variedade está relacionada com expressões principalmente
relacionadas com os sentimentos humanos como o piscar de olhos ou o franzir da sobrancelha,
impossíveis de detetar noutras interfaces.
Os sistemas gestuais não são diferentes das outras formas de interação. Estes necessitam de
seguir as regras básicas do design de interação. E porque gesticular é um comportamento
humano automático e natural, o sistema tem de ser afinado de modo a evitar movimentos
involuntários ou não pretendidos com input – esta afinação leva a uma provável perda de
Figura 12. Barbara Buchholz a tocar num Theremin
22
movimentos que eram pretendidos como input. Nenhuma destas situações aconteceria com um
teclado, sistemas de toque, canetas ou ratos (Norman, 2010).
2.1.3.3 Dez Características de uma Boa Interface Gestual
Apesar de existirem alguns aspetos que necessitem uma reflexão contextual, Saffer (2008)
enumerou o que, na sua opinião, representariam as dez características ideais de uma boa
interface gestual.
1. Visibilidade. As Interfaces Gestuais estão diretamente ligadas ao conceito de
Affordance39. O utilizador necessita de olhar e perceber de imediato para que serve cada
elemento da mesma, como se processará a interação.
2. Fidedigno. Este tipo de interface tem de ser competente, seguro e deve respeitar a
privacidade do utilizador.
3. Responsivo. Quando interagem com uma Interface Gestual, os utilizadores gostam de
saber que o sistema recebeu e compreendeu os comandos efetuados. Nestas interfaces,
a resposta deve ser o mais breve possível (cerca de 100ms). Sem nenhuma resposta, ou
uma resposta demorada, os utilizadores tendem a repetir a ação realizada, supondo que
o sistema não a recebeu/compreendeu.
4. Apropriado. Deve ser apropriado ao contexto, situação ou cultura em que se inserem.
Como referido anteriormente, gestos têm interpretações diferentes conforme a cultura
e o que parece um simples, inofensivo gesto na verdade pode ferir suscetibilidades.
5. Significativo. Se o sistema não satisfizer as necessidades do utilizador, não é um grande
sistema, mesmo que a interação proporcionada seja extraordinária.
6. Esperto. Os dispositivos que utilizamos fazem tarefas que temos dificuldades em
cumprir, como efetuar cálculos rápidos ou possuir memória infalível.
7. Inteligente. Os melhores produtos preveem as necessidades dos seus utilizadores e
satisfazem-nas de modos impensáveis.
8. Divertido. Os utilizadores devem sentir-se relaxados o suficiente para explorarem novas
funcionalidades e variações nos seus gestos. Erros devem ser difíceis de surgir e, além
disso, é muito importante existir a possibilidade para desfazer ações, proporcionando,
assim, um ambiente propício à diversão. A diversão termina se os utilizadores se
sentirem perdidos, encurralados ou sem poder sobre as suas ações.
39 James Gibson (1986) define Affordance como a interpretação que fazemos de um objeto quando o visualizamos (“What we perceive when we look at objects are their affordances, not their qualities”)
23
9. Agradável. As Interfaces Gestuais devem ser agradáveis tanto a nível estético com
funcional. As partes de um sistema gestual devem ser apelativas a nível sensorial,
gerando sensações positivas junto dos utilizadores.
10. Bom. Estes sistemas têm de ser bons para os utilizadores, bons para as pessoas
indiretamente ligadas, bons em termos culturais e bons para o ambiente. Por último, o
respeito e compaixão por quem utilize estas interfaces devem ser priorizados.
2.1.4 First Person User Interfaces
Este tipo de interfaces derivam das Interfaces Naturais, embora sejam mais imersivas. Segundo
Wrobleski (2011), estas interfaces permitem a um utilizador interagir com o mundo real ao
mesmo tempo que o estão a sentir e explorar. É possível obter automaticamente informações
relevantes tendo em conta a localização atual do utilizador e sobre quem ou o quê se encontra
perto do mesmo – é possível fazer com que pessoas, localizações e objetos do mundo real se
tornem elementos interativos interligados entre si. Google Maps, aplicações que permitam
explorar e conhecer uma cidade, leitores de códigos de barras e fotografias utilizadas em
motores de pesquisa são apenas alguns exemplos desta tipologia de interfaces.
As FPUI tiram partido de vários tipos de sensores, que têm funcionalidades como a deteção de
movimento e posicionamento do dispositivo através de acelerómetros, captura de vídeo e
imagem através da câmara, deteção de proximidade, perceção da luminosidade do ambiente,
deteção de localizações, etc. No que diz respeito aos sistemas de localização, os smartphones
são uma espécie de híbridos, podendo combinar informações provenientes de GPS, Wifi e
triangulação de torres telefónicas. No caso dos computadores portáteis e de secretária, esta
informação pode ser obtida, principalmente, através de Wifi e IP, sendo que raramente ainda
pode ser obtida por GPS (Wrobleski, 2011).
2.1.4.1 Evolução
À medida que as interfaces foram evoluindo, o seu grau de abstração foi reduzido. Agora todas
as interações são mais intuitivas, naturais. Se aplicássemos o ciclo de vida do produto à evolução
das interfaces, o resultado obtido seria o presente na figura 13. As ILC encontram-se em declínio,
as IG já estão numa fase de maturidade, as IN encontram-se em crescimento e, por último, as
FPUI estão agora a emergir.
24
2.1.5 Usabilidade
Usabilidade aplica-se a todos os aspetos de um sistema com os quais um humano possa
interagir, incluindo os procedimentos de instalação e manutenção do mesmo (Nielsen, 1993); é
a medida que permite verificar até que ponto um produto pode ser usado por utilizadores
específicos para atingir determinados objetivos com eficácia, eficiência e satisfação, num
determinado contexto de uso (ISO 9241-11, 1998); descreve a facilidade com a qual o utilizador
do produto consegue compreender como este funciona e como fazer com que este comece a
funcionar (Norman, 2004); significa garantir que algo funciona bem: que uma pessoa de
capacidade e experiência medianas consegue usar algo no sentido para que foi desenvolvido
sem ficar frustrada (Krug, 2006);
A usabilidade centra-se em três conceitos: eficácia, eficiência e satisfação. A eficácia é medida
analisando os objetivos e subobjetivos do utilizador em relação à precisão e integralidade com
que podem ser atingidos. A eficiência relaciona-se com o nível de eficácia obtido em detrimento
do número de recursos utilizados e pode incluir esforço físico e mental, materiais e custo
financeiro. Por último, a satisfação pode ser medida ao nível de até que ponto os utilizadores
estão livres do desconforto e a sua atitude quanto à utilização do produto (ISO 9241-11, 1998),
como a quantidade de comentários positivos ou negativos durante a interação com o produto,
entre outros.
Figura 13. Ciclo de vida do produto aplicado às interfaces (Wrobleski, 2011)
25
Krug (2006) menciona as suas principais leis, ou princípios, no que diz respeito à Usabilidade
Web, de um modo simples e fácil de compreender:
Não me Faças Pensar40. Os utilizadores não gostam de pensar. Qualquer entrave que surja na
utilização da interface faz com que o utilizador não a queira mais usar a menos que seja
estritamente necessário. Por exemplo, quando nos deparamos com um programa cuja interface
é complicada ou confusa demais para ser utilizada instantaneamente, o nosso primeiro instinto
passa por fechá-lo e procurar uma alternativa. No caso de sistemas web, os utilizadores gostam
de ver claramente onde podem clicar e, por vezes, as hiperligações não estão assinaladas
corretamente o que pode levar a um nível de confusão e/ou frustração.
Não importa quantas vezes tenho de clicar, desde que cada clique seja uma escolha clara e
irracional41. Esta regra surge no seguimento da seguinte. Krug defende que, mais importante
que o número de cliques efetuados, é o processo que envolve essas escolhas. Ou seja, o quanto
o utilizador tem de pensar para efetuar a escolha mais acertada.
Elimina metade das palavras em cada página e posteriormente elimina metade do que
restou42. Quantas vezes elaboramos uma simples pesquisa num motor de buscar e selecionamos
um website que apresenta um enorme bloco de texto? Nestes casos, o mais comum seria o
utilizador retroceder e procurar outro de mais fácil leitura. Os websites, tal como as
apresentações, devem apresentar o mínimo de texto possível, de modo a não cansar o
utilizador.
2.1.5.1 Cinco Atributos da Usabilidade
Para Nielsen (1993) a usabilidade não é apenas uma propriedade unidimensional de interface
do utilizador. Esta é composta por múltiplos componentes associados a cinco atributos -
Capacidade de Aprendizagem, Capacidade de Memorização, Eficiência de Utilização, Prevenção
de Erros e Satisfação Subjetiva.
40 Tradução do Autor de “Don’t Make me Think.” 41 Tradução do Autor de “It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice.” 42 Tradução do Autor de “Get rid of half the words on each page, then get rid of half of what’s left.”
26
Capacidade de Aprendizagem
Na opinião de Nielsen (1993), este é talvez o atributo mais importante da usabilidade, uma vez
que a maioria dos sistemas precisam de ser fáceis de aprender e a primeira experiência que um
utilizador tem com o sistema é, de facto, a sua aprendizagem.
Este atributo é o mais fácil de avaliar no sentido em que para o fazer basta colocar um novo
utilizador a interagir com o sistema em questão e medir o tempo que este leva a concretizar
uma determinada ação previamente proposta.
Quando analisamos a capacidade de aprendizagem, devemos ter em conta que a maioria dos
utilizadores começa a interagir com um sistema após conhecer a sua interface parcialmente, em
vez de interagir apenas quando a conhece por completo (Nielsen, 1993). Por este motivo, e
porque os utilizadores têm tendência para começar de imediato a interagir com um sistema,
quando avaliamos este parâmetro, devemos procurar um determinado nível de domínio da
execução de uma tarefa, em vez de procurar a excelência.
Capacidade de Memorização
A capacidade de memorização de um sistema está relacionada com a facilidade de memorizar
como uma determinada tarefa dentro de um sistema pode ser efetuada. Esta capacidade é
facilmente posta à prova quando, por exemplo, o utilizador deixa de interagir com o sistema
durante um determinado período de tempo.
Nielsen (1993) menciona dois métodos interessantes de testar esta mesma capacidade de
memorização. Um método passa por pedir a um utilizador, que já não interaja com o sistema há
um determinado período de tempo, que realize um determinado conjunto de tarefas. O outro
método inclui a elaboração de um teste de memória através da seleção de alguns utilizadores,
após uma sessão de testes, pedindo a estes que mencionem alguns pormenores, como o nome
ou aspeto de algum objeto, ou que expliquem como devemos proceder para realizar uma
determinada tarefa.
27
Eficiência de Utilização
A eficiência de utilização está relacionada com o grau de rapidez e sucesso com que os
utilizadores conseguem desempenhar uma determinada tarefa no sistema. Cooper (2004)
afirma que a maioria dos utilizadores que interage com um sistema são intermediários, sendo
os utilizadores iniciantes ou experientes uma fração pequena desse universo43.
Um modo comum de avaliar esta eficiência passa por reunir um grupo de utilizadores que
reúnam uma determinada condição como, por exemplo, há quantos anos interagem com a
aplicação, e medir o tempo que esses utilizadores demoram a realizar um conjunto de tarefas.
Prevenção de Erros
Podemos definir erro como qualquer ação que não satisfaça um objetivo pretendido e o rácio
de erros de um sistema deve ser medido através de uma contagem dessas ações realizadas pelos
utilizadores enquanto efetuam uma determinada tarefa (Nielsen, 1993).
Enquanto alguns erros são facilmente ultrapassados pelo utilizador, em que este percebe como
deve proceder para contornar a situação, existem outros erros mais graves em que o utilizador
não consegue perceber como se deve comportar para conseguir ultrapassar esse obstáculo.
Nielsen (1993) defende que este tipo de erros devem ser considerados em separado, dando
mais relevância aos últimos.
Satisfação Subjetiva
Este atributo diz respeito ao grau de satisfação do utilizador ao interagir com o sistema. Apesar
de esta satisfação subjetiva poder ser medida através de simples perguntas colocadas aos
utilizadores, o modo de obtenção de resultados mais consistentes recorre ao preenchimento de
pequenos inquéritos após um teste de usabilidade do sistema (Nielsen, 1993), de modo a
conseguir perceber qual a sensação que os utilizadores tiveram da interface com a qual
interagiram (figura 14).
43 “Most users are neither beginners nor experts; instead they are perpetual intermediates.” (Alan Cooper, 2004).
Figura 14. Exemplo de uma escala para inquéritos de satisfação (Nielsen, 1993)
28
2.1.5.2 ISO 9241
A norma ISO 9241 diz respeito aos requisitos internacionais sobre a ergonomia de sistemas
interativos e contém dezassete secções. Existem duas secções particularmente importantes,
merecendo destaque. A secção dez, relativa aos princípios de diálogo, é importante visto auxiliar
o desenvolvimento de bons diálogos do sistema, satisfatórios e eficientes. A secção onze
relaciona-se com o modo como percecionamos, definimos e avaliamos a usabilidade em termos
de performance e satisfação do utilizador. Ambas as seções estão relacionadas uma vez que os
diálogos bem desenvolvidos podem levar a uma melhoria da usabilidade do sistema.
Igualmente importante é a ISO 25062. Esta ISO está relacionada com o formato a utilizar nos
relatórios de testes de usabilidade. Esta ISO inclui alguns termos já definidos em outras ISOs
como a 9241 e a 9126, introduzindo outros como a acessibilidade, tecnologias de apoio (por
exemplo, leitores de ecrã e ecrãs Braille) e assistência, no sentido em que o testador pode
fornecer algum tipo de ajuda ao testado quando este não consegue completar a tarefa por ele
mesmo. Resumidamente, esta ISO aborda aspetos como a descrição do produto, os objetivos
do teste, os participantes do teste realizado, as tarefas que os utilizadores tiveram de
desempenhar, o design experimental do teste, o método ou processo através do qual o teste foi
conduzido, as medidas de usabilidade e os métodos de recolha de dados e, por último, os
resultados numéricos.
2.1.5.2.1 ISO 9241-11
Razão e Benefícios
A usabilidade tem em consideração o grau de eficiência, de eficácia e de satisfação dos
utilizadores, sendo esta de extrema importância durante a fase de design de produtos. A
usabilidade dos produtos é possível de ser melhorada introduzindo funcionalidades e atributos
reconhecidos por beneficiarem os utilizadores em determinados contextos.
É importante avaliar a usabilidade tendo em conta a complexidade das interações entre o
utilizador, os objetivos, as características das tarefas e os restantes elementos dos cenários de
contexto. Um produto poderá ter diferentes níveis de usabilidade dependendo desse mesmo
contexto.
29
Planear a usabilidade como parte do design e desenvolvimento dos produtos requer uma
identificação sistemática dos requisitos de usabilidade, incluindo medição da usabilidade e
descrições verificadas dos cenários de contexto. Deste modo obtemos objetivos de design que
podem ser usados para avaliar o design resultante.
Os benefícios da ISO 9241-11 resumem-se em quatro aspetos importantes:
A infraestrutura pode ser utilizada para identificar os aspetos de usabilidade e
componentes dos cenários de contexto que devem ser considerados quando se
especifica, se delineia ou se avalia o produto (figura 15);
A performance, no que diz respeito à eficácia e eficiência, e satisfação do utilizador
podem ser utilizadas para definir em que medida um produto é utilizável num
determinado contexto;
A avaliação da performance e da satisfação do utilizador servem de base para
comparações entre a usabilidade relativa de produtos com especificações técnicas
distintas em cenários idênticos;
A usabilidade planeada para um produto pode ser definida, documentada e verificada.
Figura 15. Estrutura de Usabilidade (ISO 9241-11, 1998)
30
Quando pretendemos especificar ou medir a usabilidade, é necessário reunir um conjunto de
informações como a descrição dos objetivos finais pretendidos; quais os objetivos ou valores
reais para a eficácia, eficiência e satisfação dos contextos desejados, e a descrição dos
componentes de contexto e uso, incluindo utilizadores, tarefas, equipamentos e ambiente. Este
último aspeto pode ser relativo à descrição de um contexto existente ou apenas uma
especificação dos contextos pretendidos. Esta descrição do contexto necessita de ser o mais
detalhada possível, de maneira a que os aspetos do contexto que tenham uma influência
relevante na usabilidade possam ser reproduzidos.
Descrição dos Objetivos de Uso de um Produto
Estes objetivos devem ser descritos e podem ser decompostos em subobjetivos que especificam
um objetivo geral e o critério para o satisfazer. Por exemplo, um profissional de vendas por
telefone pode ter como objetivo guardar as encomendas dos clientes mas este objetivo pode
ser detalhado em subobjetivos como manter registos detalhados das encomendas dos clientes
ou fornecer informação o mais rapidamente possível a dúvidas dos clientes sobre as
encomendas realizadas.
Cooper et al. (2007) afirmam que os objetivos dos utilizadores podem identificados em três
categorias: objetivos experienciais, finais e de vida. Os primeiros, refletem como os indivíduos
se querem sentir quando interagem com um produto ou a qualidade da interação com este. Os
objetivos finais relacionam-se com as motivações do utilizador para desempenhar determinada
tarefa com determinado produto. Os objetivos de vida representam aspirações pessoais do
utilizador que, habitualmente, abrangem mais aspetos que o contexto do produto pois
descrevem desejos a longo prazo, motivações e a imagem que o utilizador tem dele próprio –
este aspetos são responsáveis pelo desenvolvimento de uma ligação entre o utilizador e o
produto.
Contexto de Uso
Na descrição dos utilizadores, as características mais relevantes dos mesmos devem ser
descritas (por exemplo, utilizando métodos como o uso de personas). Algumas das
características possíveis de serem enumeradas podem ser o grau de conhecimentos, as
capacidades, a experiência, a educação, a formação e as características físicas, motoras e
sensoriais.
31
Relativamente à descrição das tarefas, estas são consideradas as atividades desenvolvidas para
atingir um determinado objetivo. Todas as características destas atividades que possam
influenciar a usabilidade devem ser descritas, por exemplo, aspetos como a frequência e
duração da tarefa. Podem ser necessárias descrições pormenorizadas das atividades e dos
processos se a descrição do contexto for utilizada como base para o design ou avaliação dos
detalhes da interação com o produto. Isto pode incluir descrição da alocação das atividades e
passos entre os recursos humanos e os recursos tecnológicos. A descrição das tarefas não se
deve resumir apenas a descrições em termos de funções ou características do produto ou
sistema. Para fins de avaliação da usabilidade, um número concreto de tarefas-chave deve ser
selecionado para representar aspetos significativos de uma tarefa em geral.
No que diz respeito às características do equipamento, é necessário uma descrição do hardware,
software e outros materiais associados com os terminais de apresentação visual. Esta descrição
pode ser em termos de um conjunto de produtos, em que um ou mais desses seja o foco da
avaliação ou especificação da usabilidade, ou pode ser em termos de um conjunto de atributos
ou características de performance do hardware, software e outros materiais. Neste sentido, é
importante a descrição de métodos de input como, por exemplo, o teclado ou o dispositivo
apontador, e métodos de output (se existe output sonoro, com imagens, entre outros).
Por último, a descrição do ambiente deve incluir características relevantes do ambiente social e
físico. Por exemplo, num ambiente tecnológico podemos mencionar a rede de área local, num
ambiente físico mencionaríamos o escritório, a respeito de condições climatéricas era possível
enumerar informações como a temperatura ou a humidade, em aspetos culturais e sociais
poderíamos referir práticas empresariais ou atitudes.
Medidas de Usabilidade
É necessário estabelecer uma medida para o grau de eficácia, eficiência e de satisfação embora
não exista nenhuma regra geral para a escolha das medidas. Esta escolha deve ser realizada
considerando os objetivos de ambas as partes. A importância de cada medida face aos objetivos
deve ser considerada ou seja, por exemplo, se a utilização é pouco frequente, uma maior
importância pode recair sobre a aprendizagem e a reaprendizagem. De seguida, abordarmos
como podem ser medidas a eficácia, a eficiência e a satisfação.
A eficácia é medida tendo em conta os objetivos e subobjetivos do utilizador relativamente à
precisão e integralidade com que estes podem ser atingidos. Por exemplo, se o objetivo for a
criação de um documento de texto com duas páginas num formato específico, a precisão pode
ser medida tendo em conta a quantidade de erros ortográficos e o número de desvios em
32
relação ao formato pretendido enquanto a integralidade é medida através da divisão do número
de palavras do documento transcrito pelo número de palavras do documento original.
A medição da eficiência está diretamente relacionada com o nível de eficácia obtido em relação
ao número de recursos utilizados. Esta medição pode incluir o esforço físico e mental ou os
materiais e o custo financeiro.
Em último lugar, a satisfação pode ser medida ao nível de até que ponto os utilizadores estão
livres do desconforto e a sua atitude relativamente à utilização do produto em questão. O
número de comentários positivos ou negativos durante o uso, o facto de gostar ou não do
produto e em que medida alguns aspetos de usabilidade são atingidos são métodos para medir
a satisfação.
Especificar e Avaliar um Sistema de Trabalho em Uso
Quando o objetivo é melhorar um sistema de trabalho em geral, qualquer parte desse sistema
pode ser alvo de avaliação – as medidas de eficácia, eficiência e satisfação podem ser usadas
para medir qualquer componente. Por exemplo, pode ser relevante considerar a quantidade de
formação que necessitará de ser dada aos utilizadores, reorganização de tarefas, etc. Quando
um produto é motivo de preocupação, estas medidas fornecem a informação necessária
relativamente à usabilidade desse produto nesse particular contexto de uso providenciado pelo
restante sistema de trabalho.
2.1.5.3 Cinco Fatores Humanos Mensuráveis a Considerar
Semelhantes aos atributos de Nielsen, Shneiderman (1983) enumerou cinco fatores humanos
mensuráveis a considerar na altura de elaborar o design de uma interface:
Tempo de Aprendizagem. Quantidade de tempo necessária para aprender a realizar a
tarefa;
Velocidade do Desempenho. Quanto tempo é necessário para realizar as tarefas;
Rácio de Erros. Quantos e que tipo de erros os utilizadores cometem ao realizar as
tarefas;
Satisfação Subjetiva. Nível de satisfação dos utilizadores com os diversos aspetos do
sistema. Os melhores métodos de avaliação desta satisfação, segundo Shneiderman, são
as entrevistas ou inquéritos escritos que incluam escalas de satisfação e espaços
próprios para os entrevistados poderem deixar as suas opiniões/sugestões;
33
Memorização. Capacidade de memorização de conhecimento após uma hora, um dia
ou uma semana. Esta capacidade pode estar relacionada com a facilidade de
aprendizagem e é importante considerar que a frequência de uso do produto pode
influenciar essa mesma capacidade.
2.1.5.4 Graus de Severidade para Problemas de Usabilidade
Graus de severidade (Nielsen, 1995) podem ser utilizados para ajudar a gerir recursos de modo
a corrigir os problemas mais graves, além de ajudar a estimar a necessidade para esforços
adicionais para melhoria da usabilidade.
Por um lado, se os graus de severidade indicarem a existência de problemas de usabilidade
muito graves, a interface não deverá ser implementada. Por outro lado, se for averiguado que a
maioria dos problemas são de ordem cosmética, isto poderá não ser um obstáculo ao
lançamento da interface.
Segundo Nielsen (1995), a severidade de um problema de usabilidade consiste na combinação
de três fatores: a frequência com que um problema ocorre, o impacto da ocorrência desse
problema e a persistência do problema. Este último está relacionado com o facto de os
utilizadores conseguirem ultrapassar o problema através da primeira experiência falhada ou se
esse problema será um obstáculo constante.
Igualmente importante é efetuar um estudo de mercado de modo a medir o impacto do
problema no mesmo, uma vez que os problemas de usabilidade podem afetar negativamente a
popularidade do produto, mesmo aqueles problemas que parecem relativamente pequenos,
insignificantes e fáceis de contornar.
Apesar de a severidade agrupar vários elementos, normalmente são agrupados todos os aspetos
num único grau de severidade de modo a facilitar a priorização e tomada de decisão na altura
de resolver os problemas encontrados. Nielsen (1995) refere, então, uma escala de 0 a 4 para
classificar a severidade dos problemas de usabilidade (tabela 2).
34
2.1.5.5 Três Princípios que Suportam a Usabilidade
Dix, Finlay, Abowd e Beale (1998) escrevem sobre três grandes categorias de princípios que
suportam a usabilidade: Capacidade de Aprendizagem, Flexibilidade e Robustez.
Capacidade de Aprendizagem
Segundo os autores, esta categoria foca-se sobretudo nas particularidades de um sistema
interativo que permitem que utilizadores inexperientes percebam como o devem utilizar e tirar
o máximo partido do mesmo. Esta categoria reúne os princípios da Previsibilidade, Síntese,
Familiaridade, Generalização e Consistência e estes encontram-se resumidos na tabela 3.
Grau Significado
0 Não concordo que seja um problema de usabilidade.
1 Problema cosmético. Não necessita de ser corrigido, a não ser que exista tempo livre extra.
2 Problema de usabilidade menor – Grau de prioridade baixo.
3 Problema de usabilidade maior – Importante corrigir, grau de prioridade alto.
4 Catástrofe de usabilidade – Extremamente necessário corrigir este problema antes de implementar a interface.
Tabela 2. Graus de Severidade (Nielsen, 1995)
Princípios Definição Outros Princípios
Relacionados
Previsibilidade Suporte para o utilizador determinar o efeito de uma ação futura através da experiência de uma ação passada
Visibilidade da Operação
Síntese Suporte para o utilizador aceder ao efeito de ações prévias no estado atual
Honestidade Imediata/Eventual
Familiaridade Até que ponto a experiência e conhecimento do utilizador do mundo real ou outras aplicações computacionais pode ser aplicada quando este interage com um novo sistema
Capacidade de Dedução/Affordance
Generalização Suporte para o utilizador aplicar o conhecimento ou uma interação especifica a outras aplicações ou situações similares
-
Consistência Parecença de comportamentos input/output com situações ou objetivos semelhantes
-
Tabela 3. Princípios que afetam a capacidade de aprendizagem (Dix et al., 2004)
35
Flexibilidade
A categoria Flexibilidade diz respeito à multiplicidade de modos em que o utilizador final e o
sistema trocam informação (Dix et al., 2004). A Flexibilidade da interação, na opinião dos
autores, pode ser subdividida nos princípios da Iniciativa de Diálogo, Multi-threading,
Capacidade de Migração de Tarefas, Capacidade de Substituição e Personalização, como ilustra
a tabela 4.
Robustez
A interação entre utilizador e sistema tem em vista o cumprimento de um determinado conjunto
de objetivos. A robustez da interação cobre funcionalidades que suportem a avaliação da
realização os objetivos assim como os resultados obtidos (Dix et al., 2004). Esta última categoria
engloba os princípios da Observabilidade, Recuperação, Capacidade de Resposta e
Conformidade de Tarefas (tabela 5).
44 Adaptabilidade proporciona aos utilizadores a possibilidade de adaptar por eles mesmos a estrutura e navegação de um sistema conforme as suas preferências. Adaptatividade diz respeito a uma adaptação automática do sistema de modo a ajustar-se às necessidades do seu utilizador (Treiblmaier, et al., 2004).
Princípios Definição Outros
Princípios Relacionados
Iniciativa de Diálogo
Liberdade nos diálogos de input impostos pelo sistema, remoção de limites artificiais
Antecipação Sistema/Utilizador
Multi-threading
Capacidade do sistema permitir ao utilizador realizar mais que uma tarefa ao mesmo tempo
Simultâneo vs. Intercalação, várias
modalidades
Capacidade de Migração de Tarefas
Passagem do controlo de tarefas entre o utilizador e o sistema (por exemplo, delegação de verificação ortográfica para o sistema)
-
Capacidade de Substituição
Capacidade de valores de input e output equivalentes serem arbitrariamente substituídos um pelo outro
Múltipla Representação,
Oportunidade Igual
Personalização Capacidade de modificação da interface por parte do utilizador ou do sistema
Adaptatividade, adaptabilidade44
Tabela 4. Princípios que afetam a flexibilidade do sistema (Dix et al., 2004)
36
2.1.5.6 Usabilidade em Sistemas Móveis
Flat design and improperly rescaled design are the main threats to tablet usability,
followed by poor gestures and workflow
- Jakob Nielsen, Tablet Usability, 2013
Ao longo dos anos, com a descoberta de novas tecnologias e adaptação às mesmas, a
usabilidade de sistemas móveis foi melhorando. No que diz respeito aos tablets, as aplicações
para todos os sistemas operativos viram melhorias, assim como os websites, que foram
aprendendo a ajustar-se às novas tecnologias (Nielsen, 2013).
45 Reachbility refere-se à possibilidade de navegação através dos estados de sistema observáveis (Dix et al., 2004). 46 O princípio do esforço proporcional menciona que se uma determinada ação é difícil de reverter, esta deveria ter sido difícil de efetuar em primeiro lugar. O contrário também se aplica, ou seja, ações possíveis de reverter facilmente devem igualmente ser facilmente efetuadas.
Princípios Definição Outros Princípios
Relacionados
Observabilidade Capacidade de o utilizador compreender em que situação o sistema se encontra através da sua representação
Navegabilidade, Valores por defeito
estáticos/dinâmicos, Reachability45,
Persistência, Visibilidade das operações
Recuperação Permitir ao utilizador corrigir as suas ações quando um erro é detetado
Reachability, Recuperação
Forward/Backward, Esforço Proporcional46
Capacidade de Resposta
Medição do tempo de resposta entre o sistema e o utilizador. Informação por parte do sistema ao utilizador sobre alterações efetuadas
Estabilidade
Conformidade das Tarefas
Até que ponto o sistema suporta todas as tarefas que o utilizador deseja desempenhar e de uma maneira que o utilizador as compreenda
Completação e Adequação das Tarefas
Tabela 5. Princípios que afetam a robustez (Dix et al., 2004)
37
Budiu e Nielsen, através do Nielsen Norman Group, publicaram um relatório dedicado à
Usabilidade em sistemas móveis, onde incluíram cerca de 85 diretrizes para design móvel47. Na
opinião dos autores existem quatro principais barreiras no que diz respeito à usabilidade em
sistemas móveis:
Ecrãs pequenos. Este tipo de ecrãs possibilitam menos opções visíveis, necessitando
que os utilizadores recorram mais frequentemente à memória a curto-prazo. Além
disso, é difícil de arranjar espaço para múltiplas janelas ou outros elementos de
interface que proporcionem comportamentos avançados como, por exemplo,
comparação de produtos.
Tipo de Input Esquisito. Principalmente no que diz respeito a escrever - a introdução de
texto é relativamente lenta e propicia erros, mesmo em dispositivos com miniteclados
dedicados. Além disso, certos elementos das Interfaces Gráficas como menus, botões
ou hiperligações são difíceis de manusear sem um dispositivo apontador.
Transferências lentas. A troca entre ecrãs demora demasiado tempo, mesmo em
dispositivos com 3G.
Websites Não Otimizados. Os designs destes não seguem as normas dos websites para
sistemas móveis uma vez que, por norma, apenas estão otimizados para usabilidade de
computadores Desktop.
Os utilizadores de sistemas móveis dos tempos correntes recorrem muito à introdução de texto.
Introduzir texto em dispositivos móveis pode criar uma sensação estranha e, até mesmo,
frustrante.
Quando desenhamos interfaces para estes dispositivos em particular, temos de conciliar vários
aspetos como estarmos a criar algo para ecrãs pequenos, dispositivos com velocidades de
transferências reduzidas, e elaborar conteúdo e navegação prática de modo a não complicar a
utilização da interface.
Na opinião de Nielsen (2013), existem dois obstáculos principais para a usabilidade em tablet: o
design plano que dificulta a aprendizagem dos utilizadores e a distinção entre os elementos
constituintes das interfaces, e o design redimensionado a partir de ecrãs mais pequenos
(smartphones) ou maiores (computadores) que não se adequa quando redimensionado para
tablet. O segundo aspeto ocorre mais frequentemente em dispositivos Android do que nos
dispositivos iPad e tablet Windows, e apresenta um nível de ameaça superior devido a uma
47 “Usability of Mobile Websites. 85 Design Guidelines for Improving Access to Web-Based Content and Services Through Mobile Devices”.
38
mentalidade que defende que qualquer design simples é superior desde que se adapte ao
espaço disponível no ecrã.
No que diz respeito à usabilidade de sistemas com interfaces gestuais, em particular, Nielsen e
Norman (2010) afirmam que estes são um passo atrás nesta área. Respeitados e comprovados
padrões do design de interação estão a ser esquecidos, ignorados e quebrados e com isso
surgem desastres de Usabilidade.
Em 2010, Raluca Budiu e Hoa Loranger, através de testes de usabilidade realizados em iPad,
chegaram à conclusão que estavam a encontrar diversos obstáculos na interação devido à falta
de estabelecimento de normas de controlo gestual, insistência em ignorar padrões já existentes
e serem criados novos mal concebidos e o desconhecimento da comunidade em relação à
história e descobertas efetuadas na área da IHC.
Em 2013, Nielsen divulgou uma lista das principais preocupações a nível de usabilidade nestas
interfaces. A lista continha itens como como a ativação ocasional de elementos por acidente; a
possível ambiguidade relativa ao deslizar dos dedos, especialmente se a aplicação em questão
tiver diversas secções; a invisibilidade dos gestos realizados pelo utilizador, que não podem ser
representados no ecrã; e a baixa capacidade de aprendizagem dos utilizadores, que se limitam
a fazer uma lista reduzida de ações como tocar, pressionar, deslizar, arrastar ou comprimir.
Website Móvel ou Aplicação?
Enquanto uma aplicação tem a vantagem de poder ser utlizada mais rapidamente, um website
tem a vantagem de funcionar em qualquer sistema operativo, ao contrário das aplicações que
precisam de ser trabalhadas para cada sistema operativo em particular. Além disso, uma das
vantagens dos websites é que estes não precisam de ser transferidos ou atualizados pelo
utilizador (Budiu & Nielsen).
Na altura de decidir sobre a opção a tomar, devemos ter em conta os aspetos positivos e
negativos de cada uma das alternativas, o contexto em que vão ser usadas, e escolher a que
mais se adequa ao caso em particular.
39
2.2 DESIGN CENTRADO NO UTILIZADOR
O Design Centrado no Utilizador48 é uma metodologia iterativa que coloca o utilizador no centro
de todas as decisões de design (Hursman, 2010).
Enquanto a IHC surge da usabilidade mas centra-se na interação dos humanos com os
computadores, o Design Centrado no Utilizador emergiu da IHC, não é usabilidade mas sim uma
metodologia de design utilizada, sobretudo, por programadores e designers que pretende
certificar-se que os produtos correspondem às necessidades dos seus utilizadores (Lowdermilk,
2013).
O DCU relaciona-se com o conceito de Experiência do Utilizador49, uma vez que este pode ser
implementado de modo a certificar que o nosso produto, aplicação ou sistema garante uma boa
experiência para os utilizadores (figura 16).
Usabilidade(factores humanos)
IHC DCUExperiência
do UtilizadorAplicação
Figura 16. Relação entre os diferentes conceitos (Lowdermilk, 2013)
Para Hursman (2010), o DCU é composto por cinco áreas de atuação sendo estas a Arquitetura
da Informação, o Design Gráfico, o Design de Interação, a Pesquisa e a Usabilidade. Para este
autor, o principal objetivo deste tipo de design foca-se na otimização da Experiência do
Utilizador de um sistema, produto ou processo. Como tal, é necessário considerar sempre a
perspetiva do utilizador durante todas as fases de desenvolvimento do projeto.
A perspetiva do utilizador pode ser resumida através de sete itens:
1. Necessidades e desejos;
2. Objetivos, motivação e triggers;
3. Obstáculos e limitações;
4. Tarefas, atividades e comportamentos;
5. Geografia e língua;
6. Meio envolvente e equipamento;
7. Vida profissional e experiência;
48 User-Centered Design ou UCD 49 User-Experience ou UX
40
Processos do Design Centrado no Utilizador
O primeiro passo diz respeito à elaboração de uma pesquisa extensa. Para realizar esta pesquisa
recorrem-se, por exemplo, inquéritos, entrevistas, grupos de foco, brainstorming, personas e
cenários de contexto. Em segundo lugar, é necessário ter em conta a circunstância de utilização.
Para melhor compreender esta temática, existem diversas ferramentas úteis como storyboards,
protótipos, wireframes, design participativo, layouts das páginas, modelos de navegação ou
vocabulário controlado50. De seguida, devemos pensar no design a vários níveis como o design
gráfico, de logótipos, branding, ícones, mockups51 e protótipos (baixa e alta-fidelidade, em papel
e funcionais). Por último, é extremamente importante a realização de uma avaliação. Esta deve
ser realizada através de testes de usabilidade e web analytics. Estes testes de usabilidade podem
ser realizados em laboratório ou remotamente.
Como parte do processo do DCU, devemos dedicar uma boa parte do nosso tempo a considerar
narrativas, personas e cenários – cada um destes métodos esclarecerão o melhor caminho a
seguir para atingir o objetivo final (Lowdermilk, 2013). Se possível, é interessante deixar que os
próprios utilizadores revejam as personas e cenários criados e forneçam o seu feedback relativo
aos mesmos (Lowdermilk, 2013).
Vantagens do Design Centrado no Utilizador
Os principais benefícios deste tipo de abordagem são as taxas mais altas de aprovação, a
melhoria da produtividade dos utilizadores, a melhor qualidade inicial do sistema, custos de
manutenção reduzidos e retorno percetível do investimento (Hursman, 2010). O retorno do
investimento52 é uma medida de performance utilizada com o fim de avaliar a eficiência de um
investimento ou comparar a eficiência de diversos investimentos. Esta medida é calculada
através da divisão do benefício (retorno) de um investimento pelo custo do investimento, onde
o resultado pode ser apresentado como percentagem ou como rácio.
��� =(���ℎ��������������� − �������������������)
�������������������
50 Palavras ou frases, conhecidas por tags, com o objetivo de rotular conteúdo de modo a ser possível encontrá-lo rapidamente através da navegação ou pesquisa de conteúdos. 51 Mockups, ou maquetas, são modelos utilizados para demonstração e avaliação dos produtos. 52 Em inglês, Return On Investment.
41
Além disso, o processo criativo e o fluxo de trabalho numa empresa acabam por ser
beneficiados. Shneiderman (2005) constata ainda que uma boa prática de DCU gera sistemas
menos problemáticos durante a fase de desenvolvimento e menores custos ao longo da
existência, simples aprendizagem, melhor desempenho e com menos probabilidade de surgirem
erros por parte dos utilizadores.
2.3 DESIGN DE INTERFACES MÓVEIS
Quando falamos em design de interfaces, sejam estas pensadas para plataformas móveis ou
não, é importante ter em conta as oito regras elaboradas por Ben Shneidermen (2010):
1. Esforçar-se por manter a consistência. Ações semelhantes devem ser realizadas de
modos idênticos. É igualmente importante manter a consistência no que diz respeito a
terminologia, cores e layout.
2. Satisfazer a usabilidade geral. É necessário considerar a variedade de utilizadores que
utilizarão o sistema e as suas diferenças, como a idade ou competências tecnológicas.
Além disso, adicionar funcionalidades específicas para novos utilizadores como
explicações, ou atalhos para utilizadores mais avançados, enriquecem a interface.
3. Oferecer feedback informativo. O utilizador deve sempre obter feedback do sistema
após efetuar qualquer tarefa.
4. Desenhar diálogos conclusivos. As sequências de ações devem ter um início, meio e fim
evidentes. Deve ser fornecida informação que transmita ao utilizador a sensação de
realização e alívio e, ao mesmo tempo, preparar para o próximo passo.
5. Prevenir erros. Se um utilizador comete um erro, a interface deve detetá-lo
imediatamente e providenciar uma resposta simples e construtiva de modo a auxiliar o
utilizador.
6. Permitir reverter ações com facilidade. Todas as ações devem, dentro do possível, ser
possíveis de repetir. Esta funcionalidade permite aos utilizadores uma interação mais
descontraída, sabendo que a qualquer momento podem voltar atrás nas suas escolhas,
ao mesmo tempo promovendo a exploração da interface.
7. Providenciar controlo. Utilizadores experientes gostam da sensação de pleno controlo
da interface com que estão a interagir e que esta opera conforme as suas expectativas.
Os utilizadores não gostam de surpresas ou mudanças repentinas em ações com que já
se encontram familiarizados.
42
8. Evitar recurso a memória recorrente. Designers devem evitar situações em que o
utilizador tem de decorar informação durante diferentes fases da mesma tarefa.
Tendo em consideração as regras anteriores como base, quando estamos a desenhar uma
interface para uma plataforma móvel como um tablet ou um smartphone, temos de ter em
conta que existem certas restrições que podem influenciar a interação do utilizador com a
mesma, sendo as principais o tamanho do ecrã, o contexto de uso e a velocidade das conexões.
Ao adaptarmos uma interface Desktop para uma plataforma móvel, uma boa parte do espaço
disponível é perdido, devido à diferença no tamanho de ecrã em ambas as plataformas. Ao
trabalharem para ecrãs reduzidos, os designers têm obrigatoriamente de se centrar em
disponibilizar apenas a informação relevante. De facto, este ponto está ligado a outro muito
importante que diz respeito ao contexto de uso. Devido à portabilidade dos sistemas móveis,
existem certas opções menos relevantes em contextos móveis, que ganham mais relevância em
contextos Desktop.
As conexões nos dispositivos móveis são mais restritas que nos dispositivos fixos. Por este
motivo, a interface deve ser pensada de modo a minimizar a carga de descarregamento de
ficheiros, através da redução do número e tamanho de ficheiros. Este último ponto é muito
importante porque, principalmente, num contexto móvel, se o utilizador tiver de esperar muito
tempo para interagir/visualizar todos os elementos de uma interface, este pode perder o
interesse na mesma.
Estas três restrições abordadas obrigam a um profundo conhecimento dos utilizadores do
sistema e das próprias restrições impostas pelos diversos dispositivos móveis. Igualmente
relevante é considerar as situações de uso destes dispositivos. Ao contrário de, por exemplo, os
computadores de secretária, os dispositivos móveis podem ser utilizados em inúmeras situações
diferentes desde um transporte público a um momento de relaxamento no sofá ou cama.
2.3.1 Tipos de Interação
Wroblewski (2011) definiu quatro tipos de interações possíveis, ou objetivos, em dispositivos
móveis, sendo elas a procura de informação, exploração ou diversão, verificação de informação
e edição ou criação. Conhecer estes tipos de interações possíveis ajuda a melhor estruturar e
organizar a informação a apresentar.
No que diz respeito aos tipos de interação com os dispositivos móveis, além dos gestos, existem
a voz, o som e os teclados externos, entre outros. A pensar nos diversos tipos de interação que
43
os utilizadores podem ter com os Surface, como o toque, o rato, a caneta ou o teclado, a
Windows elaborou uma guia de possíveis interações relativamente aos diversos tipos 53 .
Wroblewski (2013) refere ainda que o futuro da interação com estes dispositivos, e não só,
passará pelos sensores e voz, remetendo o toque para um tipo de interação secundário.
A utilização de ecrãs tácteis tem vindo a crescer nos últimos anos. No que diz respeito ao
tamanho dos elementos para interação táctil, estes devem ser grandes e espaçados o suficiente,
de modo a evitar interações não pretendidas. Para um melhor desenvolvimento destas
interfaces, é necessário compreender a variedade de gestos possíveis de realizar (figura 17). No
entanto, quando se trata da elaboração de interfaces moveis, é importante considerar de igual
modo os dispositivos não tactéis. Leitão (2012) afirma que a usabilidade deste tipo de interfaces
ainda não foi muito trabalhada a pensar em utilizadores com características específicas, como
os utilizadores seniores. Cevada et al. (2013) puderam observar que doentes de Parkinson
53 http://msdn.microsoft.com/en-us/library/windows/apps/dn456349.aspx consultado em 14-05-2014
Figura 17. Gestos básicos em interfaces tácteis (Wroblewski, 2011)
44
revelam algumas dificuldades em interagir com ecrãs tácteis, no que diz respeito aos gestos e à
própria sensibilidade dos mesmos, devido a limitações motoras derivadas da sua condição.
Hoje em dia, os dispositivos vêm integrados com funcionalidades de reconhecimento de voz.
Mais que uma questão prática de dizer ao dispositivo o que procurar na Internet, por exemplo,
é um tipo de interação muito importante quando temos em conta a acessibilidade.
No que diz respeito ao som, os sistemas informam o utilizador do estado da ação que efetua
através de efeitos sonoros. Por exemplo, ao pressionar o teclado e escolher uma determinada
ação, o sistema emite um som para o utilizador saber que o dispositivo reconheceu o toque.
A nível de teclados externos, recentemente as atenções recaem sobre o Microsoft Surface mas
mesmo para os outros dispositivos móveis existe a possibilidade de adquirir um teclado externo
e ligá-lo ao dispositivo. Situações de trabalho, onde a escrita ganha relevo, são ótimos exemplos
da utilidade destes.
2.3.2 Layout e Conteúdos
O layout tem que ser pensado tendo em conta características particulares da utilização móvel
como a postura, o tipo de input e os tamanhos de ecrã distintos. É, igualmente, importante que
um website apresente um layout responsivo, capaz de se adaptar a diferentes viewports. Por
último, este deve ser simples, limitando-se a apresentar apenas o necessário.
Quando questionado em relação à importância da utilização de um layout responsivo em design,
Jeffrey Veen54 (2011) responde que, a cada dia que passa, o número de dispositivos, plataformas
e browsers vai aumentando e que o layout responsivo é fundamental para o design de websites
para a próxima década.
Relativamente a interfaces móveis, estas requerem uma priorização de conteúdo pois é
necessário aproveitar ao máximo o espaço em ecrã disponível. Uma boa opção para poupar
espaço em ecrã passa por usar as capacidades do HTML555 e utilizar o atributo placeholder
em elementos de introdução de dados em formulários, evitando assim texto explicativo extra
antes das caixas. Para que o utilizador perceba que se trata de um texto explicativo e provisório,
este deve estar colorido num tom subtil.
54 Fundador e CEO da Typekit. “Day by day, the number of devices, platforms, and browsers that need to work with your site grows. Responsive web design represents a fundamental shift in how we’ll build websites for the decade to come”. 55 HyperText Markup Language
45
Menus de navegação que surjam após pressionar um botão específico (dropdown menus) são
outro bom exemplo de como poupar espaço em ecrã, quando comparados com um menu de
navegação convencional. Em determinadas situações, os menus sob a forma de caixas de
listagem podem ser problemáticos em interfaces tácteis devido ao espaço reduzido entre os
elementos da lista. Os designers devem considerar este aspeto adaptando essas caixas a essa
realidade.
Apesar de atributos como o autocapitalize e o autocorrect serem úteis em contextos
móveis (Wroblewski, 2011), é importante que estes não sejam utilizados em campos como
nomes de utilizador ou palavras-chave. Igualmente importante pode ser a utilização de
máscaras de introdução em campos destinados a endereços eletrónicos e códigos postais,
facilitando assim a introdução de informação com uma formatação específica e idêntica em
todos os casos. Um outro método pra facilitar a introdução de dados passa por disponibilizar a
opção de autodetecção da localização para preenchimento de campos relacionados.
Mas mais do que o aspeto da interface em si, em contextos móveis com possibilidade de toque,
é necessário considerar questões ergonómicas. A interface tem de ser usável confortavelmente,
adequando-se ao modo como os nossos dedos e mãos envolvem o dispositivo.
2.3.2.1 Ergonomia
Quando a ergonomia surgiu, esta foi pensada com o objetivo de adaptar os produtos para
indivíduos que trabalhassem nas áreas da segurança, indústria, aeronáutica, entre outros. Por
outras palavras, foi uma disciplina pensada para o auxílio de pessoas qualificadas que
permitissem uma observação da realização das suas tarefas de modo a perceber as suas
necessidades (Karwowski et al., 2011).
Hoje em dia, a ergonomia torna-se importante para o desenvolvimento de produtos que
facilitam o dia-a-dia do ser humano, desenvolvem o conhecimento e melhoram o bem-estar e
segurança dos seus utilizadores, tendo assim um enorme relevo no sucesso de um produto
(Karwowski et al., 2011).
Esta disciplina da ergonomia proporciona-nos uma perspetiva humana baseada em
conhecimento científico que permite a caracterização e compreensão de certas dimensões
físicas: psicológicas, antropométricas e biomecânicas, expressas como domínios físicos; e
dimensões cognitivas: processos mentais, perceção, memória, raciocínio e resposta motora, e
como estes conceitos moldam a interação entre seres humanos (Karwowski et al., 2011).
46
Segundo Clark (2012), existem cinco tópicos importantes a nível de ergonomia que devemos
considerar quando estamos a pensar numa interface para contextos móveis tácteis, sendo estes.
Wrobleski (2013) afirma que existem três modos distintos de segurar um telemóvel: uma mão
e um polegar, duas mãos e um dedo ou polegar, duas mãos e dois polegares. O autor refere
ainda que 49% das pessoas que observou a utilizar os telemóveis na rua seguravam o objeto
com uma mão e um polegar, das restantes 51%, 75% utilizavam duas mãos com um polegar.
Regra do Polegar
Em primeiro lugar, é necessário desenvolver uma consciência em
relação às áreas dos dispositivos onde as nossas mãos conseguem
interagir sem esforço. Normalmente, em smartphones, os
controlos principais para a navegação ou barras de ferramentas
encontram-se no fundo do ecrã, ao contrário do software
desenvolvido para Desktop. Isso deve-se a essa zona (figura 18)
ser a que requer menos esforço para interagir quando seguramos
o dispositivo na nossa mão (Wroblewski, 2013).
O facto de esses controlos não incidirem exatamente na área
demarcada na figura 18 mas sim na parte de baixo do ecrã por
completo, diz respeito à troca frequente da mão que utiliza o
dispositivo. No dia-a-dia, ninguém utiliza o dispositivo apenas
com uma mão, eventualmente existe uma troca de mão passado
um determinado tempo.
Esta regra relativa à posição do polegar foi tornada numa
convenção nos sistemas iOS onde, por exemplo, os botões
importantes como o “editar” ficam fora do alcance imediato do
dedo a fim de evitar um toque não pretendido (figura 19).
Outra razão para os controlos principais se encontraram na base
do ecrã deve-se ao facto de os dedos taparem o ecrã e ocultarem
informação. Por esta razão, o conteúdo deve vir colocado sempre
acima dos controlos principais.
Figura 18. Zona abrangida pelo polegar da mão direita
Figura 19. Botão "Edit" longe da zona de conforto do polegar
47
Agregação de Barras de Ferramentas
Em smartphones Android, os botões físicos situam-se na base do dispositivo. Por esse motivo,
ao desenharmos interfaces móveis para Android, em apps, devemos pensar na existência desses
dispositivos e colocar os controlos principais no topo caso contrário existirão duas barras na
base: a física e a virtual. Infelizmente, ao utilizarmos os controlos no topo, iremos cobrir uma
parte do conteúdo com as nossas mãos.
Através da implementação dos controlos virtuais no topo, permitimos uma melhor
funcionalidade da interface em dispositivos Android antigos, evitando pressionar uma função
indesejada. Apesar de esta opção contrariar o primeiro tópico referido, é extremamente
necessária em contextos Android. Aqui os sistemas iOS são claramente beneficiados (figura 20).
No caso de não estarmos a desenvolver uma app mas sim um website, devemos evitar colocar
os controlos principais na base do dispositivo tal como colocamos nas apps. Se, por um lado, o
atributo position:fixed em CSS 56 não é reconhecido pelos browsers para dispositivos
móveis, por outro cada browser tem a sua interface própria, com controlos e botões diferentes,
podendo causar sérios problemas de navegação. Wroblewski (2011) exemplifica, através do
website da Ad Age Mobile, o que seria uma solução ideal para este problema (figura 21). A
navegação diz respeito a um botão menu no topo da página que, na verdade, não abre um novo
56 Cascading Style Sheets
Figura 20. Comparação da App Foursquareentre dispositivos Android (esquerda) e iPhone
(direita)
48
menu mas é uma âncora para o fim da página. Deste modo, o conteúdo continua com prioridade
sob a navegação e, como o autor bem refere, evita-se o recurso a tecnologias como o JS57 que
iriam pesar no carregamento do menu em questão.
Resumindo, no caso das apps, em Android os controlos devem vir no topo do ecrã mas em iOS
os controlos devem situar-se no fundo do ecrã. No caso de websites, os controlos devem
localizar-se no fundo do layout da página.
Tablets
Como os tablets não deixam de ser dispositivos tácteis, a regra do polegar também se aplica aos
mesmos, embora com uma zona de conforto diferente, uma vez que o modo como seguramos
o dispositivo também é diferente.
O modo como seguramos o tablet e a sua orientação influenciam a maneira como tocamos nele.
Se estivermos de pé, provavelmente usaremos as duas mãos simultaneamente para
interagirmos com ele; se estivermos sentados numa mesa, e apoiarmos os braços na mesma,
57 JavaScript
Figura 21. Layout do website Ad Age Mobile como é visualizado no dispositivo e o seu verdadeiro layout
49
seguraremos com uma mão e interagiremos com outra; sentados temos tendência para
colocarmos o dispositivo sobre o nosso colo, segurá-lo com uma mão e interagir com a outra;
deitados ou a reclinar tendemos a deitar o dispositivo sob o nosso estômago, segurando com
uma mão e interagindo com a outra. Outro aspeto relevante é a proximidade do dispositivo –
seguramos este mais próximo estando de pé do que se estivermos deitados ou reclinados (Clark,
2012).
Apesar de segurarmos e interagirmos com os dispositivos de diversos modos distintos, existem
dois pontos em comum. Em primeiro lugar, usualmente seguramos o tablet na metade de cima
para um melhor equilíbrio do peso, o que significa que os polegares recaem no terço de cima do
ecrã, perto dos cantos do dispositivo. Por último, o ecrã dos tablets é muito maior comparando
com os smarthphones. Por esse motivo, o foco da atenção recai sob o centro do ecrã e o design
deve refletir isso mesmo. Considerando estes dois aspetos, os controlos e botões principais
devem surgir na primeira metade do ecrã em apps (figura 22).
Figura 22. Controlos principaissituados na zona de conforto do
polegar, conteúdos relevantes no centro do ecrã
50
Parte Inferior do Ecrã
Sempre que os controlos modifiquem ou apresentem novo conteúdo devem ser colocados no
fundo do ecrã. Na figura 23, podemos ver um bom exemplo deste aspeto em prática. Se a lista
que o botão abriu estivesse situada no topo do ecrã, os itens listados seriam tapados pela nossa
mão, inconscientemente situada sobre a lista à espera que o nosso cérebro escolhesse o item
pretendido.
Figura 23. App do The Sydney Morning Herald
51
Resumindo os dois últimos aspetos, nos cantos superiores devem ser colocados botões de
navegação ou itens como adicionar a favoritos ou apagar. No fundo do ecrã devem estar
situados botões que permitam escolher ou visualizar conteúdo novo.
Tamanho e Espaçamento dos Elementos
Os botões virtuais com os quais interagimos têm de ser desenhados com intuito de ser
impossível de falhar a interação com os mesmos. O modo como seguramos o dispositivo e a
posição na qual o estamos a utilizar, influenciam o modo como iremos pressionar os controlos
ou botões. Embora não exista nenhuma regra de ouro a seguir, diferentes empresas têm a sua
própria regra, apesar de serem semelhantes.
A Microsoft estabelece três tamanhos e distâncias entre os elementos a utilizar: um primeiro
recomendado, um segundo quando é extremamente importante não falhar e um terceiro mais
reduzido quando existe falta de espaço na interface e o erro que possa surgir de pressionar no
sítio errado seja facilmente revertido com um gesto (figura 24). A Apple insiste que é importante
facilitar a interação e criar ícones de 44px, equivalente a 7mm (figura 25).
Figura 24. Normas estabelecidas pela Microsoft em relação a tamanhos e distâncias entre elementos
52
A Google estabelece que, em Android, o tamanho recomendado é de 48dp58, cerca de 9mm.
Deste modo, dependendo do ecrã do dispositivo, o tamanho dos elementos variará entre os 7 a
10mm59.
Analisando as regras das companhias, mais a experiência com os
próprios dispositivos, Clarke (2012) afirma que o tamanho
mínimo mais adequado para qualquer elemento de toque seria
de 44px por 30px. A nível de espaçamento, como seria de esperar,
quanto mais perto os elementos se encontrarem uns dos outros,
maiores devem ser para evitar a escolha da opção errada.
Leitão (2012) estudou o modo como utilizadores seniores
conseguiam interagir com os sistemas móveis. Uma das
diferentes fases do estudo consistia em testar 28 toques em
localizações diferentes (figura 26). A percentagem média
com que os participantes conseguiram de facto pressionar o
sítio correto com sucesso foi de cerca de 90%, existindo duas
localizações onde os resultados foram ligeiramente acima de 94%
e uma, no canto superior esquerdo, teve uma percentagem de
80%. Este estudo realizado pela autora, na sua totalidade, leva à
conclusão que o design de sistemas móveis ainda não foi muito
pensado no que diz respeito a este segmento de mercado.
58 Density-independent pixel. 1dp equivale a 1px num ecrã de 160dpi. Em http://developer.android.com/design/style/iconography.html consultado em 13-12-2013 59 http://developer.android.com/design/style/metrics-grids.html consultado em 13-12-2013
Figura 25. Tamanho recomendado (em pixéis) pela Apple para os
elementos da UI
Figura 26. Grelha de localizações de testes
utilizada por Leitão (2012)
53
Cevada et al. (2014) desenvolveram uma aplicação para doentes de Parkinson com o objetivo
de gerir a sua medicação. Para medirem a eficácia das áreas dos elementos (botões retangulares
com uma altura de 10.5cm e os quadrados com lados de 14cm) realizaram um estudo junto de
um grupo de participantes com esta doença. Este estudo permitiu observarem alguns problemas
a nível de interação. Um dos aspetos interessantes de observar diz respeito aos participantes
tenderem a pressionar o ícone ou o texto presente nos botões da interface. Tendo em conta
esta descoberta, foi demonstrada a preocupação de afastar esses elementos gráficos dos limites
dos botões com o objetivo de reduzir erros.
2.3.3 Diferenças entre Sistemas Operativos
Existe uma considerável variedade de sistemas operativos existentes no mercado mobile –
Android, iOS e Windows. Apesar de uma parte destas diferenças já terem sido descritas ao longo
do subcapítulo 2.3.2 Layout e Conteúdos, outras podem ser encontradas, por exemplo, nos
gestos e como estes são interpretados pelo sistema operativo em questão.
Ações como carregar num ícone para abrir uma aplicação, apenas pressionando o ecrã e
largando imediatamente, ou fazer zoom in/out, através de pinch (ver figura 17 - Gestos básicos
em interfaces tácteis), são efetuadas do mesmo modo nos três sistemas operativos. Gestos
como, por exemplo, pressionar durante uns segundos podem abrir o modo de seleção de itens
em que surgem diversas check box para escolhermos um ou mais itens e escolher o que
queremos fazer (Android), ver mais informações sobre um determinado item (Windows) ou
melhorar o cursor quando em situações de texto editável ou selecionável (iOS).
Existem igualmente gestos implementados em sistemas operativos que não têm nenhuma
função nos restantes. Abanar o dispositivo em iOS pode dar inicio a reverter ou voltar a fazer
uma ação; no Windows, deslizar o dedo de baixo para cima perto da extremidade faz com que
surja um menu de comandos da aplicação, ou da direita para esquerda, perto da extremidade,
surge o menu do sistema; em Android, pressionar um item durante uns segundos e arrastar é
utilizado frequentemente para modificar a disposição dos itens nos diversos ambientes de
trabalho.
54
2.3.4 Acessibilidade
A acessibilidade em dispositivos móveis está relacionada com o acesso multimodal à informação
em contextos adversos de uso e/ou incapacidade, permanente ou temporária, do utilizador. Os
sistemas operativos existentes no mercado até à data apresentam várias técnicas com vista a
tornar a interação com os dispositivos mais facilitada. Os três sistemas operativos serão
analisados individualmente.
Android
O Android foca o seu design na regra “Eu devo saber sempre onde estou”60. Enquanto o
utilizador comum consegue perceber muito do conteúdo disponibilizado pelos ícones, um
utilizador cego precisa de outro tipo de suporte. Neste sistema operativo, é possível acrescentar
o atributo android:contentDescription em XML61 para que aplicações como o Google
TalkBack 62 , instalado por defeito na maioria dos dispositivos, permitam uma interação
melhorada com o dispositivo. Porém, o TalkBack deve estar ativado nas opções do sistema, na
seção de Acessibilidade. Outras opções podem ser ativadas nesse menu, como o aumento do
tipo de letra, a leitura de palavras-passe em voz alta, entre outros (figura 27).
60 Tradução do autor de “I should always know where I am”. http://developer.android.com/design/patterns/accessibility.html consultado em 14-05-2014 61 Extensible Markup Language 62 Google TalkBack está disponível na Google Play gratuitamente e providencia um serviço de acessibilidade voltado para utilizadores cegos, através de respostas faladas, audíveis e vibração.
Figura 27. Menu de Acessibilidade em Android (v4.1.1)
55
Como os utilizadores podem não querer interagir com o dispositivo apenas através do ecrã de
toque, todos os elementos de navegação devem suportar a opção de focus. Esta opção pode ser
modificada através do método View.setFocusable() ou em XML através do atributo
android:focusable. Igualmente, cada controlo da interface tem quatro atributos
(android:nextFocusUp, android:nextFocusDown, android:nextFocusLeft e
android:nextFocusRight) para que seja possível alterar a sequência de navegação
predefinida pela plataforma.
iOS
Este sistema operativo é bastante reconhecido pelas
suas funcionalidades pensadas em melhorar a
acessibilidade dos seus utilizadores. VoiceOver, um
leitor de ecrã semelhante ao Google TalkBack, além
de ler as breves descrições implementadas,
possibilita aos utilizadores ouvirem dicas sobre para
que estes servem (figura 28). Neste leitor de ecrã,
merece destaque a compatibilidade com terminais
de Braille, em diversas linguas e com uma grande
compatibilidade de terminais, alargando assim o seu
suporte a utilizadores cegos. Além disso, este leitor
enuncia em voz alta todos os caracteres introduzidos
quer no teclado virtual, requer um teclado físico
ligado diretamente ao dispositivo. O VoiceOver
conta com cerca de 30 idiomas à disposição, incluindo o
Português de Portugal. Outras opções de acessibilidade disponíveis neste sistema operativo a
pensar nos utilizadores cegos são a possibilidade de ajuste do tamanho do texto e a possibilidade
de inversão de cores, incluindo vídeos.
A pensar nos utilizadores com problemas do foro auditivo, a Apple criou o FaceTime. Esta
aplicação, semelhante ao Skype, permite a realização de videochamadas e é indicada para
utilizadores de língua gestual, uma vez que a alta qualidade de vídeo e velocidade de fotogramas
faz com que os gestos sejam bem percetíveis e fluidos. O iTunes U disponibiliza um botão onde
o utilizador é reencaminhado para a iTunes Store a fim de encontrar as legendas para o
conteúdo que está a tentar visualizar. O iOS disponibiliza igualmente suporte para outras
legendas, permitindo alterar o seu estilo ou tipo de letra. O iMessage, aplicação de troca de
Figura 28. Exemplificação do VoiceOver em funcionamento
56
mensagens escritas, permite trocar mensagens textuais ilimitadamente e adicionar fotos,
smileys, vídeos, entre outros. É, ainda, possível definir o áudio para mono para evitar a perda de
som devido à divisão de faixas de áudio pelos canais em som estéreo, ou ativar alertas visíveis
ou vibratórios para as mais diversas funções. A Apple trabalhou ainda no desenvolvimento de
aparelhos auditivos que trabalhassem em cooperação com o iPhone, permitindo uma gestão do
aparelho através do dispositivo e um aproveitamento de todas as funcionalidades ao mais alto
nível.
No que diz respeito aos utilizadores com incapacidades físicas ou motoras, a Apple implementou
uma funcionalidade chamada AssitiveTouch. Quando o utilizador tem dificuldade em efetuar um
determinados gestos, pode programar outra ação que emule esse gesto, através do menu de
acessibilidade do iOS. Além disso, os dispositivos iOS são compatíveis com software de funções
equivalentes, desenvolvidos por outras empresas. Outra funcionalidade existente permite a
criação de atalhos de teclado para que seja mais rápido escrever um endereço eletrónico, um
nome, uma morada ou outro pedaço de texto utilizado frequentemente (figura 29).
Este sistema operativo é o mais completo do mercado a nível de acessibilidade, providenciado
aos seus utilizadores
um grande suporte
na interação com os
seus dispositivos.
Windows
No que diz respeito aos Surface, a Windows integrou um conjunto de funcionalidades a pensar
na acessibilidade dos mesmos. A nível de utilizadores cegos, existem funcionalidades como o
narrador (leitor de ecrã), a lupa (zoom em determinadas partes do ecrã), o alto contraste, o
aumento da espessura do cursor e o aumento de tamanho e modificação da cor do ponteiro do
rato. Para utilizadores com deficiências motoras, é possível ainda definir o controlo do rato
através do teclado numérico.
Figura 29. Utilização do atalho "Cyl" para escrever a expressão "Call You Later”
57
3 MÉTODOS
Existe uma grande variedade de métodos a utilizar quando queremos avaliar um produto ou
interface, alguns propícios a uma determinada fase de desenvolvimento do produto, outros
adequando-se a todas as fases de desenvolvimento.
Este estudo foca-se numa abordagem, principalmente, qualitativa. O sistema em questão é um
sistema real, já implementado e em desenvolvimento há vários anos. Por este motivo, é
necessário recorrer a metodologias comprovadas de modo a obter um resultado credível.
Durante a realização do estudo, diferentes metodologias foram utilizadas, sobretudo
qualitativas, para atingir os fins pretendidos. Estas, e outras existentes, são abordadas nas
próximas páginas.
Fases de Desenvolvimento de um Novo Produto
Desde a sua criação, o produto passa por diversas fases de desenvolvimento. Porém, este ciclo
não deve ser confundido com o Ciclo de Vida do Produto (CVP)63. Este último é constituído por
cinco fases que descrevem o estágio no qual o produto se encontra. O CVP é muito utilizado em
Marketing para desenvolver estratégias tendo em conta o produto e seu mercado.
As fases de desenvolvimento de um novo produto64 não têm um número em concreto, porém
as que consideramos como mais importantes são o surgimento da ideia, a pesquisa, o
desenvolvimento do produto, a fase de testes e a análise do feedback dos seus utilizadores
(figura 30). Enquadrar o produto com uma das fases permite uma escolha mais eficaz e
consciente de quais as metodologias que melhor se adaptam à fase corrente.
63 Product Life Cycle 64 Tradução do autor de New Product Development Stages
Figura 30. Fases de Desenvolvimento de um Novo Produto
ideia Pesquisa Desenvolvimento Testes Análise
58
O facto de existirem cinco fases, não corresponde a estas serem lineares, ou seja, é um processo
iterativo. Durante o processo de desenvolvimento do produto existe uma evolução, podendo
ser necessário voltar a uma ou mais fases prévias.
Numa primeira a fase, a ideia começa a ser desenvolvida. É nesta fase que as análises SWOT65
são elaboradas, assim como o recurso aos grupos focais ou brainstorming, etc. Na segunda fase,
é elaborada uma pesquisa extensa, complementar à análise SWOT, onde tentamos perceber
quais os utilizadores do nosso potencial produto. Entrevistas e personas, por exemplo, surgem
frequentemente ao longo desta fase. Na terceira fase, o produto começa a ser desenvolvido,
através de mockups e protótipos, por exemplo. Na penúltima etapa, são realizados testes ao
produto, verificando se este corresponde às expectativas ou se existem obstáculos nunca
previstos. Por último, antes de o produto ser colocado no mercado e começar a ser considerado
o CVP, é necessária uma análise dos resultados obtidos na quarta etapa além do feedback dos
utilizadores, recolhido através de inquéritos ou durante os próprios testes, por exemplo.
3.1 AVALIAÇÃO HEURÍSTICA (INCLUINDO ESTRUTURA DE LAVERY)
Uma Avaliação Heurística é uma apreciação do sistema realizada considerando as Heurísticas de
Usabilidade. Numa altura em que as normas de usabilidade exigiam que imensas regras fossem
seguidas, Nielsen e Molich (1990) simplificaram essa quantidade gigantesca numa lista de dez
princípios básicos de usabilidade. Mais tarde, Nielsen (1995) publica um artigo correspondente
a uma versão mais refinada desses princípios ao que chama As Dez Heurísticas de Usabilidade
para o Design de Interfaces:
1. Visibilidade do Estado do Sistema. O sistema deve informar os utilizadores sobre o que
se está a passar, através de feedback adequado e dentro de um espaço de tempo
considerável.
2. Concordância entre o Sistema e a Realidade. O sistema deve utilizar palavras, frases e
conceitos familiares ao utilizador, em vez de termos técnicos. Assim, deve seguir
convenções do mundo real, fazendo com que a informação apareça ordenada de um
modo lógico e natural.
65 Análises que avaliam os pontos fortes e fracos do produto, assim como as oportunidades e ameaças existentes no mercado (Strenghts, Weaknesses, Opportunities and Threats).
59
3. Controlo e Liberdade do Utilizador. Por vezes, os utilizadores selecionam funções do
sistema de forma não intencional. O sistema deve suportar as opções “Anular” e
“Refazer”66.
4. Consistência e Normas. Os utilizadores não devem necessitar de pensar se diferentes
palavras, situações e ações significam o mesmo. Devem-se seguir as convenções da
plataforma.
5. Prevenção de Erros. Melhor que boas mensagens de erro é a implementação de um
bom design que previne estes problemas de acontecerem em primeiro lugar. As
condições propícias de erros devem ser eliminadas ou identificá-las e apresentar aos
utilizadores uma opção de confirmação.
6. Reconhecer em vez de Recordar. Os objetos, ações e opções necessitam de estar
sempre visíveis. O utilizador não deve ser obrigado a decorar informação de uma parte
do diálogo para a outra. As instruções para interagir com o sistema devem estar bem
visíveis, caso contrário deve existir fácil acesso às mesmas, se necessário.
7. Flexibilidade e Eficiência de Uso. Os atalhos permitem aos utilizadores mais experientes
a execução de operações mais rapidamente. Apesar de poderem passar despercebidos
a utilizadores inexperientes, proporcionam funcionalidades avançadas para os mais
experientes.
8. Estética e Design Minimalista. Os diálogos não devem conter informação irrelevante ou
que raramente é necessária. Esta compete com a informação relevante, diminuindo a
sua visibilidade.
9. Ajudar os Utilizadores a Reconhecer, Diagnosticar e Recuperar de erros. As mensagens
de erro devem ser descritas em linguagem simples, sem siglas possivelmente estranhas
ao utilizador, sem possíveis códigos de sistema, como ID’s, indicar precisamente o
problema e disponibilizar soluções úteis e construtivas.
10. Ajuda e Documentação. Apesar de ser preferível que o sistema seja utilizável sem
documentação, pode ser necessário disponibilizar ajuda e documentação. Essa
informação deve ser fácil de pesquisar, focada nas tarefas do utilizador, listar os passos
a seguir e não ser demasiado longa.
66 Em inglês, Redo. Em software traduzido na língua portuguesa, redo é normalmente traduzido por refazer pois permite voltar a fazer a última ação elaborada
60
No decorrer deste estudo, foi elaborada uma análise heurística do sistema com vista a levantar
o máximo de informação possível sobre o estado do mesmo. Para isso, utilizamos a Estrutura de
Lavery, segundo a qual o analista deverá fazer um levantamento dos seguintes elementos para
cada uma das dez heurísticas apresentadas anteriormente:
Questão de conformidade. Registar o que o sistema deve fazer para satisfazer o
princípio heurístico em causa;
Evidência de conformidade. Registar exemplos/evidências da aplicabilidade dessa
heurística, assim como o que pode ser alterado para melhor a satisfazer;
Motivação. Registar a importância dessa heurística num determinado contexto de uso.
Podemos afirmar que a avaliação heurística é confiável e proveitosa uma vez que os resultados
são facilmente compreensíveis para indivíduos que não sejam especialistas de usabilidade,
define como elaborar análises heurísticas e disponibiliza uma lista curta de heurísticas de
usabilidade aceites. No que diz respeito à confiança dos resultados, não é necessário que a
pessoa que realiza a análise possua conhecimentos aprofundados na área da usabilidade.
Apenas é necessário encarar esta análise atenta e seriamente, sendo aconselhada a estrutura
de Lavery a indivíduos inexperientes pois serve de guião e facilita a compreensão dos problemas
possivelmente detetados.
Esta análise explica como interpretar os resultados e representa um trabalho muito importante
no campo das heurísticas de usabilidade, ao ser um dos primeiros experimentos a testar
empiricamente o modelo de heurísticas para testes de usabilidade67. Por último, a avaliação
heurística é considerada importante no campo da usabilidade, possível de verificar através do
Google Académico, onde o artigo “Heuristic Evaluation of User Interfaces by Molich and Nielsen”
é citado em mais de 2700 artigos.
É relevante referir que em 2006 foi publicado o artigo “Appropriating and Assessing Heuristics
for Mobile Computing” (Bertini et al.). Este artigo sugere que estas heurísticas de Nielsen sejam
adaptadas de modo a obter resultados mais relevantes em análises de dispositivos móveis.
Como resultado do estudo efetuado pelos autores, as heurísticas foram reduzidas a oito e
adaptadas ao contexto móvel:
67 Professional Review: Heuristic Evaluation of User Interfaces by Rolf Molich and Jakob Nielsen - https://medium.com/@intuitivous/professional-review-heuristic-evaluation-of-user-interfaces-by-rolf-molich-and-jakob-nielsen-eae08197026
61
1. Visibilidade do Estado do Sistema e o Fator de Perda/Localização do Dispositivo.
Tratando-se de dispositivos móveis, o sistema deve ainda mostrar informações relativas
a fatores críticos como, o estado da bateria ou da ligação à rede. O sistema deve ainda
permitir encriptação de informação ou outras medidas adequadas em caso de perda do
dispositivo ou ainda fornecer um modo de encontrar o dispositivo caso este se encontre
fora do lugar habitual;
2. Concordância entre o Sistema e a Realidade. Nesta heurística é acrescentado o aspeto
de o sistema dever, sempre que possível, ter a capacidade de reconhecimento do
ambiente em que se encontra e adaptar a informação de acordo;
3. Consistência e Mapeamento das Ações. O modelo conceptual referente à possível
utilização do dispositivo ou sistema por parte do utilizador necessita de ser consistente
com o contexto.
4. Boa Ergonomia e Design Minimalista. Os dispositivos móveis têm de ser confortáveis e
fáceis de segurar e transportar, além de robustos. Os diálogos não devem conter
informação irrelevante ou raramente necessária.
5. Facilidade de Input, Legibilidade do Ecrã e Relance. Sistemas móveis devem permitir a
introdução de dados de um modo simples, reduzindo a necessidade do utilizador
recorrer a ambas as mãos para o fazer. Os conteúdos do ecrã devem ser de fácil leitura
e navegação considerando as possíveis condições de iluminação. Por último, o utilizador
deve ser capaz de reter informação importante de relance.
6. Flexibilidade, Eficiência de Uso e Personalização. Os utilizadores deste tipo de
dispositivos precisam de ter flexibilidade para personalizar ações que fazem
frequentemente, assim como configurar o sistema conforme as suas necessidades
contextuais. O sistema pode ainda sugerir opções de personalização se estas forem
oportunas.
7. Estética, Privacidade e Convenções Sociais. A estética deve ser considerada, assim
como a privacidade dos utilizadores – a informação necessita de estar segura e ser
privada. A interação com os dispositivos móveis precisa ser confortável e respeitar as
convenções sociais.
8. Gestão de Erros Realista. É necessário proteger os utilizadores dos erros. Quando estes
ocorrem é fundamental disponibilizar ajuda de modo aos erros puderem ser
diagnosticados e ultrapassados com sucesso. As mensagens de erro devem ser simples
e precisas. Devem-se sugerir soluções construtivas, como as FAQ68 ou simples dicas.
68 Perguntas Frequentes (em inglês, Frequently Asked Questions)
62
3.2 INQUÉRITOS
Existem dois grandes tipos de inquéritos, os de resposta fixa, como os SUS (System Usability
Scale - abordados no próximo subcapítulo), e os de resposta aberta. Nos questionários de
resposta fixa, os participantes têm de responder a questões, existindo diversas respostas sob a
forma de alternativa, sendo pedido que escolham a que lhes parecer mais apropriada. Também
se podem usar escalas, como a de Likert69, para escolherem a opção que mais se aproxima da
sua opinião. Por último, nos questionários de resposta aberta, os participantes escrevem as suas
próprias respostas às perguntas colocadas e podem ser bastante úteis quando o investigador
não sabe ao certo quais os assuntos de maior relevo quanto à usabilidade de um produto. Ao
proporcionarem uma maior liberdade nas respostas, estes últimos questionários permitem que
os participantes se alonguem nas suas respostas.
3.2.1 Inquéritos SUS
Os inquéritos SUS (System Usability Scale) utilizam a escala Likert para avaliar a satisfação de um
utilizador em relação a um website. Esta escala foi desenvolvida por John Brooke (1986) no Reino
Unido. Estes são dos inquéritos mais utilizados para medir a usabilidade de um sistema ou
produto e abrangem aspetos como a necessidade de suporte, necessidade de aprendizagem e
complexidade do sistema ou produto70.
A nível de estrutura, os inquéritos SUS são compostos por 10 perguntas, avaliadas de 1 a 5, em
que o 1 representa discordância e o 5, por oposição, concordância. As perguntas que compõem
o inquérito são apresentadas de seguida.
69 Utilizador indica o seu nível de concordância com uma frase através de uma escala de valores pré-definidos. A escala padrão é constituída por cinco itens como resposta, iniciando em discordo fortemente até concordo fortemente, sendo que a posição intermédia demonstra uma atitude neutral em relação à questão. 70 A Comparison of Questionaries for Assessing Website Usability - http://home.comcast.net/~tomtullis/publications/UPA2004TullisStetson.pdf
63
1. Penso que gostaria de usar este sistema frequentemente
Discordo fortemente
1 2 3 4 5 Concordo
fortemente
2. Achei o sistema desnecessariamente complexo
Discordo fortemente
1 2 3 4 5 Concordo
fortemente
3. Achei o sistema fácil de usar
Discordo fortemente
1 2 3 4 5 Concordo
fortemente
4. Penso que precisaria do apoio técnico para conseguir usar o sistema
Discordo fortemente
1 2 3 4 5 Concordo
fortemente
5. Achei que as várias funções do sistema estavam bem integradas
Discordo fortemente
1 2 3 4 5 Concordo
fortemente
6. Achei que havia demasiadas inconsistências neste sistema
Discordo fortemente
1 2 3 4 5 Concordo
fortemente
7. Imagino que a maioria das pessoas consegue aprender a usar este sistema muito rapidamente
Discordo fortemente
1 2 3 4 5 Concordo
fortemente
64
8. Achei o sistema muito incómodo de usar
Discordo fortemente
1 2 3 4 5 Concordo
fortemente
9. Senti-me muito confiante ao usar o sistema
Discordo fortemente
1 2 3 4 5 Concordo
fortemente
10. Precisei de aprender muitas coisas antes de conseguir começar a usar o sistema
Discordo fortemente
1 2 3 4 5 Concordo
fortemente
No que diz respeito aos resultados, os valores obtidos encontram-se compreendidos entre 0 e
100 valores. Cada uma das dez perguntas contribui para o resultado final de um modo diferente,
sendo par ou ímpar, com um valor entre 0 e 4 para o resultado final. No caso das perguntas de
números ímpares, a contribuição corresponde à posição na escala menos 1 valor. Se a pergunta
for número par, a contribuição é 5 menos a posição na escala. Por último, o resultado final é
encontrado através da soma da contribuição das 10 perguntas multiplicada por 2.5.
A escala de usabilidade do sistema é considerada fidedigna e válida devido a ser um inquérito
usado na indústria da usabilidade71, além de permitir comparar usabilidade de sistemas através
dos resultados. No entanto, requer interpretação dos resultados obtidos. Estes inquéritos
devem ser efetuados em amostras de, pelo menos, doze participantes 72 – quantos mais
participantes mais precisos serão os resultados.
Devido à facilidade e fiabilidade dos inquéritos SUS, estes foram os escolhidos para serem
utilizados neste estudo. Graças a eles foi possível recolher mais informações sobre o sistema e
os seus utilizadores de um modo simples, rápido e eficiente.
71 http://www.measuringusability.com/sus.php consultado em 25-07-2014. 72 http://home.comcast.net/~tomtullis/publications/UPA2004TullisStetson.pdf consultado em 25-07-2014.
65
Além do SUS, existem outros modelos de inquéritos semelhantes, como o CSUQ (Computer
System Usability Questionnaire) a nível de estrutura, embora não sejam os mais utilizados, tendo
como objetivo medir a satisfação do utilizador em relação a um determinado sistema.
3.2.2 Vantagens e Desvantagens
Um bom questionário, depois de elaborado e validado, pode ser reproduzido quantas vezes for
necessário, se fiável, ficando o número de participantes ao critério do investigador, não
esquecendo que no caso do SUS, o número recomendado são doze participantes. Estes são uma
forma fácil e acessível de obter informação de um grande grupo de utilizadores, tendo a
particularidade de serem versáteis ao ponto de poderem ser utilizados em diversas fases do
ciclo de desenvolvimento do produto. Ao contrário das entrevistas, como podemos observar no
método seguinte, os participantes não se sentem persuadidos a dar respostas que julgam que o
investigador quer ouvir, por serem anónimos. É igualmente importante referenciar que em
determinadas situações os indivíduos inquiridos podem preencher o formulário sem refletirem
nas perguntas a fim de terminarem o mesmo rapidamente.
O facto de não haver um controlo no preenchimento leva a possíveis preenchimentos parciais.
Nesta situação, o problema não diz respeito ao número de questionários preenchidos na
totalidade, mas sim ao facto dos participantes que preenchem na totalidade poderem
representar apenas uma amostra reduzida e pouco representativa. No caso dos inquéritos
serem preenchidos remotamente, é necessário algum cuidado ao elaborar as questões, pois se
estas levantarem algumas dúvidas não existirá ninguém para esclarecer os participantes. Esta
última situação pode, inclusive, levar ao não preenchimento/entrega do questionário por
frustração.
3.3 ENTREVISTAS
Por norma são utilizados três tipos de entrevistas, sendo elas as estruturadas, as
semiestruturadas e as não estruturadas. Neste método, é elaborada uma lista de questões que
irão ser colocadas diretamente aos participantes. Nas entrevistas estruturadas, os participantes
escolhem respostas às questões colocadas dentro de um certo limite predefinido como, por
exemplo, avaliarem a utilidade de determinada funcionalidade com o auxílio da escala de Lickert
ou escolherem uma resposta dentro de um grupo de opções.
66
Nas entrevistas semiestruturadas, o entrevistador tem uma ideia clara dos assuntos que são
relevantes para a avaliação que precisa fazer. Os entrevistados encontram-se parcialmente
restritos, uma vez que o entrevistador tentará garantir que certos temas serão abordados.
Por último, nas entrevistas não estruturadas, o entrevistador coloca ao entrevistado uma série
de questões abertas permitindo, deste modo, uma maior liberdade aos entrevistados para que
estes conduzam a discussão para assuntos que considerem importantes.
3.3.1 Vantagens e Desvantagens
Uma das vantagens das entrevistas é que estas podem ser utilizadas nas diferentes fases de
desenvolvimento do produto. Tal como nos inquéritos, método abordado anteriormente, as
questões podem ser formuladas de modo a obter informações quanto aos requisitos e atitudes
dos utilizadores relativamente a protótipos e produtos finalizados. O facto de este método ser
interativo pode levar a que os dados gerados sejam mais válidos do que os obtidos através de
questionários (Jordan, 1998). Ainda em relação aos questionários existe a vantagem de,
geralmente, os entrevistados permanecerem até ao final da entrevista, originando menos
situações de perguntas sem resposta.
Os custos são uma das principais desvantagens deste método. O investigador precisa de
despender uma grande parte do seu tempo para realizar as entrevistas, uma vez que estas têm
de ser realizadas pessoalmente, ao contrário dos questionários em que a sua presença não é
indispensável. A presença do entrevistador potencia o risco de influência da informação
recolhida, tendo em conta a sua interação direta com o entrevistado.
3.4 PERSONAS
Uma persona não é uma pessoal real, é um modelo complexo baseado nos comportamentos e
motivações de pessoas reais (Cooper et al., 2007), é uma representação sumária dos utilizadores
pretendidos de um sistema, frequentemente descrita como uma pessoa real (Brown, 2011); é
uma ferramenta de IHC que melhora o processo de design visto focar-se no utilizador do sistema
(Nunes et al., 2010); é um documento que descreve de que modo certos tipos de pessoas irão
utilizar o website (Caddick & Cable, 2011); é uma pessoa imaginária que representa grupos
específicos de utilizadores dentro do público-alvo (Mathis, 2011); é um utilizador modelo que
representa um grupo maior (Walter, 2011); é uma técnica que reúne toda a informação
recolhida na pesquisa dos potenciais utilizadores do sistema em utilizadores fictícios (Santos,
67
2012); é uma personagem fictícia que é uma personificação dos utilizadores reais (Lowdermilk,
2013).
Apesar das múltiplas definições fornecidas por diversos autores desde a sua criação, é unânime
que as personas, embora não sejam pessoas reais, são baseadas e representam grupos de
utilizadores reais. Estas são criadas tendo em conta preferências, comportamentos, dados
demográficos, entre outros aspetos que as torne únicas.
A informação necessária para a criação das personas, por ordem de eficácia, é reunida através
de entrevistas com utilizadores, informação sobre os utilizadores disponibilizada pelas partes
interessadas73 e peritos da área, estudos de mercado como grupos de foco e inquéritos, modelos
de segmentação de mercado e informação reunida através de revisões de literatura e estudos
prévios (Cooper et al., 2007).
Embora não exista nenhum modelo específico para a elaboração e desenvolvimento de
personas, existe a preocupação de as tornar o mais humanas possível. Isto é, devem incluir
elementos como nome, idade e fotografias com o maior número de elementos possíveis,
fugindo às fotografias tipo passe. Quando mencionamos fotografias tipo passe não nos
referimos propriamente ao formato físico da fotografia mas sim o ambiente de fundo neutro
característico deste tipo de fotografias que não transmite nenhuma informação adicional sobre
a pessoa. Caddick e Cable (2011) defendem que as fotografias escolhidas devem refletir o
comportamento dos utilizadores, além da idade e do sexo da persona. Objetivos, competências
e necessidades são outros elementos chaves na criação da persona. A persona deve ser
atualizada, não sendo um elemento estático no tempo – por exemplo, as necessidades do
utilizador que representa vão evoluindo à medida que este interage com o sistema.
Esta metodologia foi implementada no estudo com o fim de perceber melhor quem são os
nossos utilizadores, o que esperam do sistema, as suas necessidades, capacidades e limitações.
3.4.1 Tipologia
De modo a priorizar quem é o principal público-alvo do nosso produto e em que nos devemos
focar em primeiro lugar, é necessária a atribuição de um tipo a cada persona. Existem seis tipos
de Personas sendo estas Primária, Secundária, Suplementar, Clientes, Indiretas e Negativas
(Cooper et al., 2007).
73 Stakeholders
68
Personas Primárias
As Personas Primárias representam o público-alvo principal para o design de uma determinada
interface. Apenas pode existir uma persona primária por interface para cada produto embora
seja possível, em alguns casos, existir múltiplas interfaces distintas, cada uma dedicada a uma
persona primária distinta. Nestes últimos casos, não precisam de ser necessariamente
aplicações distintas, podem apenas ser conjuntos de funcionalidades disponíveis distintos
adequados à persona em questão.
A escolha da persona primária passa por um processo de eliminação, testando os objetivos das
personas. Se nenhuma persona primária se tornar evidente, o produto necessita de várias
interfaces ou o produto está a tentar alcançar resultados em demasia.
Personas Secundárias
Este tipo de persona está satisfeita com a interface desenhada para a persona primária, embora
tenha necessidades que podem ser incluídas sem que estas alterem a capacidade de o produto
satisfazer a persona anterior. Nem sempre as personas secundárias existem e o facto de
existirem mais de três pessoas secundárias pode fazer com que o produto perca o seu foco.
Personas Complementares
Quaisquer personas, que não se enquadrem como primárias ou secundárias, são personas
complementares. As suas necessidades são atendidas através da combinação das necessidades
das personas anteriores. Não existe nenhum número excessivo para estas personas.
Personas Clientes
Estas personas são baseadas nas necessidades dos clientes e não dos utilizadores da interface.
Um cliente pode não ser o utilizador final de uma aplicação se tiver algum intermediário que
interaja por ele. Por norma, estas são tratadas como personas secundárias, a menos que
necessitem de uma interface própria, sendo então tratadas como personas primárias.
Personas Indiretas
As Personas Indiretas representam utilizadores que, apesar de não serem utilizadores diretos
do produto, são afetas pela sua utilização. Estas são tratadas como se de Personas Secundárias
se tratassem.
69
Personas Negativas
Este último tipo de personas representa os utilizadores para os quais a interface não está a ser
desenhada. Como o tipo anterior, estas personas não são utilizadoras do produto. De certo
modo, ajudam a estabelecer que limites não são desejados de ultrapassar.
3.4.2 Benefícios e Riscos
A criação de personas ajuda a manter o foco nos utilizadores e contextos de trabalho.
Igualmente, ajuda a responder a questões relacionadas com a implementação de
funcionalidades. O facto de estas se focarem num grupo em específico, ajuda a perceber o
público para o qual não estamos a desenhar o nosso produto (Pruitt & Grudin, 2003). As
personas permitem a elaboração de wireframes apropriadas e a adequação da informação
textual e dos comportamentos do sistema ao tipo de utilizador em questão.
Apesar de todas as vantagens das personas, estas não substituem os utilizadores reais (Ribeiro,
2012), pelo que as interfaces devem ser sempre testadas com utilizadores de modo a garantir
que, de facto, o utilizador consegue atingir os seus objetivos e o sistema é usável.
Através de um estudo realizado na plataforma LinkedIn, Santos (2012) pôde observar que
profissionais que interagem com personas no seu mundo profissional consideram como
principais vantagens das personas o facto de elas se focarem nos utilizadores-alvo, a semelhança
com pessoais reais, os objetivos das personas, a validação de suposições e a comunicação.
Quando pedido aos participantes que escolhessem quais consideravam ser os pontos mais
fortes do uso de Personas estes elegeram a melhoria da comunicação entre os elementos da
equipa e o facto de estas orientarem o processo no sentido das necessidades dos utilizadores
(gráfico 1). Por outro lado, quando questionados sobre as fraquezas das Personas, a resposta
mais selecionada foi a generalização excessiva dos utilizadores (gráfico 2).
70
A análise deste estudo permitiu adquirir mais alguma informação importante proveniente de
pessoas que utilizam este método no dia-a-dia.
Gráfico 1. Pontos fortes das Personas (Santos, 2012)
Gráfico 2. Pontos fracos das Personas (Santos, 2012)
71
3.5 CENÁRIOS
Carroll (2000) define um cenário como uma história com um contexto, agentes ou atores que
possuem objetivos e um guião ou uma sequência de ações e eventos. Estes descrevem situações
imaginárias com as quais os participantes se deparam, definindo uma tarefa ou desafio para
estes tendo em conta a versão do produto com que se deparam (Brown, 2011). Além disso, os
cenários descrevem as histórias e contextos que levam um utilizador ou grupo de utilizadores a
visitar o website74.
A primeira vez que os cenários foram utilizados no âmbito da IHC foi durante a década de 1980.
Nessa altura, os cenários não eram pensados em termos de design de sistemas, servindo apenas
como um método para providenciar explicações (Santos, 2012).
Atualmente, a IHC usa os cenários para descrever a utilização de sistemas e para criar sistemas
mais usáveis (Santos 2012). Para que isto aconteça, estes têm de envolver utilizadores reais e as
situações por eles representadas devem ser o mais detalhadas possíveis. Os cenários devem
começar a ser desenvolvidos uma vez encontradas as personas que refletem os utilizadores do
nosso produto. Estes são mini histórias que refletem situações nas quais as personas se podem
encontrar (Lowdermilk, 2013).
Os cenários são comummente utilizados no estudo de utilizadores, assim como as personas.
Estes ajudam a compreender de que modo a persona pode interagir com o produto ou sistema
em questão (Santos 2012). Santos (2012) afirma ainda que estes podem ser definidos como uma
história, com diferentes elementos, que se desenvolve com o decorrer do tempo, realçando
também a sua utilidade em sessões de brainstorming.
Na elaboração de cenários existem três ou quatro aspetos a considerar: quem é o utilizador, o
que o motiva a visitar o website, quais os seus objetivos e como este pode atingir os seus
objetivos no website75. Nos cenários, devemos ter em conta como a aplicação irá melhorar a
experiência do utilizador (Lowdermilk, 2013).
74 http://www.usability.gov/how-to-and-tools/methods/scenarios.html consultado em 2014-07-26 75 http://www.usability.gov/how-to-and-tools/methods/scenarios.html consultado em 2014-07-26
72
Para Brown (2010) todos os cenários estão divididos em pelo menos cinco partes distintas:
1. Contexto. Ponto de partida de um cenário, identificando a localização do utilizador ou
a situação que o levou ao cenário em particular;
2. Acionador76: O evento que causou o cenário;
3. Ação. O que o utilizador fez para superar o cenário;
4. Inputs: Que informação o utilizador necessita para solucionar o problema apresentado
pelo cenário;
5. Expectativas. Como a situação se deve alterar para cumprir as necessidades do
utilizador.
No que diz respeito ao número de cenários ideal, Brown (2010) refere que um bom design
consegue antecipar todos os cenários possíveis. Para o autor, esta é uma tarefa multidisciplinar
pois designers de experiência de utilizador conseguem imaginar todos os cenários menos
comuns e estranhos que possam surgir durante a interação mas apenas as pessoas responsáveis
pela tecnologia e as operações conseguem antecipar outros cenários como erros de bases de
dados.
Cenários Baseados em Personas
Os cenários baseados em personas são descrições narrativas concisas que narram o modo como
os utilizadores interagem com o produto para cumprirem determinados objetivos (Cooper et al.,
2007). Estes partem da perspetiva da persona, focando-se em pessoas reais, como estas pensam
e se comportam, deixando para segundo plano a tecnologia e os objetivos económicos.
Os objetivos presentes nestes cenários servem como tarefas e como orientação para estruturar
a apresentação da informação (Cooper et al., 2007).
3.5.1 Tipologia
Não existe nenhum número certo de tipos de cenários. No entanto, Cooper et al. (2007) definem
três tipos de cenários baseados nas personas: cenários de contexto, percurso-chave e validação.
Brown (2010) menciona ainda um cenário extra denominado cenário de erro.
76 Trigger
73
Cenários de Contexto
Os cenários de contexto são utilizados para explorar de que modo o produto pode satisfazer o
melhor possível as necessidades das personas. Estes são escritos do ponto de vista da persona,
focando em atividades humanas, perceções e desejos (Cooper et al., 2007).
Os cenários de contexto devem responder a questões como: em que circunstâncias o produto
irá ser utilizado, durante quanto tempo, continuidade de utilização por parte da persona,
quantidade de utilizadores por dispositivo, que ações principais a persona necessita de realizar
para atingir os seus objetivos, qual o resultado final pretendido, qual a complexidade permitida
baseada nas capacidades e frequência de utilização da persona (Cooper et al., 2007).
Cenários de Percurso-chave
Quando os elementos funcionais do produto e a infraestrutura de design estiverem definidos,
os cenários de contexto podem evoluir eventualmente para cenários de percursos-chave
(Cooper et al., 2007). Estes descrevem as interações dos utilizadores com o produto ao
pormenor focando-se nas interações mais significativas das personas dentro da aplicação
focando como a persona procede a fim de atingir os seus objetivos.
Este segundo tipo de cenário deve descrever a interação com o produto o mais detalhadamente
possível, incluindo termos próprios de design e é refinado à medida que o próprio design evolui
(Cooper et al., 2007).
Cenários de Validação
O último tipo de cenários é criado como meio de teste de soluções de design. Estes cenários
tendem a ser pouco detalhados e, tipicamente, assumem a forma de questões começadas por
“E se…?” acerca das soluções propostas (Cooper et al., 2007). Nesta categoria podem ainda ser
incluídos os percursos alternativos, as utilizações necessárias e as situações-limite.
Cenários de Erro
Este tipo de cenários descrevem o que acontece quando os utilizadores fazem algo que os
impede de completar a tarefa em mente (Brown, 2011), por exemplo, uma situação onde os
utilizadores não introduzam a sua palavra-chave numa tarefa que necessite de autenticação, a
não introdução de uma morada para finalizar uma encomenda, etc.
74
3.6 PROTOTIPAGEM
Para Cable & Caddick (2011) todos os projetos em desenvolvimento, a certo ponto, devem
passar por uma fase de testes com recurso a protótipos. Os protótipos podem incluir diversos
tipos de informação desde listas de funcionalidades, especificações técnicas, ou aspetos mais
visuais como o tamanho, as cores, etc. (Jordan, 1998), podendo ser uma ferramenta importante
e com bastante utilidade no DCU, sendo relevante a documentação de ecrãs de todas as suas
etapas de desenvolvimento (Lowdermilk, 2013). Deste modo, é possível observar a evolução do
produto.
3.6.1 Tipos de Protótipos
Existem diversas técnicas de prototipagem com diferentes níveis de fidelidade e sofisticação.
Por questões financeiras ou de tempo, é necessário escolher quais os tipos de protótipos que
mais de adequam à situação. No que diz respeito à qualidade dos protótipos, Lowdermilk (2013)
defende que devem ser considerados dois aspetos: a fase de desenvolvimento atual do produto
e a perceção que o utilizador vai ter dessa fase.
Nielsen (1993) afirma que os protótipos são utilizados para poupar tempo e dinheiro e criar algo
que pode ser testado com utilizadores reais e, nesse sentido, é necessário cortar em algo como
número de funcionalidades existentes no protótipo ou reduzir a funcionalidade de
determinadas funções ao ponto de parecer que fazem algo mas de facto não o estão a fazer
como, por exemplo, modificações em bases de dados. Estes dois aspetos são o que Nielsen
chama de prototipagem vertical e horizontal e, quando ambos são combinados, estamos na
presença de cenários.
Idealmente, devem ser desenhadas múltiplas versões de protótipos e testar o maior número
possível (Saffer, 2008). Deste modo conseguimos perceber o que funciona melhor e obter
diversos tipos de feedback que, quando combinados, podem acrescentar valor ao produto.
Jordan (1998) distingue três categorias de protótipos sendo estas os protótipos visuais, os
modelos iterativos e os protótipos totalmente funcionais.
75
Protótipos Visuais
Estes protótipos são, basicamente, representações visuais do produto. Podem ser desenhados
à mão ou serem representações de alta-fidelidade recorrendo a software adequado, podendo
incluir descrições verbais ou escritas das funcionalidades ou procedimentos para manusear o
produto. Estes protótipos podem ser utilizados para transmitir aos utilizadores funcionalidades
e decisões de design e obter feedback em relação às mesmas. Os utilizadores não podem
interagir com o protótipo como fariam com o produto final, podendo às vezes levar a feedback
menos válido em alguns aspetos do design (Jordan, 1998).
Se estes protótipos foram elaborados à mão em papel estes devem ser, sempre que possível,
desenhados com a escala correta pois, de outro modo, é fácil elaborar uma interface pouco
prática. Estes devem restringir-se ao teste de conceitos gerais, fluxo de ecrãs e gestos, no que
toca a Interfaces Gestuais (Saffer, 2008).
Mathis (2011) menciona alguns aspetos a ter em conta na criação e teste de protótipos desta
categoria como preparar todos os ecrãs que as pessoas podem eventualmente aceder para que
estes não fiquem muito restritos, acrescentar elementos extra da interface (por exemplo, janela
do browser se o produto for um website), desenhar todos os elementos pop-up necessários
como os menus drop-down (podendo recorrer a notas Post-it para os representar em testes),
permitir às pessoas desenhar algo no protótipo sempre que possível, fornecer as tarefas a testar
impressas em papéis distintos e, por último, testar o protótipo de todas as maneiras possíveis
antes de testar com um utilizador de modo a ver se os passos anteriores estão cumpridos.
Um dos fatores chave destes protótipos está relacionado com a facilidade de resolução dos
problemas encontrados pois, uma vez detetado e solucionado um problema nesta fase, é menos
um problema que mais tarde necessitaria de ser totalmente modificado em código (Mathis,
2011).
Modelos Interativos
Estes protótipos são representações visuais interativas em ecrã e permitem simular interações
com os protótipos como, por exemplo, clicar em botões ou hiperligações no protótipo com o
rato, podendo assim ver como iria o produto responder à interação realizada. Os modelos são
mais utilizados quando existem ideias firmes acerca do produto e como a interação poderá ser
efetuada ainda que existam algumas incertezas justificando a realização de testes à interface
recorrendo a estes (Jordan, 1998). É neste tipo que se incluem, por exemplo, os protótipos
recorrendo ao Powerpoint ou outro software similar.
76
Brown (2011) defende que protótipos deste género, tais como os protótipos visuais, embora
menos apelativos visualmente, podem ser os que descrevem melhor o design pretendido.
Igualmente, como nos protótipos visuais, poupam tempo e recursos pois problemas detetados
aqui são menos problemas a resolver posteriormente em questões de programação (Mathis,
2011).
Protótipos Completamente Funcionais
Por último, estes são os protótipos que, para os utilizadores, são praticamente semelhantes ao
produto final embora, no contexto de software, estes sejam equivalentes a modelos interativos
pois respondem à interação como o produto final responderia (Jordan, 1998).
3.6.2 Benefícios e Riscos Gerais
A vantagem mais evidente do uso de protótipos diz respeito a estes permitirem ver se o produto
pensado irá de facto corresponder as expectativas. É possível ver que falhas este ainda tem, que
melhorias podem ser implementadas que nunca antes tinham sido pensadas e os utilizadores
que os testaram sugeriram, que funções já integradas podem ser modificadas para acrescentar
valor, entre outros. Wroblewski (2011) afirma ainda que num contexto móvel, quanto mais cedo
os protótipos estiveram a ser testados, mais rapidamente conseguimos perceber se a interface
foi bem pensada e se de facto funciona.
Por outro lado, a criação de protótipos evita o desperdício de tempo e energias a construir algo
posteriormente que não iria funcionar (Lowdermilk, 2013), sendo deste modo apenas uma
representação visual do produto sem ter de investir demasiado na programação do mesmo
numa primeira fase.
O maior risco no desenvolvimento de protótipos é desenvolvê-lo no sentido errado, ou seja,
pensar no protótipo ao mesmo tempo que pensamos como o vamos codificar posteriormente
(Lowdermilk, 2013). Quando esta situação acontece, o nosso foco deixa de ser o utilizador do
produto, trazendo poucos ou nenhuns benefícios.
Outro risco na utilização dos protótipos está associado com a fidelidade dos mesmos. Como
referido anteriormente, a qualidade dos protótipos gerará diferentes implicações no feedback
proporcionado pelos utilizadores. Por exemplo, se colocarmos diante do utilizador um protótipo
bastante completo, o utilizador pode não fornecer tanto feedback pois fica com a sensação que
o produto está quase terminado, remetendo o feedback para pequenos detalhes. Se o protótipo
for de baixa-fidelidade, é mais provável que o utilizador questione variados aspetos desde
77
funcionalidades a conceitos fundamentais do produto prototipado (Lowdermilk, 2013). Por
outro lado, em software, o autor defende que faz sentido ter algo funcional, pois protótipos não
funcionais podem não permitir o teste das funcionalidades pretendidas. Shneiderman (2005)
afirma que embora os protótipos de baixa-fidelidade sejam úteis, a utilização de protótipos
online de alta-fidelidade cria um ambiente mais realista para peritos e para os próprios testes
de usabilidade.
Saffer (2008) defende que para interfaces gestuais, quanto mais refinado o protótipo for, mais
refinado será o feedback apresentado pelos utilizadores. Isto pode não ser necessariamente
uma vantagem pois os utilizadores podem focar-se mais nos aspetos visuais do produto como
cores ou os tipos de letra em vez do conceito, gestos e funcionalidades que queremos testar.
Lowdermilk (2013) menciona ainda que um dos melhores métodos para tirar partido dos
protótipos é apresentar aos utilizadores algo totalmente inesperado e, se não gostarem,
questionar porquê. Deste modo obtemos de um modo mais aproximado da realidade o que os
utilizadores realmente querem pois, quando questionados diretamente, muitas vezes nem os
próprios utilizadores têm consciência do que realmente pretendem.
3.6.3 Ferramentas de Prototipagem
Atualmente existem no mercado algumas ferramentas conhecidas que permitem a criação e
teste de protótipos como a Proto.io, a Fluid UI ou a Moqups. Para a elaboração deste estudo, foi
realizada uma análise comparativa de algumas das ferramentas disponíveis no mercado, com
vista a escolher a que mais se adequava dentro de estudo (ver Apêndice 1 - Análise Comparativa
de Ferramentas de Prototipagem).
Inicialmente a escolha recaiu sobre a ferramenta FUSAMI. Apesar de a ferramenta ainda se
encontrar em fase de testes, julgamos que seria de extremo proveito a sua utilização porque
além de pertencer ao centro de interface da UP (Fraunhofer Portugal), e sendo o SIGARRA
pertencente à UP, seria possível contribuir para testar a mesma através deste estudo. Devido a
problemas técnicos encontrados durante a prototipagem e ao limite de tempo, foi necessário
escolher outra ferramenta para realizar os protótipos. A ferramenta escolhida foi a Fluid UI pois
não necessitava de conhecimentos de programação, era simples e rápida e permitia o teste do
protótipo no dispositivo Android com uma simples leitura do código QR77.
77 Quick Response Code, ou código de resposta rápida, é um código de barras bidimensional que utiliza quatro modos de codificação distintos (alfabético, byte/binário, kanji e numérico) que serve para
78
Apesar de a FUSAMI não ter sido utilizada como pretendido inicialmente, toda a experiência
com a ferramenta será descrita futuramente no subcapítulo 4.2.1 Protótipos Passo-a-Passo.
3.7 TESTES DE USABILIDADE
The best results come from testing no more than 5 users and running as many small
tests as you can afford.
- Jakob Nielsen, Why You Only Need to Test with 5 Users, 2000
Testes de usabilidade são uma coleção de técnicas utilizadas para medir características da
interação de um utilizador com um produto com o objetivo de melhorar a usabilidade do
mesmo. Normalmente estes testes focam-se em medir se os utilizadores conseguem completar
tarefas específicas com sucessão assim como problemas encontrados no decorrer do processo.
Os resultados frequentemente revelam aspetos que os utilizadores têm dificuldade em
compreender e interagir com determinadas interfaces (Cooper et al., 2007).
Brown é um dos muitos autores que apoiam a elaboração dos testes de usabilidade desde cedo.
Além disso, o autor (2010) refere que a melhor maneira de explicar o que são os testes de
usabilidade a alguém que não tenha conhecimento ou a partes interessadas é referir de um
modo simples que:
(…) é meio de adquirir feedback sobre o design do sistema em contexto de tarefas
reais do dia-a-dia. Ao pedirmos aos utilizadores para utilizares o sistema podemos
observar oportunidades para melhorar o design, encontrando essas falhas nesta
altura em vez de uma fase avançada, onde as alterações nos iriam sair mais caras.
Krug (2010) resume a definição de testes de usabilidade a uma também simples explicação,
sendo que estes consistem em observar as pessoas a tentarem utilizar o que criámos,
desenhámos ou construímos, ou estamos de momento numa fase de desenvolvimento, com a
intenção de facilitar a interação das pessoas com o produto e provar que este é fácil de utilizar.
Os testes de usabilidade podem ser utilizados em qualquer fase de desenvolvimento do produto,
seja este uma nova ideia ou um produto já existente. Inicialmente, os testes de usabilidade eram
realizados apenas em laboratórios de usabilidade, com salas de observação, que continham
duas câmaras de filmar de modo a obter informação sobre o que os utilizadores estavam a fazer
armazenar dados. Surgido no Japão em 1994, hoje é frequentemente utilizado em catálogos, por exemplo, com hiperligações para conteúdos extra na Internet.
79
e as suas reações. Além disso, eram realizados com um número de utilizadores elevado de modo
a gerar dados estatisticamente relevantes (Krug, 2006). Por estes motivos, os testes eram
bastante dispendiosos sendo, portanto, realizados com pouca frequência.
Esta opinião sobre as condições de realização destes testes sofreu como que uma revolução
quando, em 1989, Nielsen afirmou que não era necessário um laboratório nem um número tão
elevado de utilizadores. Apesar disto, muitos anos depois, a opinião das pessoas ainda refletia
uma necessidade de realizar os testes junto de especialistas que conduzissem testes de custos
compreendidos em milhares de dólares. Como ainda assim eram dispendiosos, apesar de se
realizarem com mais frequência, ainda não eram feitos testes suficientes.
Krug (2006) enumera sete observações relevantes onde demonstra perfeitamente qual a
necessidade de fazer testes de usabilidade em websites, podendo estes mesmos pontos
aplicarem-se igualmente aos websites em dispositivos móveis:
1. Se desejamos um bom website, temos de o testar78. Após trabalhar durante semanas
num website, passamos a conhecê-lo demasiado, sendo o nosso juízo sobre o mesmo
comprometido. A única maneira de o testar eficazmente é através de testes de
usabilidade.
2. Testar um utilizador é 100% melhor do que não testar nenhum79. Todos os testes
mostram fraquezas que podem ser melhoradas, mesmo se o testado não for o utilizador
mais ideal.
3. Testar um utilizador no início do projeto é melhor que testar cinquenta perto do fim
do mesmo80. Um simples teste no início compensa o que for aprendido poder ser
refletido no tempo que ainda resta para a conclusão do projeto. Visto os utilizadores,
habitualmente, resistirem às mudanças, é preferível disponibilizar o website com
algumas alterações realizadas devido a esses testes que alterar o mesmo depois de já
se encontrar disponibilizado aos seus utilizadores.
4. É atribuída demasiada importância à necessidade de encontrar utilizadores
representativos 81 . É bom realizar testes com pessoas semelhantes aos nossos
utilizadores finais mas é muito mais importante realizar os testes o mais cedo possível e
regularmente.
78 Tradução do autor de “If you want a great site, you’ve got to test” 79 Tradução do autor de “Testing one user is 100 percent better than testing none” 80 Tradução do autor de “Testing one user early in the project is better than testing 50 near the end” 81 Tradução do autor de “The importance of recruiting representative users is overrated”
80
5. O objetivo de testar não é aprovar ou desaprovar algo mas sim ajudar na tomada de
decisões82. Não devemos usar os testes para verificar se uma opção é melhor que a
outra. Estes devem ser realizados com o objetivo de recolher informações valiosas que
quando conjugadas com a experiência e senso comum permitem uma melhor decisão
sobre qual das opções a tomar.
6. Testar é um processo iterativo83. Os testes não devem ser realizados apenas uma vez.
Após um produto ou website ser criado, estes devem ser testados, corrigidos e
novamente testados constantemente.
7. Por último, nada bate a reação dos utilizadores84. Ou seja, ver o modo como as pessoas
reagem ao interagirem com os produtos ou websites no momento do teste pode
fornecer-nos informações valiosas sobre o seu estado de satisfação relativamente ao
sistema.
Por outro lado, Cooper et al. (2007) defendem que o objetivo destes testes é validar o design do
produto e por este motivo a melhor altura para realizar estes testes é numa fase mais avançada
do desenvolvimento do projeto. Os autores defendem que o feedback obtido nestes é mais
importante quando é necessário validar ou melhorar um mecanismo de interação em particular
ou quando é relativo a elementos de design específicos, sendo os testes especialmente efetivos
a apurar informações como nomes de botões ou rótulos, organização da informação, facilidade
em descobrir informação pretendida por utilizadores que interagem com o produto pela
primeira vez, existência de necessidade de instruções para encontrar informação pretendida e
eficiência na elaboração das tarefas. Mathis (2011) é da mesma opinião de Krug no sentido em
que prioriza a realização de testes numa fase inicial do projeto e de um modo iterativo.
Shneiderman (2005) afirma que é importante que as mensagens transmitidas pelos sistemas
sejam testadas junto dos utilizadores para que seja possível apurar se estas são devidamente
compreensíveis. Além disso, chama a atenção para o facto de um sistema complexo, utilizado
por milhares de utilizadores como é o caso do SIGARRA, nunca se encontrar completo até ficar
de todo obsoleto. Nestas situações os esquemas de design mais efetivos resultam de testes
iterativos e melhoramento constante.
82 Tradução do autor de “The point of testing is not to prove or disprove something. It’s to inform your judgment” 83 Tradução do autor de “Testing is an iterative process” 84 Tradução do autor de “Nothing beats a live audience reaction”
81
3.7.1 Condições para a Realização dos Testes
Ainda Krug (2006) menciona como é possível realizar testes de usabilidade quando o orçamento
disponível e o tempo são escassos. Se pretendermos realizar muitos testes, o recomendável
seria contratar um especialista. Por outro lado, se o número de testes a realizar não for muito
elevado não o devemos fazer.
3.7.1.1 Número de Utilizadores Ideal
Tradicionalmente, os testes necessitavam de oito ou mais utilizadores para justificarem os
custos da realização dos testes. Krug (2006) e Walter (2011) recomendam entre três a quatro
utilizadores diferentes (tabela 6). Já Nielsen (2000) afirma que cinco utilizadores diferentes são
suficientes para descobrir mais de 75% de erros de usabilidade mas, no entanto, para descobrir
a totalidade, são necessários cerca de quinze (gráfico 3). Mathis (2011) também é da opinião
que três a cinco utilizadores é o suficiente.
3.7.1.2 Equipamento
Enquanto os testes tradicionais são realizados por empresas ou especialistas em laboratórios
equipados com câmaras de filmar e vidros espelhados, Krug (2006) sugere que se fique pela
utilização de meios para filmar os testes e ferramentas de captura de ecrã, como meios menos
dispendiosos (tabela 6). Como alternativa a câmaras de vídeo, podemos gravar áudio.
Gráfico 3. Relação entre o número de utilizadores testados e a totalidade de erros de usabilidade descobertos (Nielsen, 2000)
82
Do ponto de vista do testador, é relevante estar acompanhado de um bloco de notas e uma
caneta (Lowdermilk,2013). Aspetos como tempo de execução de tarefas, caminhos percorridos,
obstáculos encontrados, entre outros, devem ser anotados para serem analisados em conjunto
com imagens capturadas e capturas de ecrã.
3.7.2 Vantagens e Desvantagens
Os testes de usabilidade com diferentes utilizadores permitem acesso a informação importante
para a avaliação da usabilidade. Além disso, estes permitem a identificação de um número
significativo de erros mesmo com poucos utilizadores (Nielsen, 2000). O facto de os testes
poderem ser realizados por alguém que não seja um especialista de usabilidade permite uma
maior flexibilidade às equipas de trabalho uma vez que qualquer membro das mesmas pode
levar a cabo essa tarefa.
Testes Tradicionais Testes segundo Krug
Número de
Utilizadores
Oito ou mais para justificar os
custos
Três ou quatro
Recrutamento. Aproximar ao público-alvo Quase todas as pessoas que
utilizam a Internet
Local de Teste Laboratórios de usabilidade Escritório ou sala de conferências
Testador Profissional de usabilidade
experiente
Pessoa razoavelmente paciente.
Planeamento
antecipado.
Esboço, discussão e revisão do
protocolo de testes.
Decidir aquilo que pretendemos
mostrar.
Quando realizar o
teste?
Uma vez apenas, quando o website
estiver quase pronto, a menos que
exista um orçamento elevado
Diversos testes pequenos
durante todo o processo de
desenvolvimento
Custo Elevado Reduzido
Após a Realização
do(s) Teste(s)
Relatório de 20 páginas passado
uma semana, seguido de uma
reunião da equipa para decidir
alterações a fazer
Equipa de desenvolvimento e as
partes interessadas reúnem-se no
próprio dia para discutir
resultados.
Tabela 6. Resumo e comparação entre testes tradicionais e método alternativo proposto por Krug (2006)
83
Como principal desvantagem, Ribeiro (2012) alerta que existe o perigo de os utilizadores
fornecerem informação incorreta devido a fatores condicionantes como a falta de motivação ou
nervosismo devido a se encontrarem em ambientes artificiais de utilização.
3.7.3 Ferramentas de Análise de Dados
As ferramentas de análise de dados podem ser igualmente utilizadas para sistemas novos ou já
existentes. Este tipo de ferramentas é particularmente útil para recolher informações
provenientes dos testes de usabilidade. Se ao observarmos um utilizador durante o teste
conseguimos perceber, por exemplo, o que pode estar a sentir através das suas expressões
faciais, estas aplicações podem fornecer outro tipo de informações relevantes, como percursos
de navegação utilizados, opções mais utilizadas, scroll efetuado, gestos elaborados, localização
de acessos, etc. A combinação destes dados pode contribuir positivamente para uma melhoria
do sistema a ser testado.
Atualmente existem no mercado algumas ferramentas conhecidas para a recolha de dados
durante testes de usabilidade como a Google Analytics, a Heatmaps, a Appsee ou a Crazyegg.
Para a elaboração deste estudo, foi realizada uma análise comparativa de algumas das
ferramentas disponíveis no mercado, com vista a escolher a que mais se adequava dentro de
estudo (ver Apêndice 2 - Análise Comparativa de Ferramentas de Análise de Dados). Durante a
pesquisa de ferramentas, foi possível ver um número considerável das mesmas desenvolvidas
apenas para iOS, enquanto para Android eram escassas. Inicialmente a escolha recairia sobre a
ferramenta FUSAMI mas, devido aos problemas brevemente referidos no subcapítulo 3.6.3.
Ferramentas de Prototipagem, infelizmente, não foi possível utilizar nenhuma destas
ferramentas.
No entanto, vale a pena mencionar que a FUSAMI providencia várias funcionalidades
relativamente à recolha de dados, como os heat maps, transições, informações relativas a
gestos, entre outras (figura 31). Seria uma grande mais-valia para o estudo ter sido possível
disfrutar das mesmas.
84
3.8 CONVERSA FILMADA
Neste método, o participante é colocado numa sala, apenas com um câmara de vídeo, sendo
estimulado a falar sobre um tópico pré-definido pelo investigador como, por exemplo, de que
modo utilizam um produto ou se o sistema em questão é simples de utilizar. Uma variante deste
método consiste em colocar dois participantes na mesma sala ao mesmo tempo para tentar
perceber como estes abordam aspetos referidos pelo outro participante presente na sala.
3.8.1 Vantagens e Desvantagens
A vantagem mais evidente diz respeito ao investigador não estar presente enquanto o
participante fala para a câmara. Deste modo, o risco de influência é reduzido pois o facto de o
participante se encontrar sozinho na sala, provavelmente leva ao mesmo prenunciar-se sem se
sentir constrangido. Outra vantagem é a presença de uma atmosfera informal, deixando os
Figura 31. Conjunto de funcionalidades disponibilizadas pela FUSAMI
85
participantes mais relaxados (Jordan, 1998). Na altura de desenvolver relatórios relativos à
investigação, os vídeos servem ainda de prova do trabalho realizado.
Se o facto de o investigador não estar presente pode ser uma vantagem, pode também se tornar
num inconveniente pois, deste modo, não consegue delinear o rumo da sessão. A falta de
estrutura pode ainda dificultar a análise posterior das sessões gravadas.
3.9 CODESCOBERTA
A codescoberta envolve dois participantes, por norma amigos ou conhecidos, a trabalharem em
equipa com o fim de explorar um produto e como certas tarefas são realizadas com o mesmo,
observados por um investigador. O investigador, através da observação do diálogo dos
participantes, deve identificar problemas de usabilidade associados ao produto e o seu papel
pode ser de simples observação ou mais ativo, colocando perguntas aos dois elementos. O facto
de os participantes se conhecerem é proveitoso uma vez que estarão menos inibidos em falar
um com o outro sobre o que estão a fazer a sua opinião sobre o produto.
3.9.1 Vantagens e Desvantagens
O diálogo existente neste processo é uma vantagem pois ajuda a detetar situações que, de outro
modo, podiam não ser detetados. Este método pode ser filmado para ser analisado e relatado
posteriormente.
Além de ser uma vantagem, o diálogo existente pode ser também uma desvantagem, pois os
participantes podem distrair-se facilmente da tarefa que estavam a fazer. Tendo em conta este
aspeto, problemas encontrados relativos ao desempenho das tarefas são pouco fiáveis mas,
informações básicas, como se uma tarefa foi ou não completada com sucesso, são fáceis de
perceber e fiáveis. Outra desvantagem deste método diz respeito à direção da sessão, pois o
investigador não a poderá controlar. O investigador podia pedir aos participantes que todos os
assuntos descritos na lista de tarefas fossem abordados, mas iria retirar parte da
espontaneidade da sessão, perdendo assim um dos pontos mais fortes deste método (Jordan,
1998).
86
3.10 GRUPOS DE FOCO
Os grupos de foco ou grupos de discussão85 consistem num grupo de pessoas reunidas para
discutir um determinado assunto como, por exemplo, a partilha de experiências dos utilizadores
em relação a um produto ou problemas de usabilidade associados com o uso do produto. Por
norma, existe um líder da discussão e um certo número de participantes. O líder terá uma
agenda dos temas que devem ser abordados, estabelecendo assim os limites entre os quais a
discussão pode ocorrer, sem que haja uma ordem estrita pela qual os assuntos tenham de ser
abordados. Outros papéis do líder passam por certificar-se que todos os participantes têm
possibilidade de intervir e fornecer frases pré-elaboradas para reestabelecer a conversa caso
esta comece a ficar demasiado pausada, sem nunca forçar uma determinada resposta dos
participantes.
3.10.1 Vantagens e Desvantagens
Este método pode ser utilizado em qualquer fase do ciclo de desenvolvimento do produto
(Jordan, 1998), ao contrário de outros que estão restritos a uma ou duas fases apenas. Outra
vantagem, associada às dinâmicas de grupo em geral, refere-se ao facto de uma questão
levantada por um participante poder estimular os restantes a apresentarem novas ideias
derivadas da questão inicial.
Quanto a desvantagens, existe o risco de alguns participantes serem mais dominantes que os
outros. Esta situação pode induzir em erro - opiniões obtidas que deviam refletir a opinião do
grupo são afinal opiniões individuais. Podem ainda existir elementos silenciosos ao longo da
sessão, que não se pronunciam. O líder pode tentar influenciar este aspeto questionando os
participantes menos ativos sobre um determinado assunto ou, reconhecendo a participação dos
elementos mais dominantes e dirigindo em seguida outras questões para os restantes
elementos.
85 Focus groups
87
3.11 WORKSHOPS DE UTILIZADORES
Os workshops de utilizadores consistem num grupo de participantes reunidos para discutirem
problemas de design e utilização de um produto. Por norma, os utilizadores estarão envolvidos
no “design de um novo produto”, ou seja, tarefas como listar os requisitos de usabilidade e de
funcionalidades dos utilizadores ou envolvimento com designers a fim de discutir ideias e
rascunhos de possíveis estruturas de design. Quando comparado com os grupos de foco, este
método distingue-se pois envolve os seus participantes em tarefas mais práticas.
3.11.1 Vantagens e Desvantagens
Uma vantagem deste método é o envolvimento que providencia aos seus utilizadores desde
cedo no ciclo de desenvolvimento de produtos. Além de simplesmente questionar os
utilizadores sobre os requisitos, estes estão também responsáveis por transformar os mesmos
em “soluções de design”, ou seja, ajudar a adaptar o design às suas necessidades. Por outro
lado, estes workshops podem ser bastante exigentes para os participantes, a nível de tempo e
quantidade de trabalho. Esta situação é uma das desvantagens pois dificulta a obtenção de
participantes. A interação entre utilizadores e designers pode ser uma desvantagem porque
alguns utilizadores podem sentir-se menos à vontade para mencionarem determinados
requisitos com os designers presentes (Jordan, 1998).
3.12 PENSAMENTO EM VOZ ALTA
Este método requer que o participante fale em voz alta sobre o que está a pensar e a fazer
quando interagem com uma interface. A nível de liberdade do participante, este pode ter uma
lista de determinadas tarefas a realizar ou ter total liberdade para explorar a interface como
desejar. Por norma, o investigador incentiva o participante a falar, colocando questões como “O
que está a pensar agora?” ou “Porque pressionou esse botão?” (Jordan, 1998). As informações
transmitidas pelos participantes ajudam ainda a perceber qual a sua satisfação ao interagir com
o produto/interface.
88
3.12.1 Vantagens e Desvantagens
As verbalizações permitem a compreensão dos problemas da interface e como estes surgem,
podendo estes resultar em futuras “soluções de design”. Outra vantagem deste método prende-
se no facto de este ser um veículo eficiente para a obtenção muita informação a partir de um
número reduzido de participantes (Jordan, 1998).
Uma potencial desvantagem deste método está relacionada com a possível dificuldade em
realizar as duas tarefas ao mesmo tempo: explorar a interface convenientemente e expressar o
que estão a fazer ou pensar. Uma outra desvantagem diz respeito à intervenção do investigador
que, se tentar obter uma maior participação forçadamente, pode influenciar o participante a
expressar algo sob pressão apenas para dar uma resposta (Jordan, 1998).
3.13 LISTAS DE VERIFICAÇÃO DE FUNCIONALIDADES
Neste método, existe uma lista de verificação das funcionalidades de um produto onde os
utilizadores têm apenas que marcar quais as funcionalidades que utilizaram. Este método é
importante para descobrir os requisitos do produto, durante a sua fase de desenvolvimento,
para saber quais as funcionalidades que são ou não usadas. Além disso é possível comprovar se
os utilizadores se aperceberam que existe determinada funcionalidade ou ainda se os
utilizadores saberiam como utilizar uma funcionalidade caso quisessem de facto utilizá-la. Estas
listas fornecem informações quanto à forma como o produto é utilizado e podem, ainda, ser
trabalhadas de modo a obter outras informações no que diz respeito à usabilidade das diversas
funcionalidades.
3.13.1 Vantagens e Desvantagens
A nível de vantagens, é um método que requer pouco tempo disponibilizado ou equipamento.
Além disso, as listas são um método eficaz para perceber como um produto é utilizado, no geral
(Jordan, 1998). Por outro lado, o método não permite obter informação suficiente que possa ser
ligada diretamente a soluções de usabilidade - os utilizadores podem ser questionados de modo
a descobrir-se mais do que se utilizam ou não uma funcionalidade mas o investigador continua
a necessitar de interpretar a informação para tentar obter algo sobre a facilidade do uso da
mesma.
89
3.14 PESQUISA DE CAMPO
A pesquisa de campo permite ao investigador observar os utilizadores nos ambientes onde
normalmente utilizariam o produto, complementando assim avaliações em ambientes
laboratoriais (Jordan, 1998). O investigador permitirá que os utilizadores tenham liberdade para
fazerem o que pretendem ou, noutros casos, pode pedir aos utilizadores que indiquem o que
fariam em determinada situação. Neste método, pretende-se descobrir como seria o
desempenho do produto em situações naturais, sem barreiras ou controlo imposto.
3.14.1 Vantagens e Desvantagens
A principal vantagem deste método é o facto de este permitir analisar a usabilidade de um
produto em circunstâncias de uso normais, com exceções pouco relevantes para este caso como
a presença do investigador e a filmagem da situação. As complicações que possam surgir na
análise dos dados e possíveis dificuldades éticas são as principais desvantagens. Quando
comparada com outros métodos, a pesquisa de campo tem menos flexibilidade uma vez que
normalmente só pode ser realizada em produtos já finalizados, enquanto métodos como as
entrevistas podem ser realizados ao longo de diversas fases do ciclo de desenvolvimento do
produto.
90
4 TRABALHO DE CAMPO
O trabalho de campo deste estudo, tratando-se de um estudo de usabilidade, teve duas fases
distintas. Na primeira fase, foram elaboradas diversas entrevistas, preenchimento de inquéritos
SUS e testes de usabilidade recorrendo ao sistema no seu estado atual. Na fase final, utilizando
os mesmos critérios dos testes anteriormente realizados, recorreu-se a protótipos para efetuar
novos testes de usabilidade. Para além disso, foram preenchidos novamente inquéritos SUS
como meio de medir a satisfação dos utilizadores.
4.1 FASE INICIAL
4.1.1 Entrevistas
Para obter alguma informação base e histórica sobre o sistema de informação da UP foi
concedida uma entrevista pela Dra. Lígia Ribeiro, à altura Pró-reitora e responsável pela
Universidade Digital. Através desta entrevista, foi igualmente possível compreender as
expectativas iniciais e futuras em relação ao sistema e perceber melhor como as decisões em
volta do SIGARRA são tomadas.
Para a realização das entrevistas a estudantes, foi utilizada uma amostra de cinquenta e três
pessoas provenientes de diferentes unidades orgânicas da UP. Após uma análise das
informações recebidas nas entrevistas, conseguimos reunir informações relativamente aos
principais obstáculos de usabilidade na opinião dos utilizadores, a sua satisfação em geral, as
tarefas mais recorrentes e sugestões.
Todas as entrevistas realizadas foram semiestruturadas, permitindo assim espaço para os
entrevistados falarem sobre o que considerassem ser mais pertinente. Estas permitiram uma
perceção da opinião dos utilizadores em relação ao sistema, assim como o conhecimento de
obstáculos que necessitavam de ser trabalhados.
As perguntas elaboradas pré-entrevista, assim como o resumo das respostas fornecidas nas
entrevistas com os estudantes estão disponíveis para consulta no Apêndice 3 – Entrevistas.
91
4.1.2 Testes de Usabilidade e Inquéritos SUS
Tendo em conta as principais tarefas apuradas durante a fase de entrevistas, escolhemos três
dessas para a realização dos testes de usabilidade do sistema. As tarefas escolhidas foram
aceder ao plano de curso respetivo, procurar um contacto de um docente à escolha e verificar
o próprio horário. Simultaneamente, contámos com a colaboração de cinquenta e cinco pessoas
para responderem aos nossos inquéritos SUS em relação ao SIGARRA.
A média dos resultados obtidos nos inquéritos SUS foi de 57,9 valores. Estes resultados indicam
que a satisfação com o sistema, à data de início do estudo, era mediana. Estes inquéritos foram
realizados à porta das unidades orgânicas escolhidas para o estudo, durante os testes de
usabilidade e, assim como já referido, durante as entrevistas.
Os testes de usabilidade iniciais foram realizados nos dispositivos móveis dos utilizadores, tanto
em Android como iOS, não podendo utilizar os sistemas Windows, pois nenhum dos
participantes possuía um tablet com esse sistema operativo. Apesar de não ter sido usado
nenhum meio de captura de vídeo, contámos com o auxílio do colega Luís Mendes, igualmente
estudante do Mestrado de Multimédia, como observador. Deste modo, foi possível combinar
notas comportamentais com as notas técnicas retiradas da interação do utilizador com a
interface do SIGARRA.
4.1.3 Análise Heurística
Como foi previamente referido no subcapítulo 3.1 Avaliação Heurística (Incluindo Estrutura de
Lavery), foi elaborada uma análise heurística do sistema com o objetivo de perceber melhor o
estado em que se encontrava o sistema e recolher mais informações sobre o mesmo.
No decorrer da análise da heurística número cinco – prevenção de erros – foi possível detetar
um caso grave que potência muitos erros na interação com o sistema. A tentativa de consulta
do percurso académico com ícone que é representativo de outra função (lupa) faz com que, por
vezes, o utilizador não consiga descobrir onde essa consulta pode ser feita (figura 32). Outro
problema detetado diz respeito à
verificação do horário pessoal, onde o
utilizador se depara com um página de erro
onde é informado da inexistência do
horário, sem qualquer informação útil
adicional (figura 33). Figura 32. Botão de lupa com função de consulta de percurso
académico
92
Durante a análise da heurística sete – flexibilidade e eficiência de uso – verificamos que o
sistema fornece ao utilizador a possibilidade de criação de atalhos personalizados mas,
relativamente a tabulações, a ordem pela qual as mesmas percorrem o layout do website não é
mais correta.
No que diz respeito à heurística oito – Estética e design minimalista – é
importante realçar alguns aspetos como a não filtração de elementos
visíveis pelo tipo de utilizador no menu de navegação do lado direito do ecrã
(figura 34). Ainda neste princípio podemos observar que algumas páginas
que compõe o website, quando visualizadas em orientação retrato, são
redimensionadas tornando o conteúdo menos legível e a navegação menos
prática.
Na heurística dez – Ajuda e documentação – podemos observar que de facto
o sistema fornece alguma informação de ajuda. Porém existem diversos
problemas com a informação, como encontrar-se em duplicado, por vezes
desatualizada, ou ser pouco pertinente para os utilizadores do sistema.
Esta análise encontra-se na íntegra no Apêndice 4 - Avaliação Heurística,
onde é possível obter informações mais detalhadas sobre a análise do sistema.
4.1.4 Personas e Cenários de Contexto
Com a informação reunida até este ponto do estudo, começámos a esboçar diversas personas.
Como mencionado previamente no subcapítulo 3.4 Personas, recorremos às personas a fim de
perceber melhor quem são os nossos utilizadores, o que esperam do sistema, as suas
necessidades, capacidades e limitações (ver Apêndice 5 - Personas e Cenários). Após alguns
esboços chegamos à conclusão que uma interface do SIGARRA para estudantes contaria com
Figura 33. Página de erro na consulta de horário pessoal
Figura 34. Exemplo de opções do menu não
filtradas
93
três tipos de utilizadores distintos, sendo um deles uma persona primária e os restantes
personas secundárias. Além disso, para cada persona, foram elaborados três possíveis cenários
de contexto onde eram descritas motivações e contextos de uso.
4.2 FASE FINAL
A primeira preocupação na fase final do estudo foi fazer uma análise cuidada dos dados
recolhidos na primeira fase. Após essa consideração começaram a ser elaborados os primeiros
protótipos.
4.2.1 Protótipos Passo-a-Passo
Para a elaboração de protótipos vários aspetos foram considerados como a regra do polegar
mencionada no subcapítulo 2.3 Design de Interfaces Moveis ou os vários tipos de protótipos
existentes e as suas implicações mencionados no subcapítulo 3.6 Prototipagem. Além disso, o
trabalho elaborado pelo Jorge Ribeiro (2012) foi importante, principalmente a nível de
considerações relativas aos menus de navegação e estrutura de conteúdos. Esse trabalho está
igualmente disponível de modo interativo num website86, complemento da sua dissertação.
Apesar de na análise heurística realizada já existirem algumas imagens do sistema atual,
consideramos importante retratar o sistema atual antes da apresentação dos novos protótipos,
incluindo um apêndice com essa informação, para possibilitar uma comparação com as soluções
apesentadas face ao estado atual do SIGARRA (ver apêndice 6 – Sistema Atual (Julho de 2014)).
Numa primeira fase, os protótipos foram esboçados em papel apenas com pequenos traços
representantes de como seria a estrutura dos conteúdos em ambas as orientações do
dispositivo. Após este primeiro esboço, os protótipos foram implementados em PowerPoint,
novamente em ambas as orientações, ainda com conteúdos abstratos placeholder (ver Apêndice
7 - Protótipos em PowerPoint). Nestes segundos protótipos, começaram também a surgir
elementos mais detalhados como bandeiras e ícones, assim como algumas alterações aos
protótipos iniciais como, por exemplo, posicionamento do menu e própria estrutura do mesmo
– surgiram novas soluções para os menus de navegação e menus de atalhos. A esta altura, os
protótipos deveriam começar a ser implementados na ferramenta FUSAMI, como planeado
inicialmente, a fim de testar os mesmos juntos dos potenciais utilizadores.
86 http://patterns.jribeiro.org/ consultado em 26-06-2014
94
Antes de passar ao desenvolvimento dos protótipos em ferramentas apropriadas para o fim, é
importante mencionar que não foi definido qualquer sistema de cores para os mesmos, sendo
o foco do estudo a estruturação de conteúdos tendo em vista a usabilidade do sistema.
Quaisquer cor ou elementos gráficos nos protótipos servem apenas para fazer algum contraste
e simplificar a compreensão da interface. Por questões de prazos, optámos por apenas realizar
protótipos na orientação de retrato nestas ferramentas, embora houvesse o desejo de realizar
em ambas as orientações inicialmente.
4.2.1.1 FUSAMI
A FUSAMI (Fraunhofer Usage Mining) tem como objetivo o teste de aplicações móveis assim
como a análise dos dados recolhidos, embora forneça suporte para prototipagem. Desde o
início, são notórias as fragilidades da ferramenta, facilmente justificadas por ainda se encontrar
em fase de testes. A ferramenta permite de momento duas principais funções: a integração da
mesma em aplicações para Android a fim de recolher dados provenientes da utilização dessas
aplicações, bastando apenas copiar o código gerado para a aplicação em conjunto com as
bibliotecas necessárias, e a criação de protótipos muito simples, sendo estes últimos mais
limitados. A ferramenta foi testada em dois browsers distintos, Chrome e Firefox. A nível geral,
um dos problemas encontrados diz respeito ao botão de ajuda, que apenas mexe com o layout
do ecrã onde nos encontramos (por exemplo, aumenta o tipo de letra).
Antes de podermos recolher os dados relativos à interação com a nossa aplicação, apenas temos
de importar os ecrãs da mesma para a ferramenta, indicando posteriormente quais as áreas
onde os utilizadores podem interagir. Deste modo indicamos à FUSAMI os locais onde a
informação deve ser recolhida. É possível ainda dar um nome aos ecrãs e áreas interativas. A
figura 35 mostra uma imagem, proveniente dos protótipos em PowerPoint, onde é possível ver
as funcionalidades da ferramenta, onde o retângulo azul visível é indicador de uma área de
possível interação. Após todas as áreas de interação serem assinaladas e todos os ecrãs serem
importados, basta apenas carregar no botão Integrate Application, presente na figura 34, onde
somos remetidos para uma página onde é fornecido ao programador todo o código necessário
para a FUSAMI trabalhar em conjunto com a aplicação, assim como as bibliotecas.
95
A nível de problemas técnicos, foram possíveis de observar situações onde não era possível
modificar o nome de uma das páginas sem reiniciar o browser ou a vista de ecrãs não apresentar
todas as páginas inseridas. Não foi possível testar esta funcionalidade a partir deste ponto por
dois motivos: por um lado, os protótipos desenhados dizem respeito a uma versão móvel do
website do SIGARRA e não de uma aplicação e, por outro lado, a criação de uma aplicação em
Android para fins de teste da ferramenta requeria conhecimentos de programação específicos
para o sistema operativo em questão.
Quando escolhemos a funcionalidade de prototipagem da ferramenta e criámos um novo
protótipo, deparamo-nos com um problema técnico - a ferramenta fica a gerar o protótipo
eternamente, sendo a única opção disponível em botão cancelar. Ao pressionarmos o botão
podemos verificar que, de facto, o protótipo já foi criado, o que leva a crer que o sistema está
de facto a criar devidamente os protótipos e apenas não está a informar corretamente o
utilizador do seu estado.
Figura 35. Ambiente de trabalho da FUSAMI para desenvolvimento de Apps
96
Após criado um protótipo, o código QR é gerado
automaticamente (figura 36). Existe outro método de criar
protótipos – na funcionalidade anterior é possível assinalar
uma caixa de verificação87 informando que queremos criar
um protótipo (figura 37), sendo depois remetidos para as
funcionalidades correspondentes.
No que diz respeito ao ambiente de trabalho da criação de protótipos, a
ferramenta apresenta nesta fase algumas opções, embora limitadas. É possível
acrescentar ecrãs na orientação e resolução desejadas e especificar as ligações
existentes entre eles, assim como cabeçalhos, áreas de interação, botões, caixas
e áreas de texto, etiquetas, caixas de verificação e botões de opção88 (figuras 38
e 39).
87 Em inglês, checkbox. 88 Em inglês, radio button
Figura 36. Código QR gerado
Figura 37. Menu de criação de Apps
Figura 38. Barra de ferramentas da FUSAMI na criação de protótipos
97
Nesta funcionalidade foram encontrados diversos problemas técnicos derivados de a aplicação
ainda estar em fase de testes. A opção para adicionar um fundo aos ecrãs criados pela FUSAMI
(figura 39) parece ainda não estar implementada. Por diversas vezes, após estabelecer uma
ligação entre ecrãs a ferramenta bloqueava – aparentemente continuava a funcionar
normalmente mas não gravava as alterações ou deixava testar, sendo necessário reiniciar o
browser para voltar a funcionar corretamente. Após adicionar dois ecrãs e três ligações entre os
mesmos, a aplicação deixou de permitir o teste em browser e gravar alterações feitas às ligações
após essa gravação, mesmo apagando os elementos que permitiam que essa ligação existisse.
Quando tentámos testar o protótipo existente num leitor de códigos QR gratuito disponível na
loja Google Play (QR Code Reader), a ligação encontrava-se vazia, não abrindo o protótipo como
devia. Seria interessante, ainda, implementar na FUSAMI uma opção para adicionar imagens
placeholder, uploaded ou não, de modo a introduzir mais informações nos protótipos.
As limitações encontradas, aliadas à falta de conhecimentos de programação neste campo,
levaram à escolha de outra ferramenta, esperando que a análise e experiência com a FUSAMI
tenha contribuído para uma evolução da mesma.
Figura 39. Opções de personalização dos ecrãs na elaboração de protótipos na
FUSAMI
98
4.2.1.2 Fluid UI
A Fluid UI permitiu elaborar rapidamente os protótipos necessários para os testes pois não
necessitava de conhecimentos de programação, embora não completamente como inicialmente
planeado, pois a ferramenta na sua versão gratuita apenas permite o desenvolvimento de dez
ecrãs. Embora o número de limitações da ferramenta seja considerável, quando comparada com
as outras ferramentas analisadas, esta é a que melhor cumpre as necessidades do projeto.
Devido à restrição de ecrãs foi necessário tomar decisões sobre que ecrãs não iriam ser
implementados uma vez que, com menus expandidos, estes deveriam de ser de cerca de setenta
e dois: trinta e seis para cada uma das diferentes orientações de ecrã – doze sem nenhum menu
expandido, outros doze com menu de navegação principal expandido e, por último, doze com o
menu de atalhos expandido.
Antes de surgirem exclusões de ecrãs mais detalhadas, foi necessário optar por uma das
orientações. A orientação escolhida foi a de retrato por dois motivos principais o primeiro diz
respeito ao que pudemos observar nos testes iniciais, onde os utilizadores tenderam a utilizar
os tablets nessa orientação, sendo a exceção a utilização de a base de apoio numa superfície; o
segundo motivo está diretamente relacionado com a gestão de tempo, onde se torna
complicado a criação de tantos ecrãs em tão pouco tempo disponível para a conclusão do
estudo.
Já com metade dos ecrãs previstos, a primeira decisão complicada foi excluir a página inicial sem
login efetuado, reduzindo os ecrãs necessários para trinta e cinco. De seguida, todos os ecrãs
com o menu de navegação principal expandido foram deixados de parte, à exceção do existente
na página principal, uma vez que era crucial para as tarefas existir esse menu e essa era a página
central. Já com os menus reduzidos a vinte e quatro, todos os ecrãs com menus de atalhos
expandidos foram excluídos pois não eram relevantes para o teste do protótipo que se iria
realizar, deixando os ecrãs em doze. A última decisão foi a mais complicada de tomar pois
tivemos de remover páginas intermédias da pesquisa avançada – a página de pesquisa avançada
onde escolhíamos o tipo de pesquisa a fazer e a página onde indicávamos campos específicos
para pesquisa (por exemplo, na página da pesquisa avançada escolhíamos a opção “docentes"
e na seguinte dizíamos se queríamos pesquisar pelo nome do docente ou pelo email).
Depois dos ecrãs terem sido todos criados e interligados, foram elaborados alguns testes ao
protótipos, nos vários percursos possíveis para completar a mesma tarefa, tanto no browser
como no dispositivo onde os testes iriam ser realizados. Para testar os protótipos no dispositivo
99
foi utilizada uma aplicação disponibilizada pela ferramenta para ler o código QR em dispositivos
Android. As figuras 40, 41 e 42 correspondem a alguns dos ecrãs finais realizados na ferramenta.
Os dez ecrãs elaborados encontram-se no Apêndice 8 - Protótipos Finais para consulta.
Figura 40. Página inicial com menu expandido
100
Figura 41. Página Pessoal
101
Figura 42. Página de Cursos - Mestrados
102
4.2.2 Testes de Usabilidade e Inquéritos SUS
Lowdermilk (2013) considera que a utilização de equipamento como câmaras de filmar e
gravação de áudio contribui para distrair os utilizadores, além de muitas pessoas não gostarem
de serem filmadas. Além disso, mesmo afirmando o contrário, alguns participantes podem sentir
que estão a ser testados, sentindo ansiedade.
Partilhando da opinião do autor, optei por não filmar ou gravar os participantes deste teste de
usabilidade. De facto, nem todos os seres humanos são iguais e, se existem indivíduos que são
mais desinibidos, outros preferem não ser expostos a uma câmara. Outro motivo para evitar a
utilização desse equipamento refere-se ao ambiente ruidoso onde os testes foram realizados,
tais como os bares das faculdades. Gostava, sim, de ter existido oportunidade de capturar o ecrã
do dispositivo mas não foi encontrada nenhuma aplicação gratuita para Android que permitisse
a gravação do ecrã sem efetuar root ao dispositivo.
Os testes de usabilidades foram realizados no dispositivo do autor, tablet BQ Edison 2 com
sistema operativo Android 4.1.1, recorrendo à aplicação de leitura de códigos QR gerados pela
ferramenta escolhida. Para estes testes foi utilizada uma amostra de seis participantes, de
diferentes unidades orgânicas da UP, e foi pedido aos participantes que desempenhassem as
mesmas três tarefas que outros utilizadores realizaram na fase inicial do estudo: aceder ao plano
de cursos respetivo, procurar um contacto de um docente à escolha e verificar o próprio horário.
Na preparação dos testes de usabilidade foram elaborados dois documentos: o plano de
atividades e o protocolo dos testes de usabilidade (ver apêndices 9 e 10 - Plano de Testes de
Usabilidade e Protocolo de Testes de Usabilidade).
Durante os testes, foram possíveis notar algumas pequenas confusões por parte dos
participantes derivadas das limitações da ferramenta de prototipagem como, por exemplo, a
tentativa de usar a pesquisa avançada. Após a realização destes testes de usabilidade, foi
elaborado um relatório como o resultado dos testes de usabilidade, que inclui também os
resultados dos inquéritos SUS, uma vez que estes foram utilizados para medir a satisfação dos
utilizadores. O relatório pode ser em encontrado no Apêndice 11 - Relatório de Testes de
Usabilidade.
Durante ou após os testes, foram possíveis recolher outras informações relevantes, tais como
comentários relativos à simplicidade do protótipo e a rapidez com que a informação é
encontrada. Foi ainda sugerida a implementação da possibilidade de fechar o menu através de
um toque no exterior do mesmo, além da opção de clicar no “x” para o fechar. Foi possível
103
observar dois participantes, P3 e P6 em concreto, a tentarem fazer essa ação e mostrarem uma
expressão confusa pois esperavam que a interface se comportasse desse modo.
Foi possível ainda observar que os participantes que necessitaram de assistência para completar
uma ou mais tarefas, quando obtinham essa assistência, conseguiam concluir sempre a tarefa
com sucesso.
4.3 CONCLUSÕES FINAIS
Após a análise das três tarefas, podemos concluir que as soluções implementadas aparentam
ser compreendidas e bem aceites pelos utilizadores. A simplificação dos menus, limitando as
opções visíveis às que realmente fazem mais sentido em contextos móveis, veio contribuir
imenso para a navegação dentro do sistema de informação de um modo eficiente e eficaz.
Embora tivesse sido interessante e enriquecedor poder testar muitas mais funcionalidades do
SIGARRA junto do seu público-alvo neste estudo, pelo que podemos observar nestas três tarefas
testadas, as sugestões propostas parecem ser compreendidas e bem aceites pelos utilizadores.
Porém, olhando para a satisfação dos participantes do teste, medida através dos inquéritos SUS,
podemos constatar que ainda existe um longo caminho a percorrer para o sistema obter uma
interface simples, de acesso rápido à informação pretendida e que agrade à maior parte dos
utilizadores.
Nas entrevistas que realizámos na primeira fase, verificámos que alguns utilizadores
consideravam a função de pesquisa no menu principal do website demasiado complexa,
desejando ter acesso a uma funcionalidade mais simples e eficiente de pesquisa. O modo mais
simples de resolver esta situação foi a simples implementação de uma caixa de pesquisa num
local acessível no canto superior direito da interface. Decidimos manter a opção de pesquisa
avançada dentro do menu principal de navegação de modo a perceber qual a interação preferida
pelos utilizadores. Neste caso podemos concluir que a maioria recorre imediatamente ao campo
de pesquisa inserido no topo da interface, sendo que uma possível alteração a fazer futuramente
seria remover a pesquisa avançada se assim se justificasse.
As observações, ou sugestões, que os participantes nos forneceram foram igualmente valiosas
para as conclusões tiradas a partir do estudo, especialmente a referência à melhoria do fecho
do menu. De facto, é uma interação comum em websites com menus que deve ser incluída
futuramente.
104
Na “batalha” website móvel vs. app é da nossa opinião que este é um assunto delicado que deve
ser bem pensado. Assim que o SIGARRA suporte o desenvolvimento de aplicações para
dispositivos móveis, no futuro, devem ser começados a fazer estudos nesse sentido. A verdade
é que uma aplicação é mais prática que a consulta de websites. Porém, se esta não for otimizada
ou não se adaptar ao contexto em que se insere e não traga nenhuma vantagem, a ideia não
deve seguir em frente.
105
CONCLUSÃO
Em primeiro lugar serão abordados temas como a satisfação dos objetivos propostos, seguidos
de considerações relativamente a trabalho futuro.
Sendo um dos objetivos deste estudo a contribuição para a definição de boas práticas de
usabilidade foi elaborada uma vasta análise de diversos métodos e ferramentas que podem ser
utilizados com o fim de melhorar a usabilidade de um produto ou interface. O cumprimento
deste objetivo foi relevante porque, além de permitir um alargamento de conhecimento,
constitui um guia para iniciantes no campo da usabilidade.
Outro objetivo cumprido remetia para a exploração de possíveis fragilidades do sistema de
informação da UP, principalmente em tablets, e apresentar soluções para essas mesmas
fragilidades. Tendo em conta que os tablets são dispositivos móveis, aspetos extra como a
dimensão do ecrã, contexto de uso do dispositivo e sistemas operativos, entre outros, tiveram
de ser estudados e compreendidos para um estudo mais preciso.
A análise efetuada de métodos e ferramentas de usabilidade permitiu descobrir diversas
fragilidades do SIGARRA, identificar possíveis soluções e testar as mesmas. A avaliação das
soluções propostas em protótipos foi efetuada recorrendo a testes de usabilidade e inquéritos
SUS. Todo este estudo está documentado em apêndices, devidamente identificados ao longo do
estudo para facilitar a compreensão da evolução da investigação por parte do leitor.
Resumidamente, este estudo contribuiu para a catalogação de diferentes métodos e
ferramentas para a avaliação da usabilidade de sistemas, assim como sugestões, presentes nos
protótipos finais, de melhoria do sistema de informação da UP, o SIGARRA, diariamente usado
por milhares de alunos.
TRABALHO FUTURO
Um dos objetivos inicialmente propostos seria averiguar se existiriam diferenças significativas
entre alunos de distintas UO no momento em que interagiam com o SIGARRA. Devido ao tempo
disponível para o estudo ser limitado, não foi possível levantar essa informação e poderia ser
interessante compreender se de facto existem algumas diferenças que, após identificadas, nos
permitissem melhorar a usabilidade do sistema.
106
No futuro, seria benéfico utilizar a informação recolhida nos últimos testes de usabilidade e
realizar protótipos mais adequados às necessidades dos utilizadores, corrigindo os problemas
encontrados. Seria ainda interessante elaborar protótipos completamente funcionais e testar os
mesmos junto de diversos alunos da UP – não só das UO abrangidas por este estudo mas de
todas as que compõem o universo da UP.
A nível de dimensão de amostra, seria interessante, futuramente, realizar um estudo mais
abrangente do sistema incluindo pessoal administrativo, docentes e potenciais alunos das
diferentes UO da UP.
No que diz respeito a contexto móvel, seria relevante estudar soluções para a orientação de
paisagem, uma vez que a duração do projeto apenas permitiu o estudo da orientação de retrato.
As tarefas sazonais complementadas pelo sistema, como inquéritos académicos ou
preenchimento de matrículas, constituem uma parte do sistema igualmente interessante de
estudar futuramente, visto não ter existido tempo suficiente para explorar essa faceta do
sistema.
107
REFERÊNCIAS BIBLIOGRÁFICAS
BEDFORD, Aurora; (2014). Maps and Location Finders on Mobile Devices. Disponível em WWW:
< http://www.nngroup.com/articles/mobile-maps-locations/>. [Consultado em 2014.02.20].
BERTINI, Enrico; GABRIELLI, Silvia; KIMANI, Stephen; (2006). Appropriating and Assessing
Heuristics for Mobile Computing. Disponível em WWW:
<http://www.dis.uniroma1.it/~kimani/teach/hci/slides/Bertini%20et%20al%202006-
mobile%20usability%20heuristics.pdf>. [Consultado em 2014.07.25].
BROWN, Dan M.; (2011). Communicating Design: Developing Web Site Documentation for
Design and Planning. 2nd Ed. Berkeley, California: Pearson Education.
BUDIU, Raluca; (2014). Usability Testing for Mobile Is Easy. Disponível em WWW: <
http://www.nngroup.com/articles/mobile-usability-testing/>. [Consultado em 2014.02.20].
CADDICK, Richard; CABLE, Steve; (2011). Communicating The User Experience: A Pratical Guide
For Creating Useful Ux Documentation. Chichester, West Sussex: John Wiley & Sons Inc.
CARDELLO, Jennifer; (2013). Three Uses for Analytics in User-Experience Practice. Disponível em
WWW: <http://www.nngroup.com/articles/analytics-user-experience/>. [Consultado em
2014.02.20].
CEVADA, João; BARROS, Ana Correia; MESTRE, Berta; ALCAINE, Sheila; BAYÉS, Àngels; (2013).
User-Centred Design of a Mobile Self-Management Solution for Parkinson’s Disease publicado
em MUM '13 Proceedings of the 12th International Conference on Mobile and Ubiquitous
Multimedia, Artigo 23.
CEVADA, João; BARROS, Ana Correia; MESTRE, Berta; ALCAINE, Sheila; BAYÉS, Àngels; (2014).
Design and Evaluation of a Medication Application for People with Parkinson’s Disease publicado
em Mobile Computing, Applications, and Services Lecture Notes of the Institute for Computer
Sciences, Social Informatics and Telecommunications Engineering, Volume 130, pp 273-276.
COOPER, Alan; REINMANN, Robert; CRONIN, David; (2007). About Face 3: The Essencials of
Interaction Design. 3rd Ed. Indianápolis, Indiana: Wiley Publishing.
DIX, Alan; FINLAY, Janet; ABOWD, Gregory D.; BEALE, Russell; (2004). Human-Computer
Interaction. 3rd Ed. Harlow, Essex: Pearson Education.
108
HOOBER, Steven; BERKMAN Eric; (2011). Designing Mobile Interfaces. Sebastopol, California:
O'Reilly Media.
HURSMAN, Aaron; (2010). User Centered Design Overview. Disponível em WWW:
<http://www.slideshare.net/hursman/user-centered-design-overview>. [Consultado em
2014.02.06]
JORDAN, Patrick; (1998). An Introduction to Usability. Londres: CRC Press.
ISO 9241-11; (1998). Ergonomic requirements for office work with visual display terminals (VDTs)
— Part 11: Guidance on usability
ISO 25062; (2006). Software engineering - Software product Quality Requirements and
Evaluation (SQuaRE) - Common Industry Format (CIF) for usability test reports. Disponivel em
WWW: <https://www.iso.org/obp/ui/#iso:std:iso-iec:25062:ed-1:v1:en>. [Consultado em
2014.06.04].
KARWOWSKI, Waldemar; SOARES, Marcelo; STANTON, Neville; (2011). Human Factors and
Ergonomics in Consumer Product Design. Methods and Techniques. Boca Raton, Flórida: CRC
Press.
KRUG, Steve; (2006). Don’t Make Me Think! A Common Sense Approach to Web Usability. 2nd
Ed. Berkeley, Califórnia: New Riders.
KRUG, Steve; (2010). Rocket Surgery Made Easy - The Do-it-yourself Guide to Finding and Fixing
Usability Problems. Berkeley, Califórnia: New Riders.
LEITÃO, Roxanne; (2012). Creating Mobile Gesture-based Interaction Design Patterns for Older
Adults: a study of tap and swipe gestores with Portuguese seniors. Porto: Faculdade de
Engenharia do Porto. Dissertação de Mestrado.
LOWDERMILK, Travis; (2013). User-Centered Design. Sebastopol, Califórnia: O'Reilly Media.
MATHIS, Lukas; (2011). Designed for Use: Create Usable Interfaces for Applications and Web.
Raleigh, Carolina do Norte: Pragmatic Programmers.
MEISSNER, Fritz; BLAKE, Edwin; (2011). Understanding Culturally Distant End-Users Through
Intermediary-Derived Personas publicado em SAICSIT '11 Proceedings of the South African
Institute of Computer Scientists and Information Technologists Conference on Knowledge,
Innovation and Leadership in a Diverse, Multidisciplinary Environment. pp.314-317.
109
MIFSUD, Justin; (2011). An Extensive Guide to Web Form Usability. Disponível em WWW:
<http://uxdesign.smashingmagazine.com/2011/11/08/extensive-guide-web-form-usability/>.
[Consultado em 2013.12.17].
NIELSEN, Jakob; (1993). Usability Engineering. Academic Press. Mountain View.
NIELSEN, Jakob; (1995). Severity Ratings for Usability Problems. Disponível em WWW: <
http://www.nngroup.com/articles/how-to-rate-the-severity-of-usability-problems/>.
[Consultado em 2014.02.07].
NIELSEN, Jakob; (1995). 10 Usability Heuristics for User Interface Design. Disponível em WWW:
<http://www.nngroup.com/articles/ten-usability-heuristics/>. [Consultado em 2013.10.05].
NIELSEN, Jakob; (1998). Designing Web Usability. Thousand Oaks, Califórnia: Pearson Education.
NIELSEN, Jakob; (2000). Why You Only Need to Test with 5 Users. Disponivel em WWW: <
http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/>. [Consultado em
2014.06.03].
NIELSEN, Jakob; (2012). Mobile Usability. Berkeley, Califórnia: Pearson Education.
NIELSEN, Jakob; (2012). Mobile Site vs. Full Site. Disponível em WWW:
<http://www.nngroup.com/articles/mobile-site-vs-full-site/>. [Consultado em 2014.02.20].
NIELSEN, Jakob; (2013). Tablet Usability. Disponível em WWW:
<http://www.nngroup.com/articles/tablet-usability/>. [Consultado em 2014.02.19].
NIELSEN, Jakob; BUDIU, Raluca. Usability of Mobile Websites. 85 Design Guidelines for Improving
Access to Web-Based Content and Service Through Mobile Devices in Nielsen Norman Group.
NIELSEN, Jakob; LORANGER, Hoa; (2006). Prioritizing Web Usability. Berkeley, Califórnia:
Pearson Education.
NIELSEN, Jakob; NORMAN, Donald; (2010). Gestural Interfaces: A Step Backwards In Usability.
Disponível em WWW:
<http://www.jnd.org/dn.mss/gestural_interfaces_a_step_backwards_in_usability_6.html>.
[Consultado em 2014.02.24].
NORMAN, Donald; (2004). Emotional Design. Nova Iorque: Basic Books.
NORMAN, Donald; (2010). Natural User Interfaces Are Not Natural. Disponível em WWW: <
http://www.jnd.org/dn.mss/natural_user_interfa.html> [Consultado em 2014.02.22].
110
NUNES, Francisco; SILVA, Paula Alexandra; ABRANTES, Filipe; (2010). Human-Computer
Interaction and the Older Adult: An Example Using User Research and Personas publicado em
PETRA '10 Proceedings of the 3rd International Conference on PErvasive Technologies Related
to Assistive Environments. Artigo 49.
PRUITT, John; GRUDIN, Jonathan; (2003). Personas: Practice and Theory publicado em DUX '03
Proceedings of the 2003 conference on Designing for user experiences, pp.1-15.
RIBEIRO, Hugo; (2012). Usabilidade Acessível: Metodologias para a Avaliação Qualitativa da
Usabilidade no Design para a Web. Porto: Faculdade de Belas Artes da Universidade do Porto.
Dissertação de Mestrado.
RIBEIRO, Jorge; (2012). Web Design Patterns for Mobile Devices. Porto: Faculdade de Belas Artes
da Universidade do Porto. Dissertação de Mestrado.
SAFFER, Dan; (2008). Designing Gestural Interfaces: Touchscreens and Interactive Devices.
Sebastopol, Califórnia: O'Reilly Media.
SANTOS, Ivo; (2012). Understanding how Personas and Scenarios are used in real world practice.
Porto: Faculdade de Engenharia da Universidade do Porto. Dissertação de Mestrado.
SHNEIDERMAN, Ben; (1983). Human factors in interactive software. Disponível em WWW: <
http://www.cs.umd.edu/~ben/papers/Shneiderman1983Human.pdf>. [Consultado em
2014.02.18].
SHNEIDERMAN, Ben; PLAISANT, Catherine; (2005). Designing the User Interface: Strategies for
Effective Human-Computer Interaction. Pearson Education.
SHERWIN, Katie; (2014). University Websites: Top 10 Design Guidelines. Disponível em WWW:
<http://www.nngroup.com/articles/university-sites/> [Consultado em 2014.02.20].
TRACTINSKY, N.; KATZ, A.S.; IKAR, D.; (2000). What is Beautiful is Usable publicado em
Interacting with Computers. Vol. 13, Issue 2. pp.124-145.
WAGNER, Mindy; (2008). Why Mood Boards Matter. DIsponivel em WWW:
<http://www.webdesignerdepot.com/2008/12/why-mood-boards-matter/> [Consultado em
2014.02.22].
WALTER, Aarron; (2011). Designing For Emotion. Nova Iorque: A Book Apart.
WROBLEWSKI, Luke; (2011). First Person User Interfaces. Disponível em WWW: <
http://static.lukew.com/FirstPersonInterfaces_11022011.pdf> [Consultado em 2014.06.04].
111
WROBLEWSKI, Luke; (2011). Mobile First. Nova Iorque: A Book Apart.
112
APÊNDICES
APÊNDICE 1 – ANÁLISE COMPARATIVA DE FERRAMENTAS DE PROTOTIPAGEM
Esta análise comparativa foi realizada a cinco ferramentas atualmente no mercado que
permitem a elaboração de protótipos que podem ser úteis para o estudo a decorrer. Em
primeiro lugar será efetuada uma introdução das ferramentas, procedendo depois à análise
comparativa das mesmas.
Proto.io
Website: http://proto.io/
A Proto.io é uma ferramenta de prototipagem com
suporte para vários sistemas operativos e permite a
implementação de gestos, eventos de toque, efeitos
de transição entre ecrãs e animações. A nível de
elementos de UI, existe uma grande variedade de
ícones por onde escolher, além dos elementos
básicos, como caixas de texto, formas ou imagens
adequadas ao sistema operativo pensado para o
projeto (figura 43). Não é necessário conhecimentos
de programação uma vez que o editor trabalha
segundo a tecnologia drag-and-drop89. Igualmente, não
é necessária a instalação de conteúdos para trabalhar com a ferramenta.
No que diz respeito ao teste dos protótipos, este pode ser feito através do acesso ao URL do
protótipo. Como alternativa, existe a possibilidade de descarregar das lojas oficiais da Apple ou
da Google uma aplicação para testar os protótipos no dispositivo.
89 Literalmente, arrastar e largar.
Figura 43. Lista Parcial de Elementos da UI do iOS Retina disponibilizados pela Proto.io
113
Esta ferramenta fornece funcionalidades extra, como exportação de conteúdos para HTML5,
impressão e exportação para ficheiros em formato PDF, publicação e partilha.
Fluid UI
Website: http://fluidui.com/
A Fluid UI suporta os sistemas operativos Android e
iOS. Em ambos os casos, é possível encontrar nas
respetivas lojas uma aplicação da ferramenta que
permite o teste dos protótipos nos dispositivos
móveis.
Na criação dos protótipos, é possível escolher entre
elementos de alta ou baixa definição, existindo uma
lista de diferentes elementos da interface
adequados ao sistema operativo em questão (figura
44). Existe ainda a possibilidade de definição de
gestos e animações de transição entre os diferentes
ecrãs, assim como a partilha de mockups e
exportação dos ecrãs. Não necessita de
conhecimentos de programação pois utiliza a
tecnologia drag-and-drop.
Moqups
Website: http://moqups.com/
É uma ferramenta curiosa porque, logo na sua página inicial, deixa o possível utilizador interagir
com diversos elementos que pode ter acesso na elaboração dos seus próprios mockups (figura
45). A Moqups trabalha em HTML5 e tem suporte para os browsers Chrome 16+, Firefox 10+,
Safari 5+ e Opera 15+. Existe a possibilidade de exportação para ficheiros PDF ou formato de
imagem PNG. Esta ferramenta não precisa de conhecimentos de programação, uma vez que
utiliza a tecnologia drag-and-drop.
Figura 44. Lista Parcial de Elementos de UI para iPhone disponibilizados pela Fluid UI
114
Flinto
Website: https://www.flinto.com/
Esta ferramenta suporta iOS e Android. Flinto permite a ligação de ecrãs (figura 46), atualização
de conteúdo sem quebra de ligações e não precisa de conhecimentos de programação pois
utiliza a tecnologia drag-and-drop. A ferramenta oferece ainda a possibilidade de escolher o
ícone a aparecer no ambiente de trabalho do dispositivo, transições suaves e scroll.
Figura 45. Ambiente de trabalho da Moqups
115
Framerjs
Website: http://www.framerjs.com/
Esta ferramenta permite a elaboração de protótipos quer para contextos Desktop quer para
contextos mobile. Esta pode trabalhar diretamente com ficheiros Photoshop ou começar
projetos através de um template90 - requer conhecimento de linguagens de programação Web
como o HTML, CSS e JS.
Existe a possibilidade de estabelecer hierarquias de ecrãs assim como a criação de animações
nos elementos desenhados. O código base para começar a desenvolver um projeto está
disponível gratuitamente no website da ferramenta.
90 Projeto modelo, base que contém elementos básicos necessários ao desenvolvimento de um projeto
Figura 46. Ambiente de trabalho da Flinto
116
Análise Comparativa
Para a realização do estudo, apenas é possível a utilização de planos grátis ou sem custos
acrescidos. Por esse motivo, esta análise compara apenas as versões de teste ou sem custos
(tabela 7).
Proto Fluid UI
Moqups Flinto Framerjs
Suporte Mobile ✔ ✔ ✔ ✔ ✔
Conhecimentos de Programação ✘ ✘ ✘ ✘ ✔
Número de Projetos
1 1 2 Ilimitado Ilimitado
Número de Ecrãs
5 /10Mb Armazenamento
10 Ilimitado até
5Mb de Armazenamento
Ilimitado Ilimitado
Limitação de Funcionalidades
Extra ✔ ✔ ✔ ✘ ✘
Período de teste
15 Dias Plano sem
custos
Plano sem custos
30 Dias Opensource91
Tabela 7. Tabela Comparativa de Ferramentas de Prototipagem
91 Opensource diz respeito a software que pode ser usado, alterado e partilhado livremente e sem custos por qualquer pessoa (opensource.org).
117
APÊNDICE 2 – ANÁLISE COMPARATIVA DE FERRAMENTAS DE ANÁLISE DE DADOS
Este relatório inclui a comparação de seis ferramentas presentes atualmente no mercado que
podem ser úteis para o estudo a decorrer. Em primeiro lugar será efetuada uma introdução das
ferramentas, procedendo depois à análise comparativa das mesmas.
Google Analytics
Website: http://www.google.com/intl/pt-PT_ALL/analytics/index.html
Através desta ferramenta, é possível aceder a dados como o número de utilizadores ativos da
aplicação, de que país/cidade a aplicação está a ser acedida, como determinadas
funcionalidades e características da aplicação são utilizadas e como os utilizadores se adaptam
à interface, relatórios relativos a crashes da aplicação, compras ou transações efetuadas na
aplicação, número de vezes que a aplicação foi descarregada da Google Play (no caso da versão
Android), entre outros (figura 47).
Para a ferramenta funcionar em sistemas Android, é necessário editar/criar ficheiros XML. Existe
no website um guia detalhado de como o fazer passo-a-passo. Atualmente existem três versões,
sendo que a mais recente ainda se encontra em beta92. No caso do iOS, são necessários editar
diferentes ficheiros header93. À semelhança da versão anterior, existe um guia detalhado para
ajudar a configurar.
92 Versão de testes 93 Ficheiros que contêm, por norma, declarações ou segmentos de código. São particularmente úteis para fazer uma reutilização eficiente de código.
Figura 47. Google Analytics
118
Heatmaps
SO Exclusivo: iOS
Website: https://heatmaps.io/
Esta ferramenta tem a vantagem de proporcionar uma leitura
dos sítios mais tocados pelo utilizador quando interage com um
aplicação ou website (figura 48). Além disso, podemos verificar a
ordem pela qual os utilizadores interagiram com os diversos
elementos, não existindo restrição na quantidade de elementos
que podemos observar. A ferramenta permite, ainda, a geração
de relatórios em formato PDF.
A leitura dos locais onde o utilizador toca pode ajudar a ler quais
as funções mais utilizadas e como são acedidas. Deste modo
podemos identificar erros que os utilizadores possam estar a
cometer, interpretar e refletir sobre qual a melhor alteração a
fazer para os resolver. A ordem pode também ser relevante para
definir prioridades de elementos.
Outras informações proporcionadas pela ferramenta (figura 49) incluem:
Quantidade de rotações da interface no sentido dos ponteiros do relógio e vice-versa
que o utilizador efetuou;
Quantidade de vezes que o utilizador fez zoom-in e zoom-out na interface;
Quantidade de vezes que o utilizador moveu a interface em qualquer uma das quatro
direções possíveis e se efetuou esses gestos com um ou dois dedos;
Informação sobre a orientação do dispositivo, paisagem ou retrato, quando o utilizador
interagia com as diversas funções da aplicação testada;
Número de vezes que o dispositivo foi abanado enquanto existiu interação com a
interface;
Tempo entre os diversos toques efetuados no ecrã;
Tempo total despendido na interação com a interface;
Caminhos que os utilizadores seguiram para realizar a(s) tarefa(s) pretendida(s).
Figura 48. Heat maps gerados pela ferramenta Heatmaps
119
Esta lista de informações pode fornecer dados relevantes para melhorar a usabilidade de uma
aplicação. Por exemplo, podemos observar se o utilizador utiliza os caminhos idealizados, que
outros caminhos que nunca tinham sido pensados foram pensados.
Appsee
Sistema Operativo: iOS
Website: http://www.appsee.com/
Figura 49. Informações fornecidas pela ferramenta Heatmaps
120
Esta ferramenta fornece mapas de toques efetuados pelo
utilizador (figura 50), mas não fica por aí. A grande vantagem da
Appsee diz respeito à gravação das ações do utilizador.
Appsee grava, do ponto de vista do utilizador, todas as interações
feitas pelo mesmo, desde que teclas pressionou no ecrã, onde e
por que motivo fez scroll, onde pressionou, se pressionou locais
que não era suposto fazerem qualquer tipo de ação, como foi
utilizado formulário de pesquisa. Através de controlo remoto, é
possível inclusive filmar apenas utilizadores que cumpram
determinados requisitos como, por exemplo, a versão do sistema
operativo ou as tarefas efetuadas.
Esta ferramenta fornece ainda relatórios relativos a crashes, que
podem ser úteis para detetar frustrações proporcionadas pela
aplicação em teste, embora, como muitas das funções, não está disponível no plano grátis. A
figura 51 representa o menu da Appsee onde é possível obter acesso a toda a informação
recolhida.
Figura 50. Heat maps gerados pela ferramenta Appsee
Figura 51. Exemplo de dados recolhidos pela Appsee
121
Delight
Sistema Operativo: iOS
Website: http://www.delight.io/
Esta ferramenta permitia a gravação de vídeo do ecrã, gravação das expressões do utilizador e
do som ambiente, através da câmara frontal do aparelho (figura 52). Essas sessões gravadas
podiam ser partilhadas, com suporte para HTML5 e h264. Podiam, ainda, ser enviados convites
para pessoas em particular poderem aceder às gravações efetuadas.
No entanto, esta ferramenta anunciou no seu blog94, dia 15 de Janeiro de 2014, que iria encerrar
os seus serviços no dia 31 do mesmo mês. No mesmo anúncio, é possível ler duas
recomendações de outras aplicações95. Uma das recomendações, Lookback, será analisada de
seguida, uma vez que a ferramenta Watchsend apenas suporta iPhone, não sendo assim útil
para o estudo.
94 http://www.delight.io/blog 95 “Thank you again for all your support to Delight. We recommend Lookback and Watchsend for alternatives.”
Figura 52. Delight em funcionamento
122
Lookback
Sistema Operativo: iOS
Website: http://lookback.io/
Lookback é uma ferramenta que ainda encontra em versão beta aberta ao público, ou seja,
qualquer pessoa pode utilizar e ajudar a testar esta versão teste que antecede a versão final, e
que permanecerá grátis pelo menos em quanto estiver nesta fase. Até ao momento, esta
aplicação permite gravar o ecrã e também o utilizador através da câmara frontal do dispositivo
móvel iOS (figura 53).
Esta ferramenta integra-se na aplicação que desejamos testar e
forma uma versão personalizada da mesma. Efetuado este passo,
requer que seja utilizada uma aplicação semelhante às
recomendadas Testflight96 ou HockeyApp97 (para enviar essa versão
personalizada aos utilizadores que queremos que testem a
aplicação). O SDK 98 da Lookback fornece aos utilizadores uma
interface que permite decidirem quando são gravados e o que deve
ser gravado, dentro da própria aplicação. Isto proporciona aos
utilizadores a decisão de gravar continuamente um vídeo ou apenas
pequenos segmentos.
De momento, a Lookback suporta iPhone e iPad embora existam
algumas restrições mencionadas no website da ferramenta. Existem
igualmente planos para desenvolver compatibilidade para sistemas
Android mas sem uma data definida.
Crazyegg
Website: http://www.crazyegg.com/
96 http://testflightapp.com/ 97 http://hockeyapp.net/features/ 98 Kit de Desenvolvimento de Software. Em inglês, Software Development Kit
Figura 53. Captura de ecrã realizada pela Lookback
123
Esta aplicação foi descoberta através da leitura de um
artigo de Jennifer Cardello (2013). Numa primeira
análise, verificamos ser possível ter acesso a heat
maps, scroll maps e confetti. Uma vez que o código da
ferramenta é incluindo diretamente no código do
website, esta funcionará em qualquer sistema
operativo.
Esta aplicação fornece heat maps (figura 54) mas,
além disso, esta ferramenta proporciona a vantagem
de permite saber informações como, por exemplo,
que percentagem de utilizadores acede a uma
hiperligação (figura 55).
Os scroll maps (figura 56) fornecem informações como a quantidade de dados, presentes na
página, que foram lidos pelos utilizadores ou a que ponto estes perdem interesse em procurar
a informação pretendida na página.
Figura 55. Quantos utilizadores acederam a determinada hiperligação e a percentagem correspondente
Figura 54. Heat maps gerados pela ferramenta Crazyegg
124
A funcionalidade confetti está relacionada com o tráfego do website e permite saber parâmetros
interessantes, como quantos dos utilizadores acederam ao nosso website através de outro
website, se estes utilizaram alguma palavra-chave para chegarem ao nosso website,
estabelecimento de comparações entre novos e usuais utilizadores no que diz respeito ao
conteúdo a que acedem (figura 57).
Figura 56. Scroll maps gerados pela ferramenta Crazyegg
Figura 57. Funcionalidade Confetti
125
Análise Comparativa
Para a realização do estudo, apenas é possível a utilização de planos grátis ou sem custos acrescidos. Por esse motivo, esta análise compara as versões de
teste mais completas de cada ferramenta com as versões sem custos das aplicações sem versão de testes (tabela 8). A ferramenta Delight não se encontra na
comparação devido a ter sido descontinuada.
126
Google Analytics
Heatmaps Appsee Lookback Crazyegg
Sistema Operativo Android/iOS iOS iOS iOS Sem restrições
Estatísticas ✔ ✘ ✔ ✘ ✘
Heat Maps n/a ✔ ✔ ✘ ✔
Relatórios ✔ ✔ ✘ ✘ ✔
Quantidade de Amostras Mensal Ilimitado 1.000.000
1.000 (+100 com vídeo)
Ilimitado 250.000
Deteção Variada de Gestos n/a ✔ ✘ ✔ ✘
Deteção de Scrolls n/a ✘ ✔ ✘ ✔
Personalização de Conteúdo Recolhido ✔ ✘ ✘ ✔ ✘
Percursos de Navegação (interno e/ou externo)
✔ ✔ Possível observar
através de uma lista de eventos
É possível ter uma ideia através da funcionalidade de temporizador, semelhante a
uma linha de tempo
✔
Captura de Ecrã/Utilizador (vídeo) n/a ✘ Apenas ecrã Ambos ✘
Duração da Versão de Teste (se existente) n/a
30 Dias – qualquer um dos três planos
predefinidos n/a
Ilimitado enquanto estiver em testes
30 Dias – qualquer plano
Tabela 8. Tabela Comparativa de Ferramentas de Análise de Dados
127
APÊNDICE 3 – ENTREVISTAS
Entrevista com a Dra. Lígia Ribeiro – Questões e Respostas
Relativamente a esta entrevista, apresenta-se a enumeração das questões colocadas à
entrevistada assim como notas relativas às respostas, não sendo uma transcrição das mesmas.
Questão 1 – Quais eram as expetativas da Reitoria quanto ao SIGARRA aquando da criação do
sistema?
Notas da Questão 1:
O diretor da FEUP, Dr. Marques dos Santos, em 95/96 criou iniciativa para ter mais
acesso à informação que antes chegava com muito atraso. Vários departamentos
enviavam a informação conforme as suas próprias normas e ferramentas e não eram
todas uniformes;
O sistema tencionava fazer chegar a informação de modo uniforme e ágil;
Foi lançado desafio ao professor Gabriel David, estudantes e Dra. Lígia para resolverem
esse problema – surgiu o SiFEUP;
Antes do SIGARRA em 92 havia o GAUP (GA atual). Utilizado por todas as UO menos a
de ciências que usava o Infociências;
A ideia foi construir o SI em cima do GAUP até para melhorar a componente backoffice;
O SiFEUP devia fornecer suporte administrativo, via intranet, além de mostrar à
comunidade interna e externa o que se fazia na FEUP;
1998 – Prémio Decartes;
O sistema fazia relatórios e estatísticas adequadas às necessidades das reitorias;
2000 – Prémio EUNIS;
Dr. Novais Barbosa, reitor, considerou uma mais-valia para a UP e convidou a instalar o
SiFEUP em todas as faculdades.
As datas variam porque as equipas de gestão e adaptabilidade do sistema influenciaram
a sua adoção. Era necessário ver se o sistema se adequava ao contexto da UO em
questão.
SIGARRA surgiu do nome SIFEUP mencionar apenas FEUP e não todas as UO onde viria
a ser implementado, além de ser um nome de fácil memorização.
128
A grande recetibilidade do sistema veio de esta já estar implementado na FEUP há algum
tempo e ter dado provas;
A FCUP demorou a adotar o sistema devido a ter o seu próprio sistema. Embora numa
primeira fase ter se tentado conciliar ambos, a FCUP acabou por reconhecer os
benefícios de adotar o SIGARRA.
Q2 – É referido no plano de atividades e orçamento da UP para 2014 que pretendem melhorar
a usabilidade do SIGARRA. Qual a importância deste investimento?
NQ2:
Usabilidade sempre foi importante desde o início. Esta deve acompanhar inovações
tecnológicas e necessidades ao longo do tempo;
2011 - existiu um estudo de usabilidade pedido à FBAUP centrado na instância da UP
(up.pt). Este mostrou algumas debilidades mas também comprovou que na verdade as
pessoas conseguiam encontrar a informação que pretendiam mais rapidamente do que
o que afirmavam;
Este estudo levou a um novo desenho do SIGARA. Apesar de concluído e os diretores
das UO e os gestores de informação para o SIGARRA terem conhecimento do mesmo,
este ainda não se encontra disponível publicamente;
A comissão de utilizadores acompanha o desenvolvimento do sistema, respondendo às
necessidades do mesmo. Dessa comissão fazem parte os gestores de informação;
O design novo tem 2 camadas: comunicacional e organizacional. A comunicacional é
dirigida ao público externo fornecendo informações gerais sobre a universidade. Foi
pensada para investigadores externos, potenciais alunos, entre outros. A outra camada
contém informações mais detalhadas relativamente à UO em questão. Exemplo:
o Camada comunicacional – lista de cursos;
o Camada organizacional – detalhes sobre cursos.
Com eleição do novo reitor recentemente tenciona-se implementar o novo desenho
para a instância da UP em breve;
Recentemente, podemos observar que os ícones da FEUP foram alterados. Estas
alterações foram possíveis devido a uma alteração recente na framework do sistema,
preparando-o para providenciar suporte às novas funcionalidades. Cada universidade
decide o seu design específico para o SIGARRA. Isso explica porque a UO (confirmar qual)
usa uma página de loading enquanto as restantes não o fazem ou porque o design do
SIGARRA da FCUP é totalmente distinto das restantes UO.
129
A alteração dos ícones, no caso da FEUP, serviu para de certa forma modernizar um
pouco o sistema. Estas alterações não podem ser forçadas, não se pode pedir a uma UO
que implemente algo contra a sua vontade – o gestor de informação de cada UO é
sempre avisado previamente de uma qualquer alteração planeada. Do mesmo modo,
cada universidade escolher ativar os módulos que deseja. Embora alguns sejam
obrigatórios, o módulo responsável por menus de cantina, por exemplo, é opcional.
Por norma as outras universidades, a nível nacional e internacional, têm sistemas de
informação distintos para cada uma das suas subsidiárias, além de existirem CRIS,
sistemas financeiros, entre outros, todos independentes. A vantagem do SIGARRA em
relação a outras universidades diz respeito ao modo de acesso, rapidez e consistência
da informação pretendida. Exemplo:
o Avaliação de docentes precisa de componentes pedagógicos, investigação, etc.
os sistemas independentes são mais lentos a reunir informação, o grau de
complexidade é superior e não asseguram tão facilmente a consistência dos
dados.
Q3 – O SIGARRA é, atualmente, muito mais que um sistema de informação, é uma ferramenta
de trabalho utilizada com muita frequência. Tendo em conta esta característica, de que forma a
Reitoria pretende investir no SIGARRA?
NQ3:
Acompanhar mudanças legislativas ou regulamentares (propinas, do estudante) e
preparar o sistema nesse sentido. O plano mais próximo passa por investir na assinatura
digital, existindo já uma requisição para implementar esta tecnologia a aguardar
aprovação. Exemplo:
o Lançamento de notas pelo professor -> período de esclarecimentos -> professor
imprime termo e assina -> informação é transmitida da camada frontoffice para
a backoffice, bloqueando possíveis alterações.
No exemplo anterior, a introdução da assinatura digital evita a impressão do termo para
o assinar. Neste sentido, seria também criado um repositório para os termos assinados
digitalmente. De um modo geral, se num workflow surgir necessidade de assinatura, é
necessário garantir que as pessoas podem assinar digitalmente.
O SIGARRA tem a vantagem de ter sido desenhado de acordo com as necessidades da
UP -> existe a preocupação de acompanhar as necessidades da UP e utilizar a tecnologia
de modo a acrescentar valor.
130
Q4 – Qual a importância da adaptação do sistema a dispositivos móveis?
NQ4:
Existe vontade de investir em mobile;
Deseja-se criar uma camada para mobile para as apps irem buscar a informação
necessária apenas aí. No próximo ano pensam já ter novidades relativas a este assunto:
Várias entidades, como empresas, têm mostrado grande interesse em desenvolver
aplicações para o SIGARRA.
Q5 – Que planos existem para o desenvolvimento do SIGARRA?
NQ5:
Embora esta questão estivesse inicialmente prevista, acabou por não ser colocada uma vez que
consideramos que, ao longo da entrevista, esta acabou por ser respondida.
Notas adicionais:
As páginas de estatísticas do SIGARRA variam de acordo com o perfil de utilizador (por exemplo:
um estudante não consegue visualizar tantas estatísticas quanto o diretor de um curso).
Pretende-se acoplar um sistema de Business Intelligence, com o objetivo de possibilitar obter
estatísticas para responder às necessidades de cada Faculdade, sendo este uma espécie de
armazém para construção de relatórios de forma autónoma.
Entrevistas com os estudantes – Questões e Respostas
Seguem-se a caracterização da amostra, a experiência dos participantes com o sistema, as
questões colocadas aos entrevistados e notas relativas às respetivas respostas, sendo sempre o
número indicado entre parêntesis referente ao número de participantes que relatou cada uma
das observações ou possui uma determinada experiência com o sistema.
Amostra: 53 alunos das diversas UO da UP
Experiência com o sistema: menos de um ano (21), 1 ano (11), 2 anos (5), 3 anos (13), 4 anos ou
mais (3).
131
Questão 1 – Qual a satisfação geral em relação à plataforma online do SIGARRA?
Respostas à questão 1 – O menu do lado direito é confuso e, em alguns casos, extenso,
tornando-se frustrante procurar opções nessa lista (20); o sistema no geral é confuso, por vezes
os utilizadores ficam desorientados com a quantidade de menus, hiperligações e banners que
acabam por ofuscar a informação mais importante (23); a falta de organização das páginas (6),
havendo demasiada informação redundante (9); quanto aos estudantes estrangeiros, indicaram
que algumas hiperligações estão em português, assim como os banners e slideshows (3).
Q2 – Quais as principais tarefas efetuadas com mais regularidade?
R2 – Verificação de horários (50), conta corrente (42), plano de curso (45), percurso académico
(39), contactos dos professores/funcionários (47), aceder ao Moodle da UP (36) e aceder ao
Webmail (22).
Q3 – Quais os principais obstáculos encontrados durante a utilização do sistema?
R3 – Hiperligações encontram-se pouco espaçadas, o que dificulta utilização do SIGARRA em
tablet (38); nos dispositivos móveis, a página é apresentada com banners com dimensão
desadequada, assim como o calendário (45). Além disto, a página no geral não se encontra bem
adaptada para a visualização em dispositivos móveis (53); não é possível encontrar um evento
em específico, sem andar a procurar no meio de todos os dispostos no calendário (21);
demasiados passos para chegar à opção/informação pretendida (36), pouco eficiente; sempre
que se faz login no SIGARRA e existe uma tentativa de aceder ao percurso académico, é
necessário indicar a faculdade a que queremos aceder, caso o curso tenha parceria com outras
faculdades, sendo um passo desnecessário (10).
Q4 – O que achavam que podia ser mudado em relação ao sistema (navegação, apresentação,
organização dos conteúdos, entre outros)?
R4 – Cores de alguns websites, ainda que sejam as cores institucionais, causam
descontentamento - exemplo referido: FEP (4); eventos deviam ser filtrados de acordo com o
tipo de utilizador (19), existindo também algumas hipóteses de configuração (14); a faculdade
“principal” a que pertence o curso devia ser automaticamente selecionada (3), havendo depois
a possibilidade de alternar entre os websites das faculdades, num menu facultativo; a pesquisa
é muito complexa, e devia ser simplificada (46).
132
APÊNDICE 4 – ANÁLISE HEURÍSTICA
Tarefas selecionadas para a elaboração da análise:
1. Aceder ao plano de curso;
2. Procurar contacto de um professor;
3. Verificar o horário.
A análise foi efetuada num tablet BQ Edison 2 de 10” com SO Android 4.1.1 e encontra-se
acompanhada de diversos exemplos visuais.
1 – Visibilidade do estado do sistema
Questão de conformidade
O sistema deve sempre manter os utilizadores informados sobre o que se está a passar, através
de feedback adequado e dentro de um espaço de tempo razoável.
Evidência de conformidade
O sistema informa o utilizador onde se encontra no sistema, podendo a qualquer altura clicar
numa das hiperligações para regressar a páginas anteriormente visitadas.
O sistema também informa o utilizador do tempo que demorou a abrir uma página, assim como
a hora da última atualização do conteúdo dessa página.
Por outro lado, como é possível observar nas duas imagens seguintes, verifica-se que a barra
que indica a posição do utilizador no sistema por vezes não funciona corretamente. Neste caso,
no menu do lado esquerdo da página ao selecionar a opção “Estudantes”, abre uma página com
diversas informações, entre as quais “Matrículas/Inscrições”. Selecionando esta opção, a barra
no topo da página não permite retroceder para “Estudantes”, apenas para a página Home.
133
Motivação
É extremamente importante que o utilizador consiga saber o estado do sistema, uma vez que é
prejudicial à experiência de utilizador o sistema não o informar do que se está a passar no
momento.
2 – Concordância entre o sistema e a realidade
Questão de conformidade
O sistema deve utilizar a mesma linguagem que o utilizador, com palavras, frases e conceitos
familiares ao utilizador, ao invés de termos orientados para o sistema. Assim, deve seguir o
convencional do mundo real, a informação deve aparecer de uma forma lógica e natural.
Evidência de conformidade
A nível geral, no que diz respeito à linguagem, esta é acessível e fácil de compreender ao que
corresponde na realidade.
No caso dos contactos dos docentes, consideramos que a informação está disposta de uma
forma lógica e concisa, ainda que informações como a sigla e o código não serão relevantes para
a maioria dos utilizadores, pelo que esta informação deveria ser filtrada de acordo com o tipo
de utilizador.
No geral, o sistema funciona bem neste aspeto, excetuando algumas situações que podem ser
melhoradas, como a referida anteriormente.
Motivação
A necessidade de existir simplicidade a nível linguístico permite uma navegação mais eficaz e
direta, evitando assim a possibilidade de existir uma reflexão extra sobre o significado de
determinada opção dentro do sistema.
134
3 – Controlo de utilizador e liberdade
Questão de conformidade
Por vezes, os utilizadores selecionam funções do sistema de forma não intencional, necessitando
de uma “saída de emergência”. O sistema deve suportar as opções “Anular” e “Repetir”;
Evidência de conformidade
Neste aspeto, é possível referir que os utilizadores do SIGARRA têm ao seu dispor as
ferramentas, e um nível de controlo e liberdade satisfatório, para desempenharem diversas
tarefas dentro do sistema.
No caso dos horários, se o utilizador selecionar um período que não existe, surge um botão que
permite retroceder para a página anterior.
Além disto, no plano de estudos, também existem botões para fechar percursos alternativos e
minimizar anos curriculares.
Quanto aos contatos de docentes, é possível verificar que ao efetuar uma pesquisa e selecionar
um dos resultados, não existe nenhum botão para voltar a essa lista, portanto, obriga o
utilizador a fazer uso dos botões de avançar e retroceder do browser.
A nível geral, o controlo de utilizador e liberdade é adequado, mas em certas situações, como
por exemplo tentar aceder ao horário através do percurso académico do estudante, resulta
numa página de erro (“Não foram encontrados registos para o período em questão.” – mesmo
caso que aconteceria ao escolher um período de aulas incorreto), que obriga o utilizador a
aceder à página do curso para visualizar o horário, uma vez que aquela opção não funciona de
todo.
135
Motivação
É importante existirem opções para anular ações ou simplesmente retroceder, uma vez que é
normal os utilizadores cometerem erros, tais como cliques em opções próximas ou,
simplesmente, selecionarem uma opção por estarem demasiado apressados, sem tomar a
devida atenção. Em tablets, mais concretamente, o número de vezes em que se escolhe uma
opção por engano é ainda maior se tivermos em conta que a inclinação do visor pode induzir em
erro.
4 – Consistência e normas
Questão de conformidade
Os utilizadores não devem necessitar de considerar se diferentes palavras, situações e ações
significam a mesma coisa. Deve-se seguir as convenções da plataforma;
Evidência de conformidade
Nas tarefas que realizámos para testar esta heurística, não conseguimos identificar
inconsistências a nível da linguagem e efeito das ações e objetos. Neste estudo preliminar,
verificámos concordância com as convenções utilizadas para sistemas web.
Assim, em qualquer uma das três tarefas realizadas, os objetos e respetivas ações correspondem
ao habitual em qualquer sistema web. Utilizando como exemplo a página dos horários, os
botões “Submeter” e “Voltar Atrás” (no caso de selecionar um período em que não existem
aulas) têm o resultado esperado, não havendo qualquer erro neste aspeto.
136
Por outro lado, foi possível identificar um problema, ainda que não esteja
diretamente ligado a qualquer uma das tarefas deste estudo, com os ícones
presentes nos botões “Validar” e “Desligar”. No caso do botão “Validar”,
está presente um aloquete aberto, e no caso do botão “Desligar”, o
aloquete encontra-se fechado. Os ícones não são adequados para
representar a ação espoletada por ambos botões, ou devem ser removidos,
ou deve ser trocado, passando o aloquete aberto para o botão “Desligar”,
e o botão “Validar” fica sem nenhum ícone.
Motivação
Logicamente, a importância deste ponto está ligada à facilidade de uso de qualquer sistema.
Assim, se o utilizador consegue generalizar o efeito de determinada opção numa página,
tomando como princípio qualquer outra página do mesmo ou de outro sistema totalmente
alheio, então a experiência e eficiência de utilização serão bastante satisfatórias, e neste aspeto
não foi possível identificar defeitos.
5- Prevenção de erros
Questão de conformidade
A utilização de mensagens de erro claras é importante, mas mais relevante ainda é a
implementação de um design cuidado que previna estes problemas de acontecerem em
primeiro lugar. Ou se deve eliminar condições que propiciem erros ou verificá-las e apresentar
aos utilizadores uma opção de confirmação antes de cometerem a ação.
Evidência de conformidade
Neste ponto foi possível identificar algumas situações, que com um design mais cuidado, não
iriam induzir os utilizadores a cometer erros.
No caso das tarefas que efetuámos, verificámos que o design é adequado à conclusão com
sucesso das mesmas. Noutras situações, por exemplo, a confirmação da intenção de pagamento
de propina, existem botões para confirmar esta ação, assim como para alterar os valores e
mesmo anular a referência multibanco. Outro exemplo, na página pessoal dos alunos, para
137
aceder ao percurso académico temos de pressionar
o ícone de uma lupa, o que nos parece confuso e
pouco adequado para atingir esse fim, induzindo o
utilizador em erro.
No caso da visualização do horário através do
percurso académico, é apresentada a seguinte
mensagem de erro: “Não foram encontrados
registos para o período em questão”.
Sendo este período, por defeito, o período corrente,
esta mensagem não faz sentido, nem explica ao
utilizador como deve proceder para conseguir visualizar a informação pretendida.
Motivação
Nos dois últimos exemplos referidos anteriormente, podemos concluir que as situações
apresentadas afetam negativamente a experiência do utilizador, ao induzir o mesmo a cometer
erros, não oferecendo qualquer solução ou percurso alternativo para obter a informação
pretendida.
6 – Reconhecer e não decorar
Questão de conformidade
Deve ser minimizada a carga na memória do utilizador. Os objetos, ações e opções devem estar
visíveis. O utilizador não deve ser obrigado a decorar informação de uma parte do diálogo para
o outro. As instruções necessárias para a interação com o sistema devem ou estar visíveis ou de
serem de fácil acesso caso seja necessário.
Evidência de conformidade
A nível geral, as opções, ações e objetos estão visíveis e o utilizador não é obrigado a decorar
informação para conseguir utilizar o sistema. No caso de dúvidas, existe um botão no topo da
página que permite ao utilizador aceder a uma página de ajuda (na imagem seguinte, terceiro
botão, da esquerda para a direita).
138
Por outro lado, voltando ao caso referido na heurística anterior, numa fase inicial de utilização
do SIGARRA, o utilizador é obrigado a decorar que ao pressionar na lupa acede ao percurso
académico e outras informações sobre as unidades curriculares. Assim, torna-se importante
substituir a lupa por um botão de texto “Percurso académico”, pois além de ser mais intuitivo,
não induz novos utilizadores do sistema a cometer erros e a ficarem desorientados no sistema,
uma vez que é uma das tarefas desempenhadas com mais frequência dentro do sistema.
Motivação
A importância deste aspeto está associada, também, à prevenção de erros. O reconhecimento
do efeito das diversas opções e a visibilidade dos mesmos, permite ao utilizador navegar de uma
forma mais cómoda e eficaz pelo sistema, reduzindo a necessidade atual de “experimentar”
carregar em botões de modo a encontrar a informação pretendida, como no caso da lupa do
percurso académico.
7 – Flexibilidade e eficiência de uso
Questão de conformidade
Os atalhos permitem aos utilizadores mais experientes a execução de operações mais
rapidamente. Os atalhos também permitem aos utilizadores o acesso a informações que, de
outro modo, obrigariam a navegar através de várias páginas para as aceder.
Evidência de conformidade
De modo a desempenhar mais rapidamente tarefas que o utilizador faça
frequentemente, é possível adicionar atalhos para aceder a essas
tarefas.
O utilizador não tem a possibilidade de ocultar e/ou remover atalhos pré-definidos na barra
lateral, existindo diversas opções que não serão relevantes para a maioria dos utilizadores, pelo
que consideramos que seria necessário alterar este aspeto, de modo a tornar mais eficiente a
utilização do sistema.
139
Por outro lado, a página de atalhos pessoal permite adicionar, editar ou até mesmo apagar
atalhos definidos pelo utilizador. Esta página pode ser acedida através da hiperligação “Ver
Lista” existente na barra lateral, dentro da secção de atalhos.
Na imagem apresentada em seguida, dentro da página do “Mestrado em Multimédia”, existe a
opção “Documentos”, que não é relevante para a grande maioria dos utilizadores, muito menos
para os estudantes, além de estar totalmente em branco, pelo que poderia e deveria ser
removida das opções pré-definidas.
140
Além disso, é possível utilizar a tecla TAB para navegar pela página, porém a ordem pela qual
esta percorre os diferentes componentes do website não é nada prática, não funciona da
maneira esperada.
Motivação
Os métodos disponíveis não são eficientes (tanto no caso da navegação por teclado, como no
caso dos atalhos e opções pré-definidas), pelo que são propícios a originar níveis baixos de
eficiência do sistema por parte dos seus utilizadores.
Concluindo, é importante existir uma maior flexibilidade e customização do sistema, pois
permitiria aos utilizadores o desempenhar de tarefas de uma forma mais cómoda e rápida.
8 – Estética e design minimalista
Questão de conformidade
Os diálogos não devem conter informação irrelevante ou que só ocasionalmente é necessária.
Cada unidade de informação no diálogo ocupada com informação desnecessária compete com
a informação relevante, diminuindo a sua visibilidade.
Evidência de conformidade
No que toca à estética e design do sistema, é um dos pontos que deve ser revisto e melhorado,
pois é alvo de grandes frustrações e desagrado por parte de utilizadores. Existe demasiada
informação e opções raramente utilizadas, que ofuscam informação mais importante.
141
A lista do lado direito do sistema não filtra as opções de acordo com o tipo de utilizador,
apresentando diversas tarefas que só podem ser desempenhadas ou acedidas por um grupo
restrito de utilizadores. No caso dos contactos de docentes, existem opções como “Participações
em júri de teses” e “Reserva de recursos”, que só deveriam ser apresentadas ao próprio e,
eventualmente, pessoal administrativo.
O menu do lado direito da página, em alguns casos, possui uma dimensão exagerada, sendo
necessário procurar no meio de todas as opções de forma a encontrar a opção pretendida.
Além disso, a estética do sistema não é ideal, existindo demasiada informação irrelevante, além
do excesso de banners, que ocultam a informação importante, tornando a experiência de
utilização bastante pouco satisfatória.
No caso do plano de estudos, concluímos que para aceder a algumas unidades curriculares
temos de carregar num botão para aceder a percursos alternativos e, em alguns casos, pedir
para visualizar quais as unidades curriculares optativas para aquele perfil. Consideramos que a
informação devia estar disposta de uma forma mais lógica, possibilitando o acesso à informação
sem a necessidade de ter de passar por tantas barreiras.
142
Quando visualizado com a orientação em retrato, em geral, todo o sistema reduz a escala de um
modo que torna o conteúdo menos legível e prático, como é possível observar nos exemplos
anterior e seguinte.
143
Motivação
No caso extremo do número exagerado de opções na barra lateral, referido anteriormente,
podemos verificar a importância de minimizar o número de opções disponíveis. Utilizadores que
não estejam familiarizados com o sistema necessitam de procurar a opção que desejam entre
as diversas opções existentes. Ao ser reduzido o número de opções desnecessárias, a
experiência de navegação será bastante menos frustrante.
Além disto, um design mais corrente e apelativo também iria contribuir para a satisfação dos
utilizadores, uma vez que o atual é, claramente, uma das maiores fraquezas do sistema.
144
9 – Ajudar utilizadores a reconhecer, diagnosticar e recuperar dos erros
Questão de conformidade
As mensagens de erro devem ser expressas em linguagem simples (sem códigos), indicar
claramente qual o problema e disponibilizar soluções úteis e construtivas;
Evidência de conformidade
Certas mensagens de erro não são apresentadas com uma linguagem simples. Não apresentam
ao utilizador sugestões para resolver o problema, nem descrevem de forma compreensível, pela
maioria dos utilizadores, o problema em si.
Como exemplo, ao copiar de forma incompleta o URL de uma página, é apresentada uma
mensagem de erro que não dá qualquer solução viável nem informação relevante ao utilizador
para resolver este erro.
Noutra situação idêntica, a mensagem de erro obtida foi diferente, disponibilizando ao utilizador
informações de uma forma mais clara que a anterior, e com uma possível solução para o
problema. Em último caso, o utilizador tem ao seu dispor o botão “Voltar Atrás”.
145
Outro exemplo de erro presente refere-se à tentativa de abrir uma página que não existe de
todo. Neste caso, é apresentada uma mensagem de erro muito mais útil que as presentes nos
exemplos anteriores, oferecendo diversas alternativas e possíveis soluções ao utilizador.
Por último, existe uma outra página de erro disponibilizada pelo sistema. Esta ocorre,
principalmente, sempre que algo corre mal quando efetuamos uma pesquisa na base de dados
do sistema. À semelhança do primeiro exemplo, apenas informa que houve um erro de sintaxe,
não oferecendo qualquer suporte ao utilizador. Aliás, se os conhecimentos informáticos do
utilizador não forem algo avançados, este pode não perceber a que sintaxe a página de erro se
refere.
Motivação
Os erros reduzem bastante a eficiência de utilização do sistema, e como aconteceu em alguns
dos exemplos mencionados, se não existirem opções viáveis para recuperar dos erros, tornam
a experiência muito negativa.
146
A nível geral, não são apresentados ao utilizador métodos para recuperar dos erros, o que o
deixa o utilizador desorientado neste tipo de situações, sendo necessário um verdadeiro “trial
and error” para ultrapassar os mesmos. As mensagens de erros deveriam ser mais precisas, à
semelhança da última página de erro apresentada, com soluções para o utilizador conseguir
ultrapassar estas situações com autonomia.
10 – Ajuda e documentação
Questão de conformidade
Apesar de ser preferível que o sistema seja utilizável sem recorrer a documentação, pode ser
necessário providenciar ajuda e documentação. Toda a informação deve ser fácil de pesquisar,
focada nas tarefas do utilizador, listar os passos que se devem tomar e não ser demasiado longa.
Evidência de conformidade
Existem diversas páginas de documentação disponíveis em diversas situações ao longo do
sistema. Aceder a estas páginas é bastante simples, sendo apenas necessário pressionar num
ícone presente no topo da página (na imagem seguinte, terceiro botão, da esquerda para a
direita).
Ao visualizar várias páginas de ajuda, é possível concluir que a informação apresentada é
demasiado extensa, devendo esta ser simplificada e reduzida, apresentando ao utilizador
somente os passos a proceder de uma forma clara e resumida para desempenhar tarefas, e não
os significados dos termos utilizados nas páginas. Além disso, a informação está em duplicado.
147
Apesar de ser fácil de aceder, a informação é muito pouco pertinente, não apresentando
informações importantes aos utilizadores. De facto, a imagem acima mostra a ajuda contextual
relativa a uma pesquisa de resultados de pessoal que apenas lista os nomes, pesquisa essa que
não contêm alguns dos elementos mencionados na lista – por exemplo, a opção “exportar” não
está disponível (para os estudantes pelo menos) e a opção “web” não se encontra nesta lista
mas sim na página pessoal do individuo em questão.
Motivação
Mais uma vez, não é desejável ser necessário utilizar um manual de instruções para se utilizar o
sistema, porém, no caso de dúvidas, é de facto útil existir esta informação. A forma como está
disponibilizada é correta, pois é o utilizador que decide se quer aceder ou não a esta informação
através de um ícone que ocupa um espaço relativamente reduzido na página.
148
APÊNDICE 5 – PERSONAS E CENÁRIOS DE CONTEXTO
António Cruz
Tipo de Persona: Primária
Designação: Estudante (não trabalhador)
Dados Demográficos:
Português;
19 Anos.
Características:
Estudante do 2º ano de Mestrado Integrado;
Já teve contato prévio com o sistema – ano letivo anterior;
Utiliza o sistema com alguma regularidade;
Disponibilidade para explorar o sistema.
Competências tecnológicas:
Facilidade em utilizar dispositivos móveis e manuseamento de aplicações web.
Objetivos finais:
Verificar horário das unidades curriculares;
Procurar contactos de professores;
Localizar das salas de aula e de exame;
Aceder a diferentes tarefas através da sua conta corrente;
Confirmar datas de exame;
Visualizar o seu percurso académico;
Obter acesso ao Moodle;
Verificar o seu Webmail.
149
Necessidades / Expectativas:
Espera obter a informação desejada sem dificuldades técnicas;
Espera ter a liberdade para conseguir cumprir tarefas sem atrasos causados pelo
sistema;
Necessita da existência de suporte caso surjam dificuldades;
Necessita que a disposição da informação e o comportamento do sistema se adequem
ao esperado num sistema móvel, caso contrário pode deixar de utilizar o sistema neste
formato devido a frustrações.
Motivações e Cenários de Contexto:
1. Em casa, verifica confortavelmente no sofá o seu horário para o dia seguinte no tablet,
evitando deslocar-se para o computador Desktop.
2. No café com os amigos, lembra-se que tem uma dúvida sobre um trabalho que precisa
esclarecer o mais rapidamente possível. Para tal, consulta o contato do docente no
sistema e envia um email.
3. A caminho da universidade, lembra-se que tinha de pagar uma determinada prestação
das propinas no fim do mês corrente e fica em dúvida se já o fez. Antes que seja tarde
demais, consulta a conta corrente através do SIGARRA.
150
Ruth Cooper
Tipo de Persona: Secundária
Designação: Estudante ERASMUS
Dados Demográficos:
Inglesa;
22 Anos.
Características:
Nunca teve contato com o sistema;
Utiliza o sistema com alguma regularidade;
Disponibilidade para explorar o sistema.
Competências tecnológicas:
Facilidade em utilizar dispositivos móveis e manuseamento de aplicações web.
Objetivos finais:
Verificar horário das unidades curriculares;
Procurar contactos de professores;
Localizar das salas de aula e de exame;
Aceder a diferentes tarefas através da sua conta corrente;
Confirmar datas de exame;
Visualizar o seu percurso académico;
Obter acesso ao Moodle;
Verificar o seu Webmail.
151
Necessidades / Expectativas:
Necessita que o sistema tenha suporte linguístico, no mínimo, para inglês. Caso
contrário, ficará impossibilitada de usar parcialmente, senão de todo, o sistema;
Espera obter a informação desejada sem dificuldades técnicas;
Espera ter a liberdade para conseguir cumprir tarefas sem atrasos causados pelo
sistema;
Necessita da existência de suporte caso surjam dificuldades e que esta tenha,
igualmente, suporte linguístico;
Necessita que a disposição da informação e o comportamento do sistema se adequem
ao esperado num sistema móvel, caso contrário pode deixar de utilizar o sistema neste
formato devido a frustrações.
Motivações e Cenários de Contexto:
1. Visto ser uma estudante ERASMUS, não tem um computador Desktop em casa. Numa
situação em que o seu portátil esteja a ser utilizado por uma colega com quem partilha
a residência, a Ruth necessita de aceder ao sistema para ter acesso à plataforma Moodle
e consultar conteúdos de apoio aí disponibilizados.
2. No autocarro, enquanto de desloca entre a residência e a universidade, verifica o
horário.
3. Também no autocarro, desta vez a caminho da residência, verifica o seu percurso
académico a fim de verificar se as alterações que pediu que fossem feitas na secretaria
já entraram em vigor.
152
Manuel Carvalho
Tipo de Persona: Secundária
Designação: Estudante
Dados Demográficos:
Português;
28 Anos.
Características:
Estudante do 1º ano de Doutoramento;
Já teve contato prévio com o sistema – licenciatura na UP;
Utiliza o sistema com alguma regularidade;
Pouca capacidade para explorar as funcionalidades do sistema.
Competências tecnológicas:
Pouca experiência e pouco confortável com o manuseamento de aplicações web e dispositivos
móveis.
Objetivos finais:
Verificar horário das unidades curriculares;
Procurar contactos de professores;
Localizar das salas de aula e de exame;
Aceder a diferentes tarefas através da sua conta corrente;
Confirmar datas de exame;
Visualizar o seu percurso académico;
Obter acesso ao Moodle;
Verificar o seu Webmail.
153
Necessidades / Expectativas:
Necessita que o sistema seja simples, intuitivo e fácil de usar para alguém com pouca
experiência como ele, caso contrário, pode não o utilizar por ser demasiado complexo;
Necessita de conseguir obter a informação que necessita com facilidade e sem ter de
fazer muitos passos devido a não se sentir confortável como o manuseamento deste
tipo de aplicações;
Espera que o sistema não dê erros e, caso ocorram, necessita que seja possível resolver
os mesmos com facilidade para alguém com os seus conhecimentos em dispositivos
móveis.
Necessita que o sistema utilize linguagem e termos acessíveis, o mais semelhantes
possível ao mundo real. Se for demasiado complexo pode levar à efetuação de tarefas
não pretendidas, tarefas parcialmente efetuadas tendo em conta o pretendido
inicialmente ou a não realização de tarefa alguma.
Motivações e Cenários de Contexto:
1. Nos corredores da universidade, estranhando a demora do docente ao chegar à sala de
aula, consulta o email para verificar se o docente avisou nas últimas horas que ia ser
impossível comparecer à aula.
2. Durante a época de exames oficial, enquanto está na fila da caixa do supermercado,
aproveita para verificar se já saíram as notas das unidades curriculares do primeiro
semestre.
3. No início do ano, e porque é novo aluno daquela faculdade, precisa de aceder ao horário
para saber quais são as suas salas de aula mas, mais importante que isso, precisa de
consultar o sistema de modo a descobrir em que parte do campus se localiza a sala em
questão de modo a saber onde se dirigir. Apesar de no dia anterior ter consultado no
seu computador a localização, aproveita para verificar de novo a mesma, uma vez nas
instalações.
154
APÊNDICE 6 – SISTEMA ATUAL (JULHO DE 2014)
Nas próximas páginas deste apêndice, seguem-se capturas de imagens consideradas relevantes
para a compreensão do estado do sistema atualmente e das soluções propostas ao longo do
estudo. Apesar de 10 das 11 capturas estarem documentadas com a data de Julho, quando
comparadas com o sistema no início do estudo, apenas modificações estéticas foram feitas, por
exemplo, modernização dos botões de login. A página do horário do curso, em Julho, não
conseguia disponibilizar o horário (surgia o erro mencionado na análise heurística onde não era
possível encontrar o horário requisitado), pelo que tivemos de apresentar uma captura gerada
em Outubro, no início do estudo. O ecrã é apresentado na totalidade de modo a exemplificar o
espaço em branco encontrado nas páginas do website que não preenchem na totalidade o ecrã
do dispositivo.
155
Página Inicial, sem login
156
Página Inicial, com login
157
Página Pessoal do Utilizador
158
Página de Pesquisa Avançada
159
Página de Apresentação de Resultados da Pesquisa
160
Página do Docente
161
Página do Curso
162
Página de Planos de Estudos do Curso
163
Página de Cursos
164
Página de Horário
165
APÊNDICE 7 – PROTÓTIPOS EM POWERPOINT
Página Inicial, sem login
166
Página Inicial, com login
167
Página Pessoal do Utilizador
168
Página de Pesquisa Avançada
169
Página de Pesquisa de Docentes
170
Página de Apresentação de Resultados da Pesquisa
171
Página do Docente
172
Página do Curso
173
Página de Planos de Estudos do Curso
174
Página de Cursos
175
Página de Horário
176
APÊNDICE 8 – PROTÓTIPOS FINAIS
Este apêndice incluí uma hiperligação para os protótipos para teste em browser, o código QR e
os ecrãs dos protótipos, por esta ordem.
Hiperligação
Os protótipos estão disponíveis para teste no browser seguindo a seguinte hiperligação:
https://www.fluidui.com/editor/live/preview/p_3ioZVmUklIkvP6p2mZMDSOLUQOhH6VBI.140
3804556531
Código QR
Para visualizar os protótipos nos dispositivos móveis deve ser efetuado o download da aplicação
da Fluid gratuitamente da lojas de aplicações adequadas ao dispositivo. De seguida, ler o código
abaixo.
177
Ecrãs dos Protótipos
Página Inicial
178
Página Inicial, com menu expandido
179
Página Pessoal
180
Resultados da Pesquisa
181
Página do Docente
182
Página de Cursos
183
Página de Mestrados
184
Página do Curso
185
Plano de Estudos do Curso
186
Horário do Curso
187
APÊNDICE 9 – PLANO DE TESTES DE USABILIDADE
[SIGARRA Mobile] Plano de Testes de Usabilidade
188
Meta
Serão realizados testes de usabilidade com estudantes de três unidades orgânicas distintas da
UP aos protótipos para Tablet criados no âmbito da dissertação.
Objetivos
Testar a performance dos utilizadores ao desempenharem as três tarefas pedidas, através da
eficiência e eficácia, e a sua satisfação subjetiva.
Local e recursos
a) Cafés/bares da FCUP, FLUP e FMDUP e redondezas;
b) Tablet BQ Edison 2 com Android 4.1.1, aplicação Fluid UI Barcode Scanner para leitura
de código QR do protótipo.
Participantes
Seis participantes.
Metodologia
Duração das sessões: 6 minutos no máximo.
Introduzir a sessão (1 minuto).
Tarefas (4,5 minutos)
Discussão após o teste (2 minutos).
Medidas
a) Eficácia – Verificar até que ponto as tarefas são completadas na totalidade, de
preferência, sem assistência.
b) Eficiência – Tempo que os utilizadores demoraram a completar cada tarefa. As tarefas
foram concebidas para não demorar mais que um minuto e meio cada.
c) Satisfação – Averiguada através de inquéritos SUS, além da observação das expressões
e verbalizações dos participantes durante o teste.
Conteúdos do relatório
As características de cada participante serão apresentadas em forma de tabela, assim como os
resultados a nível de performance em cada tarefa. De seguida será apresentado o resultado
obtido nos inquéritos SUS, a nível individual e média de total, de modo a medir a satisfação.
189
Agenda do projeto
Materiais
Inquéritos SUS após os testes de usabilidade.
Ambiente de Testes
Cafés/bares da FCUP, FLUP e FMDUP e redondezas; Tablet BQ Edison 2 com Android 4.1.1,
aplicação Fluid UI Barcode Scanner para leitura de código QR do protótipo.
Papel do Moderador
Introduzir a sessão, explicar as tarefas a desempenhar pelos participantes, fazer anotações que
considerar relevantes e solicitar o preenchimento dos inquéritos SUS.
Documentação Derivada
Do teste irão resultar anotações em papel relativas ao desempenho / expressões corporais dos
participantes.
Tarefas
a) Os participantes devem aceder ao horário do estudante. Para tal, é pedido que assumam
o papel de João Cunha, um estudante fictício;
b) De seguida, estes devem procurar no website o docente Mário Vaz de modo a obter o
seu contacto;
c) Por último, é pedido aos participantes que encontrem o plano de estudos do Mestrado
em Ciências de Comunicação.
190
APÊNDICE 10 – PROTOCOLO DE TESTES DE USABILIDADE
[SIGARRA Mobile] Protocolo de Testes de Usabilidade
191
Utilizadores
a) Seis participantes;
b) Alunos das Unidades Orgânicas da UP.
Contexto de Uso do Produto
Local dos Testes
a) Bares/cafés da FCUP, FLUP ou FMUDUP e redondezas.
Ambiente Computacional dos Utilizadores
a) Tablet BQ Edison 2 com Android 4.1.1, aplicação Fluid UI Barcode Scanner para leitura
de código QR do protótipo.
b) Ligação wireless.
Procedimento
Cenários
a) Desempenhar de tarefas básicas na interface dos protótipos.
b) Completar com sucesso significa conseguir obter a informação pedida, existindo mais
que um percurso para atingir os objetivos.
c) As tarefas devem ser desempenhadas no limite máximo de 4 minutos e meio.
d) O participante pode colocar questões ao moderador durante os testes.
Instruções
a) É pedido aos participantes que usem o protocolo de pensamento em voz alta para
melhor perceber o seu raciocínio;
b) É indicado aos participantes que é a interface que está a ser testada, não os mesmos;
c) Os participantes podem colocar questões se acharem pertinente ou necessitarem de
ajuda;
d) Devido a limitações da ferramenta de prototipagem, os participantes são informados
que o menu apenas está operacional no ecrã inicial.
192
Tarefas
a) Os participantes devem aceder ao horário do estudante. Para tal, é pedido que
assumam o papel de João Cunha, um estudante fictício;
b) De seguida, estes devem procurar no website o docente Mário Vaz de modo a obter o
seu contacto;
c) Por último, é pedido aos participantes que encontrem o plano de estudos do Mestrado
em Ciências de Comunicação.
Medidas de Performance e Satisfação
Critérios
a) Performance – Verificar se os participantes conseguem completar as tarefas na
totalidade e o tempo que demoram a realizar as mesmas;
b) Percurso – Existe mais que um percurso para completar as tarefas. Se possível, averiguar
qual o percurso mais comum.
Medidas
a) Eficácia – Verificar até que ponto as tarefas são completadas na totalidade, de
preferência, sem assistência;
b) Eficiência – Tempo que os utilizadores demoraram a completar cada tarefa. As tarefas
foram concebidas para não demorar mais que um minuto e meio cada;
c) Satisfação – Averiguada através de inquéritos SUS, além da observação das expressões
e verbalizações dos participantes durante o teste.
193
APÊNDICE 11 – RELATÓRIO DE TESTES DE USABILIDADE
SIGARRA Mobile
Testado por: Diana Oliveira
Data dos Testes de Usabilidade: 19 de Junho de 2014
Data do Relatório: 24 de Junho de 2014
Preparado por: Diana Oliveira
194
Sumário
Foram realizados testes de usabilidade com estudantes da UP aos protótipos para o sistema
SIGARRA da UP, criados no âmbito desta dissertação, sendo os protótipos pensados
exclusivamente para tablets, na orientação de retrato.
Os testes contaram com a participação de 6 estudantes de distintas unidades orgânicas da UP.
Foi pedido a estes que executassem três tarefas básicas na interface dos protótipos, tais como
aceder ao horário, procurar um docente e aceder ao plano de estudos de um curso em concreto.
Por último, estes testes de usabilidade foram realizados para averiguar a adequação das
soluções apresentadas nos protótipos. O sumário dos resultados, a nível de performance, pode
ser consultado na tabela seguinte.
Participante
Eficácia ao completar tarefa s/
assistência (%)
Eficácia ao completar tarefa c/
assistência (%)
Duração aproximada
(min) Erros Assistências
P1 100% 100% 2,5 0 0
P2 88,89% 100% 3,5 0 1
P3 88,89% 100% 3 0 1
P4 100% 100% 2 0 0
P5 100% 100% 2 0 0
P6 88,89% 100% 4 1 1
Média 94,45% 100% 2,83 0,17 0,5
Desvio Padrão
5,56% 0% 0,75 0,37 0,5
Min 88,89% 100% 2 0 0
Max 100% 100% 4 1 1
195
Introdução
Descrição
a) Protótipos SIGARRA website para Tablets, versão 3;
b) Público-alvo: estudantes da UP.
Objetivos dos Testes
a) Testar a performance dos utilizadores ao desempenharem as três tarefas pedidas,
através da eficiência e eficácia, e a sua satisfação subjetiva;
b) Os utilizadores interagem com a interface através de menus de navegação e campos de
texto (caixas de combinação e campos de texto encontram-se limitados, pois não
permitem o preenchimento).
Método
Participantes
a) Seis participantes;
b) Estudantes da UP.
Género Idade Educação Ocupação Experiência
com o Sistema
P1 M 23 Licenciado Estudante 2 anos
P2 F 19 Ensino
Secundário Trabalhador-
estudante 1 ano
P3 F 26 Mestrado Trabalhador-
estudante 5 anos
P4 M 20 Ensino
Secundário Estudante 2 anos
P5 M 22 Licenciado Estudante 4 anos
P6 F 18 Ensino
Secundário Trabalhador-
estudante 1 ano
196
Tarefas
a) Três Tarefas:
a. Os participantes devem aceder ao horário do estudante. Para tal, é pedido que
assumam o papel de João Cunha, um estudante fictício;
b. De seguida, estes devem procurar no website o docente Mário Vaz de modo a
obter o seu contacto;
c. Por último, é pedido aos participantes que encontrem o plano de estudos do
Mestrado em Ciências de Comunicação;
b) Estas foram selecionadas por terem sido utilizadas anteriormente para testar o SIGARRA
na fase inicial do projeto. Nessa fase, foram escolhidas após a realização de entrevistas
com estudantes, sendo estas as tarefas efetuadas com maior regularidade pela maioria
dos estudantes;
c) As tarefas devem, preferencialmente, ser completadas dentro do tempo definido, com
a menor quantidade de assistência possível.
Local
Os testes foram realizados nos bares ou em cafés das redondezas da FCUP, FLUP ou FMDUP.
Ambiente Computacional dos Participantes
c) Tablet BQ Edison 2 com Android 4.1.1, aplicação Fluid UI Barcode Scanner para leitura
de código QR do protótipo.
d) Ligação wireless.
Dispositivos
Tablet BQ Edison 2, Android 4.1.1
Métodos para Medir a Satisfação
Inquéritos SUS.
197
Design experimental
Procedimento
Os participantes:
a) Devem completar cada tarefa, no máximo, em 1,5 minutos;
b) Podem pedir ajuda e/ou colocar questões ao moderador;
c) São abordados nos ambientes descritos, sendo-lhes questionado se são alunos da UP;
d) São incentivados a pensar em voz alta quando interagem com o protótipo;
e) São informados das tarefas (tendo presente uma folha de papel com as mesmas caso
necessitem de consultar durante o teste) e é aberta a página de entrada dos
protótipos. O tempo começa a contar apenas quando o participante se sentir
preparado;
Esteve ainda presente o colega Luís Mendes no papel de colaborador. A sua principal função
foi auxiliar na observação comportamental dos participantes.
Medidas de Usabilidade
a) Eficácia – Verificar até que ponto as tarefas são completadas na totalidade, de
preferência, sem assistência;
b) Eficiência – Tempo que os utilizadores demoraram a completar cada tarefa, foram
concebidas para não demorar mais que um minuto e meio cada;
c) Satisfação – Averiguada através de inquéritos SUS, além da observação das expressões
e verbalizações dos participantes durante o teste.
Eficácia
Rácio de Sucesso
Percentagem de participantes que completou as tarefas na totalidade.
198
Erros
Situações em que o participante não completou a tarefa com sucesso, ou número de vezes que
teve de repetir um determinado passo para a concluir.
Assistência
a) Rácio de sucesso sem assistência do moderador;
b) Medidas separadas para avaliar quem completou com sucesso as tarefas sem
assistência, e quem completou as tarefas com sucesso com assistência.
Eficiência
Tempo que os utilizadores demoraram a completar as tarefas e desvios de eventuais
participantes.
Satisfação
Os participantes, no final da sessão de testes, preencheram inquéritos SUS.
Resultados
a) Métricas separadas para averiguar quem completou as tarefas com assistência, e
quem as completou sem qualquer assistência.
b) Dados estatísticos.
Apresentação de resultados
Apresentados os resultados em forma de tabelas a nível de performance. No caso dos
inquéritos SUS estes são apresentados em forma de lista não ordenada.
199
Resultados de Performance
Tarefa 1
Participante Eficácia ao
completar tarefa s/ assistência (%)
Duração aproximada
(min) Erros Assistências
P1 100% 1 0 0
P2 100% 1 0 0
P3 100% 1 0 0
P4 100% 0,5 0 0
P5 100% 1 0 0
P6 100% 1,5 0 0
Média 100% 1 0 0
Desvio Padrão 0% 0,29 0 0
Min 100% 0,5 0 0
Max 100% 1,5 0 0
200
Tarefa 2
Participante Eficácia ao
completar tarefa s/ assistência (%)
Duração aproximada
(min) Erros Assistências
P1 100% 0,5 0 0
P2 66,67% 1,5 0 1
P3 100% 0,5 0 0
P4 100% 0,5 0 0
P5 100% 0,5 0 0
P6 100% 0,5 0 0
Média 94,45% 0,67 0 0,17
Desvio Padrão 12,42% 0,37 0 0,37
Min 66,67% 0,5 0 0
Max 100% 1,5 0 1
201
Tarefa 3
Participante Eficácia ao
completar tarefa s/ assistência (%)
Duração aproximada
(min) Erros Assistências
P1 100% 1 0 0
P2 100% 1 0 0
P3 66,67% 1,5 0 1
P4 100% 1 0 0
P5 100% 0,5 0 0
P6 66,67% 2 1 1
Média 88,89% 1,17 0,17 0,33
Desvio Padrão 15,71% 0,47 0,37 0,47
Min 66,67% 0,5 0 0
Max 100% 2 1 1
202
Sumário
Participante Eficácia ao
completar tarefa s/ assistência (%)
Duração aproximada
(min) Erros Assistências
P1 100% 2,5 0 0
P2 88,89% 3,5 0 1
P3 88,89% 3 0 1
P4 100% 2 0 0
P5 100% 2 0 0
P6 88,89% 4 1 1
Média 94,45% 2,83 0,17 0,5
Desvio Padrão 5,56% 0,75 0,37 0,5
Min 88,89% 2 0 0
Max 100% 4 1 1
Resultados de Satisfação
Resultados dos questionários SUS:
Participante 1 – 87,5 valores.
Participante 2 – 67,5 valores
Participante 3 – 70 valores.
Participante 4 – 92,5 valores.
Participante 5 – 85 valores.
Participante 6 – 62,5 valores.
Máximo: 92,5 valores.
Mínimo: 62,5 valores.
Média: 77,5 valores.