UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação

UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação Aplicações para dispositivos móveis: Avaliação heurística e comunicação entre dispositivos William Pedrini Custódio [Nome do Aluno]

Aplicações para dispositivos móveis: Avaliação heurística e comunicação entre dispositivos William Pedrini Custódio Orientador: Maria da Graça Campos Pimentel Monografia de conclusão de curso apresentada ao Instituto de Ciências Matemáticas e de Computação ICMC-USP - para obtenção do título de Bacharel em Informática. Área de Concentração: Sistemas Web e Multimídia Interativos USP São Carlos Junho de 2013 1

"Toda a teoria deve ser feita para poder ser posta em prática, e toda a prática deve obedecer a uma teoria." Fernando Pessoa i

Agradecimentos À minha família, por sempre me incentivar nos estudos acima de tudo e darem apoio nos momentos difíceis. À minha companheira Carolina Tavares, por ter aceito se privar de minha companhia para que eu pudesse realizar este trabalho. Ao Diogo Pedrosa e ao Olibário J. M Neto, pelo apoio que me deram ao longo de todo o desenvolvimento dos projetos. A todos docentes e funcionários da Universidade de São Paulo, por fazerem desta universidade uma das melhores deste país. Aos meus amigos, pela companhia em todos estes anos da faculdade. ii

Resumo As atividades da disciplina Projeto de Graduação foram realizadas no contexto de dois trabalhos em andamento no grupo de Sistemas Web e Multimídia Interativos, e são identificadas ao longo da monografia por Projeto de Avaliação Heurística e por Projeto de Comunicação via Bluetooth. O Projeto de Avaliação Heurística foi dividido em duas partes distintas. A primeira envolve a comparação do conjunto das heurísticas propostas por Jakob Nielsen com as compiladas pelo mestrando Olibário J. Machado Neto como extensão do conjunto de Nielsen. A segunda envolve a organização e a generalização dos componentes originais das guidelines de usabilidade de interfaces associadas ao sistema operacional para dispositivos móveis ios. O Projeto de Comunicação via Bluetooth envolveu a extensão da comunicação via Bluetooth do protótipo BlueMorse, e foi realizado em colaboração com o doutorando Diogo Pedrosa, orientado pela mesma orientadora. Procurou-se melhorar a comunicação Bluetooth do protótipo, cuja implementação original não permitia mais que um dispositivo cliente se conectasse ao dispositivo servidor. Dessa maneira, estudou-se o código referente à comunicação Bluetooth, em busca de pontos a serem modificados para suprir essa carência, como resultado novos trechos de códigos foram gerados. São apresentados métodos, resultados alcançados, conclusão sobre o trabalho realizado e considerações sobre o curso de graduação. iii

Sumário CAPÍTULO 1: INTRODUÇÃO... 1 1.1. CONTEXTUALIZAÇÃO E MOTIVAÇÃO... 1 1.2. OBJETIVOS... 2 1.3. ORGANIZAÇÃO DO TRABALHO... 2 CAPÍTULO 2: EMBASAMENTO TEÓRICO... 3 2.1. CONSIDERAÇÕES INICIAIS... 3 2.2. PROJETO DE AVALIÇÃO HEURÍSTICA... 3 2.2.2 Guidelines... 3 2.2.2 Heurísticas... 5 2.3. PROJETO DE COMUNICAÇÃO VIA BLUETOOTH... 8 2.3.1. Android... 8 2.3.2. Android SDK... 8 2.3.2. Comunicação via Bluetooth... 9 2.3.3. CÓDIGO MORSE... 11 2.4. CONSIDERAÇÕES FINAIS... 12 CAPÍTULO 3: DESENVOLVIMENTO DO TRABALHO... 13 3.1. CONSIDERAÇÕES INICIAIS... 13 3.2. PROJETO DE AVALIÇÃO HEURÍSTICA... 13 3.2.1. DESCRIÇÃO DAS ATIVIDADES REALIZADAS... 13 3.2.1.1 AVALIAÇÕES HEURÍSTICAS... 13 3.2.1.2 ORGANIZAÇÃO DE GUIDELINES PARA IOS... 18 3.2.2. RESULTADOS OBTIDOS... 19 3.2.2.1 AVALIÇÕES HEURÍSTICAS... 19 iv

3.2.2.2 ORGANIZAÇÃO DOS GUIDELINES IOS... 20 3.3 PROJETO DE COMUNICAÇÃO VIA BLUETOOTH... 21 3.3.1. DESCRIÇÃO DAS ATIVIDADES REALIZADAS... 23 3.3.2. RESULTADOS OBTIDOS... 24 3.4. DIFICULDADES ENCONTRADAS... 26 3.5. CONSIDERAÇÕES FINAIS... 26 CAPÍTULO 4: CONCLUSÃO... 28 4.1. CONTRIBUIÇÕES... 28 4.2. CONSIDERAÇÕES SOBRE O CURSO DE GRADUAÇÃO... 29 REFERÊNCIAS... 30 v

CAPÍTULO 1: INTRODUÇÃO 1.1. CONTEXTUALIZAÇÃO E MOTIVAÇÃO A área de atuação na qual este trabalho se insere é Interação Usuário-Computador (IHC), devido à afinidade identificada ao cursar a disciplina de mesmo nome no segundo semestre do ano de 2010. Dessa maneira, procurou-se a docente Maria da Graça Campos Pimentel, que lecionou a disciplina naquela oportunidade, com a finalidade de solicitar sua orientação no projeto. Após reunião com a docente, definiu-se nova reunião na qual seriam determinados os trabalhos em que o aluno aturaria. Nela fizeram-se as apresentações dos mestrandos Olibário J. Machado Neto e Bruna Cunha, e do doutorando Diogo Pedrosa, juntamente com seus respectivos projetos e as possibilidades de atuações dentro de cada um. Para o projeto do mestrando Olibário J. Machado Neto havia as possibilidades de trabalhos com avaliações heurísticas e generalizações de guidelines de usabilidade para dispositivos móveis. No projeto de Bruna Cunha havia a possibilidade da contribuição no desenvolvimento do aplicativo de anotações multimídia. Por fim, no contexto do projeto de Diogo Pedrosa seria possível atuar na melhoria da comunicação Bluetooth do aplicativo BlueMorse. A partir das reuniões iniciais, desenvolveu-se o cronograma a ser seguido ao longo da disciplina de Projeto de Graduação I. Dentre as alternativas possíveis de atuação, aluno e orientadora optaram pela atuação no contexto dos trabalhos de Olibário J. Machado Neto e de Diogo Pedrosa. Assim, o trabalho na disciplina Projeto de Graduação foi estruturado em duas partes, uma para cada um dos projetos. A atuação no contexto do trabalho de Olibário J. Machado Neto foi motivada pelo ao fato de as atividades associadas permitirem a prática de métodos estudados na disciplina de IHC. Já a atuação no projeto de Diogo Pedrosa foi motivada pela oportunidade de adquirir conhecimento sobre o desenvolvimento de aplicativos para dispositivos móveis que possuem como base o sistema operacional Android. 1

