Cidades Inteligentes e Aplicativos de Roteirização: Modelos Conceituais, Avaliações de Usabilidade e Uma

Proposta de Aplicativo Daniel Antônio Midena Aguillar1, Daniele Haucke1, Socrates Veridiano Faria Lopes1,

Plinio Thomaz Aquino Junior1,2 1IPT - Instituto de Pesquisas Tecnológicas do Estado de São Paulo, São Paulo, Brasil 2Centro Universitário FEI – Fundação Educacional Inaciana Pe. Sabóia de Medeiros,

São Bernardo do Campo, Brasil danielaguillar@yahoo.com.br, danielehaucke@gmail.com, socrateslopes@acm.org,

plinio.aquino@fei.edu.br ABSTRACT The goal of this research is to evaluate Waze and Google Maps’ user experience, compiling the suggested improvements in a report. These apps were chosen because of their global popularity levels. Traditional HCI theories and methods were used to help retrieve information about the apps in order to generate more knowledge for general planning and evaluation activities. These apps were evaluated using methods such as communicability evaluation, heuristics evaluation and usability testing. These methods were combined to enhance results and evaluations’ quality levels. The evaluation team consists of one advisor teacher and three post-graduation students. All evaluations brought useful knowledge for the proposition of improvements within the apps. Additionally, due to the implementation impossibility of such improvements, it is presented an app proposal that considers them.

Author Keywords Usability; heuristics; mobile apps UX testing; HCI; communicability evaluation.

ACM Classification Keywords H.5.m. Information interfaces and presentation (e.g., HCI): Miscellaneous;

INTRODUÇÃO O dinamismo do trânsito nos grandes centros urbanos, alta quantidade de veículos e baixa previsibilidade das condições das vias motivam o cidadão a buscar eficiência nos deslocamentos realizados cotidianamente. Muitos fatores influenciam a busca por essa eficiência: ganhar tempo fugindo do trânsito, diminuir custo, aumentar segurança e conforto, entre outros. Quando necessário deslocamento por meio de veículo próprio, transporte coletivo, taxi, bicicleta,

motocicleta ou mesmo a pé, faz-se necessária a identificação de melhores rotas em trajetos do cotidiano, principalmente em deslocamentos até locais não explorados anteriormente. Neste último caso, são necessárias buscas por melhores trajetos e auxilio contínuo durante a viagem. Com a popularização dos smartphones e maior acesso a redes móveis, os cidadãos recorrem a diversos aplicativos disponibilizados no mercado para atender tais necessidades, e.g. Waze, Google Maps, TomTom, Garmin, GPS Navigator, HERE, Sygic, CoPilot GPS, Navmii GPS Brasil, entre outros. Verifica-se que estes aplicativos são usados em diversos cenários, com múltiplos motivadores, e atendem diferentes perfis de usuários. O objetivo deste trabalho é avaliar a experiência de uso dos aplicativos Waze e Google Maps, compilando melhorias sugeridas em um relatório. A popularidade, alcance global, disponibilidade nas duas plataformas mais populares (iOS e Android) além de sua gratuidade motivaram sua escolha. Teorias e métodos tradicionais de IHC foram utilizados no levantamento de informações sobre os aplicativos de modo a gerar mais conhecimento para o planejamento e execução das avaliações. A experiência de uso dos aplicativos foi avaliada utilizando-se uma combinação de métodos de avaliação através de inspeção e de observação. Tais métodos foram combinados para aumentar a qualidade do resultado das avaliações. A equipe de avaliadores é formada por um professor orientador e três alunos de pós-graduação. As avaliações geraram entendimentos para a proposição de melhorias nos aplicativos, constatando-se que os aplicativos avaliados possuem baixo nível de acessibilidade. Segundo Barbosa e Silva [6], a acessibilidade também é considerada um critério da qualidade de uso, que atribui igual importância às pessoas com e sem limitações nas capacidades de movimento, percepção, cognição e de aprendizado, e por este motivo, a acessibilidade foi observada neste trabalho. No entanto, devido aos aplicativos avaliados serem aplicações comerciais com respectivos direitos autorais, a aplicação de melhorias de usabilidade e acessibilidade constatadas no estudo para este trabalho foram incorporados na apresentação de uma proposta de aplicativo de mobilidade voltado a usuários deficientes visuais. Desta forma, os

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IHC'16, Brazilian Symposium on Human Factors in Computing Systems. October 4-7, 2016, São Paulo, SP, Brazil. Copyright 2016 SBC. ISBN XXX-XX- XXXX-XXX- X (online).

usuários com este perfil poderiam compartilhar a experiência de uso de um aplicativo que também poderia atender a usuários sem tal deficiência, garantindo assim um tratamento sem distinção entre ambos os perfis.

PROCESSO DE AVALIAÇÃO O processo de avaliação é apresentado neste relatório utilizando-se os três métodos de avaliação escolhidos, descrevendo-se o planejamento das avaliações e, por fim, relatando-se o processo de avaliação e seus resultados. O planejamento do projeto das avaliações auxilia em sua produtividade e controle, considerando uma visão geral do processo aplicado, especialistas de usabilidade e público alvo. A etapa de planejamento se baseia no framework DECIDE [3] – os tópicos descritos a seguir baseiam-se em sua estrutura (o planejamento completo do projeto, assim como mais detalhes pode ser acessado em www.fei.edu.br/~plinio.aquino/competicaoIHC2016/).

Descrição de Objetivos Esta seção refere-se à determinação de objetivos que guiarão planejamento, execução e apresentação dos resultados desta pesquisa, conforme framework DECIDE [3]. • Avaliar a experiência subjetiva do usuário no uso de

aplicativos de apoio à mobilidade urbana, utilizando os aplicativos Waze e Google Maps;

• Realizar avaliações e testes de usabilidade utilizando-se métodos de inspeção e observação em conjunto, utilizando os métodos descritos a seguir, em conformidade com escopo estabelecido na Tabela 1:

1. Avaliação heurística (inspeção) 2. Avaliação de comunicabilidade (observação) 3. Teste de usabilidade (observação)

App iOS Android

Waze 1 e 2 (a) 1 e 3 (c) Google Maps 1 e 2 (b) X

Tabela 1 – Matriz com escopo de avaliações e análises

• Analisar o comportamento de um mesmo aplicativo em diferentes plataformas – Tabela 1 (a) e (c);

• Analisar diferenças entre aplicativos na mesma plataforma – Tabela 1 (a) e (b);

• Analisar e comparar resultados. Optou-se por não avaliar o aplicativo Google Maps na plataforma Android com o objetivo de diminuir o custo do processo de avaliação e levando-se em consideração que o aplicativo possui múltiplos objetivos, rotas a pé, transporte público etc., enquanto que o Waze apenas apresenta rotas para automóveis.

Perguntas a Serem Respondidas Nesta seção exploram-se as perguntas a serem respondidas com as avaliações realizadas, tais perguntas têm como objetivo guiar a operacionalização da investigação e o julgamento de valor a ser realizados DECIDE [3]. • Quais problemas de usabilidade são apresentados por

cada um dos aplicativos?

• Há signos que geram confusão nos aplicativos? • Quais rupturas de comunicação são mais frequentes? • De que maneira os usuários usam o aplicativo? • Os usuários sentem-se confortáveis e confiantes ao

utilizar a interface? • Os usuários abandonam a interface quando não

conseguem realizar alguma tarefa? • Os usuários cometem erros? Com qual frequência? Eles

conseguem se recuperar? • Os usuários sentem-se inseguros, com medo de

"estragar" algo nos aplicativos? • Existem problemas de IHC que impedem ou dificultam

os usuários alcançarem seus objetivos? Com que frequência ocorrem? Qual é a gravidade deles?

• Os usuários conseguem se lembrar facilmente dos comandos utilizados?

JUSTIFICATIVA DA ESCOLHA DOS MÉTODOS Em sistemas interativos os problemas costumam ocorrer, principalmente, na obtenção, interpretação, processamento e compartilhamento de dados entre os stakeholders, mas também se revelam na fase de implementação[6], onde, por exemplo, um programador insere comportamentos não projetado no sistema. Selecionou-se para a avaliação três métodos: avaliação heurística, avaliação de comunicabilidade – com o uso de etiquetas de comunicação – e teste de usabilidade. Estes métodos foram escolhidos considerando-se: objetivo da avaliação, experiência dos avaliadores e questões práticas de avaliação. Dada a natureza distinta e complementar dos métodos citados, acredita-se que avaliações por inspeção e observação unidas gerem um resultado mais rico, sob diferentes perspectivas: visão do especialista e do usuário com acompanhamento de especialistas. As avaliações em contexto foram realizadas em diferentes roteiros pois os avaliadores consideram que as diferentes características das rotas contribuem para aumentar a quantidade de possíveis problemas enfrentados pelos usuários. Conforme demonstrado na Tabela 1, decidiu-se não avaliar o aplicativo Google Maps na plataforma Android, uma vez que as outras avaliações e dimensões desejadas para análise já atendem aos objetivos e critérios estabelecidos para esta pesquisa, outrossim, a decisão foi tomada de modo a auxiliar na redução de custos das avaliações. A Tabela 2 apresenta as plataformas consideradas nos testes.

Marca Modelo S.O. Firmware

Apple iPhone 6S (MKRG2LL/A) iOS 9.3.2 1.60.00

Asus ZenFone 2 Laser (ZE550KL)

Android 5.0.2 1.17.40.1531

Tabela 2 – Descrição de plataformas utilizadas Considerar duas plataformas representativas no mercado é importante, pois podem existir falhas e inconsistências diferentes em diferentes plataformas.

A Tabela 3, por sua vez, apresenta os aplicativos utilizados para os testes e análises com suas respectivas versões. Por haver a possibilidade dos aplicativos ou plataformas sofrerem atualizações que podem melhorar ou piorar sua usabilidade e acessibilidade, documentou-se as versões dos aplicativos e plataformas usados. Deste modo, garante-se também a reprodutibilidade de testes e análises feitos.

Nome Desenvolvedor Versão/Release S.O.

Waze Google 4.6.0.0 iOS Google Maps Google 4.18.81882 iOS

Waze Google 4.2.0.1 Android Tabela 3 – Lista de aplicativos utilizados nas avaliações

DESCRIÇÃO DOS MÉTODOS ESCOLHIDOS Nesta seção apresenta-se uma breve descrição dos três métodos de avaliação escolhidos, que ajudarão a responder as perguntas e objetivos já citados, considerando o grau de conhecimento, prazo, orçamento, entre outros recursos disponíveis para esta pesquisa DECIDE [3]. Avaliação por heurísticas de Nielsen A base deste método é um conjunto de diretrizes de usabilidade (heurísticas), descrevendo as características desejadas da interface e da interação. Neste trabalho, levou-se em consideração as 10 heurísticas propostas por Nielsen [2] para a condução da avaliação. Avaliação de comunicabilidade Este método avalia a recepção da mensagem pelos usuários do sistema, através de situações e problemas reais durante a realização de atividades. O foco de avaliação baseia-se na interpretação dos usuários, rupturas de comunicação e intenções de comunicação dos usuários.

Teste de usabilidade Assim como a avaliação de comunicabilidade, o teste de usabilidade é um método de observação. Este método consiste na avaliação de um sistema interativo analisando sua utilização por usuários identificados como integrantes do público alvo, levando em consideração metas de usabilidade. AVALIAÇÃO POR HEURÍSTICAS DE NIELSEN O esquema para documentação das violações encontradas utilizando o método de heurísticas, fornecido na Tabela 4, leva em consideração a natureza do problema, perspectiva da tarefa e perspectiva do usuário [7]. Para a natureza do problema existem três categorias: ruído (o usuário tem uma diminuição do seu desempenho em uma tarefa devido a um problema), obstáculo (usuário encontra dificuldade em realizar a tarefa algumas vezes devido a um problema, mas acaba aprendendo a superá-lo), barreira (o problema impede o usuário de realizar a tarefa). Quanto à perspectiva da tarefa, um problema secundário atrapalha o usuário a realizar tarefas de menor importância e frequência, enquanto que um problema primário impacta diretamente na realização de

tarefas importantes. Da perspectiva do usuário, problema especial atrapalha usuários com necessidades especiais, problema preliminar atrapalha usuários iniciantes ou infrequentes e problema geral atrapalha todos os tipos de usuários. Para a plataforma iOS a avaliação foi realizada apenas em laboratório e para a plataforma Android, adicionalmente, em contexto. Uma rota partindo da R. Professor Sylvio Marcondes Machado, localizado na Zona Norte da cidade de São Paulo, e a R. José Francisco de Freitas, na Zona Sul da mesma cidade, foi percorrida passando por ruas pouco movimentadas e de baixa velocidade, por avenidas e por vias expressas (como as Marginais Tietê e Pinheiros). A escolha desta rota foi para evidenciar comportamentos de interface que possam estar relacionados ao trânsito e velocidade média/máxima das vias transitadas. As violações foram documentadas utilizando-se o esquema apresentado na Tabela 4. As violações encontradas e suas classificações são apresentadas neste artigo de modo resumido:

<nome da heurística> Verificação: <perguntas objetivas para verificação da heurística>

Grau de Severidade: ( ) 0 - Sem importância ( ) 1 - Cosmético ( ) 2 - Simples ( ) 3 - Grave ( ) 4 - Catastrófico

Natureza do problema: ( ) Ruído ( ) Obstáculo ( ) Barreira

Perspectiva da tarefa: ( ) Problema Secundário ( ) Problema Principal

Perspectiva do usuário: ( )Problema Especial ( )Problema Preliminar ( ) Problema Geral Descrição do Problema: <descrição sucinta do problema encontrado>

Contexto: <contexto em que o problema foi encontrado>

Efeito sobre o usuário: <efeito sobre o usuário causado pelo problema> Efeito sobre a tarefa: <efeito sobre a tarefa causado pelo problema> Recomendação: <proposta de re-design para mitigar ou corrigir o problema>

Tabela 4 - Esquema para avaliação por heurísticas de Nielsen

AVALIAÇÃO DE COMUNICABILIDADE O modelo de processo de avaliação de comunicabilidade [1][4][5] a ser seguido baseou-se no diagrama da Figura 1. O diagrama apresentado utiliza a Business Process Modeling Notation (BPMn) [14], e foi modelado como ferramenta de suporte ao entendimento do método e suas etapas. O método

prevê que o especialista avalie os vídeos dos testes e atribua etiquetas nas rupturas de comunicação. Neste projeto, a equipe propõe que o usuário participante do teste seja treinado nas etiquetas, de tal forma, que este tente manifestar as rupturas com as etiquetas correspondentes. No final do teste o usuário participa da sessão de revisão do vídeo ajudando o especialista na correta atribuição das etiquetas. As etiquetas da Figura 2 foram utilizadas para identificar e documentar as rupturas de comunicação durante o uso dos aplicativos.

“CADÊ?” “E AGORA?” “O QUE É ISTO?” “EPA!” “ONDE ESTOU?” “UÉ, O QUE HOUVE?” “POR QUE NÃO FUNCIONA?”

“ASSIM NÃO DÁ.” “VAI DE OUTRO JEITO.”

“NÃO, OBRIGADO!” “PRA MIM ESTÁ BOM.”

“SOCORRO!” “DESISTO”

Figura 2 – Etiquetas utilizadas na Avaliação de Comunicabilidade

As avaliações seguiram três macro etapas: aplicação de questionário pré-teste, avaliação em contexto de uso, e aplicação de questionário pós-teste. As macro etapas foram executadas considerando critérios éticos na recepção e envolvimento dos usuários nos testes (descrito em detalhes posteriormente neste artigo). A seguir são descritos resumo de protocolo, roteiros de avaliação e solicitações realizadas durante o procedimento: Protocolo: Antes do início, os participantes foram informados sobre os procedimentos, assinaram o termo de consentimento livre e esclarecido, e preencheram o questionário pré-teste. O questionário pré-teste busca