1.2. OBJETIVOS Dividem-se os objetivos do Projeto de Graduação pelas atuações em cada um dos trabalhos. Foram dois os objetivos do trabalho realizado juntamente com Olibário J. Machado Neto. O primeiro objetivo é a realização de avaliações heurísticas em aplicativos para dispositivos móveis utilizando-se dois conjuntos de heurísticas: o conjunto originalmente por Jakob Nielsen, e o conjunto compilado pelo mestrando Olibário J. Machado Neto. O segundo objetivo é a generalização dos guidelines de design de aplicações para dispositivos móveis ios. O projeto realizado com Diogo de trabalho Pedrosa teve como objetivo a melhoria da comunicação Bluetooth do protótipo BlueMorse. 1.3. ORGANIZAÇÃO DO TRABALHO Cada um dos capítulos seguintes será dividido em duas partes, uma para cada projeto no qual o aluno atuou. Ao longo da monografia serão descritos os estudos realizados em cada um dos projetos, as atividades vinculadas a eles, os resultados obtidos, e, por fim, uma conclusão, que descreverá o que foi adquirido ao longo do Projeto de Graduação. 2

CAPÍTULO 2: EMBASAMENTO TEÓRICO 2.1. CONSIDERAÇÕES INICIAIS Este capítulo sumariza os estudos e as técnicas utilizadas para realizar as atividades relacionadas a cada um dos dois projetos no qual o aluno atuou. O primeiro projeto é referente às avaliações de usabilidade de interfaces de dispositivos móveis utilizando dois conjuntos de heurísticas. O conjunto tradicional de 10 heurísticas 1 proposto 2 por Nielsen 3 (Nielsen, 1994), e o conjunto para dispositivos móveis compilado por um aluno de mestrado da mesma orientadora, Olibário J. Machado Neto (Machado Neto, 2013), a partir do conjunto de Nielsen. Ainda no mesmo projeto, contribuiu-se na organização de diretrizes para guiar o desenvolvimento de aplicativos para dispositivos móveis ios, assim como na generalização dos nomes dos seus componentes. Para a identificação do primeiro projeto ao longo da monografia, é utilizado o termo Projeto de Avaliação Heurística. O segundo projeto envolve uma extensão do mecanismo de comunicação via Bluetooth do protótipo BlueMorse, trabalho esse realizado em conjunto com o doutorando Diogo Pedrosa, orientado pela mesma orientadora. Ao longo da monografia, identificaremos esse trabalho pelo nome Projeto de Comunicação via Bluetooth. 2.2. PROJETO DE AVALIÇÃO HEURÍSTICA 2.2.2 Guidelines Segundo Nielsen (1994), as avaliações de usabilidade devem ser realizadas juntamente com o desenvolvimento do produto, para que erros sejam detectados o mais cedo possível, simplificando as modificações necessárias no mesmo. Entretanto, na prática muitas vezes 1 http://www.nngroup.com/articles/ten-usability-heuristics 2 Nielsen, J. (1994b). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods, John Wiley & Sons, New York, NY. 3 A partir do trabalho conjunto com Rolf Molich (Rolf Molich & Jakob Nielsen. Improving a humancomputer dialogue. CACM 33, 3 (March 1990), 338-348. http://doi.acm.org/10.1145/77481.77486) 3