identificar o perfil dos participantes e sua familiaridade com tecnologia e o sistema sob avaliação. Na sequência, os roteiros foram executados pelos usuários mediante observação dos especialistas. Roteiro A - Sair do ponto de Partida (Rua Tibães, 502, Jd. São Bento, São Paulo, SP) e chegar ao ponto de destino (Rua Maestro Antão Fernantes, 415, Jd. São Bento, São Paulo, SP) Trajeto: 1,5km – Tempo Estimado: 3-5 minutos Roteiro B - Sair do ponto de Partida (Rua Maestro Antão Fernantes, 415, Jd. São Bento, São Paulo, SP), passar pelo ponto intermediário (Rua Padre Ângelo Siqueira, 160, Jd. São Bento, São Paulo, SP) e chegar ao ponto de destino (Rua Tibães, 502, Jd. São Bento, São Paulo, SP) Trajeto: 1,1km – Tempo Estimado: 3-4 minutos Roteiro C - Sair do ponto de Partida (Rua Tibães, 502, Jd. São Bento, São Paulo, SP), passar pelo ponto intermediário (Rua Frei Mauro Teixeira, 222, Jd. São Bento, São Paulo, SP), passar por outro ponto intermediário (Rua Padre Ângelo Siqueira, 160, Jd. São Bento, São Paulo, SP) e chegar ao ponto de destino (Rua Maestro Antão Fernantes, 415, Jd. São Bento, São Paulo, SP) Trajeto: 2,2km – Tempo Estimado: 5-7 minutos Solicitações: Durante o teste, o avaliador instruiu os usuários a fazerem ao menos dois desvios da rota calculada e realizarem o aviso de trânsito no aplicativo. Finalizadas as avaliações, aplicou-se o questionário pós-teste para levantamento de informações sobre a experiência

Figura 1 – Processo de avaliação de comunicabilidade descrito em notação BPMn – Business Process Modeling Notation[14] Fonte: Desenvolvido pelos autores

subjetiva do usuário durante o uso dos aplicativos e realização dos roteiros de teste/avaliação.

TESTE DE USABILIDADE Para o teste de usabilidade, três metas de usabilidade [2] foram consideradas: • Segurança no uso (safety) – os usuários utilizam os

sistemas avaliados, geralmente, enquanto dirigem e problemas de interação e na interface podem colocar a vida desses usuários em risco.

• Facilidade de memorização – o contexto de uso exige uma alta carga cognitiva (atenção ao trânsito, pedestres, leis de trânsito etc.), portanto o uso do sistema deve ser intuitivo, sem necessidade de o usuário ter que aprender a cada uso como realizar a mesma tarefa. Uma vez aprendida, este deverá ser capaz de se lembrar com facilidade, realizando o mínimo esforço cognitivo.

• Satisfação do usuário – os usuários não devem sentir impactos negativos em suas emoções e sentimentos em decorrência da utilização dos sistemas avaliados.

Os testes de usabilidade também foram realizados em três etapas, assim como na avaliação de comunicabilidade, sendo estas: aplicação de questionário pré-teste, teste em contexto de uso e aplicação de questionário pós-teste. Protocolo: Antes do início, os participantes foram informados sobre como ocorreria o teste e assinaram o termo de consentimento livre e esclarecido, preencheram o questionário pré-teste e executaram os roteiros de teste. Roteiro A – Sair do ponto de partida (Rua Augusto Perroni, 249, São Paulo, SP) e chegar ao ponto de destino (Rua Pirajussara, 530, São Paulo, SP). Trajeto: 2km – Tempo Estimado: 4-6 minutos. Roteiro B – Sair do ponto de partida (Rua Pirajussara, 530, São Paulo, SP) e chegar ao ponto de destino no Estacionamento do Shopping Villa Lobos (Avenida das Nações Unidas, 4777, São Paulo, SP). Trajeto: 4km – Tempo Estimado: 8-12 minutos. Roteiro C – Sair do ponto de partida (Rua Augusto Perroni, 249, São Paulo, SP), passar por outro ponto intermediário (Rua Pirajussara, 530, São Paulo, SP) e chegar ao ponto de destino no Estacionamento do Shopping Villa Lobos (Avenida das Nações Unidas, 4777, São Paulo, SP). Trajeto: 6km – Tempo Estimado: 9-15 minutos. Solicitações: Durante o teste, o avaliador instruiu que os usuários fizessem rotas alternativas para evitar trânsito, declarando em voz alta pensamentos e tomadas de decisões. Após finalização dos testes, como feito na avaliação de comunicabilidade, foi aplicado um questionário pós-teste para levantamento de informações sobre a experiência subjetiva do usuário durante o uso dos aplicativos.

IDENTIFICAÇÃO DE QUESTÕES PRÁTICAS DAS AVALIAÇÕES / AMBIENTE DE TESTE Seguindo o framework DECIDE [3], identificou-se as questões práticas referentes ao processo de avaliação e detalhes sobre os ambientes de teste: Quantos usuários participarão das avaliações e testes? Entre dois e cinco usuários com perfil intermediário (excluindo iniciantes e especialistas), podendo um deles ser um dos avaliadores – desde que não seja especialista no uso dos aplicativos testados. Qual a preparação e equipamentos necessários? Possuir voluntários para os testes; Ter os documentos de consentimento, diretrizes do teste, questionários pré e pós teste prontos para resposta; O avaliador não deve dialogar com o usuário – apenas o observar; Usuário deve possuir habilitação e ter experiência para dirigir um veículo; Possuir carro com combustível; Possuir bateria do smartphone com carga acima de 95% no início de cada teste; Avaliador deve possuir material para anotação dos resultados do experimento. Qual o prazo? Para realização do experimento por cada voluntário: máximo 30 minutos Organização: 10 min. – Questionário pré-teste e termo consentimento 15 min. – Realização do experimento 5 min. – Questionário pós-teste Qual orçamento disponível? R$0,00 – sem orçamento disponível – custos bancados pelo avaliador Qual a mão-de-obra necessária para conduzir uma avaliação/um teste? Mínimo de duas pessoas – Avaliador e Usuário

DECISÕES SOBRE QUESTÕES ÉTICAS Como os experimentos envolveram seres humanos com observação e documentação das suas ações, os procedimentos foram realizados guardando estreita relação com a ética DECIDE [3], por meio da permissão prévia dos participantes, com assinatura do Termo de Consentimento Livre e Esclarecido (TCLE), seguindo os preceitos da norma 196/96 do Conselho Nacional de Saúde (CNS). Os seguintes tópicos foram considerados: • Aplicação do TCLE - os participantes somente poderiam

participar do teste após leitura e assinatura do TCLE; • Os dados coletados dos usuários não serão identificados; • Os usuários serão filmados para a extração de

informações para a avaliação – mas seus dados e vídeos serão mantidos em sigilo, não sendo publicados ou identificados. O material será descartado ao término da extração de informações relevantes;

• Os usuários não serão colocados em cenários de pressão ou risco no trânsito;

• Para os testes - durante a etapa prática, será usada via local em bairro residencial, com baixo nível de movimento. Se necessário, serão utilizados dias de semana menos movimentados, como sábado e domingo;

• Os usuários poderão desistir e parar a qualquer momento, declarando se desejam que seus dados sejam totalmente descartados;

• Será fornecido pronto atendimento médico, ou suporte da equipe para encaminhamentos, se necessário;

• Os usuários devem possuir convênio médico; • Os avaliadores não poderão obrigar os participantes a

realizar nenhuma tarefa; • Participantes que não possuam habilitação do tipo B não

poderão participar do teste, mesmo que saibam dirigir; • O resultado de qualquer teste poderá ser descartado sem

o consentimento dos participantes; • Os participantes do teste não interagirão entre si; • O avaliador não poderá ser responsabilizado por

condutas inadequadas dos participantes, mesmo quando sob a alegação de que tal conduta somente se revelou devido à realização do teste.

Todos os tópicos planejados quanto às questões éticas foram comunicados aos participantes do teste antes do início das atividades.

DADOS COLETADOS E RESULTADOS As avaliações foram conduzidas sem a interação do avaliador, que idealmente apenas deveriam observar o uso. A experiência foi filmada e seus resultados foram analisados a partir da extração dos dados e informações dos experimentos. Todas as avaliações e testes foram realizados com sucesso. As próximas seções apresentarão os dados coletados e resultados observados. Avaliação por heurísticas de Nielsen A avaliação por heurísticas foi realizada por dois especialistas, em sistemas operacionais distintos e fisicamente separados. Acreditou-se que ao realizar a avaliação deste modo, seria possível detectar mais violações, que poderiam ser identificadas por um e não identificadas por outro, nas plataformas mais utilizadas de smartphones: iOS e Android. Um especialista trabalhou com as aplicações Waze e Google Maps no sistema operacional iOS da Apple e o outro com o aplicativo Waze no sistema operacional Android do Google. Ambos possuem familiaridade com o método de avaliação, sistemas computacionais e facilidade para uso e manuseio dos smartphones e conhecimentos prévios sobre aplicativos avaliados. As avaliações foram feitas com base no seguinte planejamento: preparação, onde foram selecionadas partes da interface a serem avaliadas. No iOS avaliou-se as aplicações de modo integral. Já no Android, selecionou-se apenas telas relacionadas ao objetivo de cálculo de rota. Realizou-se, portanto, a coleta de dados pela inspeção das interfaces na busca de violações das heurísticas, interpretou-se os dados obtidos e estes foram consolidados como resultados obtidos por meio de listagem das heurísticas violadas, indicando para cada violação o local, gravidade, justificativa e recomendações de solução. Os resultados foram relatados utilizando-se o esquema previamente fornecido. A seguir serão descritos os resultados das

avaliações em cada caso, de modo resumido, dadas as restrições de espaço para este relatório. Para avaliar as violações em termos de gravidade, aplicou-se a seguinte escala: (0) Sem importância; (1) Cosmético; (2) Simples; (3) Grave; (4) Catastrófico. No universo das violações apresentadas na Tabela 5, considerando a avaliação na plataforma iOS, observou-se que no Waze, 39% das violações foram classificadas como Simples, 46% como Graves e 14% como Cosméticas. As Figuras 3, 4 e 5 ilustram algumas violações classificadas como grve durante a avaliação heurística.

Figura 3 - Violação grave da heurística “Compatibilidade com

o mundo real” no Aplicativo Waze para iOS

Já no aplicativo Google Maps, na plataforma iOS, foi possível observar uma distribuição diferente, sendo as violações, em 93% dos casos violações Graves e apenas 7% Simples.

Figura 4 - Exemplo de violação grave da heurística “Controle do usuário e liberdade” no aplicativo Google Maps para iOS

Figura 5 – Violações graves da heurística “Reconhecimento ao

invés de lembrança” no aplicativo Waze para Android

Por sua vez, na Tabela 6 apresentam-se os resultados da avaliação heurística considerando apenas as funcionalidades e etapas diretamente envolvidas no cálculo de rota do aplicativo Waze na plataforma Android, conforme plano de testes descrito anteriormente.

Heurísticas/ Telas com violações Waze Google Maps

1.Visibilidade do status do Sistema 3 0 2.Compatibilidade do Sistema com o mundo real

10 17

3.Controle do usuário e liberdade 4 3 4.Consistência e padrões 8 23 5.Prevenção de erros 0 0 6.Reconhecimento ao invés de lembrança

3 0

7.Flexibilidade e eficiência de uso 0 0 8.Estética e design minimalista 0 0 9. Auxiliar os usuários a reconhecer, diagnosticar e corrigir erros

0 0

10.Ajuda e documentação 0 0 Total de telas com violações 28 43

Tabela 5 - Resultado da Avaliação Heurística no iOS

Decidiu-se reduzir o escopo desta avaliação para filtrar apenas as violações encontradas no objetivo central do aplicativo: o cálculo de rotas. Neste universo de violações apresentadas, observou-se que 62,5% das violações foram classificadas como Simples e 37,5% como Graves.

Heurísticas/ Telas com violações Waze 1.Visibilidade do status do Sistema 0 2.Compatibilidade do Sistema com o mundo real 2 3.Controle do usuário e liberdade 1 4.Consistência e padrões 1 5.Prevenção de erros 0 6.Reconhecimento ao invés de lembrança 1 7.Flexibilidade e eficiência de uso 1 8.Estética e design minimalista 1 9. Auxiliar os usuários a reconhecer, diagnosticar e corrigir erros

1

10.Ajuda e documentação 0 Total de telas com violações 8

Tabela 6 - Resultado da Avaliação Heurística no Android

Comparativamente, ao filtrar-se as avaliações realizadas em iOS com base no escopo das avaliações feitas em Android, verificou-se que o número de violações se manteve idêntico. Houve pouca variação (ordem de 5%) apenas em sua distribuição e classificação, como poderia se esperar, pois esse tipo de avaliação possui envolvimento de especialistas com perfis que podem variar, além de envolver a subjetividade de interpretação de cada pessoa. Em suma, mesmo reduzindo o escopo de avaliação heurística, ainda assim foi possível observar que as violações encontradas são principalmente de natureza grave e simples.

A partir da observação dos resultados obtidos das avaliações, considera-se que houve elevado número de violações encontradas consideradas como graves, evidenciando problemas de usabilidade que não podem ser ignorados e que exigem ajustes imediatos para evitar rupturas de comunicação frequentes, dado que há muitos problemas de usabilidade nas telas mais usadas dos aplicativos - e.g. a tela de início, busca de rotas, tela para estimar tempo de chegada em diferentes horários, menus de ajuda e configuração, entre outros. Os resultados completos do teste serão fornecidos no link do projeto declarado no final do relatório.

Avaliação de comunicabilidade Como resultado da avaliação de comunicabilidade, serão apresentadas, de modo consolidado, as informações obtidas no questionários pré-teste/pós-teste, além das informações coletadas durante a execução da avaliação. Questionários pré-teste Analisando o perfil dos 10 participantes da avaliação, pode-se dizer que possuem em média entre 20 e 30 anos, ensino superior incompleto, não trabalham formalmente na área de TI, avaliam ter bom conhecimento em computação, já usaram smartphones, não possuindo dificuldades em seu uso. Também relataram terem usado, com uma frequência de uso média, aplicativos de cálculo de rotas como Google Maps e Waze. Suas maiores reclamações sobre os aplicativos giram em torno de falta de agilidade para uso, rotas erradas ou demoradas, pouca praticidade da interface, falta de suporte off-line simplificado e muita publicidade (esta, mais especificamente no Waze, que atrapalha seu uso). O objetivo geral dos participantes ao usar estes aplicativos, segundo seus relatos, é a busca por melhores trajetos para fugirem do trânsito. Resultados da avaliação de comunicabilidade A seguir serão descritos de modo resumido, dadas as restrições de espaço, os resultados observados durante as avaliações com os três participantes mais relevantes quanto a contribuição de feedback, separando os comentários por aplicativo. Participante 1 Aplicativo: Waze Problemas encontrados: 26 Etiquetas mais usadas: “Cadê?”, “Onde estou?” e “Desisto”

Aplicativo: Google Maps Problemas encontrados: 12 Etiquetas mais usadas: “Ué, o que houve?” e “Para mim está bom”

Participante 2 Aplicativo: Waze Problemas encontrados: 20 Etiquetas mais usadas: “Cadê?” e “O que é isto?”

Aplicativo: Google Maps Problemas encontrados: 14 Etiquetas mais usadas: “Ué, o que houve?” e “Assim não dá”

Participante 3 Aplicativo: Waze Problemas encontrados: 16 Etiquetas mais usadas: “Cadê?”, “Ué, o que houve?” e “Não, obrigado.”

Aplicativo: Google Maps Problemas encontrados: 7 Etiquetas mais usadas: “Ué, o que houve?” e “Por que não funciona?”

Com esses resultados pode-se verificar que é comum a utilização de etiquetas como “Ué, o que houve?”, além do alto número de problemas encontrados por cada usuário durante a execução dos cenários. Será documentado a seguir os problemas mais críticos encontrados no Waze: Aplicativo forneceu rota, mas notificações sobre