tornam-se difíceis de serem realizadas constantemente, inclusive pelo tempo demandado, sendo feitas usualmente na etapa final do projeto. Para melhorar a usabilidade de aplicações, foram propostas algumas regras de design de interfaces, as quais são denominadas guidelines ou diretrizes e que, quando seguidas, diminuem o número de erros de usabilidade. Guidelines de usabilidade são conjuntos de regras para o design de interfaces, que permitem que os envolvidos nesse processo de design tenham uma documentação para prevenir e corrigir erros de usabilidade que já são conhecidos por conta da experiência de outros envolvidos a priori ou com base em conhecimentos oriundos da Psicologia (Preece et al., 1994). A Apple foi pioneira na publicação de guidelines para o design de aplicação de aplicações para seus produtos, que visavam tanto padronizar o look and feel das aplicações como facilitar sua usabilidade tanto no caso de design de novas para aplicações desktop de maneira geral 4, como para hipertextos criados com a aplicação Hypercard 5. Esse exemplo foi seguido por outros fabricantes, como por exemplo para aplicações Java 6 e, mais recentemente, para aplicações Android 7. Dado que esforços de fabricantes e de pesquisadores deram origem a um grande número de guidelines de usabilidade, houve a demanda pela compilação dessas diretrizes. Por exemplo, em 1986 Smith & Moser 8 produziram uma relação com 944 diretrizes, compiladas a partir da literatura da época. Apesar de datarem dos anos 80, a maioria continua válida, como observado por Nielsen. 9 Organizadas em categorias, dois exemplos de dessas diretrizes são: Certifique-se que todos os dados que um usuário precisa para qualquer transação estarão disponível para exibição, da categoria de Entrada de Dados, e 4 Apple Human Interface Guidelines: The Apple Desktop Interface. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1987 5 Apple Computer Inc.. 1989. Hypercard Stack Design Guidelines (1st ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA 6 Java Sun Microsystems, Inc and Javasoft. 1999. Java Look & Feel Design Guidelines (1st ed.). Addison- Wesley Longman Publishing Co., Inc., Boston, MA, USA 7 http://developer.android.com/guide/practices/ui_guidelines 8 http://hcibib.org/sam 9 http://www.nngroup.com/articles/durability-of-usability-guidelines 4

Projete procedimentos padronizados para a realização de transações similares e relacionadas logicamente, da categoria Orientação ao usuário. Especialistas atestam 10 que, ao utilizar guidelines, o número de erros de usabilidade em interfaces tendem a diminuir e muitos problemas básicos são evitados. Porém, mesmo utilizando esses conjuntos de regras para desenvolver o design de interfaces, erros de usabilidade continuam. Portanto, não sendo descartada a necessidade da utilização das avaliações de usabilidade. 2.2.2 Heurísticas Com o constante crescimento e desenvolvimento na área de dispositivos móveis, principalmente de smartphones, a diversidade de usuários tende a tornar-se cada vez maior. Dessa maneira, desenvolvedores de aplicativos voltados a esses dispositivos devem procurar atingir desde usuários não familiarizados até os mais experientes. Para que isso seja possível, deve-se focar na usabilidade no momento do desenvolvimento dos aplicativos, facilitando o aprendizado dos leigos e também agilizando atividades dos experientes. Segundo Bertini et al.(2006), o design de aplicações voltadas a dispositivos móveis possui grandes desafios desde sua criação até a avaliação de sua usabilidade. A avaliação utiliza métodos que são estudados há algum tempo no mundo da computação, porém sem um grande foco em dispositivos móveis. Um exemplo que podemos citar é o método de avaliação heurística (Nielsen, 1994), processo que não exige um grande tempo para ser feito e pode ser realizado em etapas iniciais do desenvolvimento do projeto e seu custo é baixo, tornando-se o mais utilizado para realizar a busca por erros de usabilidade. Esse processo envolve analisar as interfaces do sistema, identificar problemas de usabilidade e confrontá-los com um conjunto de recomendações, conhecidas como "heurísticas", com o intuito de identificar problemas de interface. Cinco especialistas geralmente encontram de setenta e cinco a oitenta por cento dos problemas (Nielsen, 1994). Contudo, o número não é uma imposição, tampouco um limitante superior. O método de avaliação heurística foi 10 http://www.nngroup.com/articles/usability-guidelines-change 5

criado por Jakob Nielsen, um dos principais estudiosos e pesquisadores da área de Interação Usuário-Computador, e faz uso de heurísticas de usabilidade (1994). Visando identificar se as heurísticas de Nielsen, sumarizadas na Tabela 1, eram deficientes na identificação de problemas de usabilidade em dispositivos móveis, Olibário J. Machado Neto realizou um experimento de inspeção em 4 aplicativos de dispositivos móveis populares, o qual identificou categorias de problemas de usabilidade que não eram consideradas nas heurísticas de Nielsen. Por conta disso, um conjunto de heurísticas específicas para a avaliação da interface desses dispositivos foi proposta por Machado Neto (Machado Neto, 2013), como extensão do conjunto de Nielsen. Esse conjunto estendido é listado na Tabela 2. Tabela 1. Conjunto de heurísticas de Jakob Nielsen (1994). Heurística Descrição 1. Visibilidade do status O usuário deve estar completamente informado do que está acontecendo, por do sistema meio de feedback imediato da interface. 2. Compatibilidade do A terminologia deve ser adequada à linguagem do usuário e não orientada ao sistema com o mundo real sistema. As informações devem ser organizadas de acordo com o modelo mental do usuário. Segundo Helander et al (1997), o modelo mental se refere à expectativa que um usuário possui em relação ao comportamento do computador. Disponibilize saídas de emergência ao usuário, para que ele possa desfazer ou refazer ações, a fim de que ele se situe em um ponto recente da interação. 3. Controle e liberdade do usuário 4. Consistência e padrões Nunca identifique uma mesma ação por ícones ou metáforas diferentes. Elementos similares devem ser usados para propósitos semelhantes, assim como funcionalidades semelhantes devem possuir uma sequência de ações semelhantes. 5. Prevenção de erros Idealmente, interfaces não precisam de mensagens de erro por serem capazes de prevenir que erros ocorram. Ações definitivas podem ter um tratamento anterior para que o usuário as confirme por meio de checkboxes, por exemplo. 6. Reconhecimento ao invés de lembrança 7. Flexibilidade e eficiência de uso 8. Estética e design minimalista 9. Ajudar o usuário a reconhecer, diagnosticar e corrigir erros O usuário não deve precisar memorizar o que está realizando. Permita que a interface atue como um meio de dialogar com o usuário, em tempo de execução. O sistema deve ser fácil de ser operado por usuários novatos, mas também robustos o suficiente para permitirem eficiência de uso a usuário avançados. Teclas de atalho e de comandos por voz podem ser alternativas para tornarem a interface flexível. Noutras palavras, flexibilidade implica em permitir que uma mesma funcionalidade seja realizada por comandos distintos. As informações devem ser sucintas e não devem informar mais do que os usuários necessitam para realizar a funcionalidade corrente. Os diálogos do sistema precisam ser diretos e naturais e devem aparecer nos momentos adequados. As mensagens de erros devem ser claras e simples e não podem intimidar o usuário. Ao contrário, deve estimular o usuário ao oferecer formas de corrigir o erro. 10. Ajuda e documentação Um bom design evita que o usuário tenha que usar opções de ajuda com frequência. Entretanto, é fundamental que o sistema possua telas específicas de ajuda, para orientar o usuário em casos de dúvidas. 6

Tabela 2. Extensão das heurísticas de Nielsen, por Machado Neto (2013). Heurística Descrição 1. Bom aproveitamento do Independentemente da orientação do dispositivo, o design deve ser espaço da tela realizado de forma que os itens não fiquem muito distantes, nem muito juntos. Elementos relacionados devem estar próximos e os sem relacionamento devem estar mais afastados. Interfaces não devem estar carregadas com muitos elementos. 2. Consistência e padrões da interface 3. Visibilidade e acesso fácil a toda informação existente 4. Adequação entre o componente e sua funcionalidade 5. Adequação de mensagem à funcionalidade e ao usuário 6. Prevenção de erros e retomada rápida ao último estado estável 7. Facilidade de entrada de dados 8. Feedback imediato e fácil de ser notado A aplicação deve manter os componentes no mesmo lugar e na mesma configuração ao longo de toda a interação, para facilitar a aprendizagem. Funcionalidades análogas devem possuir interações análogas, por meio de atividades parecidas. As características de cada componente (seu tamanho, fonte, cor, etc.) devem permanecer os mesmos em toda a aplicação. Todas as informações devem ser visíveis e legíveis, tanto em retrato quanto em paisagem. O usuário não deve se esforçar para encontrar ou entender qualquer informação sendo transmitida. Isso também vale para mídias, que devem de ser vistas ou executadas na íntegra. Os elementos da interface devem possuir contraste e elementos de um mesmo grupo de informações devem ter alinhamento adequado. O usuário deve saber exatamente o que ele deve colocar como entrada a um componente, sem que haja ambiguidades ou dúvidas. Metáforas de funcionalidades devem ser compreendidas sem dificuldades. A aplicação deve falar a linguagem do usuário e as instruções para executar as funcionalidades devem ser claras e objetivas. A leitura deve ser natural e a linguagem não deve ser invasiva no sentido de obrigar o usuário a fazer algo. O sistema deve ser capaz de se antecipar a uma situação que leve a algum erro por parte do usuário com base em alguma atividade já realizada pelo usuário. Quando um erro ocorrer, a aplicação deve avisar o usuário prontamente e retornar ao último estado estável. Em casos em que o retorno ao último estado seja difícil, o sistema pode transferir o controle para o usuário, para que este decida o que fazer (para onde ir). A forma com que o usuário fornece os dados pode se basear em tecnologias assistivas (dispositivos que se conectam ao dispositivo móvel para garantirem acessibilidade a usuários), mas a aplicação deve sempre mostrar claramente o que está sendo solicitado, por meio de texto, áudio, vídeo etc., para que o usuário tenha total controle da situação. O feedback deve ser fácil de ser notado, para que não haja dúvidas de que a operação foi realizada ou está em andamento. Atualizações locais na página devem ser priorizadas, para evitar recarregamento e perda do ponto em que o usuário estava. Mensagens que aparecem muitas vezes devem ter opção de serem ocultadas pelo usuário. Barras de progresso demoradas devem permitir que o usuário continue executando outras atividades. Feedbacks positivos devem ser visíveis, mas não exigir interação redundante com o usuário, para não estressá-lo. 9. Ajuda e documentação O aplicativo deve possuir opção de Ajuda para especificar os problemas comuns e as formas de solucioná-los. Os assuntos considerados nessa opção devem ser fáceis de serem encontrados. 10. Minimização da carga de Memória do usuário Aplicações devem permitir que o usuário obtenha a informação de que precisa com facilidade, sem exigir que o usuário memorize passos anteriores para completar uma atividade. 7

2.3. PROJETO DE COMUNICAÇÃO VIA BLUETOOTH 2.3.1. Android O Android 11, sistema operacional mantido pela empresa Google e voltado para dispositivos móveis, baseado no núcleo Linux, vem adquirindo cada vez mais espaço no mercado de smartphones, possuindo um crescimento de mais de um milhão e trezentos mil aparelhos por dia (Google). 12 Outra informação que podemos destacar é que o sistema, que executa em smartphones e em tablets, irá superar este ano o sistema da Apple (ios) no mercado global, de acordo com analistas. 13 Assim, o sistema é utilizado pelo grupo como base para desenvolvimento por ter ampla adoção e pelo suporte que oferecido aos desenvolvedores, por meio do site Android Developer 14, voltado para aqueles que desejam desenvolver aplicativos Android. 2.3.2. Android SDK O Android SDK, sigla para Software Development Kit, é a ferramenta disponibilizada pela Google para auxiliar a criação de aplicativos Android. Ela possui um dispositivo virtual, que simula aparelhos smartphones e tablets, mostrando ao desenvolvedor o progresso da aplicação a partir da perspectiva do usuário final até o dado momento. Um exemplo de ferramenta que foi muito utilizada no Projeto de Comunicação bluetooth é a LogCat, uma ferramenta que tem como objetivo gerenciar os logs do sistema operacional, similar ao método System.out.println() no Java. O Android SDK fornece várias e diversas ferramentas e atualmente permite o desenvolvimento de aplicativos até a versão 4.2 do Android. 15 11 www.android.com 12 http://imasters.com.br/noticia/1-3-milhao-de-dispositivos-com-android-sao-ativados-diariamente/ 13 http://info.abril.com.br/noticias/tecnologia-pessoal/android-vai-superara-ios-no-mercado-de-tablets-esteano-12032013-28.shl 14 http://developer.android.com/index.html 15 http://developer.android.com/sdk/index.html 8

2.3.2. Comunicação via Bluetooth Bluetooth é um padrão global de comunicação sem fio e de baixo consumo de energia, proposto para permitir a transmissão de dados entre vários tipos de dispositivos. Para que a transferência de dados ocorra, os dispositivos devem estar próximos um do outro, sendo a distância definida de acordo com o dispositivo que possui o menor alcance. O alcance do Bluetooth é dividido em três classes: classe um, com alcance de até 100 metros, classe dois, com alcance de até 10 metros e classe três, com alcance de até 1 metro. A transmissão de dados é feita por meio de radiofrequência, permitindo que um dispositivo detecte o outro independente de suas posições, sendo necessário apenas que ambos estejam dentro do limite de proximidade. 16 A tecnologia de comunicação Bluetooth foi criada visando o alcance mundial. Dessa maneira, foi necessária a adoção de uma frequência de rádio aberta, que possa ser utilizada em qualquer país. Visando atender essa necessidade, foi adotada a faixa ISM (Industrial, Scientific, Medical), que utiliza a frequência de 2,45 GHz, com variações de 2,4 GHz até 2,5 GHz. Por ser uma frequência de rádio aberta, a ISM pode ser utilizada em qualquer outro tipo de sistema de comunicação, sendo necessário garantir que o sinal Bluetooth não sofra e não gere interferência. É utilizado o esquema de comunicação FH- CDMA (Frequency Hopping - Code-Division Multiple Access), trazendo ao Bluetooth a proteção necessária contra interferências. O esquema faz com que o dispositivo que estabelece a conexão mude de um canal para outro rapidamente, permitindo que a largura de banda da frequência seja muito pequena, diminuindo as chances de interferência. No bluetooth pode-se utilizar até 79 frequências dentro da faixa ISM, com "espaçamento" de 1 MHz entre elas. 17 O dispositivo que utiliza comunicação via Bluetooth pode tanto receber quanto transmitir dados (full-duplex). A transmissão de dados é alternada entre slots, sendo eles de transmissão e de recepção. Os slots são canais divididos em períodos de 625 microssegundos. Cada salto de frequência é ocupado por um slot. Para esse tipo de 16 http://www.infowester.com/bluetooth.php 17 http://www.infowester.com/bluetooth.php 9

transmissão damos o nome de FH/TDD (Frequency Hopping / Time Division Duplex). A conexão entre emissor e receptor utilizada no sistema Bluetooth é dada através de dois padrões: SCO (Synchronous Connection-Oriented) e ACL (Asynchronous Connection- Less). O padrão SCO cria um link sincronizado entre os dispositivos de recepção e o de transmissão, separando slots para cada um deles. Por fim, o padrão ACL, estabelece um link entre o dispositivo que cria e gerencia a comunicação e os que estão em sua rede. Ao contrário do padrão SCO, ele permite o reenvio de pacotes de dados perdidos, fazendo com que haja integridade das informações trocadas entre os dispositivos conectados. 18 Uma rede Bluetooth é formada por dois ou mais dispositivos, a qual é denominada piconet (Figura 1). Neste tipo de comunicação, os dispositivos pertencentes à rede podem assumir dois papéis, sendo eles: master (mestre), atribuído ao dispositivo que dá início a conexão, e slave (escravo), dado aos demais dispositivos pertencentes à rede. O dispositivo master regula a transmissão de dados e o sincronismo entre dispositivos. São permitidos no máximo 8 dispositivos por piconet, porém para ampliar seu alcance pode-se sobrepor piconets, gerando uma scatternet (Figura 2). Quando utilizada uma scatternet, há a possibilidade de dispositivos slave fazerem parte de mais de uma piconet, diferentemente de dispositivos master, limitados a apenas uma. 19 Figura1. Exemplo de piconet. 20 Figura2. Exemplo de scatternet. 21 18 http://www.infowester.com/bluetooth.php 19 http://www.infowester.com/bluetooth.php 20 http://blog.webtronico.com/wp-content/uploads/2012/05/piconet.png 10

2.3.3. CÓDIGO MORSE O Código Morse foi proposto e utilizado por Samuel Morse e Alfred Vail para envio de mensagens pelo telégrafo elétrico: Morse foi um dos inventores do telégrafo elétrico, que entre 1935 e 1936 foi proposto de modo independente por pelo menos três inventores, incluindo Morse 22. O Código Morse é um sistema de representação de letras, números e sinais de pontuação através de um sinal codificado enviado alternadamente. As representações de letras são feitas a partir da combinação de pontos, traços e espaço (Tabela 3). Com o desenvolvimento de novas tecnologias de comunicação, tornou-se um pouco obsoleto, mas ainda sendo utilizado em algumas finalidades especificas, tais como Rádio Faróis e radioamadorismo. 23 Deste então várias versões foram propostas, sendo que atualmente é uma recomendação da ITU (International Communication Union). 24 Tabela 3. Representação de letras a partir do Sistema de Código Morse. Letra Código Internacional Letra Código Internacional A.- N -. B -... O --- C -.-. P.--. D -.. Q --.- E. R.-. F..-. S... G --. T - H... U..- I.. V...- J.--- W.-- K -.- X -..- L.-.. Y -.-- M -- Z --.. 21 http://blog.webtronico.com/wp-content/uploads/2012/05/scatternet.png 22 http://en.wikipedia.org/wiki/telegraph#electrical_telegraphs 23 http://pt.wikipedia.org/wiki/c%c3%b3digo_morse 24 http://www.itu.int/rec/r-rec-m.1677-1-200910-i/ 11

2.4. CONSIDERAÇÕES FINAIS Os estudos realizados através do Projeto de Avaliação Heurística e abordados neste capítulo foram importantes para retomar conhecimentos adquiridos por meio de disciplinas do curso de Bacharelado em Informática, sendo eles: a técnica de avaliação de usabilidade utilizando heurísticas, e o conjunto de heurísticas desenvolvido por Nielsen. Além disso, tomou-se conhecimento da carência de métodos de avaliação de usabilidade de interfaces voltadas a aplicativos para dispositivos móveis. Do ponto de vista de recomendações para o design, identificaram-se fatores que dificultam que designers interpretem e utilizem guidelines de usabilidade desenvolvidas por empresas atuantes no mercado de dispositivos móveis. Por intermédio de estudos relacionados ao Projeto de Comunicação via Bluetooth, teve-se contato com a estrutura da programação utilizada para o desenvolvimento de aplicativos que possuem como base o sistema operacional para dispositivos móveis Android. Conjuntamente, tomou-se entendimento da estruturação e características da comunicação via Bluetooth. Por fim, através do estudo da plataforma Android, pode-se analisar melhores práticas para o desenvolvimento de aplicativos para esse sistema, e estudar ferramentas de apoio, como é o caso da ferramenta LogCat, que ajuda na identificação de erros gerados na execução de aplicativos. Finalmente, seguindo os estudos citados, foi dado início às atividades específicas de cada um dos projetos. Por meio delas, foi possível colocar em prática o conhecimento adquirido. As atividades pertinentes aos projetos mencionadas serão descritas no próximo capítulo. 12

CAPÍTULO 3: DESENVOLVIMENTO DO TRABALHO 3.1. CONSIDERAÇÕES INICIAIS Neste capítulo são descritas as atividades realizadas nos Projeto de Avaliação Heurística e Projeto de Comunicação via Bluetooth, os resultados obtidos através delas, limitações ao realizá-las e, por fim, algumas considerações finais. 3.2. PROJETO DE AVALIÇÃO HEURÍSTICA O projeto foi dividido em duas atividades distintas. A primeira envolve a comparação do conjunto das heurísticas propostas por Jakob Nielsen com as compiladas pelo mestrando Olibário J. Machado Neto, como extensão do conjunto de Nielsen. A segunda envolve a organização e a generalização dos componentes originais dos guidelines de usabilidade de interfaces pertencentes ao sistema operacional para dispositivos móveis ios. 3.2.1. DESCRIÇÃO DAS ATIVIDADES REALIZADAS 3.2.1.1 AVALIAÇÕES HEURÍSTICAS As atividades descritas tiveram interação com o mestrando Olibário J. Machado Neto. Essas interações devem-se ao fato de que o aluno atuou como um dos avaliadores que efetuaram testes de usabilidade nas interfaces de dois aplicativos desenvolvidos para plataformas de dispositivos móveis. Os aplicativos avaliados são o UOL Notícias, para a plataforma ios, e o aplicativo de anotações multimídia denominado Annotation Tool, para a plataforma Android, desenvolvido pela mestranda Bruna Rodrigues, do Laboratório Intermídia do Instituto de Ciências e de Computação (ICMC), da Universidade de São Paulo em São Carlos. Para os testes, utilizou-se o método de avaliação heurística. Um conjunto de heurísticas, criado por Jakob Nielsen (Tabela 1), foi utilizado para avaliar o aplicativo de anotações multimídia (Annotation Tool). Um segundo conjunto de heurísticas, organizado pelo mestrando Machado Neto como extensão das heurísticas de Nielsen (Tabela 2), utilizado para avaliar o aplicativo UOL Noticiais. O trabalho realizado contribuiu para análise do segundo conjunto de heurísticas, que tem por objetivos orientar a identificação 13

problemas de usabilidade em aplicações de dispositivos móveis. Todos os problemas encontrados por meio das avaliações foram anotados e classificados de acordo com as heurísticas e seus graus de severidade. O grau de severidade é uma escala de 0 a 4 elaborada por Nielsen (1994), que visa aferir a gravidade dos problemas encontrados de acordo com as seguintes descrições: 0. Eu não concordo que esse é um problema de usabilidade; 1. Problema cosmético: deve ser corrigido apenas em caso de haver tempo extra no projeto para tal; 2. Problema menor: a correção desse problema é uma tarefa de baixa prioridade; 3. Problema maior: é importante que esse problema seja corrigido e tratado com grande prioridade; 4. Problema crítico: é essencial que esse problema seja corrigido antes da continuidade do desenvolvimento. Para que se pudesse dar início às avaliações de usabilidade, foi realizada uma análise de todas as telas dos aplicativos. Com isso, foi possível verificar todos os tipos de telas de interação que ambos possuíam. Antes de qualquer avaliação, o aluno recebeu uma tabela com o conjunto de heurísticas a ser utilizado. Uma vez adquirida familiaridade para com os aplicativos e tendo em mãos a tabela, as avaliações foram realizadas. Todas as interfaces de telas de interação foram avaliadas a procura de erros de usabilidade. Primeiramente foi feita a avaliação do aplicativo UOL Notícias, que de acordo com as informações contidas na descrição do aplicativo na App Store, a loja virtual da empresa Apple, o aplicativo permite reunir as principais notícias do dia de economia, politica, esporte, entretenimento, mulher, além de outras informações sobre o cotidiano, ciência e saúde, educação, moda, entre outras. Permite também a navegação por álbuns de fotos e vídeos, e o download de noticiais para leitura local. O aplicativo foi utilizado nos testes de usabilidade por possuir versões para as plataformas ios, Android e Windows Phone, e devido também à grande popularidade dentre os aplicativos desenvolvidos para a plataforma Android, sendo instalado em mais 500 mil dispositivos equipados com esse sistema operacional (Google Play, 2013). Para sua avaliação foi utilizado o smartphone iphone 4S, com visor de 3.5" (Figura 8). 14

Utilizando as heurísticas de Jakob Nielsen, foi avaliado o aplicativo de anotações multimídia. Para criar anotações em um determinado vídeo é necessário passar por algumas telas de interação. Inicialmente, o usuário se identifica, e a partir daí pode navegar pelo aplicativo. Os nomes que aparecem para o usuário no momento da identificação são relativos às contas do Google sincronizadas com o dispositivo. Após feita a identificação do usuário, é possível selecionar o vídeo em que se desejado criar as anotações. Tendo selecionado o vídeo, é necessária que seja feita outra identificação, porém agora com o nome do autor que criará as anotações. Finalmente, realizadas todas as etapas mencionas, inicia-se as anotações no vídeo. Na criação de anotações de texto, o usuário tecla sobre o campo de texto, localizado abaixo do botão "Play/Pause" (Figura 7), que ativa o teclado do sistema operacional para que a mensagem seja digitada. A anotação de tinta é feita ao passar-se o dedo na área onde o vídeo é apresentado. Para habilita-la é necessário clicar no botão Ink Annotation is Off. Após clicado, o nome botão mudará para Ink Annotation is On, permitindo que anotações de tinta sejam criadas. Por fim, as anotações de áudio são criadas através de gravações feitas pelo microfone pertencente ao dispositivo em que o aplicativo está instalado. Para habilita-la é necessário clicar no botão Audio Annotation is Off. Com isso, o nome do botão mudará para Audio Annotation is On, mostrando ao usuário que a funcionalidade está em ação. As telas desse aplicativo podem ser visualizadas nas Figuras 3 a 7. Para sua avaliação foi utilizado o smartphone Samsung Galaxy S II, modelo i9100 com visor de 4.27" (Figura 9). 15

Figura 3. Tela Inicial do aplicativo de anotação multimídia em vídeos (quadro inferior em branco para poupar impressão). Figura 4. Tela para seleção de usuário que irá navegar pelo aplicativo de anotação multimídia (quadro inferior em branco para poupar impressão). Figura 5. Tela para seleção de vídeo a ser anotado (quadro inferior em branco para poupar impressão). Figura 6. Tela de escolha do autor do vídeo (quadro inferior em branco para poupar impressão). 16

Figura 7. Tela principal da aplicação de anotação de vídeos (quadro inferior em branco para poupar impressão). 17

Figura 8. Smartphone iphone 4S, utilizado para instalação e avaliação da interface do aplicativo UOL Notícias. 25 Figura 9. Smartphone Samsumg Galaxy SII, utilizado para instalação e avaliação da interface do aplicativo de Bruna da Cunha. 26 3.2.1.2 ORGANIZAÇÃO DE GUIDELINES PARA IOS É importante que as empresas produtoras dos sistemas operacionais se preocupem em documentar por meio de recomendações o que se deve e o que não se deve fazer ao escolher um componente para uma interface. Esse tipo de orientação já era utilizado nos anos 80, quando a Apple lançou diretrizes para criação de aplicações para seus computadores desktop (APPLE, 1987); o mesmo ocorreu com orientações para os computadores Macintosh (APPLE, 1992). Contudo, nota-se que a terminologia usada para designar esses componentes varia sensivelmente de acordo com cada fabricante, o que dificulta que pessoas sem conhecimento específico em um sistema operacional utilize os componentes corretos para criar uma interface com o usuário. Além disso, alguns elementos de um dado sistema operacional simplesmente não existem em outro sistema, o 25 http://store.storeimages.cdn-apple.com/3406/as-images.apple.com/is/image/appleinc/iphone4s-hero-xl- 2013?wid=267&hei=389&fmt=png-alpha&qlt=95&.v=1367278921767 26 http://www.samsung.com/global/business/mobile/product/smartphone/gt-i9100lkaxsp 18

que pode levar um designer a criar interfaces inconsistentes ou impossíveis de serem implementadas (Machado Neto, 2013). Com foco no problema citado, o mestrando utilizou dos componentes pertencentes aos guidelines para os sistemas operacionais de dispositivos móveis Android, ios, Black Berry e Windows Phone para criar componentes com nomes genéricos. O objetivo desse esforço era facilitar o trabalho de desenvolvedores com pouca experiência em relação aos mesmos. Para cada elemento abordado em uma determinada documentação, Machado Neto (2013) procurou seu equivalente nas demais pertencentes aos outros sistemas operacionais, criando-se um nome genérico: por exemplo, botões são chamados de Buttons em todas as referências encontradas (Machado Neto, 2013). Nesse contexto, no Projeto de Avaliação Heurística foi realizada uma organização dos guidelines para o sistema da Apple, o ios. Para isso, foi inicialmente realizada a leitura de todos os guidelines mencionados e, a seguir, foram preparadas suas traduções, pois originalmente estavam na língua inglesa. As traduções permitiram que fosse adquirido maior conhecimento sobre as terminologias adotas pela empresa e também para validar corretamente as funcionalidades dos componentes inclusos nos guidelines. Após analisar todos os guidelines, os elementos foram organizados de acordo com os nomes genéricos propostos pelo mestrando. 3.2.2. RESULTADOS OBTIDOS 3.2.2.1 AVALIÇÕES HEURÍSTICAS O aplicativo UOL Notícias, quando analisado e classificado através das heurísticas compiladas por Machado Neto (2013) a partir da extensão das de Nielsen, apresentou nove problemas de usabilidade em sua interface, com graus de severidade variando entre o nível 1 até o 3. Notou-se também que as heurísticas são consistentes, pois a classificação dos problemas encontrados foi feita sem dificuldades. O resultado referente à avaliação heurística está sumarizado na Tabela 3, que associa, a cada problema encontrado, a heurística com a qual ele foi relacionado e seu grau de severidade. Por fim, oito problemas de usabilidade na interface do aplicativo de anotações multimídia foram identificados e classificados através do conjunto de dez heurísticas desenvolvidas por Jakob Nielsen, com seus graus de severidade variando entre o nível 1 até o 3. O 19

resultado está sumarizado na Tabela 4, que também associa, a cada problema encontrado, a heurística com a qual ele foi relacionado e seu grau de severidade. Tabela 3. Problemas identificados na interface do aplicativo UOL Notícias. Problemas Heurística Grau de Severidade Não Existe ferramenta de busca de noticias 3 2 Na tela de Notícias, existe uma barra horizontal que especifica o tipo de notícia que estamos acessando. Nela para trocarmos o tipo visualizado, devemos clicar sobre o mesmo, não existindo a 3 1 possibilidade de arraste horizontal (prática muito comum em celulares touch). Na aba Ler depois não existe a possibilidade de deletar mais de uma notícia ao mesmo tempo, sendo necessário realizar a 8 3 operação para cada noticia existente. Informações referentes ao vídeo na aba Vídeos estão muito pequenas, dificultando a visualização das mesmas. 3 2 Lista de cidades está com informações mal ordenadas, dificultando a busca do usuário. 3 2 Banner localizado em cima da barra de guias está dificultando a visualização das informações. 3 2 Não existe a possibilidade de visualização em modo paisagem das fotos apresentadas na guia Fotos. 3 3 Não existe a possibilidade de visualização em modo tela-cheia dos vídeos apresentados na guia Vídeos. 3 3 Na tela inicial, as informações estão mal orientadas, dificultando sua visualização. 3 3 Tabela 4. Problemas identificados na interface do aplicativo de anotações multimídia. Problema Heurística Grau de Severidade Botão de anotação de tinta e áudio deixa usuário confuso quanto ao seu status (ligado/desligado). 1 2 Tela de vídeos não possui informação do local onde esses vídeos estão alocados, dificultando a usabilidade por parte do usuário 7 3 inexperiente. Em anotação de tinta o vídeo não está pausando para criação da mesma. 5 3 Dar opção ao usuário de visualizar múltiplos autores. 3 1 Falta de Padrão no tamanho dos botões com funcionalidades semelhantes, afetando a visualização dos mesmos. 4 2 Modo paisagem poderia possuir barra vertical com botões de visualização de anotações de tinta, áudio e texto. 7 1 Gerar informações básicas dos vídeos, tais como: número de anotações de texto, áudio e tinta que o mesmo possui e shares. 1 2 Mostrar nome do usuário ativo que está gerando as anotações. 1 2 3.2.2.2 ORGANIZAÇÃO DOS GUIDELINES IOS O resultado da classificação dos componentes do ios é sumarizado na Tabela 5, que relaciona o nome do componente original e o nome genérico proposto pelo mestrando 20

Machado Neto (2013). Os nomes dos componentes foram mantidos em língua inglesa para não perder as referências dos guidelines originais. Tabela 5. Classificação dos componentes da plataforma para dispositivos móveis ios. Componente ios Barra de atividades Navigation Bar Slider Slider Barra de navegação Navigation Bar Girador de progresso Activity indicador Barra de progresso Barra de Status Barra inferior Botão Caixa de múltipla escolha Caixa de seleção Campo de busca Campo de texto Diálogo Link Lista Menu popup Radio Button Rótulo (palavra ou frase estática) Seletor de arquivos Seletor de data Seletor de hora Seletor numérico Submenu Switch Tabela Progress View Status Bar Toolbar Button Simulado com button + picker Checkbox Search Bar Textfield Alert Picker Radio Button Label Datepicker Timepicker Stepper Switch Table View 3.3 PROJETO DE COMUNICAÇÃO VIA BLUETOOTH As atividades descritas nesta seção estão diretamente ligadas ao desenvolvimento do aplicativo BlueMorse realizado juntamente com o doutorando Diogo Pedrosa e demais membros da equipe do projeto BlueMorse. O aplicativo tem como objetivo permitir que pessoas com dificuldades motoras possam se comunicar por meio de mensagens de texto enviadas para outros dispositivos via conexão bluetooth. As dificuldades motoras são do tipo portado por indivíduos que possuem a síndrome do "homem do barril" (Orsini et al., 2009), que ficam impossibilitados de executar atividades funcionais relacionadas à movimentação dos membros superiores, 21

inclusive do pescoço e cabeça, incluindo respiração e alimentação, as quais são realizadas por aparelhos. Assim, há estágios em que o indivíduo pode se comunicar apenas por movimentação das pernas e, em alguns casos, por meio de movimentação dos lábios. Tendo em vista esta característica, o desenvolvimento do aplicativo foi realizado com foco no movimento dos membros inferiores. No início do desenvolvimento foram identificados dois desafios. O primeiro referente à maneira como o usuário do aplicativo, com problemas motores, iria enviar sinais de entre os dispositivos utilizados. O segundo referente ao sistema utilizado, para permitir o emprego meio de dispositivos de custo acessível, uma vez que os existentes têm custo alto para a maioria da população. 27 Para o primeiro desafio, foi utilizada a comunicação via Bluetooth somada ao sensor de movimento de smartphones, gerando duas possibilidades de papéis a serem assumidos pelos dispositivos: cliente ou servidor. É concedido o papel de cliente ao dispositivo que solicita a conexão e o papel de servidor ao dispositivo ao qual é solicitada. A solicitação é realizada ao selecionar-se o nome do dispositivo na lista de dispositivos emparelhados, sendo que o dispositivo que assumir o papel de servidor é acoplado em um dos pés do indivíduo portador da doença. Ao movimentar o smartphone, o sensor gera sinais emitidos por meio de comunicação Bluetooth, que são recebidos pelo dispositivo cliente conectado ao emissor. Para o servidor, é apresentada uma tela com o nome do dispositivo ao qual está conectado. Na tela do dispositivo cliente, são exibidas as letras formadas através dos sinais emitidos pelo servidor (Figura 10). O segundo desafio foi abordado com um mecanismo baseado no sistema de Código Morse. Com isso, ao movimentar-se o pé para a direta ou para a esquerda, são gerados se respectivamente o ponto ou traço. Uma versão do código adaptada para o Português foi definida pelo doutorando Diogo C. Pedrosa, e utilizada na implementação do aplicativo que foi denominado BlueMorse. 27 Por exemplo, um tablet especializado e com software para síntese de voz no Reino Unido é vendido por 6.040,00 libras esterlinas (http://www.inclusive.co.uk/tobii-c15-p5060) 22

Figura 10. Aplicação BlueMorse (autoria do doutorando Diogo C. Pedrosa) 3.3.1. DESCRIÇÃO DAS ATIVIDADES REALIZADAS Inicialmente, era permitido que apenas um dispositivo cliente se conectasse ao servidor. Nesse caso, o servidor aguardava até que alguma requisição de conexão fosse criada. Após estabelecida a conexão, não havia a possibilidade de serem criadas novas requisições por novos clientes. Do lado servidor da aplicação, são utilizadas duas threads para estabelecer a conexão. A primeira é criada no momento em que o servidor é iniciado, e utilizada para que o servidor fique "escutando" novas requisições de conexão. Ao aceitar a requisição, a thread que a gerencia é cancelada e é gerada uma segunda thread que estabelece a conexão. Do lado cliente também são utilizadas duas threads. A primeira é criada ao selecionar-se o dispositivo servidor a partir da lista de emparelhados. Como resultado da seleção, a thread gera uma requisição ao servidor selecionado e, quando completada, é cancelada, dando lugar a uma nova thread, a qual estabelece a conexão. A situação de conexão entre cliente e servidor é definida através de três estados, LISTEN, CONNECTING e CONNECTED. O primeiro estado refere-se ao servidor, utilizado no momento em que está "escutando" por requisições de conexão. O segundo, é utilizado pelo dispositivo cliente, no instante da tentativa de conexão com o servidor. Finalmente, o estado CONNECTED é adquirido por ambos, quando estabelecida a conexão. 23