entradas à direita/esquerda ocorreram muito próximo da manobra, fazendo o motorista perder a entrada;

Rota encontrada, mas ao iniciar a navegação o aplicativo parou de exibi-la (rota sumiu);

Carregamento de rota diferente da solicitada pelo usuário;

Localização incorreta no mapa; Fornecimento de rota com mais trânsito; Falta de recálculo de rota ao sair da rota traçada.

Durante as avaliações, todas as etiquetas foram usadas no aplicativo. A seguir, serão fornecidos alguns exemplos de telas onde as etiquetas foram identificadas, sendo estas utilizadas durante o uso do aplicativo em alguma ocorrência dinâmica ou mudança de estado da aplicação. Procurou-se fornecer a seguir situações estáticas, onde ocorreu o uso das etiquetas e sua documentação foi possível. Na tela abaixo (Figura 6), os usuários relataram dificuldade em encontrar o local para adição de rotas e onde inserir os pontos intermediários de parada. Os signos utilizados não fornecem o entendimento necessário para que o usuário realize as ações esperadas, como busca de rota, por exemplo. Na tela da Figura 6, não fica claro onde se pode buscar o endereço ou até inserir um ponto intermediário de parada na rota calculada. Os pontos marcados em vermelho são os pontos cujos signos dificultam os usuários a atingirem seus objetivos. Telas com repentinas mensagens de erro contendo descrições incoerentes, sem sentido ou com pouco conteúdo explicativo são recorrentes na aplicação Waze. Em casos como este, os usuários avaliados utilizaram etiquetas como “Epa!”, “Onde estou?” e “Ué, o que houve?”. Telas sem títulos e descrições também são recorrentes, pois durante as avaliações heurísticas encontrou-se diversas telas com estes problemas (e.g. Figura 8). Na avaliação de comunicabilidade, os usuários em geral sentiam-se perdidos no uso da aplicação Waze, fazendo uso das etiquetas “Onde estou?”, “Socorro!” e “Ué, o que houve?”, por não saberem o que fazer nem como agir. Em alguns casos, pensaram que eles mesmos tinham gerado algum problema na aplicação.

Figura 6 - Etiquetas usadas - Cadê? O que é isto?

A Figura 7 e a Figura 8 ilustram ocorrências no sistema operacional iOS que causaram grandes dificuldades aos usuários.

Figura 7 - Etiqueta usada –

Epa! Figura 8 - Etiquetas usadas

– Ué, o que houve? Onde estou?

Em outros casos, verificou-se a existência de vias sem nome ou com nome diferente do que constava na placa da rua, o que pode gerar desconfiança nos usuários do aplicativo (Figura 9). Em casos similares, foram usadas etiquetas como “Assim não dá” e “Onde estou?”, conforme ilustrado na Figura 10. Verificou-se que os problemas críticos mais encontrados no Google Maps foram: Aplicativo deu aviso sonoro para virar à esquerda, mas

o mapa mostrava a rota para a direita; Não avisou usuário da chegada e recalculou a rota; Falta de recálculo de rota ao sair da rota original; Ao chegar na primeira parada o aplicativo não

continuou a rota, apagando tudo; Não é possível adicionar mais de 1 ponto de parada,

embora pareça que é possível.

Durante as avaliações utilizando o Google Maps, todas as etiquetas também foram utilizadas e alguns exemplos documentados neste relatório.

Figura 9 - Etiquetas usadas – Onde estou? Assim não

dá!

Figura 10 - Etiquetas usadas

– Onde estou? Cadê?

Na Figura 11, verifica-se que foi utilizada a etiqueta “Cadê?”, pois os usuários ficaram confusos na busca por algum elemento de interface para inserir a rota. Neste ponto, os usuários declaram que desejaram inserir a rota, porém, não reconheceram o signo (elemento gráfico), que deveria comunicar-se como elemento para entrada da rota.

Figura 11 - Etiqueta usada –Cadê?

No local onde a pessoa deveria pesquisar o endereço, é exibido pela aplicação a mensagem: “Pesquise restaurantes, cafés”, o que induziu os usuários ao erro considerando como o objetivo inicial consultar e calcular uma rota para algum endereço específico.

A utilização de signos com significados incompatíveis com a funcionalidade que executam é recorrente na aplicação. Houve mistura de idiomas em diversas telas. O aplicativo foi configurado em Português Brasileiro. Este foi um problema recorrente e comum no Google Maps, identificado tanto durante as avaliações de comunicabilidade como durante as avaliações por heurísticas. Questionários pós-teste Percebeu-se ao se analisar as respostas dos questionários, que os participantes gostariam de usar os aplicativos Waze e Google Maps com maior frequência, mas declararam que os consideram desnecessariamente complexos, embora tenham dito não acreditarem ser necessário apoio técnico ou treinamento para sua utilização. Os participantes responderam que consideram os sistemas muito inconsistentes, relatando dificuldades no uso de ambos os aplicativos. As interfaces de ambos os aplicativos em geral, agradaram os participantes que sentiram relativa facilidade em seguir as rotas, embora acreditem que não seja tão fácil, mas também não tão complicado aprender a usá-los. As melhorias mais indicadas para solução dos problemas encontrados e em maior parte comuns à ambos aplicativos envolvem: Correção dos mecanismos de adição de pontos de

parada; Ajuste nos alertas fornecidos – avisar com maior

antecedência para evitar acidentes e desvios de percurso;

Corrigir signos que se repetem ao longo das plataformas com significados e funcionalidades incompatíveis ou que por vezes são utilizados os mesmos signos para funcionalidades distintas, induzindo usuários a erro em ambos os casos;

Eliminação de textos muito longos e remoção de abreviações para melhorar legibilidade e compreensão, podendo até utilizar signos no lugar dos textos abreviados;

Correção de problemas e travamentos envolvendo cálculo e recálculo de rotas;

Melhorias em algoritmo para traçar rotas com menor fluxo de trânsito e menor distância;

Correção de problema que impede os usuários de saberem se chegaram no local através do aprimoramento dos mecanismos de localização;

Melhoria em velocidade de processamento; Melhoria nos resultados de endereços buscados -

muitas vezes não aparecem informações suficientes e ruas com mesmo nome podem ser selecionadas levando o usuário a outro destino diferente do desejado;

Melhoria e ampliação de sistemas e opções de ajuda para esclarecimento de dúvidas ao longo da aplicação;

Diminuição de quantidade e aumento de assertividade em diálogos e alertas de áudio ao longo de ambas aplicações;

Melhorias em suporte off-line dos aplicativos –mediante ausência de internet, não ocorre recálculo de rota em caso de desvios;

Teste de usabilidade O teste de usabilidade será apresentado neste relatório considerando a consolidação das informações obtidas do questionário pré-teste e pós-teste, além dos resultados observados e documentados da execução do protocolo de teste. Questionários pré-teste O questionário pré-teste busca identificar o perfil dos participantes. Com base nas perguntas realizadas, identifica-se que os 2 participantes possuem entre 20 e 30 anos, mesma faixa etária trabalhada nas avaliações de comunicabilidade, possuem nível de graduação completo, bons conhecimentos em computação, utilizam smartphones com boa frequência e utilizam aplicativos de roteirização, citando como exemplo, em ambos os casos, o aplicativo Waze. Mencionaram em suas respostas que utilizam os aplicativos para cálculo de rotas enquanto dirigem e que também utilizam e tem familiaridade com o Google Maps. Resultados do teste de usabilidade Os resultados do teste de usabilidade são apresentados de maneira consolidada, indicando as dificuldades encontradas e transcrevendo os comentários. Participante 1 Dificuldades encontradas: Nenhuma Comentário 1: “Não gosto do jeito que o aplicativo fica ocupando espaço no lugar das notificações. Mesmo depois que eu o fecho, ele fica ativo. De vez em quando, eu também fecho o aplicativo sem querer, quando tento voltar para ele. ” O comentário mostra que o usuário do Waze não consegue fechar a “notificação” fazendo o movimento de fechar, deslizando para os lados, como é padrão na plataforma. Também desliga a aplicação porque o controle de fechar está muito próximo do controle de abrir.

Figura 12 - Tela com marcação do problema relatado pelo

participante durante uso do Waze no sistema Android.

Ao se encerrar o aplicativo, é esperado pelos usuários que o mesmo isto ocorra como desejado e que não execute em segundo plano (background). Este problema não ocorre no ambiente iOS, entretanto, no ambiente Android, é recorrente e compromete atividades essenciais dos usuários. Embora fechado, não aparecendo mais no rol de aplicações abertas, continua aberto e funcionando, fornecendo informações, consumindo bateria, etc. Conforme ilustrado na Figura 12, somente quando o usuário acessa a área de notificações é que se descobre que ele ainda está rodando no smartphone. Somente nesta tela o aplicativo fornece o comando “Switch Off”. Não se trata de um problema de ocorrência isolada, no entanto, segundo os testes mostraram, esta é uma configuração padrão do aplicativo Waze no sistema Android. Comentário 2: “Às vezes tem umas rotas que não dá para confiar muito. Já tive outro caso em que uma rota sugerida não podia ser traçada. ” O usuário percebeu que a sinalização o impossibilitava de realizar a conversão à direita no horário em questão (Figura 13). O aplicativo não levou em consideração a sinalização da via, o que pode induzir os usuários do aplicativo a cometer infrações ocasionando multas e até acidentes.

Figura 13 - Exemplo de sinalização desrespeitada pela rota do

Waze no cruzamento das vias Av. Vital Brasil x R. Pirajussara.

Neste caso, o participante demonstrou desconfiança nas rotas traçadas pelo aplicativo e dividia bastante a atenção entre olhar para a tela do dispositivo e a sinalização da via. Participante 2 Dificuldades encontradas: 2 Comentário 1: “Eu não queria saber dos problemas na via, só as instruções por voz” Alguns avisos por voz, e.g. a existência de radar, são realizados apenas em contextos específicos. Para o radar, o

aviso por voz somente acontece quando o usuário está muito próximo ou acima do limite de velocidade da via informado pelo aplicativo, ocorrendo o aviso a 580m de distância do local do radar (Figura 14). O usuário pode estar a uma velocidade abaixo do limite e superá-lo nestes 580m, e não ser avisado sobre o radar. Outro ponto é a impossibilidade de escolher quais serão os tipos de notificação que se deseja receber. O usuário pode apenas optar por receber todas as instruções (rota e avisos), somente avisos ou nenhuma instrução por voz, não podendo selecionar somente a narração de rota.

Figura 14 - Exemplo de aviso de radar no sistema

Android.

Figura 15 - Diálogo de verificação de motorista ou

passageiro, no sistema Android.

Comentário 2: “Não me importo, sempre seleciono passageiro” O participante tentou colocar o ponto de parada, descrito no roteiro C, com o veículo em movimento. Uma notificação avisando que não poderia fazer a ação com o veículo em movimento apareceu, mas o participante assumiu o papel de passageiro e incluiu o destino mesmo assim (Figura 15). A prevenção do aplicativo não foi efetiva, pois exigiu uma carga cognitiva baixa para ser burlada. Seria ideal que houvesse algum desafio maior para que o aplicativo não fosse utilizado no modo de digitação quando o veículo estiver em movimento, exceto se comprovado que de fato o usuário não é o motorista. Caso isto não ocorra, o aplicativo deveria ser liberado apenas para uso pelo comando de voz, que já é fornecido. Questionários pós-teste Observou-se através dos questionários que os participantes em geral não se irritaram com o aplicativo, acreditam que os caminhos oferecidos sejam os melhores de fato, algo que se contrapõe aos resultados observados no ambiente iOS. Houve consenso sobre a não necessidade de ajuda ou de ser especialista na utilização do aplicativo Waze. Os

participantes sentiram facilidade no uso do aplicativo, algo que não foi observado na avaliação realizada no mesmo aplicativo no ambiente iOS, o que indica certa diferença/inconsistência de padrões entre os aplicativos em cada uma das plataformas. Recomenda-se para futuros estudos a realização de teste de usabilidade para o aplicativo Google Maps no sistema operacional Android, para complementar os resultados como ocorreu durante o teste de usabilidade com o aplicativo Waze no Android e a avaliação de comunicabilidade no iOS.

CONCLUSÕES E OBSERVAÇÕES Verificou-se que os métodos de avaliação utilizados são complementares uns aos outros, por ser possível observar diferentes nuances de cada um dos aplicativos em cada um dos contextos e cenários de avaliação. Durante esta pesquisa foram considerados, principalmente na avaliação e interpretação dos dados coletados o grau de confiabilidade dos dados, validade do estudo, entre outros aspectos tal como definido por DECIDE [3] no item avaliação. Concluiu-se que, conforme esperado, realizar avaliações de inspeção em conjunto com avaliações observacionais gera resultado mais rico quando comparado com a realização destas avaliações de modo isolado, pois detectou-se alguns problemas com métodos de avaliação de um tipo que não foram detectados com o uso de outros. Observou-se grande necessidade de melhoria nos signos utilizados em ambos aplicativos, e em versões de ambos sistemas operacionais. Na maior parte dos casos das avaliações heurísticas, foram encontrados problemas relacionados aos signos usados que geram dificuldade no uso, por não serem compatíveis com o mundo real ou por não seguirem padrões já existentes, símbolos que não condizem com a funcionalidade esperada e a mistura de idiomas (português/inglês), identificada em diversos pontos de ambas aplicações. Nas avaliações observacionais, verificou-se problemas de natureza funcional dos aplicativos, que diminuem seu grau de usabilidade para os usuários, problemas estes envolvidos principalmente com os algoritmos de cálculo de rotas, adição de pontos de parada/partida, mapeamentos e interface gráfica. Os aplicativos atendem aos usuários de forma relativamente satisfatória na maioria dos casos, mas questões importantes referentes a segurança devem ser levadas em consideração. Traçar rotas em vias proibidas ou impedidas devido ao horário e exibir limites de velocidade acima e/ou abaixo do limite real das vias nunca deveria acontecer. Durante as avaliações ficou perceptível a grande dependência da conexão com a internet, que pode impactar negativamente a experiência dos usuários. O cálculo de rotas leva um tempo muito alto quando a conexão é ruim ou o sinal está fraco. Oferecer este tipo de funcionalidade off-line poderia ser uma saída, como existe em outras aplicações do mesmo tipo, e.g. HERE. Recomenda-se a realização de testes adicionais voltados à engenharia de software – como testes caixa preta, para

levantamento de novos problemas funcionais e até aprofundamento e detalhamento de problemas já encontrados durante as análises de usabilidade realizadas. Estes testes, feitos pelos desenvolvedores dos aplicativos, também seriam úteis para a detecção de outros problemas funcionais fora do escopo deste trabalho, por considera-se importantes para realizar as correções e ajustes necessários nos aplicativos, que gerarão por consequência, aumento do nível de usabilidade das aplicações avaliadas/testadas. Idealmente, mais usuários devem ser submetidos às avaliações e testes para aumentar a validade e variedade dos resultados obtidos através de um aumento de amostragem. Ainda assim, embora tenham contado com poucos participantes foi possível detectar problemas de interação e interface significativos em ambos os aplicativos, concluindo-se que o objetivo deste trabalho foi atingido. Outra recomendação importante refere-se à ausência de requisitos de acessibilidade incorporado às interfaces analisadas. Uma pesquisa com usuários deficientes visuais, realizada pelos autores deste trabalho, constatou a utilização de outros aplicativos de mobilidade, além dos aplicativos avaliados (i.e. Moovit e CittaMob Acessibilidade), o que não ocorre quando o mesmo questionamento ocorre a usuários sem tal deficiência. Conforme mencionado na Introdução deste trabalho, será proposto um novo formato de aplicativos de mobilidade voltado à acessibilidade para usuários com deficiência visual como sugestão de usabilidade mais apropriada a estes usuários, assim como também alguns requisitos elicitados junto a usuários com tal deficiência. A publicação final do presente artigo fornecerá o link para acesso à uma seção anexa on-line que conterá todo o detalhamento dos resultados das avaliações de comunicabilidade e heurística, teste de usabilidade e maior detalhamento sobre o processo de desenvolvimento da proposta de aplicativo. O relatório completo e proposta de design é fornecido em http://www.fei.edu.br/~plinio.aquino/competicaoIHC2016/).

Experiência Técnica sobre a Capacidade dos Métodos Com o estudo aprofundado dos métodos e execução prática foi possível construir um parecer da equipe de avaliação sobre a capacidade de os métodos revelarem os aspectos de experiência de uso nos aplicativos. Constatou-se que os três métodos revelaram aspectos distintos da experiência de uso, conforme dito anteriormente. Acredita-se que o método de heurísticas de Nielsen [2] trabalhe mais o aspecto cognitivo dos usuários - a avaliação envolve o quê e como algo pode ser feito pelo usuário. Já os métodos observacionais de avaliação de comunicabilidade e teste de usabilidade, que guardam certas semelhanças entre si, avaliaram aspectos mais funcionais dos aplicativos, pois foi possível identificar não apenas problemas cognitivos gerados por signos inadequadamente usados, mas também foi possível observar problemas funcionais durante o uso, problemas estes que no método de inspeção usado não seriam detectados, por não fazerem parte do escopo de avaliação deste método.

Especificamente para o método de comunicabilidade adaptou-se o método original, considerando que o usuário realize a declaração de uma etiqueta durante o teste. Caso não ocorra durante o teste, a etiqueta é declarada (ou reconhecida) pelo usuário em uma seção pós-teste com acompanhamento do especialista. Essa alteração mostrou-se muito produtiva, pois diminui o tempo de interpretação de dados, visto que os vídeos não precisam ser assistidos completamente pelos especialistas. Adicionalmente, essa alteração no método permite que o especialista tenha a real percepção da ruptura de comunicação, pois o usuário participa do processo. Conclui-se que os três métodos usados possuem ampla capacidade de revelarem aspectos distintos da experiência de uso nos aplicativos, sendo que os resultados de cada método complementam uns aos outros. O conhecimento produzido com os testes de usabilidade, possibilitou a construção de conhecimento da equipe na composição de uma proposta de aplicativo de mobilidade que atenderia os aspectos de usabilidade e cidades inteligentes.

CONTRIBUIÇÃO FINAL: PROPOSTA DE APLICAVITO DE MOBILIDADE VOLTADO A ACESSIBILIDADE DE USUÁRIOS DEFICIENTES VISUAIS Motivadores Conforme mencionado anteriormente, os aplicativos avaliados neste trabalho não possuem grande foco no quesito acessibilidade, muito embora, este seja um aspecto da usabilidade. Quando analisados individualmente, o Waze prioriza percursos realizados com veículos particulares, não dando igual relevância às orientações de percurso considerando transportes públicos. Em contrapartida, o Google Maps fornece opções de transportes públicos, particulares, a pé ou de bicicletas, mas sua interface não é adaptada a deficientes visuais. É consensual entre os autores deste trabalho a concordância com a frase “País rico não é aquele que pobre anda de carro. É aquele que rico anda de transporte público” [9], pois os países desenvolvidos e considerados de vanguarda no conceito de Cidades Inteligentes, investem fortemente em transportes públicos eficazes e eficientes, oferecendo serviços de qualidade que até podem chegar a desestimular o uso pela população de veículos particulares no dia a dia. Uma análise complementar foi realizada em aplicativos voltados para usuários de transportes públicos, e durante o período em que estes foram analisados, observou-se orientações sobre o percurso até a parada de ônibus mais próxima do usuário; alternativas de percursos e linhas de ônibus que conduzirão o usuário ao local desejado, localização atual dos ônibus e respectivos horários de parada no local de embarque. Estes aplicativos informam até se os ônibus possuem sinal de internet sem fio e ar-condicionado, no entanto, nenhum deles informou se haviam plataformas de acesso para cadeirantes ou portadores de necessidades especiais. Do mesmo modo, os percursos a pé sugeridos para chegar no local de

embarque, não informavam a presença de degraus, buracos nas calçadas ou rampas de acesso. Considerando o volume de 6,5 milhões de brasileiros deficientes visuais [10], a precariedade com que este público geralmente é atendido e a falta de aplicativos que facilitem sua mobilidade e consequentemente sua inclusão social, constatou-se a que existe a possibilidade de atendê-los com um aplicativo dedicado às suas necessidades. Proposta Esta proposta trata de um aplicativo para smartphones cujo propósito é o de auxiliar na locomoção de pessoas deficientes visuais, de modo que estas tenham maior autonomia ao se locomover a pé ou por meio de transportes públicos de maneira independente, reduzindo ou isentando a atualmente necessária ajuda de familiares ou de terceiros que estejam próximos, que são abordados pelos usuários deficientes visuais solicitando que os avisem sobre a chegada do ônibus desejado e/ou que os ajudem na realização do embarque. A Figura 16 demonstra a tela inicial de carregamento do protótipo que possui também feedback auditivo sinalizando que o aplicativo está sendo carregado. A Figura 17 exibe a tela da tarefa principal, onde o usuário deverá indicar o endereço de destino.

Figura 16 - Tela inicial do protótipo do aplicativo em

Fluid UI

Figura 17 - Tela principal do protótipo do aplicativo

com interação via comando de voz em Fluid UI

Para ser possível minimizar esta dificuldade com relação ao aviso de aproximação dos ônibus, orientação até a porta de embarque e aviso de proximidade da parada de desembarque, partiu-se do pressuposto que estes meios de transporte disponham de mecanismos e sensores que possibilitem a identificação pelo aplicativo, para que ocorra o adequado fornecimento de orientações ao usuário. Este aplicativo teria sua usabilidade totalmente adaptada, possibilitando a total interação com o usuário, mitigando ao máximo a necessidade de digitação, e fornecendo instrução sobre os percursos, vias

de fácil acesso (quando estas existirem) e possíveis obstáculos nas vias. Embora tenha sido dado foco ao público deficiente visual, o aplicativo deverá ter interface visual tal como os aplicativos já existentes no mercado, pois pessoas com e sem limitações visuais possuem igual importância [11]. A comunicação entre aplicativo-usuário foi projetada para ocorrer por fala, visão e alertas vibratórios. Este último deve-se a necessidade de o aparelho corresponder a um smartphone, e em um país de elevada criminalidade, entende-se ser imprescindível as orientações ocorrerem através de semântica linguística de vibração do aparelho para a orientação ao longo do trajeto (e.g. vire à direita, ônibus se aproximando, desembarque na próxima parada). Outro motivo que justifica a vibração ao invés de uso de fones de ouvido pelo usuário é que tal dispositivo comprometeria e muito o sentido da audição do usuário, que é vital para o seu deslocamento e interação com o que ocorre a sua volta. No entanto, a correta compreensão desta semântica de linguagem dependerá que o aplicativo instrua o usuário com relação aos seus distintos significados. Já a comunicação usuário-aplicativo, deverá ocorrer por meio de fala, evitando assim o uso da digitação, sendo necessário que o aplicativo interprete adequadamente a fala do usuário e armazene padrões de fala e outros dados para ajudar na correta análise e compreensão dos dados inseridos.

Funcionamento O usuário deverá primeiramente cadastrar seu perfil no aplicativo, i.e. nome, e-mail, contato e telefone de responsável para acionamento em caso de emergência; também serão pedidos pontos de interesse, i.e. supermercados, restaurantes, e farmácias, e raio de distância aceitável entre usuário e ponto de interesse cadastrado para que ocorra a notificação sobre os mesmos (conforme Figura 18).

Figura 18 - Tela de acesso ao perfil e cadastro no protótipo

Tal como o aplicativo Google Maps, para iniciar o trajeto, o usuário deverá informar o local de destino desejado e o meio de transporte a ser utilizado. O aplicativo deverá instruir o usuário sobre o percurso, e em paralelo, mapeará por proximidade os pontos de interesse cadastrados, se estes corresponderem à distância máxima cadastrada pelo usuário. Mediante a identificação de um ponto de interesse, o usuário será questionado se deseja direcionar-se até este local. Caso o usuário opte por desviar-se do percurso original, o aplicativo deverá conduzi-lo ao ponto de interesse desejado e a retomada do percurso original ocorrerá assim que o aplicativo identificar a saída do usuário deste ponto (conforme Figura 19). Caso o usuário opte por não se direcionar até o ponto de interesse, as instruções referentes ao destino originalmente inserido pelo usuário continuarão a ser fornecidas.

Figura 19 - Tela de cadastramento e ativação de pontos de

interesse no protótipo. O aplicativo deverá notificar o usuário quando da chegada ao local de destino, com isso, seu uso será encerrado automaticamente, dado que isso não ocorre com os atuais aplicativos, ficando estes com funcionamento em background, conforme mencionado anteriormente neste trabalho. Protótipo O protótipo concebido respeita as heurísticas usadas para avaliação e incorporou também aprendizados obtidos durante o desenvolvimento deste artigo. Para o desenvolvimento do protótipo constante nesta proposta, utilizou-se a ferramenta Fluid UI [12], que permite o desenho de protótipos dinâmicos/navegáveis, assim como o fornecimento de link para compartilhamento e acesso à sua visualização.

Os protótipos gerados a partir da ferramenta em questão são considerados como sendo de média fidelidade, pois nem todas as funcionalidades previstas são passíveis de inserção na ferramenta para constarem no fluxo de navegação a ser exibido (e.g. alertas de interação com o usuário). Vale ressaltar que a ferramenta Fluid UI é uma ferramenta desenvolvida no idioma Inglês e infelizmente alguns objetos possuem suas literais em tal idioma, não sendo passíveis de tradução completa ou parcial no momento da prototipagem. Como exemplos, citam-se as telas de compartilhamento de localização e realização de chamada telefônica, exibidas na Figura 20 e na Figura 21. É importante ressaltar para a implementação deste aplicativo proposto, é recomendado que todos os objetos em tela possuam suas literais padronizados no idioma em que o aplicativo for desenvolvido, neste caso, Português Brasileiro, deste modo, respeitam-se padrões de usabilidade já discutidos ao longo do presente artigo. Dado o exposto, não se deve considerar que as telas apresentadas na Figura 20 e Figura 21 possuam violações de heurísticas de usabilidade por utilizarem o idioma Inglês.

Figura 20 – Tela de

compartilhamento de localização parcialmente em

Inglês com elementos padrão da ferramenta.

Figura 21 – Tela de

chamada telefônica padrão da ferramenta Fluid UI

completamente desenhada no idioma Inglês.

O protótipo foi concebido com base no design da plataforma iOS, embora possa ser estendido para Android e outras plataformas. Adotou-se as seguintes premissas para o protótipo:

1. A ativação da funcionalidade VoiceOver [13], que possui como funcionalidade a descrição falada de itens presentes na tela ao usuário;

2. O design do protótipo foi concebido com base no sistema iOS voltado para modelos iPhone 5 em diante.

O protótipo completo construído na ferramenta Fluid UI encontra-se disponível para acesso e navegação através do link reduzido a seguir: http://goo.gl/rWJbry Desta maneira, o ciclo de avaliação de usabilidade foi composto por três grandes fases: (a) estudo das teorias de IHC no contexto das aplicações mobile alvo desta avaliação, como por exemplo, análise competitiva, análise de perfil de usuário, análise de tarefas, modelagem de contexto de uso, MOLIC, entre outras técnicas e ferramentas; (b) processo de avaliação de duas aplicações em duas plataformas distintas; (c) produção de uma proposta de interface para o mesmo tipo de aplicação, usando o conhecimento adquirido nas fases (a) e (b). Como trabalho futuro, o resultado deste projeto será documentado no formato de padrões de interface de acordo com os perfis considerados [16], pois os padrões poderão ser utilizados na composição de novos projetos de interface ou para guiar avaliações baseadas em padrões. A execução deste projeto motivou o planejamento de testes de usabilidade usando sinais de EEG [15], considerando pesquisas que envolvem o fatores humanos e ergonomia do usuário em veículos [17, 18].

REFERÊNCIAS 1. Clarisse Sieckenius de Souza. The semiotic

engineering of human-computer interaction. MIT press, p.126-150, 2005;

2. Jakob Nielsen. Usability engineering. Elsevier, 1994; 3. Jenny Preece, Yvonne Rogers, Helen Sharp. Design de

interação. Bookman, 2005; 4. Raquel Oliveira Prates; Simone Diniz Junqueira

Barbosa. Introdução à teoria e prática da interação humano computador fundamentada na engenharia semiótica. Atualizações em informática, p. 263-326, 2007;

5. Raquel O. Prates, Clarisse S. De Souza, Simone D. J. Barbosa. Methods and tools: a method for evaluating the communicability of user interfaces. Interactions, v. 7, n. 1, p. 31-38, 2000;

6. Simone Diniz Junqueira Barbosa, Bruno Santana da Silva. Interação humano-computador. Elsevier, 2010.

7. Walter de Abreu Cybis. Engenharia de usabilidade: uma abordagem ergonômica. Florianópolis: Laboratório de utilizabilidade de informática, 2003. http://www.labiutil.inf.ufsc.br/hiperdocumento/unidade3_3_1_1.html;

8. Business Dictionary. Definição do termo “Smart City”. http://www.businessdictionary.com/definition/smart-city.html

9. Edu Petta, Carol Da Riva. País rico não é aquele que pobre anda de carro. É aquele que rico anda de transporte público. Jornal Estadão - Blogs http://blogs.estadao.com.br/aprendendo-no-mundo/pais-rico-nao-e-aquele-que-pobre-anda-de-carro-e-aquele-que-rico-anda-de-transporte-publico/

10. Portal Brasil. Braile aumenta inclusão de cegos na sociedade. http://www.brasil.gov.br/cidadania-e-justica/2015/01/braile-aumenta-inclusao-de-cegos-na-sociedade

11. Ministério da Saúde. Resolução nº 196/96 do Conselho Nacional de Saúde. http://conselho.saude.gov.br/web_comissoes/conep/aquivos/resolucoes/23_out_versao_final_196_ENCEP2012.pdf

12. Fuid UI. http://www.fuidui.com 13. Apple. Guia de acessibilidade de produtos Apple.

http://www.apple.com/br/accessibility/iOS 14. BPMn Quick Guide. BPMn online reference guide.

http://www.bpmnquickguide.com/view-bpmn-quick-guide/

15. Vagner do Amaral, Leonardo A. Ferreira, Plinio Thomaz Aquino Jr. and Maria Claudia Ferrari de Castro, EEG signal classification in usability experiments, Biosignals and Biorobotics Conference (BRC), 2013 ISSNIP, Rio de Janerio, 2013, pp. 1-5. doi: 10.1109/BRC.2013.6487469, URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6487469&isnumber=6487444

16. Plinio Thomaz Aquino Junior. PICaP : padrões e personas para expressão da diversidade de usuários no projeto de interação [doi:10.11606/T.3.2008.tde-15092008-144412]. São Paulo : Escola Politécnica, Universidade de São Paulo, 2008. Tese de Doutorado em Sistemas Digitais. [acesso 2016-09-01].

17. Edson Luciano Duque; Plinio Thomaz Aquino Junior. Human Factors and Ergonomics Using Anthropometric and sEMG Data in Automotive Gearshift Quality Analysis. In: Masaaki Kurosu - The Open University of Japan. (Org.). Lecture Notes in Computer Science. 1ed.Switzerland: Springer International Publishing, 2016, v. , p. 248-258.

18. Edson Luciano Duque; Plinio Thomaz Aquino Junior. Human factors analysis of manual gear shifting performance in passenger vehicles. In: 6th International Conference on Applied Human Factors and Ergonomics (AHFE 2015) and the Affiliated Conferences, AHFE 2015, 2015, Las Vegas, USA. Procedia Manufacturing - AHFE 2015, 2015. v. 1. p. 2048-2055.