Ambientes Residenciais Controlados por Dispositivos Móveis: … · 2017-11-04 · interfaces de controle, tornando essa tarefa, relativamente, complexa. Torna-se necessário, portanto,

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA

DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO

MESTRADO ACADÊMICO EM SISTEMAS E COMPUTAÇÃO

Ambientes Residenciais Controlados por Dispositivos Móveis: Estudo, Concepção e

Desenvolvimento de um Aplicativo Considerando a Diversidade

Sarah Gomes Sakamoto

Natal-RN

Fevereiro de 2014

Sarah Gomes Sakamoto



Exame de Defesa de Mestrado apresentado ao

Programa de Pós-Graduação em Sistemas e

Computação do Departamento de Informática e

Matemática Aplicada da Universidade Federal do

Rio Grande do Norte como requisito final para a

obtenção do grau de Mestre em Sistemas e

Computação.

Linha de pesquisa:

Engenharia de Software

Orientador

Prof. Dr. Leonardo Cunha de Miranda

PPGSC – PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO DIMAP – DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA

CCET – CENTRO DE CIÊNCIAS EXATAS E DA TERRA UFRN – UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

Natal-RN

Fevereiro de 2014

Defesa de Mestrado sob o título Ambientes Residenciais Controlados por Dispositivos Móveis: Estudo,

Concepção e Desenvolvimento de um Aplicativo Considerando a Diversidade, apresentada por Sarah Gomes

Sakamoto e aceita pelo Programa de Pós-Graduação em Sistemas e Computação do

Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do

Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:

_____________________________________________________________

Prof. Dr. Leonardo Cunha de Miranda

Presidente

DIMAp – Departamento de Informática e Matemática Aplicada

UFRN – Universidade Federal do Rio Grande do Norte

_____________________________________________________________

Prof. Dra. Vânia Paula de Almeida Neris

Examinadora (Externa)

Departamento de Computação

UFSCar – Universidade Federal de São Carlos

_____________________________________________________________

Prof. Dra. Lyrene Fernandes da Silva

Examinadora (Interna)

DIMAp – Departamento de Informática e Matemática Aplicada

UFRN – Universidade Federal do Rio Grande do Norte

Natal-RN, 25, Fevereiro de 2014

Aos meus pais, Akihiko e Edilza, e ao meu amado Alessandro.

Agradecimentos

Neste momento, em que as forças se esvaem, mas a pesquisa clama pela continuidade, devemos agradecer àqueles que nos auxiliaram ao longo dessa jornada. Primeiramente, agradeço à minha família. Aos meus pais, Edilza Gomes Sakamoto e Akihiko Sakamoto, minha eterna gratidão. Obrigada pelo suporte na minha escolha de prosseguir com os estudos, amor incondicional, compreensão, cooperação nessa fase final, e por zelarem por meu bem-estar em todos os momentos. Ao meu companheiro, Alessandro Luiz Stamatto Ferreira, sempre presente em minha vida. Agradeço pelo apoio em todos os momentos. Obrigada pelo amor, compreensão, sugestões e incentivo em minha pesquisa. Você sempre me dá forças para continuar. Saiba que você é minha luz, meu principal agente de fomento, desde as palavras cativantes até a proteção nas madrugadas do DIMAp. Espero que você sempre esteja ao meu lado para ajudarmos um ao outro. Ao meu amigo Diego Henrique Dantas de Oliveira, pelo tempo, amizade e contribuição. Obrigada pelos momentos, reflexões, trocas de experiência e estímulo. Você foi fundamental para a evolução do HandyHome. Agradeço à minha segunda família, Maria Inês Sucupira Stamatto, Adir Luiz Ferreira e Luane Maria Stamatto Ferreira, por todo o apoio e compreensão nos momentos mais difíceis. Às minhas amigas Ana Carla Carvalho de Correia, Juliana de Araújo Oliveira e Jarmilla Bow Ltaif Garcia, pela cooperação e grande amizade durante o mestrado. Aos amigos Ronildo Pinheiro de Araujo Moura e Alison de Araújo Bento pelo incentivo na fase final. Aos amigos Bruno e Arrison pela assistência e garantia de amparo, à minha avó Maria Eunice pelas orações e demais familiares pela torcida. Agradeço também aos participantes do experimento (meus sinceros agradecimentos), à amiga Eliselma Vieira pela colaboração, ao Heiko pela contribuição científica, ao Paulo pela visão de hardware, à Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) pela bolsa de estudos concedida, e aos demais membros e colegas do grupo pelo crescimento coletivo. Aos membros desta banca, professoras Lyrene Fernades da Silva e Vânia Paula de Almeida Neris, pela disposição de tempo e dedicação para contribuírem com o trabalho e tornarem sua apresentação possível. À professora Vânia também pela organização do maravilhoso evento IHC'12, marcante em minha jornada, onde conheci parte da comunidade de IHC. E em especial, à professora Lyrene, que guiou meus passos para minha pesquisa atual e passou valiosas lições. Por último, e não menos importante, ao meu orientador, Leonardo Cunha de Miranda. Agradeço pela oportunidade de continuar meus estudos na área do meu interesse, e proporcionar uma nova perspectiva sobre o significado da atividade de pesquisa. Obrigada pelas melhorias significativas em nossas publicações e pelo tempo em que trabalhamos juntos e o senhor cooperava comigo. Este trabalho é a junção de pequenas contribuições, de diversas pessoas em momentos específicos. Espero poder agradecer de coração a todos que contribuíram direta ou indiretamente com a evolução deste trabalho.

화이팅!

“It is in self-limitation that a master first shows himself” ― Johann Wolfgang von Goethe



Autora: Sarah Gomes Sakamoto

Orientador: Prof. Dr. Leonardo Cunha de Miranda

RESUMO

Com o desenvolvimento tecnológico ocorrido nas últimas décadas, o ambiente residencial vem

incorporando a cada dia novos equipamentos eletroeletrônicos de consumo doméstico a fim de

facilitar as atividades do cotidiano e promover uma melhor qualidade de vida dos moradores-

usuários. Controlar esse ambiente no mundo contemporâneo demanda interação com diferentes

interfaces de controle, tornando essa tarefa, relativamente, complexa. Torna-se necessário,

portanto, prover interfaces de usuário mais adequadas para controlar esses equipamentos. Os

dispositivos móveis surgem como uma plataforma viável para realizar esse controle, trazendo

comodidade, flexibilidade e diferentes mecanismos de interação com os equipamentos desse

ambiente. Porém, ao se projetar novas soluções para esse contexto de uso é necessário considerar

a diversidade de usuários e a riqueza de situações de uso desse ambiente. O estudo realizado

nesta pesquisa visa compreender aspectos da interação desse contexto específico considerando a

relação entre os usuários, a tecnologia e o ambiente. Como resultados, apresentamos um

abrangente levantamento de aplicações, a identificação de desafios desse domínio sob a

perspectiva da diversidade e o levantamento de requisitos para aplicações desse contexto baseado

no referencial teórico-metodológico da Semiótica Organizacional e no uso de aplicativos. Ainda,

serão apresentados os passos da concepção de um aplicativo que apoia o controle de recursos do

ambiente residencial via dispositivo móvel juntamente com os resultados de um experimento

realizado com potenciais usuários da solução computacional implementada.

Palavras-chave: Interação Humano-Computador; Requisitos; Semiótica Organizacional;

Domótica; Smartphone, Android.

Home Environment Controlled by Mobile Devices: Study, Conception and Development of an

Application Considering Diversity

Author: Sarah Gomes Sakamoto

Advisor: Prof. Dr. Leonardo Cunha de Miranda

ABSTRACT

With technological advancement in recent decades, home environment incorporates several

household electronic appliances in order to facilitate activities and improve dwellers-users' quality

of life. Controlling this environment in modern society requires interaction with different

interfaces and controls, which becomes a nontrivial task. It is therefore necessary to provide

more appropriate user interfaces to control such equipment. Mobile devices emerge as a viable

platform to enable this control, providing convenience, flexibility and several interaction

possibilities. However, it is fundamental to consider users and situations diversity regarding this

environment in new solutions design. The study in this research aims providing a better

understanding of interaction aspects in this specific context considering the relation between

users, technology and environment. As results, we present a wide survey in applications, as well

as the identification of challenges under the perspective of diversity and requirements elicitation

for applications in this domain based on Organizational Semiotics theory and usage of

applications. Concept phases of a software which supports controlling home environment

resources via mobile devices along with results from an experiment with potential users of this

computational solution are also presented in this research.

Keywords: Human-Computer Interaction; Requirements; Organizational Semiotics; Domotics;

Smartphone, Android.

ix

Lista de figuras

Fig. 1 - Exemplos de formas de interface e interação através dos dispositivos móveis para

controle de elementos da casa. Fontes: [25],[37],[42] adaptado,[47] .................................................. 35

Fig. 2 – Partes Interessadas resultante da análise do domínio............................................................. 38

Fig. 3 – Overview of the M4REMAIP. .................................................................................................. 48

Fig. 4 – Some possible design solutions – icons – to functionality “Settings”. ................................ 55

Fig. 5 – Arquitetura do Sistema ............................................................................................................... 63

Fig. 6 – Comunicação com o Sistema ..................................................................................................... 64

Fig. 7 – Interface da Tela Principal ......................................................................................................... 67

Fig. 8 – Decisão de design: Posicionamento do botão de interação por voz ................................... 68

Fig. 9 – Interface de (a) Cenários, (b) Cenários, com um cenário sendo ativado e emitindo

feedback visual com mensagem toast, e (c) Cenários favoritos .......................................................... 68

Fig. 10 – Interfaces (a) Dispositivos, (b) Controle do dispositivo e (c) Configurações .................. 69

Fig. 11 – Decisão de design: (a) Botão Toggle e (b) Switch ................................................................ 70

Fig. 12 – Estrutura da casa a ser controlada no experimento ............................................................. 75

Fig. 13 – Tempo que cada usuário utilizou para realizar as tarefas 1 a 14 ......................................... 80

Fig. 14 – Taxas de realização das tarefas 1 a 14 com sucesso ............................................................. 81

Fig. 15 – Respostas dos participantes quanto às imagens A e B ......................................................... 81

Fig. 16 – Reações aos problemas de acessibilidade no uso de dispositivos móveis ......................... 82

Fig. 17 Diferentes reações após ação no ambiente: (a) usuário não percebe e (b) usuário percebe o

feedback do aparelho no ambiente.......................................................................................................... 83

Fig. 18 Conjunto de gestos definido por um participante para os cenários: (a) Acordar, (b) Antes

de dormir, (c) Cinema em casa, (d) Sair de Casa, (e) Chovendo ......................................................... 84

Fig. 19 – Reação dos usuários no momento de execução da tarefa 18 .............................................. 85

Fig. 20 – Contribuições da pesquisa no projeto desenvolvido ............................................................ 88

x

Lista de tabelas

Tabela 1 – Aplicações Residenciais da Literatura ................................................................................. 35

Tabela 2 - Escada Semiótica resultante da análise do domínio. .......................................................... 39

Table 3 – Android apps identified and analyzed applying M4REMAIP ........................................... 53

Tabela 4 – Exemplos de Interfaces de Controle ................................................................................... 64

Tabela 5 – Objetos que podem ser controlados em cada cômodo da casa com a aplicação ......... 76

Tabela 6 – Dados etnográficos e pessoais dos participantes ............................................................... 77

Tabela 7 – Dados etnográficos e pessoais dos participantes ............................................................... 78

Tabela 8 – Legenda da classificação da tabela 7 .................................................................................... 78

Tabela 9 – Formas que os usuários realizaram a tarefa 16 .................................................................. 84

Tabela 10 – Formas que os usuários realizaram a tarefa 18 ................................................................ 85

Sumário

Lista de figuras .................................................................................................................... ix

Lista de tabelas ..................................................................................................................... x

1 Introdução ................................................................................................................... 15

1.1 Contexto, Problemática e Motivação ............................................................................. 15 1.2 Objetivos ............................................................................................................................ 17 1.3 Relevância da pesquisa ..................................................................................................... 18 1.4 Estrutura do trabalho ....................................................................................................... 19

2 State of the Art and HCI Challenges under the Perspective of Diversity ................... 21

2.1 Introduction ....................................................................................................................... 21 2.2 State of the Art .................................................................................................................. 22

2.2.1 Textual Command Interface ................................................................................... 22 2.2.2 Textual Interface with Visual Layout ..................................................................... 23 2.2.3 Graphical Interface ................................................................................................... 23 2.2.4 Multi-Modal Interface and Direct Manipulation.................................................. 24

2.3 HCI Challenges under the Perspective of Diversity .................................................... 25 2.3.1 Guidelines .................................................................................................................. 28

2.4 Discussion .......................................................................................................................... 29 2.5 Conclusion ......................................................................................................................... 30 2.6 Decision Making ............................................................................................................... 31

3 Levantamento de Requisitos baseado na Semiótica Organizacional ........................ 33

3.1 Introdução .......................................................................................................................... 33 3.2 Aplicações Residenciais .................................................................................................... 34 3.3 Análise do Domínio.......................................................................................................... 36

3.3.1 Base Teórica e Metodológica .................................................................................. 36 3.3.2 Resultados .................................................................................................................. 38

3.4 Requisitos de Interface e Interação ................................................................................ 40 3.5 Discussão ........................................................................................................................... 44 3.6 Conclusão ........................................................................................................................... 45 3.7 Tomada de Decisão .......................................................................................................... 45

4 Requirements Elicitation based on Mobile Applications under an Interaction

Perspective .......................................................................................................................... 46

4.1 Introduction ....................................................................................................................... 46 4.2 M4REMAIP ...................................................................................................................... 47 4.3 Application of M4REMAIP ............................................................................................ 49

4.3.1 Phase I ........................................................................................................................ 49 4.3.2 Phase II ...................................................................................................................... 50 4.3.3 Requirements and Design Ideas ............................................................................. 54

4.4 Discussion .......................................................................................................................... 56 4.5 Conclusion ......................................................................................................................... 57 4.6 Decision Making ............................................................................................................... 57

5 Design e Implementação do Aplicativo HandyHome ............................................... 59

5.1 Introdução ......................................................................................................................... 59 5.2 Aplicações para Controle Residencial Via Dispositivos Móveis ................................ 60 5.3 Implementação .................................................................................................................. 62

5.3.1 Estrutura do Sistema ................................................................................................ 62 5.3.2 Geração Automática de Interface .......................................................................... 63

5.4 Design ................................................................................................................................. 65 5.4.1 Interação .................................................................................................................... 65 5.4.2 Interface ..................................................................................................................... 66

5.5 Discussão ........................................................................................................................... 70 5.6 Conclusão ........................................................................................................................... 71 5.7 Tomada de Decisão .......................................................................................................... 71

6 Descobertas e Reflexões de um Estudo de Caso em um Ambiente Simulado .......... 73

6.1 Introdução ......................................................................................................................... 73 6.2 Metodologia e Cenário de Pesquisa ............................................................................... 74 6.3 Resultados .......................................................................................................................... 79

6.3.1 Resultados Quantitativos ......................................................................................... 80 6.3.2 Observações Qualitativas ........................................................................................ 82

6.4 Discussão ........................................................................................................................... 86 6.5 Conclusão ........................................................................................................................... 87 6.6 Reflexão .............................................................................................................................. 87

7 Considerações Finais .................................................................................................. 89

7.1 Trabalho Realizado ........................................................................................................... 89 7.2 Contribuições .................................................................................................................... 90 7.3 Perspectivas e Trabalhos Futuros ................................................................................... 91

Referências bibliográficas .................................................................................................. 92

Apêndice A – Termo de Consentimento Livre e Esclarecido ........................................... 98

Apêndice B – Termo de Autorização de Gravação de Voz, Imagem e Vídeo ................. 100

Apêndice C – Formulário de Perfil do Participante ......................................................... 102

Apêndice D – Formulário Pós-Atividades........................................................................ 105

Apêndice E – Autorização 1 ............................................................................................. 110

Apêndice F – Autorização 2 ............................................................................................. 114

Capítulo 1

1 Introdução

No ambiente residencial, dispositivos mecânicos e digitais se agregam com a mobília e artefatos

de valor sentimental, todos imersos em um cenário íntimo em que os moradores interagem. A

tecnologia encontra-se presente nas casas de maneira distribuída, em aparelhos para diversas

finalidades, seja em eletrodomésticos, dispositivos para entretenimento ou sistemas para prover

segurança do ambiente. O controle do ambiente residencial envolve diversos desafios, tanto de

caráter tecnológico quanto humano, referente à interação com essa tecnologia. Torna-se

necessário estudar a natureza das interações nesse ambiente, com suas peculiaridades,

necessidades e restrições.

Nesse estudo é necessário considerar diversos aspectos, entre eles, a diversidade. O

ambiente residencial agrega diversos usuários em uma diversidade de situações, e essa diversidade

deve ser contemplada na concepção de novas soluções. Sob essa perspectiva, devem ser

consideradas características específicas do contexto das interações. Este trabalho visa o estudo e a

proposta de uma solução que apoie o controle de recursos do ambiente residencial via

dispositivos móveis, considerando a diversidade.

1.1 Contexto, Problemática e Motivação

Os avanços da indústria eletrônica e das redes de telecomunicação permitiram que diversos

dispositivos eletroportáteis fizessem parte da rotina das pessoas, muitas vezes sem a percepção

do usuário. O ambiente doméstico agrega cada vez mais aparelhos com tecnologia

computacional, repletos de recursos e funcionalidades. Esses aparelhos geralmente possuem uma

interface física que permite o controle de suas funções e alguns deles, controles remotos para

Ambientes Residenciais Controlados por Dispositivos Móveis: Estudo, Concepção e Desenv. de um Aplicativo Considerando a Diversidade 16

possibilitar aos usuários controlá-los remotamente. No entanto, cada dispositivo possui seu

controle individual, exigindo interação com cada um separadamente.

Nos últimos anos, foram propostas diversas formas para o controle desse ambiente, com o

intuito de promover a qualidade de vida dos moradores. Alguns trabalhos têm focado no

desenvolvimento de soluções para controlar o ambiente residencial através de dispositivos

móveis, visto que eles surgem como excelentes plataformas para viabilizar o controle dessa gama

de aparelhos e recursos da casa de forma unificada. A popularização dos dispositivos móveis para

os diversos segmentos da sociedade, também estimula sua utilização como plataforma de

controle, permitindo maior abrangência de público para esse cenário. Porém, essa interação

possui características particulares que merecem atenção e necessitam ser investigadas

considerando esse contexto específico.

O estudo da interação no ambiente doméstico requer a compreensão desse espaço e das

suas possibilidades de interação. As pessoas interagem com a tecnologia de diferentes formas, e

também executam as atividades domésticas de maneiras diferentes. Cada morador possui seus

próprios hábitos e uma visão particular desse ambiente. A tecnologia para controle residencial

deve estar integrada a essas atividades, adaptada à rotina dos usuários. Portanto, ao se projetar

interfaces e interações para novas soluções é necessário considerar essas diferenças, levando em

conta características individuais, condições físicas e sociais, além de diversas situações de uso

nesse ambiente. A área de Interação Humano-Computador (IHC) pode auxiliar no entendimento

dessas interações, a fim de prover melhorias na maneira com a qual as pessoas interagem com a

tecnologia.

No que se refere ao controle do ambiente residencial, alguns termos são comumente

utilizados: automação residencial e casa inteligente. A automação residencial, também

referenciada como domótica, se baseia na automação das tarefas domésticas, substituindo as

operações manuais por operações automatizadas, auxiliadas por máquinas. A automação provê

controle da casa, auxiliando os moradores a gerenciar seus aparelhos, trazendo comodidade,

segurança, conforto e eficiência. Essa automação pode ser aplicada apenas para dispositivos

independentes ou agregar diversos dispositivos e serviços, formando os chamados sistemas de

automação residencial [1]. Uma vantagem trazida pela maioria desses sistemas é a possibilidade de

operá-los remotamente. A população passa grande parte do seu tempo fora de suas casas, e

através da operação remota do sistema, os usuários podem controlar seus aparelhos de suas casas

à distância. E ainda, esses sistemas geralmente proveem funcionalidades de monitoramento

remoto que podem evitar desastres e danos na ausência dos moradores da casa.

Já o conceito de casa inteligente engloba uma moradia que integra tecnologias de

informação e comunicação, promovendo a interação. Apesar das diferentes denominações

adotadas na literatura, tais como “casa interativa”, “casa do futuro”, “casa adaptativa” ou “casa

ciente” [2], está sempre associada com automação e computação inteligente. A noção de

inteligência adotada nos dispositivos dessas casas pode estar relacionada à integração com objetos

17

Capítulo 1. Introdução

inteligentes ou às suas capacidades de economia de energia, providas pela integração com as redes

inteligentes (smart grids) [3]. A casa inteligente pode se ajustar às necessidades dos habitantes [4] de

acordo com preferências ou informações de contexto coletadas do ambiente. Ela é fundamentada

nas ideias de computação ubíqua com a aplicação de AmI (Ambient Intelligence) para prover melhor

qualidade de vida para seus usuários, otimizar o conforto e facilitar o controle dos dispositivos da

casa [5]. Por isso, os conceitos de casa inteligente e automação residencial estão relacionados,

todavia, o termo casa inteligente traz um conceito mais amplo, indo além do que apenas a

automatização de tarefas domésticas. A automação residencial pode ser considerada uma das

etapas para se obter uma casa inteligente.

De fato, nenhum desses termos é novo, visto que o termo casa inteligente foi popularizado

entre as décadas de 1980 e 1990 e a automação residencial já existe há mais de trinta anos. Porém,

apesar do desenvolvimento de diversos sistemas ao longo desses anos, sua adoção pelos

consumidores não foi abrangente. Diversas barreiras podem ser atribuídas como potenciais

motivos para a fraca adoção desses sistemas, entre elas, dificuldades de implantação,

interoperabilidade, gerenciamento e custos, que contribuem para dificultar uma ampla adoção

pela população. Essas barreiras estão relacionadas aos aspectos tecnológicos, e por isso muito

foco foi dado a essas características desses sistemas. Mas existem ainda outras barreiras, tais como

a imagem industrial da domótica [6] e o caráter da interação abordado pelas soluções existentes.

Muitos sistemas de domótica possuem um visual industrial que não se adéqua à natureza do lar, e

com projetos não focados em aspectos de interação humano-computador, muitas vezes exigindo

conhecimento técnico e não adaptadas às necessidades dos usuários.

Portanto, faz-se necessário um estudo acerca das características específicas considerando as

diferentes dimensões nesse contexto, no que se refere à tecnologia, aos usuários e ao ambiente

em que ocorre a interação. E esse estudo deve ser feito considerando a diversidade, permitindo

benefícios para todos os moradores.

1.2 Objetivos

Dado esse contexto, o principal objetivo deste trabalho é estudar o domínio de controle de

elementos do ambiente residencial via dispositivos móveis e propor uma nova solução que apoie

o uso de recursos desse ambiente considerando a diversidade. A fim de cumprir esse objetivo

geral, são relacionados os seguintes objetivos específicos desta pesquisa:

Levantar o que está sendo proposto na literatura para controle de elementos do ambiente

residencial via dispositivos móveis;

Identificar barreiras de interface e interação encontradas no controle de elementos do

ambiente residencial via dispositivos móveis;


Levantar requisitos de interface e interação para soluções que visam o controle de

elementos do ambiente residencial via dispositivos móveis;

Projetar uma instância de interface de uma solução para controle do ambiente residencial

via dispositivos móveis baseado nos requisitos identificados;

Desenvolver uma nova solução considerando os requisitos levantados para controle de

elementos do ambiente residencial via dispositivos móveis;

Avaliar esta nova solução com usuários, a fim de validar alguns requisitos e a proposta de

design.

Este trabalho segue norteado pela área de IHC em todas suas fases de desenvolvimento. O

estudo realizado nessa pesquisa visa compreender aspectos da interação desse contexto específico

considerando a relação entre os usuários, a tecnologia e o ambiente. Já a perspectiva da

diversidade é considerada nesse contexto visto a abrangência de público e situações de uso desse

ambiente.

1.3 Relevância da pesquisa

As soluções desenvolvidas para esse contexto geralmente focam em aspectos tecnológicos,

muitas vezes sem levar em consideração aspectos da interação e da diversidade em sua

concepção/design. Esta pesquisa surge da necessidade de cobrir essa lacuna. Sua relevância está

fundamentada na importância de se atentar para esses aspectos no desenvolvimento de novas

soluções, buscando formas de apresentar as funcionalidades oferecidas para todos os usuários e

facilitar sua interação.

Considerando a relevância sob a ótica da área de IHC, a maioria dos estudos foca somente

na relação entre tecnologia e ser-humano, como evidenciado em [7]. Porém, de acordo com

Frohlich e Kraut [8], o espaço exerce uma influência considerável no tipo de interação a ser

realizado. Considerando o ambiente residencial, fatores relativos a esse espaço impactam nessa

interação entre os moradores e a tecnologia. Alguns trabalhos [9,10] têm mostrado a importância

de se considerar fatores e restrições desses ambientes, abrindo uma série de descobertas neste

cenário.

O estudo realizado na presente pesquisa considera as três dimensões em sua concepção: os

usuários, a tecnologia e o ambiente. No aspecto tecnológico, são abordadas as características

específicas referentes ao controle de elementos domésticos e dispositivos móveis; no que se

refere aos usuários e ao ambiente, são retratados os aspectos da interação sob a perspectiva da

diversidade, para atender a heterogeneidade de público e situações de uso desse ambiente.

Quanto à relevância da pesquisa para a academia e para indústria, esse trabalho mostra sua

importância por mostrar todos os passos, do estudo à concepção de uma solução, mostrando um

19

Capítulo 1. Introdução

abrangente levantamento de soluções existentes, apontando os desafios para a área, mostrando

requisitos para novas aplicações, além do desenvolvimento do aplicativo proposto incorporando

os aspectos supracitados. Dessa forma, a pesquisa contribui por auxiliar no desenvolvimento de

novas soluções, ressaltando a importância de pontos específicos e provendo um guia para

designers de soluções desse domínio. A comunidade científica e os profissionais poderão usufruir

dos resultados desse trabalho para expandir o conhecimento e propor novas soluções que

melhorem a interação nesse contexto específico, além de novas formas de interação,

considerando a diversidade.

1.4 Estrutura do trabalho

O presente trabalho está organizado em seis capítulos, que se somam à Introdução. A estrutura

da dissertação segue o formato de coletânea de artigos, em que cada capítulo apresenta o formato

de um artigo científico. Vale salientar que, devido ao formato adotado, este trabalho apresenta

capítulos que podem estar em um dos seguintes idiomas: português ou inglês. Quando um

idioma é adotado, permanece o mesmo durante todo o capítulo. A última seção de cada capítulo

atua como uma ponte entre cada artigo, mostrando uma breve reflexão sobre aquele capítulo

dentro do contexto da presente pesquisa e próximos passos. Os capítulos, juntamente com uma

breve descrição de seus conteúdos, serão apresentados a seguir.

Capítulo 2 – State of the Art and HCI Challenges for Diversity: Este capítulo

apresenta o levantamento do estado da arte em soluções para controle de ambientes

residenciais via dispositivos móveis e desafios de IHC sob a perspectiva da

diversidade. Adicionalmente, também apresentamos um conjunto de diretrizes a fim

de minimizar ou transpor os desafios identificados;

Capítulo 3 – Levantamento de Requisitos baseado na Semiótica

Organizacional: Este capítulo apresenta os resultados de uma análise sobre o

domínio e levanta requisitos de aplicações para esse contexto sob a ótica de IHC.

Esse levantamento de requisitos foi baseado no estado da arte descrito no capítulo

anterior e na análise do domínio utilizando artefatos da Semiótica Organizacional.

Com isso, foi possível a identificação de requisitos com uma visão sócio-técnica, sob

diferentes perspectivas;

Capítulo 4 – Requirements Elicitation based on Mobile Applications under an

Interaction Perspective: Este capítulo apresenta um método para elicitação de

requisitos baseado em aplicativos sob a perspectiva da interação, bem como, os

resultados do emprego deste método em um estudo realizado para identificar


requisitos de aplicativos Android para controle residencial. Com isso, foi possível

observar o estado da prática para extrair requisitos considerando o domínio e a

plataforma de desenvolvimento específica;

Capítulo 5 – Design e Implementação do Aplicativo HandyHome: Este capítulo

apresenta um estudo sobre a concepção e desenvolvimento do aplicativo

HandyHome, que visa permitir o controle do ambiente residencial através de

dispositivos da plataforma Android. O aplicativo foi concebido sob a ótica de IHC

considerando os passos realizados nos capítulos anteriores;

Capítulo 6 – Descobertas e Reflexões de um Estudo de Caso em um Ambiente

Simulado: Este capítulo apresenta os resultados de um experimento realizado em um

ambiente simulado, a fim de observar a interação de usuários com a aplicação de

controle do ambiente residencial HandyHome. A partir dessa observação, analisamos

questões referentes ao design da aplicação e aspectos de interação dos usuários com

esse tipo de aplicação.

Capítulo 7 – Considerações Finais: Este capítulo resume os resultados da presente

pesquisa juntamente com suas contribuições, e aponta direções para trabalhos futuros.

Chapter 2

2 State of the Art and HCI Challenges under

the Perspective of Diversity1

2.1 Introduction

Home is a physical space which comprises social and human aspects, referring to propriety or

state of mind, and reflects the lifestyles of the inhabitants [11,8]. The interplay of individual and

cultural values make home a complex space. With technological advancements in recent decades,

a home environment may incorporate several electronic appliances in order to facilitate activities

and improve users’ quality of life. These household electrical appliances increased in complexity

and functionality, and present different interfaces and controls. With increasing complexity of

appliances, it can be expected that interaction becomes more complex as well. With increasingly

complex systems, it is necessary to make these functionalities available to all users, in an easier

and more effective way.

Mobile devices – e.g. mobile phones, tablets and smartphones – emerge as possible

platforms to enable control over such a range of appliances. They have already been adopted by

users from different economic and social backgrounds, are equipped with several features,

provide integration through a single interface are convenient to carry, and make home control

possible even when not at home (e.g. in the case of the smartphone). This scenario fits the needs

of users in modern societies and enables several interaction possibilities.

Much work focused on the development of solutions in this domain, especially on

technical issues (cf. Section 2.2). However, it is important to consider Human-Computer

Interaction (HCI) aspects in development of new solutions. According to Saizmaa and Kim [7],

1 This chapter is a version of the work accepted for publication in 16th International Conference on Human-

Computer Interaction (HCI International 2014)


HCI studies have focused mostly on the interaction between humans and technology, not

considering the importance of home aspects. Nonetheless, it is essential to consider the relation

between users, technology and the domestic environment. There are some challenges of home

control via mobile devices related to the diversity of users. Interface and interaction design for

this context must consider these differences.

This chapter presents the state of the art in home control via mobile devices. Based on

analysis of these solutions, we identify and discuss HCI challenges under the perspective of

diversity. In addition, we propose a set of guidelines in order to minimize or overcome these

challenges. We argue that this work might support design process of new solutions and future

research focusing on domestic space.

The chapter is organized as follows: Section 2.2 presents the literature solutions composing

the state of the art; Section 2.3 introduces HCI challenges for this context under the perspective

of diversity; Section 2.4 discusses research issues and additionally presents the proposed

guidelines; Section 2.5 presents conclusion, and Section 2.6 highlights next research steps.

2.2 State of the Art

This section presents the state of the art of mobile devices for controlling elements of domestic

environment, in the contexts of smart homes as well as home automation. The literature

solutions are organized according to the kind of interface/interaction they present via mobile

devices.

2.2.1 Textual Command Interface

Some solutions do not provide graphical interfaces to support user’s interaction. They enable

users to control their home through text commands, which are interpreted by home systems.

These solutions use mobile telephony services to enable communication, and commands are sent

via SMS (Short Messaging Service), using mobile phone.

Alheraish et al. [12], El-Medany and El-Sabry [13], Ahmad et al. [14], Khandare and

Mahajan [15], Zhai and Cheng [16], Li et al. [17] and Felix and Raglend [18] propose monitoring

and control systems which enable users to control household appliances, sending a message to

switch appliances on or off, and check statuses. These solutions are implemented in circuit and

use several sensors (e.g. fire, motion and temperature). These works focus on illumination control

or home security, for example, intrusion detection, door locking or monitoring. Solutions [15,16]

also use cameras. An example of a control command [15] is “STARTDEVICE 1;

STOPDEVICE 4”, to turn an appliance on and turn another appliance off. Al-Ali et al. [19]

focus on energy management, providing functions to users and utility companies. Users may send

23

Chapter 2. State of the Art and HCI Challenges under the Perspective of Diversity

commands such as “Turn ON AC, Turn OFF WM” to turn air-conditioning on and washing

machine off.

2.2.2 Textual Interface with Visual Layout

Although different interfaces may be designed for appliance control through mobile devices,

several works still provide simple graphical interfaces, with textual information through forms

and menus. Each appliance is represented by a name, which may be the appliance’s category or

an identifier, such as “device 1”. Users change an appliance’s status using elements such as text

fields, check boxes and radio buttons. It provides an enhanced interaction in comparison to

textual command interfaces mentioned in the previous Section 2.2.1.

Some works [20,21,22,23] demonstrate this improvement and provide a dual-approach, i.e.

communication occurs via SMS or an application. Both forms may be used, but the application

acts as an abstraction layer for interaction since users interact with visual interface elements

instead of typing commands. These applications were implemented in Java (J2ME). In the same

way as interfaces, home management evolves and some systems provide other functions in

addition to on/off switches, such as ventilation level [21] and lighting intensity control [22]. In

[24], users may check power consumption of plugged appliances and control home via PDA

applications with Bluetooth or via mobile phones with SMS. Other solutions only provide

application interfaces. The solution proposed in [25] also enables users to change an appliances

voltage level. HouseAway [26] provides a HTML page, the solutions in [27,28,29] provide

applications with textual menus, implemented in mobile C and GVM platform, Java and Python

for Symbian platforms. Systems in this section use microcontrollers, except [23], which uses an

X10 controller with power line communication. Moreover, all works focus on development of

system architecture, not on HCI aspects.

2.2.3 Graphical Interface

With the improvement of processing power and the growth of available resources in mobile

devices, several works introduced graphical elements to promote user interaction. These interface

designs use colors, icons, charts, images and videos in order to provide a better user experience.

Some solutions focus on development of applications and others on complete systems, but they

show a particular concern regarding user interface, unlike works of the previous sections.

Yeoh et al. [30] present the e2Home system, which enables switching home appliances on

or off and controlling a mobile robot. Users interact with a PDA application or sending textual

commands via e-mail. It follows the dual-approach, in which application is an abstraction layer.

Its interface shows icons for each appliance along with its name and a select list with its status,

and a 2D home map for robot control. Oh and Kim [31] present a similar work, which proposes


to control a mobile robot through an Android smartphone for home monitoring. The application

interface only displays the captured images at the center of smartphone screen and direction

buttons.

In [32], a local security system is proposed for Android devices. Users can lock, unlock and

check a door status from a short distance. The application displays the door status and four

buttons, the system uses Arduino and Bluetooth. Solutions [33,34] provide control over

appliances, image capture and alerts for security breach. HASec [33] provides an iOS application

with visual elements following the iPhone Human Interface Guidelines. SmartEye [34] has a Java

application which shows a home plan in 2D view, with appliances in their respective home space

and color scheme to help users identifying appliances status. Rahman and Saddik [35] present a

mobile client to control real home objects through 3D avatar interaction, using Second Life

virtual interface. Since mobile devices lack processing power to render such 3D graphics, it uses a

virtual display technique based on remote rendering graphics at a desktop computer. The

implemented prototype supports touch events, such as swipe and tap, and provides illumination

control, using X10 controllers.

Other systems present functionalities that are more complex. Home-in-Palm [36] provides

an Android smartphone application to configure automatic changes based on time or a user’s

location. In [37], users may define rules, schedule tasks and set priorities, interacting with an

iPhone application, an iPad client and a web client. Homer [38] provides two different

applications, for iPad and iPhone, and enables users to define rules using a language based on

triggers, conditions and actions, with clauses like “when”, “do” and “if”. The system uses a

framework based on OSGi, HTTP and JSON. Dickey et al. [39] provide a cloud service-based

system with an iPad application, which uses touchscreen interaction. Its interface uses several

visual elements, such as touch buttons similar to on/off switches, and regulators to control light

intensity with simple finger dragging. System also displays charts and uses Arduino with X10 and

ZigBee communication. Solutions [40,41] generate user interfaces automatically. uniKNX [40],

an iPhone application, uses configuration files, provided in system deployment, to aid systems

integration with mobile device. Based on these files, it generates interface elements at runtime

and provides local control. The mobile phone application presented in [41], has been

implemented in ASP .NET and JavaScript, and enables users to for example open/close doors,

turn lights on or off, and change color and intensity.

2.2.4 Multi-Modal Interface and Direct Manipulation

Current mobile devices are equipped with specialized technologies and features. Accelerometers,

camera, and NFC (Near Field Communication) are common examples. There are different forms

of interaction beyond textual or graphical user interface, and some solutions already explore these

25


technologies in interface and interaction design. The following solutions focus on home

appliances control addressing some possibilities.

Suo et al. [42] present HouseGenie, a solution for touchscreen smartphones. It provides

multi-modal interaction, integrating recognition engines of speech and handwriting, and enables

to “fusion” multiple modes of interaction, e.g. when selecting an object with a click or touch and

performing and action on this object by voice. It supports click, hold and drag-and-drop gestures,

its interface uses several visual elements and displays a 2D home map. It uses an OSGi-based

infrastructure to interconnect home appliances. Costa et al. [43] focus on interface design and

also provide multi-modal interaction on their accessible interface design proposal to home

control. This work provides voice and touchscreen interaction, and the design is based on icons

and quadrants, targeting people with visual, hearing, motor and cognitive disabilities. The

proposal was implemented over a tablet with Bluetooth communication. Kühnel et al. [44]

propose using three-dimensional gestures with a smartphone for home control. The prototype

was implemented for the iPhone, using accelerometer data for gesture recognition, and

combining touchscreen GUI interaction for more complex actions.

Chueh and Fanjiang [45] propose a context-aware application with automatic interface

generation and direct manipulation. Appliances are discovered using NFC of a smartphone, and

their descriptions are downloaded through Bluetooth. The application then generates the

interface based on user context. It enables local con-trol and uses Arduino. The prototype

provides TV control. Solution [46] proposes combining computer vision and ubiquitous

computing. In this approach, users point a smartphone camera towards a target appliance in

order to recognize it, and then select a function. It requires every appliance to have a visual

fingerprint, which can be a photo or visual descriptions. Chen et al. [47] propose a touch-driven

interaction system to control household appliances. Users touch target devices with a

smartphone, which then captures appliance data and combines it with context information. That

way, touch actions are translated into control actions. As a demonstration, three applications

were implemented, to control a stereo system, media activities on TV, and to connect a

smartphone to a Wi-Fi network.

Based on an analysis of these works, we identified some HCI challenges under the

perspective of diversity, which we present in the next section.

2.3 HCI Challenges under the Perspective of Diversity

When referring to diversity, we consider users with different characteristics, including culture,

age, education, gender, technical skills, knowledge, cognitive skills or use conditions. The

domestic environment, due to its heterogeneous nature, always aggregates a heterogeneous set of

users and diverse use situations. According to Huang [48], a key HCI challenge in mobile


application design is how to make such devices usable and affordable to a heterogeneous set of

users. To overcome this issue, it is necessary to consider social and contextual factors [49] in

order to comprehend users’ needs in their context of use, i.e. home control. The literature

presented in the previous section outlines the state of the art in home control via mobile devices.

Based on an analysis of these works, we identify and discuss HCI challenges under the

perspective of diversity for this specific domain, which are presented below.

Home view: In order to control their homes, users must manage functions provided by

household appliances, which are located in the domestic space. However, how to (re)present this

space to all dwellers? Many solutions represent home as an appliances list, with no reference to

the corresponding home space the appliances belong to [20,21,22,25,28,29,30,33,39]. Other

solutions separate them according to location, based on room selection, such as [41]. Other

approaches are to represent home as an architectural plan in a 2D-view with appliances in their

respective real positions, such as in [34], or as 3D environment with virtual objects, as proposed

in [35]. The 3D approach might enhance immersion and aid in elements assimilation. However,

some people might have difficulties to navigate in these virtual environments. According to [42],

devices identification and monitoring is faster and clearer in 2D-panoramic view than in 3D-view.

Even so, 2D map representation might impose difficulties to interpretation, and changes in

appliances arrangement might require map restructuring. Moreover, there is also the barrier of

displaying spatial representations, 2D or 3D, in restricted screen-size devices, such as the

smartphone. On the other hand, appliances lists may aid users to find the target appliance with

symbolic recognition, with no spatial processing. However, it may not be as immersive as spatial

representations. How to (re)present this space in order to assist diverse users with different

characteristics to identify appliances through mobile devices constitutes a relevant challenge in

this context.

Control complexity: Solutions for home control involve management of a wide range of

appliances, with different functions. Appliances with increasing functions make their control a

very complex task. Their control via mobile devices is even more difficult, given the intrinsic

characteristics of these platforms. Higher complexity functions, such as rule definition like in

[37,38], bring even more challenges. According to Manternaghan apud Manternaghan and

Turner [38], users would like to control their home in a way that does not resemble

programming. But policy definition usually uses conditional statements and commands, which

requires a programming-like interaction. Nylander et al. apud Suo et al. [42] claim that users

prefer using a smartphone instead of a computer to control appliances, since it is more

convenient. Since smartphones have screens with limited size, a challenge for interaction design is

to enable this wider range of appliance management through these devices. Providing solutions

which enables users with different characteristics and usage situations to manage their home

amidst this complexity constitutes another challenge.

27


Interface and interaction flexibility: Regarding interface flexibility, the configuration of

appliances in a home might change over time, e.g. new appliances might be added, removed or

changed in position. The application interface must reflect these changes, including the

customization of automatically assigned identifiers may require customization. Some applications

[21,24,40] reference household appliances and rooms as identifiers. These identifiers might be

application or manufacturer defaults, might not represent the respective object/place efficiently

or logically from a user’s point of view. However, in many cases, graphical interface and system

are tightly coupled, which makes modifications more difficult. Regarding interaction flexibility,

many solutions provide only one form to interact with system. Among 36 solutions presented in

the state of the art, only 3 provide multi-modal interaction [42,43,44]. Although some solutions

[45,46,47] explore other forms of interaction, they do not enable users to use other interaction

modes. This excludes people who cannot use a particular interaction form [50], for example, in

the case of a disability or a temporal limitation due to a specific context of use. For example, a

person doing a household chore, such as washing the dishes, might temporarily not be able to

interact with a touchscreen interface. This challenge has not been addressed/solved in most of

the work presented in the previous section.

Individuality and multi-person interaction: People share space and appliances with

other residents at domestic environment. Several people can control several appliances,

simultaneously or at different times. These appliances usually provide a single interface, common

for all users. Despite home being a shared environment, each individual has a personal

relationship with the space. Even if interface modification is enabled, if it remains common to all

users, issues regarding individuality and diversity still persist. For example, users may accomplish

routine tasks in specific way according to their preferences (e.g. configure light intensity at a

specific value). This characteristic is individual and user interface must reflect it. Another example

is regarding names of home spaces. Even if the application provides modifying names, for

example, from “Room 1” to “John’s Room”, each user should define a particular name, such as

“My Room”, which reflects the own vision of home space. It is therefore necessary to provide

solutions to equitably attend all users, but also reflect the users’ individuality in each interaction,

and it imposes a challenge to this context.

Privacy: Since home is a space that entails individual and personal values, we must

consider privacy in the solution design for domestic spaces. Solutions for home control involve

appliances and environment monitoring, which bring to light the challenge of preserving people’s

privacy. Several works presented in the previous section provide home security systems

[12,13,14,15,16,33,34]. In order to detect intrusion, these systems monitor the environment

extracting private data from cameras or sensors. The camera usage to capture image and videos in

several works [15,16,22,31,33,34] aims to provide better visualization, greater reliability and

feedback, but it may impact user privacy. The privacy issue must also be considered in solutions

that use context information or sensor data captured from mobile device, as in [47]. Data from


user profiles, such as used in [36], also highlights privacy issues, since it contains user preferences

and several personal information regarding domestic routine. Home is a sacred environment in

diverse cultures and the privacy concept might vary among individuals as well as among cultures.

Thus information regarding domestic space requires great attention and imposes a challenge for

new solutions design under this context.

Internationalization and localization: With globalization, potential users of software are

not restricted to a country or region. Home environment is a concept presented in different

cultures across the world, it is thus important that home control applications may be used by

users from different nations and cultural backgrounds. However, these applications are often

developed to support a single language, imposing a challenge for diversity. None of the solutions

presented in the previous section mention multi-language support.

2.3.1 Guidelines

Considering the challenges presented in the previous section, we propose a set of guidelines in

order to minimize or overcome them. In this paper we consider the concept of guideline as

addressed by Stephanidis et al. [51,52], as a general statement that applies in a particular context,

typically subject to further interpretation so as to reflect the requirements of a particular

organization or design case. Below we present our guidelines for the context of home control via

mobile devices.

Consider the dwellers’ perspective: Interface and interaction design of solutions must

consider each dweller’s perspective to (re)present this space, such as space division, references,

rooms and names.

When adopting a spatial representation, offer an alternative non-spatial

representation: Spatial representations, such as maps or virtual environment simulations require

human spatial reasoning skills, which may hinder access by all users.

Abstract low-level information of home control: Application interfaces must abstract

low-level details, highlighting information and simplifying home management and control. It

must provide high-level interaction, e.g. users must interact with elements that group information

and specific resources.

Provide policy management in “natural” approach: If a solution provides policy

management, provide user interaction in the most “natural” way possible, in a way that does not

seem like programming software. Practical alternatives to aid in this process may include

graphical elements usage, such as figures, natural language and gestures.

Enable simple and complex tasks accomplishment: The solution design must account

for people with different goals and levels of “mastery”, i.e. for both beginners and advanced

users, to access basic or complex functions, through mobile interface. Some possible alternatives

29


include configuration features and interface levels (e.g. beginner, intermediate and advanced)

based on users usage and knowledge.

Provide several forms of interaction: Thus, people with no ability to interact through a

certain form of interaction might use another one to accomplish tasks. Mobile devices provide

several features, such as audio, voice and sensors, which enables designers to go beyond the GUI.

Provide a dynamic interface, decoupled from system functionalities: Provide a

dynamic interface, which reflects changes, such as new appliances and floor layout. New

appliances might bring new functionalities. Different vendors might implement functionalities

differently. Decoupling would hide these details from users and provide them with a unified

interface that adapts to changes. This interface should allow users to modify interface elements,

such as identifiers and icons, as well as to insert new images (e.g. regarding new appliances

inserted into the system).

Promote individuality on interface/interaction: Provide features to enable users to

personalize some interface elements and interaction with system. Thus, solution matches the

user’s interests, reflecting their individual characteristics and personal relation with the

environment, attempting specific and personal needs. Saving user preferences, routine actions

and setup values may contribute to personalize interface/interaction and reduce manual

repetition in mobile devices.

Consider privacy on environment, device and user context: The solution design must

consider privacy regarding domestic space, the context data captured from both, environment

and mobile device, as well as personal information provided by users. Some alternatives include

consent and setup features, and all information under this context regarding personal values must

be considered.

Provide internationalization and localization: The mobile application for home control

must provide internationalization and localization, supporting translation of interface elements to

another idiom.

2.4 Discussion

Differently from other works (e.g., [48,49,53,54]), this paper focuses on HCI challenges for the

specific domain of home control via mobile devices. Some works expose HCI challenges for

mobile devices [48,49,53]. However, these challenges only cover issues related to device

characteristics and do not take into account the use context of such devices, e.g. home control.

Likewise, works presenting challenges for home automation [54] only address challenges

regarding the domestic context and do not consider restrictions relevant to mobile devices. This

work addresses both concerns under the perspective of diversity, presenting identified challenges

and relating them with literature solutions.


The set of guidelines presented in this paper requires substantial interpretation by

designers, which might be considered a drawback. Furthermore, the guidelines were not

experimentally validated, and only reflect knowledge and intuition on the specific subject.

However, we chose this format because our goal was to provide a high level support to designers

in this specific domain, supporting them to consider and reflect upon relevant points which

might minimize or overcome the challenges identified in this work. As our literature review has

shown, interaction design of domotic environments is a relatively new area. Once we gathered

more empirical data of designing and evaluating systems in this domain, the guidelines might be

refined and made more operable defining more concrete recommendations or success criteria.

Although the problem domain of home control includes terms such as smart home, most

of the found literature focused on home automation. Therefore, it is important to stress that this

paper do not focus on specific issues regarding ubiquitous computing [55]. Furthermore, despite

recent advances concerning mobile devices, many solutions still lack usage of new forms of

interaction. Most of the state of the art solutions still provide interaction through traditional GUI

and several works do not consider HCI aspects. Nowadays mobile devices present a huge impact

in users’ everyday lives, thus new mobile interfaces and interactions are expected to improve

users’ experiences. Identifying challenges in this context is the first step to tackle them and

provide a better interaction.

2.5 Conclusion

This chapter has presented the state of the art and HCI challenges in solutions for home control

via mobile devices. The contribution of this chapter is to summarize current literature solutions

considering HCI aspects and identify challenges under the perspective of diversity, contextualized

to this specific domain. In addition, we propose a set of guidelines, which may guide the design

process of new mobile applications focusing home control. Our goal is to support designers to

consider relevant points highlighted by the challenges and to minimize or overcome them.

Future work will involve a design, implementation and evaluation of app to control

household appliances following the proposed guidelines. Furthermore, research about other

forms of interaction with mobile devices for this context is required in order to extend the usage

possibilities and attend user and situation diversity.

31


2.6 Decision Making

After this survey regarding state of the art and the identification of the HCI challenges for this

context, it is necessary to continue the research analyzing this domain from different

perspectives. The next step is to make an analysis and elicit requirements for applications from

the HCI point of view. Therefore, the next chapter presents the results of an analysis based on

Organizational Semiotics (OS) theory and the requirements identified through this analysis along

with the literature works previously presented.

Capítulo 3

3 Levantamento de Requisitos baseado na

Semiótica Organizacional

3.1 Introdução

A casa é um ambiente de interação complexo, que envolve conceitos, tradições e rotinas

específicas de seus moradores [9]. Atualmente, o ambiente doméstico compreende uma gama de

dispositivos eletrônicos que visam auxiliar a realização das atividades do dia-a-dia dos moradores.

Para facilitar o gerenciamento e o controle de múltiplos aparelhos, foram propostas diversas

soluções de automação e controle dos dispositivos da casa. A automação residencial permite

automatizar tarefas e provê comodidade e eficiência para os usuários. O ambiente doméstico que

oferece essas soluções geralmente é denominado “casa inteligente”, provendo propriedades de

sensoriamento e adaptação para seus usuários.

Com o avanço das tecnologias de comunicação e o barateamento dos eletrônicos, os

dispositivos móveis se popularizaram nos diversos segmentos da sociedade, mudando a maneira

como as pessoas se comunicam ao redor do mundo. Na América Latina, 98% da população tem

acesso à comunicação via celular2. Somente no Brasil, foram vendidos 35 milhões de

smartphones em 2013, tornando o país o quarto maior mercado de smartphones do mundo3. As

vendas de tablets também impulsionam o acesso a esses dispositivos, com aumento de 119% em

2013. A previsão é que juntos, tablets e smartphones, representem 83% de todo o volume de

dispositivos com conexão à internet no país em 20144. Os dispositivos móveis emergem como

excelentes plataformas de controle e diversas soluções já empregam esses dispositivos para o

2 http://edition.cnn.com/2012/10/09/business/mobile-society-phone-brazil

3 http://br.idclatin.com/releases/news.aspx?id=1613

4 http://veja.abril.com.br/noticia/vida-digital/vendas-de-tablets-vao-superar-as-de-notebooks-no-brasil


controle do ambiente doméstico, pelo qual o usuário realiza suas interações. As soluções

desenvolvidas para esse contexto geralmente focam em aspectos tecnológicos [7], muitas vezes

sem levar em consideração aspectos da área de Interação Humano-Computador em sua

concepção/design.

Porém, o ambiente doméstico se destaca por constituir um papel significativo na vida das

pessoas, reunindo artefatos tecnológicos, mobília e outros objetos de apreço pessoal, o que releva

a importância do estudo desse ambiente [56] considerando fatores humanos, além dos

computacionais. Projetar soluções para esse ambiente único e complexo requer mais do que uma

análise do ponto de vista tecnológico. É necessária uma preocupação acerca dos aspectos

técnicos, interacionais e sociais [57], analisando o domínio através dessas diversas perspectivas.

Dado esse cenário, esse trabalho apresenta os resultados de uma análise sobre o domínio

de controle da casa via dispositivos móveis e levanta os requisitos de interface e interação para

essas aplicações, a fim de auxiliar o projeto de novas soluções para esse domínio levando em

consideração aspectos da área de IHC. Para tal, utilizamos a Semiótica Organizacional (SO) [58]

como referencial teórico-metodológico, para analisar o domínio e, então, elicitar os requisitos

almejados. Cabe destacar, ainda, que esse trabalho foi inspirado em trabalhos que já exploraram o

uso da SO para análise de outros contextos de uso [59,60], diferente do que realizamos nesse

trabalho. Ainda, esse trabalho está inserido no contexto de um projeto de pesquisa em domótica

inteligente norteado pela área de IHC.

O capítulo está organizado da seguinte maneira: a Seção 3.2 apresenta os resultados de uma

revisão da literatura acerca de soluções para controle de elementos do ambiente residencial

através de dispositivos móveis; a Seção 3.3 apresenta a análise de domínio baseada nos artefatos

da SO e na revisão da literatura; na Seção 3.4 são identificados os requisitos de interface e

interação a partir da análise realizada; a Seção 3.5 apresenta a discussão acerca dos resultados; a

Seção 3.6 apresenta a conclusão, e a Seção 3.7 discute as tomadas de decisão da presente

pesquisa.

3.2 Aplicações Residenciais

A seguir, sumarizamos o resultado de uma revisão da literatura acerca de soluções para controle

de elementos da casa em dispositivos móveis. Esses trabalhos abordam diferentes tipos de

interface e formas de interação com o usuário através dos dispositivos móveis. A Figura 1 ilustra

exemplos dos diferentes tipos encontrados nos trabalhos da literatura. Em (a) um exemplo de

interação por comando textual, que é interpretado pelo sistema de controle da casa. Esses

comandos geralmente são enviados por SMS utilizando as redes de telefonia móvel; em (b), uma

interface com informações textuais; em (c), uma interface gráfica que utiliza outros elementos

visuais. Em (d), uma interface multi-modal, que utiliza voz e interação com interface gráfica

35

Capítulo 3. Identificação de Requisitos

touchscreen, em (e), exemplo de um trabalho que utiliza manipulação direta, com interação

diretamente com o dispositivo a ser controlado.

Fig. 1 - Exemplos de formas de interface e interação através dos dispositivos móveis para controle de

elementos da casa. Fontes: [25],[37],[42] adaptado,[47]

Os trabalhos da revisão da literatura são sumarizados na Tabela 1. Os trabalhos foram

categorizados de acordo com a forma de interação apresentada, conforme mostra a primeira

coluna, “Int”. Utilizamos legendas para representá-las da seguinte maneira: A, para Interface de

Comando Textual; B para Interface Textual com Layout Visual; C para Interface Gráfica; D para

Interface Multi-Modal e E para Manipulação Direta. Essa classificação é baseada no

levantamento do trabalho proposto no capítulo 2, apenas dando destaque ao aspecto tecnológico

e de interação das propostas, para auxiliar em uma visão mais clara e concisa.

As demais colunas da tabela são: “Trabalhos”, com a referência dos trabalhos da literatura;

“Propósito”, que mostra os propósitos indicados pelos trabalhos; “Disp”, indica o dispositivo

móvel com o qual o usuário interage; e “Tecnologia Interação”, que indica a tecnologia com o

qual realiza a interação. Na coluna “Propósito”, L/D indica Ligar/Desligar e T/D indica

Trancar/Destrancar. Na coluna “Disp” é utilizada a seguinte legenda para representar os

dispositivos móveis: C para celular; P para PDA; S para smartphone; T para tablet. Na última

coluna, “Aplicação N/E” significa a interação se dá através de uma aplicação com tecnologia não

especificada.

Tabela 1 – Aplicações Residenciais da Literatura

Int. Trabalhos Propósito Disp Tecnologia Interação

A [12],[13],[14],[15],

[16],[17],[18],[19]

L/D lâmpadas/switches,

T/D portas; vigiar casa C SMS

B

[20],[21],[22],[23],

[24],[25],[26],[27],

[28],[29]

Anterior e:

alterar níveis, medir consumo,

L/D mais aparelhos

C,P

SMS; Página HTML;

Apps Java, Symbian e

GVM MobileC

C

[30],[31],[32],[33],

[34],[35],[36],[37],

[38],[39],[40],[41]

Anterior e: movimentar robô,

controlar diversos aparelhos,

regras para ações automáticas

C,P,

S,T

E-mail; Apps web, Java,

iOS e Android

D [42],[43],[44] Controlar diversos aparelhos S,T Aplicação N/E

E [45],[46][47] Controlar TV, stereo system e

diversos aparelhos S Aplicação N/E


Através da tabela, é possível verificar uma evolução acerca da interação dos trabalhos

apresentados, relacionada ao uso da tecnologia. O dispositivo de controle modificou-se ao longo

das classificações. Os primeiros trabalhos utilizam o aparelho celular como dispositivo de

controle e tecnologia SMS. Em seguida, evoluem para aplicações de diversas plataformas, ainda

utilizando celular, como também o PDA. Na terceira categoria, encontram-se todos os

dispositivos: celular, PDA, smartphone e tablet, com aplicações direcionadas a plataformas mais

recentes e com mais recursos. Na quarta classificação, vemos o uso de tablets e smartphones, e

na última, somente o smartphone; ambas com aplicações para plataformas não especificadas.

Essa interação também está diretamente relacionada aos recursos da casa providos pelas

soluções, que constam na coluna Propósito. O conjunto de funcionalidades tende a se enriquecer,

e nas duas últimas classificações, não são oferecidas tantas funcionalidades, pois o foco volta-se

mais para os aspectos de interação ao invés do foco tecnológico. Também nota-se que as ações

de ligar/desligar e trancar/destrancar surgem como as mais providas pelas soluções, seguidas

pelas ações de controles de níveis (alteração de intensidade ou modo de funcionamento do

aparelho) e por último, atividades de mídia, tal como controle de uma TV. O propósito de

vigilância está presente em quase todos os trabalhos.

E ainda, é possível notar a evolução para interações mais naturais. Porém, os trabalhos

presentes na última classificação utilizam interação diretamente com os aparelhos a serem

controlados, possibilitando apenas controle local. Essa proposta vai de contraponto com um dos

benefícios da automação residencial e também das exigências do mundo moderno, que é

controlar remotamente os recursos da residência. Vale ressaltar que a revisão da literatura se

encontra em formato de tabela, pois seu propósito nesse trabalho não é mostrar detalhadamente

cada trabalho, e sim, sumarizar os trabalhos da literatura a fim de identificar aspectos referentes

aos tipos de interface/interação e tecnologia encontrados. Na próxima seção será realizada a

análise do domínio.

3.3 Análise do Domínio

Nesse trabalho, os requisitos são levantados a partir da análise de domínio sob a ótica da

Semiótica Organizacional (SO) e da revisão de literatura. Inicialmente, introduzimos alguns

conceitos da Semiótica Organizacional fundamentais para a compreensão da base teórica dessa

análise, e em seguida, os resultados encontrados a partir da análise realizada.

3.3.1 Base Teórica e Metodológica

A Semiótica Organizacional (SO) [58] é uma disciplina baseada na Semiótica que compreende a

organização como um sistema de signos utilizados na comunicação entre as pessoas. Ela utiliza

37


conceitos e técnicas vindos da Semiótica [61,62] para estudar questões relacionadas aos aspectos

dos diferentes níveis de uma organização (informal, formal e técnico). O estudo acerca dessas

questões e suas influências são importantes para o desenvolvimento dos sistemas de informação

Um dos métodos do conjunto MEASUR (Methods for Eliciting, Analyzing and Specifying

Users’ Requirements) [58] é o Método de Articulação de Problemas (Problem Articulation

Method - PAM). Ele possui diversos artefatos para auxiliar a análise do domínio, dando suporte à

descoberta de partes interessadas, identificação de problemas e soluções, e a expressão e

representação de aspectos em diversos níveis organizacionais.

O artefato Partes Interessadas (PI), um dos artefatos do PAM, permite distribuir os

stakeholders, ou seja, todos os envolvidos com o domínio analisado, sejam diferentes grupos ou

organizações, em camadas referentes aos diferentes contextos de interesse. A identificação dos

atores envolvidos no domínio separadamente por grupos explicitam: (a) quem pode contribuir

diretamente para o desenvolvimento de soluções ou é afetado diretamente (camada contribuição);

(b) quem fornece, é fonte ou faz uso de dados, informação ou elementos da solução (camada

fonte); quem integra o mercado desse domínio (camada mercado); quem possui interesse e/ou

expectativas relacionadas às novas soluções, influencia ou é influenciado no contexto social

(camada comunidade).

Outro artefato do PAM é a Escada Semiótica (ES), que ajuda a clarificar questões do

domínio do problema e separá-las em diferentes visões. Os seis níveis da escada são referentes às

três divisões tradicionais da Semiótica, que são Sintática, Semântica e Pragmática, e a elas foram

adicionadas outras três [63]: Mundo Físico, Empírico e Mundo Social. O Mundo Físico faz

referência ao signo em seus aspectos físicos, tais como propriedades e hardware utilizado; no

Empírico são estudadas as propriedades estatísticas dos signos em diferentes meios físicos e

dispositivos utilizados, como transmissões de sinais, eficiência e codificação; já o nível Sintático

se refere à combinação dos signos sem considerar seu resultado específico, ou seja, a estrutura do

signo. Nos níveis superiores estão o Semântico, que se refere ao significado dos signos, ou seja, a

relação entre o signo e o objeto representado; o Pragmático, em que são analisados a origem, o

uso e o efeito dos signos, ou seja, o propósito de uso; e por fim, o Mundo Social, onde os efeitos

do uso dos signos no contexto social são estudados.

Conforme [64], nosso entusiasmo com os ganhos obtidos com as tecnologias podem nos

fazer negligenciar problemas que podem ser óbvios de outras perspectivas. Portanto, a análise do

domínio é importante para seu entendimento em suas diversas perspectivas, e a utilização da SO

como referencial permite essa análise com uma visão sócio-técnica. Nesse sentido, utilizaremos

dois artefatos da SO: PI e ES. A seguir, os resultados da análise utilizando esses conceitos são

apresentados.


3.3.2 Resultados

O PI resultante da análise do domínio é apresentado na Figura 2. Ele auxilia na identificação dos

stakeholders separados em uma visualização por diferentes contextos.

Fig. 2 – Partes Interessadas resultante da análise do domínio.

Com base nos resultados advindos da análise mostrada no PI, algumas considerações

merecem destaque:

Na camada Contribuição, surgem públicos pouco ou nem citados nos trabalhos da

literatura deste domínio, como donas de casa, criança e idosos. Isso reforça a

necessidade do design de soluções que atenda à diversidade de público, incluindo

essas parcelas da população, que apesar de geralmente possuírem pouco

conhecimento técnico, possuem características de uso distintas. Ainda nesta

camada, também é possível notar que as deficiências do público podem ser

permanentes, tais como as pessoas com deficiências visuais, motoras ou auditivas,

ou podem ser temporárias, como é o caso de donas de casa e outros usuários

realizando tarefas domésticas que, por exemplo, podem exigir uso e ocupação das

mãos, impossibilitando certas formas de interação.

Na camada Fonte são encontradas universidades, centros e institutos de educação –

públicas e privadas – que estão envolvidos com trabalhos relacionados ao domínio.

A maioria desses trabalhos são trabalhos de conclusão de curso, e focam em

questões de baixo nível, como implementação de um sistema em hardware

39


provendo uma interface, porém sem uma maior preocupação com aspectos de

interface e interação com o usuário.

Entre as camadas Mercado e Comunidade, surgem algumas diretrizes vindas dos

esforços de empresas que podem influenciar o design de novas soluções, tais como

as diretrizes de interface para iOS, Android e Java.

A ES resultante da análise do domínio é apresentada na Tabela 2, que auxilia na

identificação de questões relevantes sob diferentes visões do problema.

Tabela 2 - Escada Semiótica resultante da análise do domínio.

N Questões Iniciais Envolvidas

Mu

nd

o S

oci

al

S1. As soluções para controle da casa via dispositivos móveis desenvolvidas

consideram valores humanos? Quais valores humanos essas soluções devem

considerar e de que modo? S2. Quais são os impactos sociais do controle da casa via

dispositivos móveis? O uso de outras formas de interação traz algum impacto no

aspecto social? Será que a disseminação dessa forma de controle poderia causar

conflitos ou alguma forma de discriminação (e.g., por uso ou não uso)? S3. Existe

resistência por parte dos usuários para essa forma de controle? S4. Todos os usuários,

independente da condição sócio-física, são capazes de realizar essa forma de controle?

Pessoas com problemas motores e/ou cognitivos, de diferentes faixas etárias, como

crianças e idosos, analfabetos ou pessoas com baixo-letramento, pessoas de diferentes

classes sociais? Existe alguma restrição financeira que limitam o uso por algum

público? Será que as aplicações atendem à diversidade de público? S5. Que normas ou

leis as aplicações para este domínio devem seguir? S6. Existe algum receio quanto ao

uso de outras formas de interação para controle da casa via dispositivos móveis?

Pra

gm

átic

o

P1. Que funcionalidades devem ser providas pelas soluções para controle da casa via

dispositivos móveis? Que tarefas domésticas e que aparelhos devem estar disponíveis?

P2. O que deve ser explicitado pelo design da interface/interação para controle da casa

via dispositivos móveis? P3. Como o usuário expressa a forma de desfazer uma ação?

P4. Como prover uma interface para diferentes propósitos de uso? P5. Existe algum

usuário e/ou grupos de usuários implícito nas interfaces atuais para controle

residencial?

Sem

ânti

co

Se1. Como garantir que os elementos da interface (e.g., textos, ícones e figuras) para

controle da casa via dispositivos móveis – caso existam – e a forma de interação

proposta sejam entendidos por qualquer tipo de usuário? Se2. Que significados são

interpretados pelos usuários através de diferentes formas de representação dos

elementos da casa via dispositivos móveis? Se3. Diferentes formas de interação via

dispositivos móveis para controle da casa são capazes de realizar a mesma

comunicação?

Sin

táti

co

Si1. Que linguagem de interação para controle da casa via dispositivos móveis poderia

ser utilizada? Si2. Que linguagem aplicar para realizar gerenciamentos complexos?

Si3. A sintaxe varia de um tipo de dispositivo móvel para outro? Si4. Que linguagem

utilizar para representar a casa? Si5. Como avaliar se a linguagem adotada na solução

para controle de ambientes residenciais via dispositivos móveis é adequada – de uso

simples e fácil de aprender – a todos os usuários? Si6. A linguagem de interação via

tela touchscreen do dispositivo móvel pode ser mapeada diretamente por comando por

voz ou interação gestual nesse contexto de uso? Si7. Com deve ser a linguagem da

interação/interface com o dispositivo móvel para que todos os usuários (e.g., crianças,

jovens, adultos e idosos), independente de suas condições físico-cognitiva-sociais

possam controlar o ambiente residencial?

Em

pír

ico E1. Qual largura de banda é necessária, qual a velocidade mínima de conexão

necessária para comunicação entre a aplicação e a unidade responsável pelo controle?

E2. Quais tecnologias permitem essa velocidade mínima?


Mu

nd

o F

ísic

o F1. Qual infraestrutura é necessária para uso das soluções para controle da casa via

dispositivos móveis? F2. Que tecnologia de hardware é necessária para implantação

das soluções de controle da casa via dispositivos móveis? F3. Que tecnologias são

necessárias nos dispositivos móveis para uso pelas soluções para controle da casa? F4.

Como prover soluções para controle da casa que atendam aos dispositivos móveis de

diferentes tamanhos de tela? F5. Quais são os possíveis impactos posteriores de uma

única ação?

Em relação às questões levantadas a partir da análise de domínio de controle da casa via

dispositivos móveis, algumas considerações são destacadas.

Geralmente as pessoas interagiam com os dispositivos móveis somente através de uma

interface gráfica, porém existem outras formas de interação por esses dispositivos. Em relação às

questões S2 e S6, será que existe algum receio por parte dos usuários quanto a isso e qual o

impacto do uso dessas outras formas de interação para controle do ambiente residencial? Por

exemplo, será que a interação por voz pode passar uma imagem de interação para deficientes

motores e pessoas sem esse tipo de deficiência não estão induzidos a utilizá-la?

A questão Si2 refere-se ao desafio do controle de diversos aparelhos e

funcionalidades e ainda, somado às características e restrições dos dispositivos

móveis e dos usuários desses dispositivos, que linguagem aplicar para realizar esse

gerenciamento complexo?.

Em relação à questão Si7, as soluções de controle de elementos do ambiente

residencial podem envolver o uso por público como crianças, que exigem uma

atenção especial. Como deve ser a linguagem da interação/interface com o

dispositivo móvel para que todos os usuários, incluindo esse público, possam

utilizar?

Já as questões Si3 e F4, do Sintático e Físico respectivamente, referem-se às

diferentes características dos dispositivos móveis. Dispositivos com diferentes

interfaces, formas de interação, especificações de hardware e software, que

impactam em aspectos de IHC no desenvolvimento de soluções para esse contexto.

Baseado nos resultados dessa análise, na próxima seção iremos levantar os requisitos de

interface/interação para soluções que visam o controle do ambiente residencial via dispositivos

móveis.

3.4 Requisitos de Interface e Interação

Baseado na análise das soluções da literatura para controle do ambiente doméstico através de

dispositivos móveis e a análise de domínio presente na seção anterior utilizando artefatos da

Semiótica Organizacional, foram identificados alguns requisitos para novas soluções

considerando os aspectos de Interação Humano-Computador.

41


Req1. Representação da casa por ambientes: A aplicação deve permitir a representação

da casa por ambientes, com nomes específicos para cada local. Esse requisito possui correlação

com a questão Si4, sobre como representar a casa. Visto que geralmente os moradores

subdividem o espaço residencial por ambientes, a aplicação deve permitir representar a casa dessa

forma.

Req2. Visualização não-espacial da casa: Nos trabalhos da revisão da literatura

encontramos alguns tipos de visualização da casa, tais como lista de locais e dispositivos, planta

2D e ambiente 3D. Porém, as visualizações 2D e 3D são representações espaciais, que apesar de

aumentarem a imersão no ambiente e facilitarem localização para diversos usuários, exigem

raciocínio espacial, interpretação de mapa e navegação no ambiente, o que pode impor uma

barreira para algumas pessoas. Portanto, a aplicação deve prover uma visualização não-espacial da

casa. Isso não implica que essa deva ser a única forma adotada, pois a aplicação pode prover mais

de uma. O requisito vem da análise dos diferentes tipos de visualização da literatura e das

questões Se1, Se2, Si4 e S4.

Req3. Apresentação da casa no início da aplicação: Independentemente da

visualização utilizada, deve-se apresentar a casa no início da aplicação, visto que é a estrutura que

comporta os elementos controlados. A aplicação deve iniciar introduzindo esse espaço. Esse

requisito surge da questão P2.

Req4. Organização de aparelhos da casa por local da casa e por categoria de

dispositivos: Permitir que os usuários encontrem os aparelhos da casa pelos ambientes em que

se encontram ou pelo seu tipo. Ambas as alternativas visam facilitar o acesso, uma pela navegação

na representação da casa e outra diretamente pelo tipo de aparelho. Esse requisito vem das

questões Si4 e Si7.

Req5. Agrupamento de aparelhos da casa: Permitir que o usuário agrupe os aparelhos

da casa de forma arbitrária, e salve os grupos criados, facilitando acessos posteriores. Esse

requisito vem da análise da literatura e das questões P1, P4 e Si2, de forma a facilitar o controle e

diminuir a complexidade.

Req6. Funcionalidade de busca: Além da visualização já fornecida pela aplicação, deve-

se permitir realização de buscas, de forma a facilitar localização de ambientes, aparelhos ou

grupos. Esse requisito vem de encontro às questões P1, P4 e Si7.

Req7. Atalhos: Permitir que o usuário crie links de acesso rápido (atalhos) para acesso de

recursos da aplicação mais utilizados, tal como grupos de aparelhos ou ações sobre aparelhos.

Esse requisito vem de encontro às questões P1, P4 e Si7, facilitando o acesso e o uso pelos

diferentes usuários.

Req8. Alteração dos elementos da interface: Caso a aplicação proveja uma interface

gráfica, deve permitir alteração dos elementos dessa interface, através das funcionalidades:

inserção de novos gráficos e modificação de identificadores. Esse requisito vem das questões Se1

e Se2.


Req9. Perfis para os usuários: Cada usuário deve possuir um perfil, permitindo

identificar o acesso de cada morador e associar suas respectivas informações, tais como ações,

preferências e configurações. Esses dados devem ficar salvos, visando reduzir a entrada de dados

e facilitando o uso por todos os diferentes usuários. Esse requisito emerge das questões S1, P4 e

Si7, envolvendo a relação e valores de cada indivíduo com a residência, através de uma interface.

Req10. Personalização da interface/interação: A aplicação deve permitir que cada

morador configure sua visualização da casa, identificadores de locais e aparelhos, grupos e

atalhos. Com isso, cada usuário personaliza os recursos da aplicação e elementos da interface de

acordo com suas preferências individuais e de uso. Esse requisito se baseia nas questões S1, P4,

Se1, Se2 e Si7.

Req11. Uma ação sobre vários aparelhos: Caso os aparelhos da casa tenham suporte a

um mesmo comando, a aplicação deve permitir aplicar um comando sobre vários dispositivos

simultaneamente, a partir de uma única interação. Esse requisito se origina das questões P1 e Si2,

e da literatura [41,29].

Req12. Replicação de ações: A aplicação deve permitir ao usuário replicar uma ação

emitida anteriormente. Deve ser possível “copiar e colar” (“Ctrl+C, Ctrl+V”) um comando e

suas especificações. Isso é útil, por exemplo, na definição de políticas. Esse requisito das questões

P1 e Si2.

Req13. Desfazer ou cancelar uma ação: A aplicação deve permitir o usuário desfazer um

comando dado anteriormente (“Ctrl+Z”). Desfazer uma ação nem sempre é possível, visto que

as ações implicam as reações no mundo físico, porém a aplicação deve prover alternativas de,

com um único comando, desfazer o comando emitido anteriormente, e caso não seja possível

desfazer nem cancelar a ação, informar o usuário o ocorrido. Esse requisito surge das questões

P1, P3 e F5.

Req14. Histórico: Deve ser possível visualizar últimas ações realizadas pelo usuário. Esse

requisito vem das questões S6, P1, P2 e F5, e visa permitir maior confiabilidade e esclarecimento

das ações para o usuário.

Req15. Inserção de novos aparelhos: A aplicação deve permitir a inserção de novos

aparelhos da casa, visto que o ambiente pode agregar novos dispositivos. Esse requisito surge da

literatura e das questões P1 e F1.

Req16. Notificações: A aplicação deve prover notificações para o usuário, de forma a

informá-lo das ações ocorridas no sistema. Esse requisito vem da questão P1 e da revisão da

literatura [12,13,14,15,16,17,34].

Req17. Notificações ao usuário quando novos aparelhos forem inseridos: A aplicação

deve permitir que o usuário seja notificado quando novos aparelhos forem adicionados,

permitindo maior controle e ciência dos acontecimentos. Esse requisito tem correlação à questão

S6.

43


Req18. Graus de notificação: Fornecer graus de notificação, no mínimo dois: comum

(aviso) e urgente (alerta). Esse requisito veio das questões P1, P2 e Si2.

Req19. Desativar funcionalidades: A aplicação deve prover recursos para o usuário

desativar funcionalidades, tais como: recebimento de alarmes e utilização de imagens da casa.

Esse requisito está relacionado às questões S1, S6 e P1.

Req20. Interação multi-modal: A aplicação deve oferecer interação multi-modal, ou seja,

diferentes formas de interação, provendo mais de um canal de entrada/saída. A multi-modalidade

permite que pessoas impossibilitadas de utilizar um canal de comunicação, utilize outro. Esse

requisito emerge das questões S4, Si6, P5, Si7, F2, F3 e das reflexões do PI acerca da diversidade.

Req21. Feedback das ações realizadas: Prover retorno ou confirmação da realização das

ações solicitadas pelo usuário. Esse requisito visa confiança do usuário na interação e surge das

questões S6 e P2.

Req22. Diversos tipos de feedback: A aplicação deve permitir diversos tipos de

feedback, tais como visual, sonoro e háptico (vibrar). Porém, caso o dispositivo móvel do usuário

não possua suporte a algum deles, o uso da aplicação não deve ser prejudicado. Esse requisito

vem das questões S2, S4, P5, Se3, Si6, Si7 e F3.

Req23. Utilizar gráficos (imagens ou ícones): Utilizar imagens ou ícones na interface

gráfica, facilitando o reconhecimento de ambientes e aparelhos. Esse requisito vem das questões

S4, P5, Se1 e Si7, visando facilitar o uso pelo público, tal como pessoas não-letradas e crianças.

Req24. Controle de acesso: A aplicação deve permitir definir acesso a recursos do

sistema a cada usuário. Deve ser possível autorizar, bloquear ou restringir acesso, tanto à

visualização de recursos quanto à execução de ações. Esse requisito vem das questões S1, S4, e

Si7. Para permitir maior segurança para usuários como crianças, é necessário limitar o acesso a

recursos. O controle de acesso à visualização ou realização de ações também se relaciona a

valores, tal como a privacidade.

Req25. Termo de uso: No início da aplicação, apresentar um termo de uso para o usuário

a fim de obter seu consentimento para uso e/ou captura de seus dados pessoais e do ambiente

doméstico. Esse requisito surge de encontro à questão S1, e visto que diversas soluções da

literatura utilizam dados de câmeras [15,16,22,31,33,34] e sensores [12,13,14,16,17,18,22,26,28],

além de dados do usuário e informações de contexto [47].

Req26. Controle Remoto: Permitir controle mesmo longe da residência. Apesar de alguns

trabalhos da literatura abordarem interação diretamente com os dispositivos, essa interação

permite controle apenas local, dada a exigência visualização do objeto, seja acompanhada de

interação física ou a visualização à pouca distância. A aplicação deve permitir controlar a casa

remotamente, mesmo longe da residência. Esse requisito surge da questão P1, sendo que uma

funcionalidade provida pelo sistema deve ser controle e monitoramento remoto da residência.

Req27. Interface adequada ao dispositivo: Prover adequação da interface para tablets e

smartphones, dado a diferença significativa entre os tamanhos de tela, que pode ser aplicado ao


design da interface ou apenas na apresentação do conteúdo. Apesar dessas diferenças, as

funcionalidades providas devem ser as mesmas, o que vai de encontro ao design responsivo [65].

Esse requisito vem da questão F4. Na revisão da literatura, geralmente são desenvolvidas duas

aplicações distintas que também diferem nas funcionalidades [37,38]. Porém, visto a questão S4,

não devemos restringir acesso às funcionalidades.

Req28. Diferença entre Ligar/Desligar e Abrir/Fechar: Utilizar indicação diferenciada

para operação ligar/desligar e abrir/fechar, tanto textualmente quanto graficamente, visto que a

última envolve questões de segurança. Esse requisito surge das questões S1, P2, Se1, Se2 e da

revisão da literatura. Os trabalhos abordam ações binárias de ligar/desligar e abrir/fechar e

geralmente, os aparelhos suportam somente uma dessas operações. Por exemplo, uma lâmpada

liga/desliga e uma porta abre/fecha, porém utilizam a mesma representação para ambas as

operações. A indicação de algo “ligado ou desligado” pode não ser suficientemente clara para

indicar “aberto ou fechado”, resultando em problemas de interpretação.

Req29. Visualização multi-nível: Ao utilizar a visualização espacial em forma de mapa

2D para uma das formas de visualização da casa, caso a casa tenha mais de um nível (e.g., vários

andares), apresentar primeiramente os níveis da casa, e somente em seguida, os respectivos

mapas. Esse requisito vem da questão Si4.

3.5 Discussão

Vale salientar que os requisitos obtidos com essa análise, apesar de serem voltados para

interface/interação, abrangem diversas funcionalidades, necessárias para uma melhor interação

nesse contexto. Também, que os requisitos expostos nesse trabalho não estão atrelados a uma

interface específica. Eles se encontram em um nível de abstração que visa à melhoria dos

aspectos de IHC no contexto de controle de ambientes residenciais via dispositivos móveis, e

podem ser aplicados à diversos designs de interface.

Também vale ressaltar que, seguir todos os requisitos pode não ser suficiente para garantir

a melhor interação possível, porém servem de base para os designers de soluções nesse contexto

específico, e o atendimento desses requisitos indicam uma melhoria nos aspectos de IHC da

aplicação. E ainda, para levantar os requisitos de interface/interação para esse domínio, não

fizemos uso das técnicas da Engenharia de Requisitos (ER) [66]. Escolhemos fazer uso da SO,

uma vez que a ER não possui artefatos como o PI, que permitem visualizar o domínio em seus

diferentes contextos de interesse.

Outra consideração importante é que, através da análise do PI, constatou-se que as

soluções para iOS dominam o mercado, apesar do notável crescimento no uso de outros sistemas

móveis. Talvez isso ocorra devido ao foco no público com maior poder aquisitivo de renda.

Porém, o cenário brasileiro favorece o uso de dispositivos de baixo custo. É necessário

45


apresentar essas mudanças nas soluções de interface a serem propostas, que devem estar

acessíveis para todos os usuários. Além disso, ao se projetar novas soluções de interface é

necessário analisar os impactos que elas trarão ao ambiente doméstico.

3.6 Conclusão

Aplicações para controle de elementos da casa via dispositivos móveis possuem um grande

potencial de expansão, porém ainda carecem de maior preocupação com aspectos de IHC. Nesse

artigo, analisamos o domínio de controle da casa via dispositivos móveis através da revisão da

literatura e utilização de artefatos da SO, e levantamos requisitos de interface e interação para

essas aplicações visando o contexto brasileiro. A contribuição desse capítulo é mostrar como a

SO pode ajudar a encontrar os requisitos para esse domínio específico, antes não aplicado. Dessa

forma, esse trabalho agrega valor não só à metodologia utilizada, mas aos demais trabalhos da

comunidade que seguem esse referencial teórico-metodológico em suas pesquisas.

Como trabalhos futuros, com base nos resultados deste trabalho, indicamos a validação dos

requisitos propostos nesse trabalho bem como a implementação de uma instância de interface

trazendo alguns requisitos expostos para testes com usuários.

3.7 Tomada de Decisão

A partir dos resultados obtidos neste capítulo, podemos fazer algumas observações. O

levantamento dos requisitos a partir da análise das soluções da literatura permite focar em

aspectos técnicos e de interface, e mesmo analisando sob a ótica de IHC, não é possível abranger

outras perspectivas. A análise do domínio utilizando os artefatos da SO permite uma análise de

diversas perspectivas, possibilitando analisar questões relacionadas ao público além de aspectos

técnicos.

Através dos requisitos obtidos, podemos observar que eles se aplicam a diversas instâncias

de interface, inclusive, abrangendo diversas plataformas, tais como diferentes sistemas

operacionais. Porém, antes de projetar uma instância de interface é necessário observar o

domínio específico para o qual pretendemos desenvolver. E ainda, a análise da literatura não

realiza um levantamento das soluções do estado da prática, nem a análise da SO. Para tal, o

próximo passo visa levantar requisitos baseado nas soluções de mercado voltadas para a

plataforma específica para a qual desejamos desenvolver: Android.

Capítulo 45

4 Requirements Elicitation based on Mobile

Applications under an Interaction

Perspective

4.1 Introduction

Requirements elicitation requires an understanding of the problem domain in order to analyze

and identify product characteristics which reflect user needs [66]. It is a complex process with

intense information capture and is crucial for development of high quality products. Nowadays,

there is a great demand for updated software in order to meet – ever more selective – customer

expectations. Interaction aspects and aesthetic characteristics stand out as an important

differential [67,68], which deserve careful attention and must guide the product development

process. Constant software updates and user interface modifications mark out a paradigm shift. A

possibility of facilitating interaction is to integrate new solutions into the existing “ecosystem” of

already available products, aiming at improving user interaction.

Mobile devices are integrated into our everyday life activities. In recent years the use of

mobile devices has increased remarkably, attracting new users. Mobile applications, or mobile

apps, have become essential tools for daily tasks, enhancing productivity, communication and

entertainment. Users of these platforms are no longer restricted to applications supplied by

device manufactures. Mobile platforms provide several third-party apps through their

repositories, i.e. mobile app stores, enabling users to search and install apps in a quick, easy and

central manner, and sometimes, free of charge.

5 This chapter is a version of the work accepted for publication in 16th International Conference on Human-

Computer Interaction (HCI International 2014)

47

Chapter 4. Requirements Elicitation based on Mobile Applications under an Interaction Perspective

Due to this ever increasing adoption of mobile technology, it is fundamental to observe

these apps under the Human-Computer Interaction (HCI) perspective, attempting to interface

and interaction aspects of these solutions. Nowadays, several apps are available from various

segments. Just like the mobile phone context, mobile apps for home control are closely related

with people daily tasks. These apps provide control of home elements, whether single appliances

such as a lamp, or several appliances connected to a home automation system. Home control via

mobile de-vices [69,36,32] is a thriving sector, attracting interest of academy and industry. People

used fixed control panels inside the house to control home systems, but with the advantages of

mobile devices, people can control home in an effective and convenient way.

In this paper, we propose a method for requirements elicitation based on apps under the

interaction perspective. Moreover, we present the results of method’s application for

requirements identification of Android apps for home control. This work is inserted into a

research project related to smart homes based on open-source infrastructures [70] and interaction

with multiple interfaces, such as mobile and gesture-based interfaces [71,72,73].

The chapter is organized as follows: Section 4.2 describes the method; Section 4.3 presents

a case study based on the application of the method in order to identify requirements of Android

apps for home control; Section 4.4 discusses the results and research issues; Section 4.5 presents

conclusion, and Section 4.6 addresses research decisions and next steps.

4.2 M4REMAIP

The M4REMAIP (Method for Requirements Elicitation based on Mobile Applications under an

Interaction Perspective) aims at eliciting requirements based on apps’ usage. Based on description

analysis gathered from such use, it is possible to identify important characteristics of apps, aiming

at improving user interaction. This method – Fig. 3 shows an overview of the method – can be

applied in different domains and at different stages in the design lifecycle, e.g. when starting a

new project or updating an existing one. It was inspired by previous work from our research

group [74].

The method consists of five steps, performed in two distinct phases: phase I comprises

three steps and occurs before the apps’ usage, phase II comprises two steps and focuses on the

use of apps and requirements capture. Thus, the five steps of the method are as follows: (I.1)

definition, (I.2) search, (I.3) setup, (II.4) evaluation, and (II.5) extraction.

The definition step (I.1) consists of the target definition. In this step, the elicitation

objective is defined, as well as the target platform – e.g. tablet or smartphone –, the operating

system and, based on this information, the specific device to be used during the process. The

search step (I.2) consists of the search specification and the subsequent search execution. In the

search specification, search parameters are specified: search strategy – i.e. automatic and/or


manual –, keywords, selection criteria – i.e. inclusion and exclusion –, and database. Depending

on information gathered from the definition step, the database will be a specific app store, such

as Google Play®, App Store®, Samsung Apps®, BlackBerry World®, and Windows Phone

Store®. During search execution, the search is conducted according to specification. The setup

step (I.3) consists of download and installation of apps derived from the search step.

The evaluation step (II.4) is based on exploratory use and textual description of mobile

apps. An average time is defined for the exploratory use of each app – e.g. 30 minutes –, and

during the usage, an analysis of features, design and interaction characteristics is performed. This

analysis is performed manually, in order to provide an observation focusing on HCI aspects, with

details from a user perspective. Subsequently, during the description activity, each app is

described textually, with information regarding main functionality and interface characteristics, as

well as positive and negative aspects. During description activity, each app may be used again in

order to provide a brief verification of app interface details.

The extraction step (II.5) consists of the description analysis and the requirements

definition. The description analysis involves reading these textual descriptions, identifying

common or deemed important features, and analyzing whether these functionalities are relevant

requirements for the respective context.

Fig. 3 – Overview of the M4REMAIP.

At the end of the method, requirements are obtained. In addition to functional

requirements elicitation, this method might also be applied to identify possible design solutions

for the domain (vide Fig. 3). These possible design solutions may be obtained from descriptions

reading focusing on a specific feature, observing the differences regarding how it is provided by

apps.

In Figure 3, it is possible to observe a dashed line from description analysis (extraction;

II.5) to description (evaluation; II.4). This is due to the fact that during the description analysis

some characteristics may be deemed more relevant, requiring a deeper and detailed description.

Another aspect is that each step tends to act as a filter, reducing the volume of input – total

amount of apps – from one step to another. For example, in search step, input may be all apps in

49


a repository, but after search execution, only a substrate is output. Subsequently, not all apps of

this resulting set can be downloaded or installed successfully, therefore after setup step, other

substrate is generated. Moreover, depending on amount of apps to be installed, a single,

sequential performance of all method steps might not be possible, since some mobile devices

may present limitations regarding memory and storage. In this case, steps 3 and 4 should be

executed with subsets of the total amount of apps, with each subset uninstall before executing

the procedure again.

4.3 Application of M4REMAIP

This section presents the application of M4REMAIP in the context of eliciting functional

requirements of Android apps for home control. First, we present Phase I of the method, then

Phase II, and subsequently the results obtained with applying the method in this specific domain.

4.3.1 Phase I

In the definition step (step 1) the smartphone was defined as target platform, since it is a more

restrictive device in comparison with the tablet, e.g., regarding screen size. Android was chosen as

operating system, and the specifications of device used in this study are: a smartphone Motorola

Razr i XT890, with Android 4.1.2 (Jelly Bean), configured with Portuguese language, Intel Atom

Z2460 2GHz GPU, 1GB RAM, screen size 4.3” (540x960).

In the search step (step 2), the search strategy was automatic and manual search in Google

Play®. For automatic search, the following keywords were established (in alphabetical order):

“arduino”, “automação”, “automatizada”, “casa”, “control”, “domotica”, “home”, “residencial”,

and “smart”. The app was included if it, according to the app’s description, proposed controlling

home element or home automation system. The manual search consisted of selection among

related apps indicated by Google Play®, according the following inclusion criteria: the app must

present home, building or lamp as icons, or the app must have “control/controle” or

“automation/automação” terms in its tittle. In both search strategies, the exclusion criteria were:

be paid or be shown after 10th position (due to time viability reasons of application of method).

The setup step (step 3) had 35 apps as input from the previous step. All apps were

downloaded and installed successfully, and continued to next step. Steps 3 and 4 were performed

sequentially, with no need of division into apps subsets and uninstall.


4.3.2 Phase II

In the evaluation step (step 4), 1 app from the total amount of 35 apps could not be started:

Domotic Center (by Showroom), version 1.5 demo. Therefore, only 34 apps were analyzed. We

defined 30 minutes for the exploratory use of each app, and subsequently wrote the description.

During the description activity, some apps were used again, with the average duration of 10 to 15

minutes, enabling verification of details regarding interface and some characteristics.

In order to demonstrate the execution of this step, summarized descriptions of apps are

presented follows. We indicate the app developer next to each app name, so as to facilitate

possible searches at Google Play®. In the extraction step (step 5), we point out relevant aspects

identified based on use of apps, which indicate require-ments. These aspects are highlighted in

cyan.

Several apps required user authentication, not enabling a continued exploratory use. Such

was the case of QW Home Automation (by Qingjun Wei), Rogers Smart Home Monitoring (by

Rogers Communications Inc.), HCA Home Control Assistant (by Advanced Quonset

Technology, Inc.) and BeHome 247 (by BeHome247.com). InControl Home Automation Free

(by Moonlit Software) is another example: when started, it shows a sequence of instructions for

installing and configuring the server, which leads to the system’s authentication screen. Another

case is INSTEON for SmartLinc (by INSTEON), which provides two options: one for new

users and another for already existing users. For new users, it shows prerequisites for system

operation, and then, requires authentication.

Smart Automation Experience (by Possible World Wide) starts in authentication screen,

requesting a code, and exhibiting a help button and a link for registration. We performed the

registration procedure, however, did not receive the authentication code requested to visualize

the demo. InSideControl HD (by Schneider Electric Industries SAS) starts exhibiting a screen on

landscape mode, and when we clicked on information option, the app – v.1.1.0 – crashed.

Arduino Lamp (by Benhur Quintino de Souza) provides lamp control. This app can only run five

times, and does not enable visualization of options regarding its features, only a tutorial and

simple settings.

Since we performed the use of apps without a home infrastructure, several apps exhibited

an empty home screen, with a black background along with an overflow button, which reveals an

options menu. Such was the case of wdISY (by 222Designs) and Casa Domotica com Arduino

Mega (by Excontrol Automatización y Domotica). AzHomeTouch (by Azcom Technology S.r.l)

also shows this kind of interface after the authentication process. Its authentication screen

exhibits an auto-login option; after login, there are settings options which include preferences,

import configuration file, logoff and exit. DroidSeer TRIAL Version (by SPVSOFT) also exhibits

an empty screen at startup, however, it allows to add, modify and remove appliances or events,

with names to be specified by users.

51


AtMyHomeLE (by DevQ S.r.l.) exhibits options in a grid. Among them, there are lighting,

automation, cameras, scenarios, installations and favorites. It is possible to navigate between

options but when an option is selected, any information is provided. MyHomeManagerLite (by

Pascal Duray) is a limited version, providing only a subset of features. When the app starts, it

exhibits a message with information about the available features on this version, in order to

notify users.

When SoulissApp (by Alessandro Del Pex) is started for the first time, it exhibits a user

license. The app has three main options at the main screen and a brief description is provided for

each one. For appliances control, it is possible to activate commands based on time, users’

geographical position or sensor data. This app also provides an icon set, with 53 different

options, and connection test feature. Just like SoulissApp, domRemote for Domintell system (by

KZ Software) also starts exhibiting a message with terms and conditions. MobiLinc Lite (by

Mobile Integrated Solutions) provides a link to information regarding terms and conditions, to be

shown on a web page.

Domodroid beta 1.1 (by Pierre Lainé) starts exhibiting a welcome message. The initial

screen shows two options: House and Map. Although we could not access these features without

a home infrastructure, Map encompasses the idea of visualizing a home map, but it was not

possible to verify it. FIBARO (by Fibaro) starts showing a sequence of screens with a step-by-

step guide, and subsequently the app main screen. The main screen is composed of views with

grayed out options, indicating blocked or inactive functionality. A carousel menu at the bottom

of the screen also shows options through swipe interaction.

Home Buddy (by rakstar somar) starts exhibiting configuration options, which include:

setting auto-refresh interval and enable/disable vibration. The main screen has two swipe views

in order to show devices and scenes. There is also an action bar with action items, indicating

voice interaction and refresh, and an overflow button with more options. AutHomationHD (by

Garrett Power) has an interface composed of tabs and two sidebars, accessed by swipe. These

sidebars show several options, such as: search; refresh; voice; about; sort by name, type,

alphabetical order or inverse; and settings. In this last one, options are shown in different settings

categories. The app sends an audio feedback if a voice command is not found. HAL-Home

Automation @ Language (by Richard T. Schaefer) provides voice interaction and also enables

users to assign touch gestures to commands. When the app is started it emits audio instructions

regarding user settings and its interface is composed of swipe views.

Several apps provide a home control simulation in a demo mode. SRGio (by Alexus Art)

offers a demo through authentication with user/password as guest/guest and its interface is

composed of tabs. An important characteristic regarding appliances control is a single button to

turn on/off, which also indicates the current state. Vera Mobile (by Alexus Art) is identical to the

previous app as well as MiControl (by Alexus Art), but the last one is a Spanish version. I-WISH

Smart Home (by Innova Egypt) provides demo with authentication with user/password filled in


automatically. The app enables selecting or adding a server, and to assign a name, address and

port to it. Other characteristic is the language selection, with two available idioms, i.e. English

and Arabic.

Lifedomus (by Lifedomus) also provides a demo mode. Its interface is based on tabs, with

several options, such as visualization by rooms and activities history (log). Regarding log feature,

it is possible to show a complete log or filtering by alarms or events (requested actions).

ayControl KNX and more (by easyMOBIZ.com) starts in demo mode, exhibiting rooms grouped

by home floor. It is possible to import profiles, visualize and enable/disable log, and customize

the interface with themes. SmartHome One by SMARTIF (by SMARTIF) starts showing options

regarding authentication and demo offline, and displays household appliances by rooms or by

type. Like other apps, Cisco SC Residence (by Cisco Systems, Inc.) provides a simulation mode

and has a graphical interface with appliances arranged in a circle. Depending on selected

appliance, different control elements are displayed, and for each device, an icon indicates the

current status.

HSTouch Home Automation (by HomeSeer Technologies) and CMClient (by

ComfortClick) provide simulation through a demo server. HSTouch Home Automation allows

controlling home appliances, checking room climate and sending commands based on events.

For appliances control, the app displays a dedicated screen for each appliance with its control

options. In settings, it is possible to change server data, and separately, authentication data.

CMClient presents a user interface similar to a desktop or launcher, with several options and a

menu at the bottom of the screen accessed by swipe. Among options, there are calendar, mode

selection, energy consumption, language selection and messages, which include e-mail, alerts and

events.

ImperiHome (by Evertygo) offers interaction via tap, hold, swipe and voice. The main

screen is composed of swipe views organized by main rooms. The app provides scenes, which

allow execution of commands set. Regarding home appliances – home objects – it is possible to

modify its name and icon, and add each one as favorite, hide or exhibit it. Also, images set

represent the different status of the home objects. Moreover, users may add a scene shortcut in

device home screen.

Table 3 summarizes 34 apps addressed in Phase II of the method. This table presents the

column names: “Ver.” indicates app version; “Infra.” indicates the app availability for use without

infrastructure; “Conn.” indicates whether connection data, e.g. IP address, URL, is presented –

and how – at user interface; and “Auth.” indicates whether authentication data, e.g.

user/password, is presented – and how – at user interface. At column “Infra.” we used the

following classification: (N)one when app does not provide navigation; (P)artial functionality,

when app provides some functionality, however does not allow to simulate appliances control;

and (F)ull functionality, when app provides all functionality and allows simulating appliances

53


control. At columns “Conn.” and “Auth.”, we used the following caption: “N” for does not

require, “S” for require on screen, and “C” for requires in configuration settings.

Table 3 – Android apps identified and analyzed applying M4REMAIP

Icon Name Ver. Infra. Conn. Auth. Language

QW Home Automation 1.1.11 N S S English

Rogers Smart Home Monitoring 5.0.5 N N S English

HCA Home Control Assistant 11.2.11 N C N English

BeHome 247 1.1.1 N N S English

InControl Home Automation Free 2.0.9 N N S English

INSTEON for SmartLinc 1.2.3 N N S English

Smart Automation Experience 7.1.1 N N N English

InSideControl HD 1.1.0 N C N English

Arduino Lamp 1.0 N N N English

wdISY - N C C English

Casa Domotica con Arduino Mega 4.0 N S N English

AzHomeTouch 0.6.5 N C S English

DroidSeer Trial Version - P S S English

atMyHomeLE 1.0.56 P N N Portuguese

MyHomeManagerLite 1.0.1.0 P C N English

SoulissApp 1.2.31 P N N Portuguese

domRemote for Domintell system 1.1.22 P C N English

MobiLinc Lite 1.2.4 P N S English

Domodroid beta 1.1 1.1 P C N English

FIBARO 1.1 P S S English

Home Buddy 0.37 P C N English

AutHomationHD 3.1.3.5 P C C English

HAL-Home Automation @ Language 1.006 P S S English

SRGio 1.9.107 F N S English

Vera Mobile 1.9.107 F N S English

Micontrol 1.9.409 F N S Spanish

I-WISH Smart Home 1.1 F C S

English /

Arabic

Lifedomus 1.4.1 F S N Portuguese

ayControl KNX and more 3.0.9 F N N English

SmartHome One by SMARTIF 1.8.9.2 F S S Portuguese

Cisco SC Residence 2.5.2.210567 F N S English

HSTouch Home Automation 1.35 F C C English

CMClient 2.0.2 F C C

English /

Others


Icon Name Ver. Infra. Conn. Auth. Language

ImperiHome 1.9.2 F C C English

4.3.3 Requirements and Design Ideas

After executing Phases I and II of the method, we identified 45 functional requirements,

organized in eight categories: (a) general, (b) first startup, (c) configuration, (d) connection, (e)

authentication, (f) feedback, (g) home objects, and (h) control.

(a) GENERAL – R1. About: Provide information about the app; R2. Available

features: Provide information regarding available features, especially when the app is a limited

version; R3. Brief description: Provide a brief description of each feature; R4. Demo: Provide

a simulation of home infrastructure in order to enable appliances control. Thus, users may

interact and test app features. This simulation may be provided by demo mode, demo server, or

authentication with user/password filled out automatically.

(b) FIRST STARTUP – R5. User license: Exhibit user license, with options to accept or

refuse terms and conditions; R6. Welcome message: Exhibit a welcome message; R7.

Tutorial/instructions/step-by-step: Provide instructions and presentation of apps features, in

a sequence of screens with a step-by-step guide; R8. Prerequisites for system operation:

Display information about required hardware/software artifacts and necessary conditions for

system operation; R9. Help: Provide an option with help information.

(c) CONFIGURATION – R10. Settings categories: Exhibit options grouped into

categories, according similar configuration purposes; R11. Configuration file: Provide an option

to send a configuration file, containing settings data; R12. Connection and authentication

separately: Exhibit server connection information separately from authentication; R13.

Language: Provide options to language selection, in order to change the idiom of displayed

information.

(d) CONNECTION – R14. Server data: Provide options for data input related to server

such as name, address and port; R15. Connection test: Provide connection test in order to user

test connection with home system; R16. Refresh: Provide option to refresh, implying in a new

query and update of displayed information manually; R17. Auto-refresh: Provide automatic

updates based on new queries to the system; R18. Refresh interval: Provide option which

enables users set the time interval to automatic updates; R19. Logout option: Provide an option

which enables users to close the connection with the home system.

(e) AUTHENTICATION – R20. User/password: Provide authentication with user

and password; R21. Auto-login: Provide an option which enables users to choose to login to the

system automatically during the app startup.

55


(f) FEEDBACK – R22. Audio feedback: Provide audio feedback, in order to warn users

of actions performed in the system; R23. Haptic feedback: Provide haptic feedback, in order to

notify users of actions performed in the system; R24. Enable/disable audio/haptic feedback:

Provide option to enable/disable the audio or haptic feedback; R25. User interface with grayed

out options: Display interface grayed out elements if features provided through interaction with

these elements are blocked or inactive; R26. Full log: Provide a full history of actions occurred

in the system; R27. Log with filter by alarms and events: Provide filtering options regarding

log information, enabling filtering by alarms or events (requested actions); R28. Enable/disable

log: Provide option to enable/disable log functionality; R29. Alert messages: Display messages

with urgent information (alerts); R30. Event messages: Display messages with information

regarding actions performed by the system.

(g) HOME OBJECTS – R31. Objects displayed by rooms: Display home objects by

rooms; R32. Objects displayed by type: Display home objects by type of appliance; R33.

Modify name: Provide an option which enables users to modify object names identifying each

appliance; R34. Modify icon: Provide an option which enables users to modify object icon

identifying each appliance; R35. Icon set: Provide an icon set, enabling user to assign an icon to

each object; R36. Images indicating status: Provide images which represent home objects and

their current status. An image set must represent different status of each home object; R37.

Favorites: Provide an option which enables users to select objects and mark them as favorites.

(h) CONTROL – R38. Commands based on time: Activate commands based on a

predefined time; R39. Commands based on position: Activate commands based on users’

geographical positions; R40. Commands based on sensor: Activate commands based on

sensor data; R41. Commands based on events: Activate commands based on events occurred

in the home system; R42. Single button to turn on/off: Provide a single button to turn on and

turn off actions; R43. Dedicated screen for each appliance: Display a dedicated screen for

control options of each appliance; R44. Scenes: Provide an option which enables executing a

command set related to a particular usage scenario; R45. Scenes shortcuts: Provide shortcuts to

scenes activation.

We also identified some possible solutions with regard to interaction: graphical interface

with tap, hold and swipe gestures; voice commands. Moreover, we identified some possible

solutions for the “Settings” functionality, which include possible icons to represent the

functionality and possible locations inside mobile app interface. Some possible locations include:

pop-menu in an overflow button at action bar; carousel menu at the bottom of the screen;

navigation drawer (sidebar); button at home screen. With regard to icon aspects, we identified

some suggestions, as shown in Figure 4.

Fig. 4 – Some possible design solutions – icons – to functionality “Settings”.


4.4 Discussion

The results presented in previous section represent a non-exhaustive set of functional

requirements for Android apps for home control. Some considerations show relevant aspects and

are outlined below. Firstly, a difficulty in applying this method for this specific domain is that

many apps require a real home infrastructure in order to evaluate all functionalities. Despite we

could not proceed with exploratory use with several apps, this method demonstrated to be useful

and enabled identifying requirements for this domain. Moreover, implementing requirements

addressed in this paper also requires home system and the infrastructure integrated to the app.

With regard to user interface, it may be observed that most apps do not follow Android

design patterns. Several apps do not provide the ActionBar, and some solutions provide both

logout and exit buttons, contrary to the guidelines [75]. Another important observation is that

most app interfaces use dark tones, with gray and black colors. This is contrary to the design

principles of current automated and smart homes, which adopt glass and transparent materials

and use white and light colors. Regarding user interaction, it is worth mentioning that some apps

provide voice interaction, using Android resources for voice recognition. However, apps still lack

the use of other interaction modes. During exploratory use, we did not identify the use of

accelerometers for a direct interaction related to control, such as command activation or feature

selection. Regarding language, although some apps provide major information in a local language,

some messages or interface elements are not translated. This fact emphasizes the importance of

language support, as well as other localization and internationalization aspects of app design.

There are some interesting remarks regarding the method which deserve further

comments. The two activities related to evaluation step – exploratory use and description – are

mutually complementary. Exploratory use provides an overview of interface aspects and app

features, while the description activity enables attempting to interaction details. Subsequently, the

extraction step provides the deeper analysis and identification of functional requirements.

Several requirements impact interaction aspects of an app, e.g. log, and might be

discovered by applying the method proposed in this paper. The proposed categories for

functional requirements aim to aid understanding of the context and implementation of such

requirements, however, other classifications could be proposed for this purpose. Moreover,

based on descriptions and the design solutions, it is also possible to identify design patterns [75]

used in apps, as clearly noted in location suggestions to functionality “Settings”. Regarding

possible solutions, we focused on interactions and the “Settings” functionality in order to

demonstrate some examples, but other design solutions could be found.

It is noteworthy that requirements elicitation methods from the point of view of Software

Engineering are often directed by the perspective of user interaction via a graphical interface and

involve document investigation or contact with people associated with product/system usage.

57


This method might be useful for different audiences, from academia, such as researches trying to

identify characteristics on apps for this research domain, to industry, such as autonomous

developers, startups or companies with small development teams.

4.5 Conclusion

This chapter presented the definition of a method – M4REMAIP – and results of its application

in requirements elicitation of Android apps for home control. In order to achieve this, we

analyzed apps in this specific domain under an HCI perspective, considering design and

interaction issues. Based on this analysis, we identified important features and characteristics for

Android apps for home control. Results obtained with the execution of this method demonstrate

its usefulness for functional requirements elicitation focusing on interaction aspects.

For future work, we envision the design and implementation of an Android app based on

functional requirements identified in this chapter, and also, application of the method defined in

this work to other domains.

4.6 Decision Making

Based on the results obtained with this research, the next step is the design and implementation

of an Android application for home control. It is worth highlighting the reasons for choosing

Android as the target platform. First one is the market growth in this segment. According to

market reports, Android is the most-used smartphone platform worldwide. In addition, in

financial terms, Android is more cost-effective than iOS system, which in turn currently is the

main target platform in Brazilian market for home automation (according to domain analysis

results from chapter 3). With the situation of both platforms but the growth prospectus and

advantages of Android, it is the selected platform.

Capítulo 5

5 Design e Implementação do Aplicativo

HandyHome

5.1 Introdução

Designers de IHC visam criar produtos interativos para o uso humano [48]. Isso envolve a

utilização e desenvolvimento de processos, métodos e ferramentas a fim de facilitar o design de

interfaces eficientes que atendam as necessidades dos usuários. Projetar essas interfaces e também

interações para soluções dentro de qualquer contexto deve levar em consideração um estudo

aprofundado dos usuários dessas soluções a fim de compreender suas necessidades em seu

contexto de uso, compreendendo suas interações com a tecnologia e com o ambiente. Desta

forma, o domínio de IHC contribui para a melhoria de soluções computacionais, trazendo

benefícios para a forma com que as pessoas interagem com a tecnologia.

Porém, não basta considerar aspectos da interação. Os fatores estéticos também podem

influenciar a interação dos usuários e devem ser levados em consideração, visto a sobreposição

entre os princípios de IHC e do design. Dentre os diferentes conceitos de design e os campos

que o envolvem em sua definição, o comum entre eles é o desenvolvimento/concepção de um

plano ou esquema para execução posterior [76]. Para tal, é necessário conhecimento acerca do

uso e do domínio-alvo, juntamente com suas restrições. Nesse sentido, ambos os campos se

complementam. Portanto, no desenvolvimento de novas soluções computacionais, devem ser

considerados os aspectos de interação relacionados aos usuários, ambiente e tecnologia,

juntamente com um projeto detalhado de interface/interação considerando aspectos estéticos

dentro das restrições de tecnologia existentes.


A disseminação de tecnologias móveis é uma realidade que impõem desafios para o

desenvolvimento de novas aplicações, seja no ponto de vista tecnológico quanto de caráter de

uso por todos os usuários. Com a crescente demanda de aplicações para diferentes contextos,

torna-se necessário analisar os diferentes domínios e verificar suas particularidades associadas às

características de interação com esses dispositivos. Aspectos estéticos dessas soluções também

têm sido investigados e são um ponto relevante no desenvolvimento de novas soluções, dado o

cenário móvel, que exige captura de atenção do usuário, rápido acesso e uso frequente, o que

estimula a procura por novas soluções e aumenta a expectativa dos usuários.

Dentro desse contexto, propomos o design e implementação de um aplicativo para

controle de recursos do ambiente residencial via dispositivos móveis. Nosso objetivo é

desenvolver uma aplicação para controle residencial considerando aspectos de

interface/interação. Para isso, nos baseamos em trabalhos anteriores, nos quais identificamos os

desafios desse contexto sob a perspectiva da diversidade (capítulo 2) e levantamos requisitos de

interface/interação para as aplicações nesse contexto baseado em uma visão sócio-técnica do

domínio (capítulo 3). Escolhemos Android como pataforma-alvo, dada sua ampla utilização,

focando especificamente em smartphones. Portanto, também nos baseamos em (capítulo 4), no

qual foram levantados requisitos com a aplicação de um método para levantamento de requisitos

baseado no uso de aplicativos.

Nossa contribuição é demonstrar o impacto de aspectos estéticos nas soluções para

aplicações de controle do ambiente residencial, bem como alguns desafios no desenvolvimento

de aplicações nesse domínio na aplicação prática. E ainda, propomos uma instância de interface

considerando os diversos aspectos abordados com foco em IHC. Este capítulo está organizado

da seguinte forma: a Seção 5.2 introduz o conceito de aplicações para controle residencial via

dispositivos móveis e mostra alguns trabalhos relacionados; a Seção 5.3 demonstra a estrutura da

aplicação proposta; a Seção 5.4 apresenta o design da interface e da interação da aplicação

desenvolvida; a Seção 5.5 discute alguns resultados obtidos; a Seção 5.7 apresenta as conclusões,

e a Seção 5.8 finaliza o capítulo com os próximos passos dentro da presente pesquisa.

5.2 Aplicações para Controle Residencial Via Dispositivos

Móveis

Com o avanço tecnológico, os dispositivos móveis estão se tornando cada vez mais eficientes em

lidar com tarefas que antes só poderiam ser processadas por computadores convencionais, e as

redes de comunicação móvel estão se tornando mais comuns, dentro e fora das residências. Esse

cenário fornece o ambiente necessário para o crescimento e desenvolvimento de tecnologias

móveis aplicadas ao controle residencial. Os dispositivos móveis emergem como plataformas de

controle viável, fornecendo uma interface unificada. O uso de sistemas de controle e automação

61

Capítulo 5. Design e Implementação do Aplicativo HandyHome

residencial permite ao usuário executar ações no ambiente doméstico de maneira fácil, cômoda e

até mesmo automatizada. A gama de ações que esses sistemas possibilitam pode incluir desde a

execução de tarefas simples como ligar e desligar lâmpadas ou outros eletrodomésticos da casa,

travar e destravar portas, até a execução de tarefas mais complexas, tais como monitorar

remotamente o estado de diversos aparelhos e gerenciar ações automáticas de vários dispositivos

da casa baseado em um conjunto de regras pré-estabelecidas. De fato, já existem diversos

sistemas no mercado voltados a automação residencial, no entanto, esses sistemas geralmente

controlam um conjunto de aparelhos específicos ou de uma empresa especifica.

A quantidade de aparelhos eletrônicos utilizados no ambiente doméstico é crescente,

fornecendo diferentes funcionalidades e características. Portanto, o design da interface deve

suportar a escalabilidade do sistema, permitindo que qualquer número de objetos seja

reconhecido e exibido, bem como todos os serviços fornecidos por esses objetos. O design da

interface de um sistema de controle do ambiente residencial também deve levar em consideração

algumas questões, tais como a quantidade de atributos ou estados a serem exibidos, os tipos de

controles utilizados na execução de tarefas, e a relação desses controles com os atributos

exibidos. Diante desse cenário torna-se inviável a criação de uma interface estática para o sistema,

visto que os elementos que a compõem podem variar dependendo da composição atual do

ambiente. Porém, a maioria dos trabalhos da literatura utilizam um pequeno conjunto de objetos,

ou vários objetos com conjunto restrito de funcionalidades [21,22,25,32].

Somado a isso, ainda há pouca ou nenhuma preocupação com o projeto de interface e

interação da aplicação, devido ao foco nas características tecnológicas do sistema, como visto em

[12,13,14,15,16,17,18]. Suo et al. [42] se destacam nesse sentido, mostrando maior preocupação

com aspectos de interação na solução proposta, com interação multi-modal para smartphones

touchscreen. Porém, não há preocupação específica com o aspecto da diversidade de usuários no

projeto de interface, e a solução apresenta uma interface gráfica complexa. Já o trabalho de Costa

et al. [43] foca no design de uma interface acessível para controle de objetos do ambiente

doméstico, focando no grupo de pessoas com deficiências visuais, auditivas, motoras e

cognitivas. Porém, traz uma proposta de design de interface baseada em quadrantes, mostrando

apenas quatro cômodos de uma casa, o que limita bastante as opções a serem exibidas em um

cenário real.

A geração automática de interface pode auxiliar nesse sentido, provendo maior

flexibilidade, aumentando o desacoplamento entre a interface provida ao usuário e as

funcionalidades do sistema. Alguns trabalhos já foram feitos nesse sentido, como [77], em que é

proposta geração automática de interface baseada em modelos para aplicações que controlam

elementos do ambiente residencial. Porém não possui o projeto de uma aplicação considerando

diversos aspectos de IHC e formas de interação voltadas para dispositivos móveis,

especificamente, smartphones. Kartakis et al. [41] e Chueh e Fanjiang [45] também propõem

geração automática de interface em suas aplicação voltadas para smartphone. Porém, nenhuma

aplicação citada considera aspectos estéticos específicos referentes ao design da interface a ser

gerada considerando a perspectiva da diversidade.

A aplicação proposta neste capítulo, denominada HandyHome, possui um projeto de

interface e interação considerando a perspectiva da diversidade. A perspectiva da diversidade é

considerada na abrangência de público e situações de uso, no contexto do controle do ambiente


residencial via dispositivos móveis, especificamente o smartphone. Essa aplicação foi

desenvolvida considerando diferentes dimensões, no que se refere à tecnologia, aos usuários e ao

ambiente, baseando-se em passos (capítulos 2, 3 e 4) realizados ao longo dessa pesquisa.

HandyHome provê controle sobre aparelhos de uma residência através da comunicação com um

sistema que oferece todos os serviços e a infraestrutura da casa. A partir dessas informações, a

interface é gerada dinamicamente, esta, por sua vez, foi projetada considerando padrões de

interface do sistema Android [75]. O projeto de implementação do sistema, assim como o design

da interação e da interface da aplicação proposta serão detalhados a seguir.

5.3 Implementação

Nesta seção apresentamos uma visão geral da estrutura do sistema utilizado em nossa aplicação, e

alguns detalhes sobre a implementação da aplicação relacionados com a geração da interface.

5.3.1 Estrutura do Sistema

Para prover desacoplamento entre a interface e a lógica do sistema, utilizamos uma infraestrutura

para lidar com detalhes de baixo nível do sistema. HouseHub6 é a infraestrutura de software

responsável pela lógica e comunicação do sistema da casa. O sistema de código aberto foi

desenvolvido em PHP e disponibiliza informações sobre os objetos da casa, tais como os estados

atuais e funções oferecidas, além de transmitir os comandos para os objetos, de maneira

centralizada. HouseHub oferece essas informações em formato JSON através de serviços web

para as aplicações, que atuam como interfaces para a utilização do sistema. Desta forma, a

aplicação foca em aspectos de interface e interação, separadamente da lógica do sistema.

HouseHub suporta comunicação com objetos da casa que utilizem Arduino, juntamente com o

toolkit Arduino Micro Home Blocks7. A Figura 5 mostra uma visão geral da arquitetura do

sistema.

A aplicação, denominada HandyHome8, foi desenvolvida para plataforma Android, para

dispositivos com versão 4.1 (Jelly Bean) ou superior. A estrutura da aplicação é constituída

basicamente por quatro partes: a parte central da aplicação, uma parte para conexão com o

sistema da casa, uma parte para interpretação de JSON, e outra para geração de interface.

6 https://code.google.com/p/househub/

7 https://code.google.com/p/arduinomicrohomeblocks/

8 https://code.google.com/p/handyhome/

63


Fig. 5 – Arquitetura do Sistema

5.3.2 Geração Automática de Interface

Um dos objetivos da nossa aplicação residencial é possibilitar controle de uma variada gama de

aparelhos, que por sua vez possuem diferentes tipos de serviços, dando suporte à inserção de

novos aparelhos nesse ambiente. Para isso, utilizamos geração dinâmica de interface. As

funcionalidades (serviços) oferecidas pelos objetos a serem controlados tem grande impacto na

interface. O tipo de interface deve ser diferenciado dependendo do tipo de serviço

disponibilizado, possibilitando assim maior flexibilidade para o controle (ativação) daquele

serviço.

Por exemplo, na Tabela 4 apresentamos alguns exemplos de controles utilizados em

interfaces gráficas. Essas interfaces foram agrupadas de acordo com uma classificação por tipos

de serviço que possuem formas de interação semelhantes. Na coluna Interfaces de Controle,

podemos verificar exemplos de diversas soluções de interface para um mesmo tipo de interação,

que depende da natureza do comando. Ou seja, a natureza do serviço infere na forma de controle

apresentada.

Dessa forma, faz-se necessário que as informações obtidas do sistema quanto aos tipos de

serviços oferecidos pelos objetos tenham um significado correspondente, de forma que a

aplicação possa prover ao usuário um tipo de interação adequado para o controle que aquela ação

representa. Decisões acerca da interface de controle específica a ser gerada ficam a cargo da

aplicação, porém devem ser baseadas em informações dos serviços que cada objeto oferece.

Portanto, foram utilizados diferentes níveis de abstração, de forma que se mantenha a semântica

da informação.

Para isso, foram utilizados os denominados schemas, que são descrições dos serviços

providos pelo hardware, no caso, Arduino. Todo objeto deve ter uma descrição de suas

funcionalidades (serviços oferecidos), das relações entre status e serviços, além de informações


sobre suporte a idiomas, oferecidas nesse arquivo. O sistema de controle e comunicação da

infraestrutura da casa, HouseHub, acessa esses arquivos e obtém as informações de baixo-nível,

repassando para a aplicação. A Figura 6 mostra a comunicação com a aplicação.

Tabela 4 – Exemplos de Interfaces de Controle

Tipos de Comando Funções Interfaces de Controle

Booleano

Ligar, Desligar

Abrir, Fechar

Ativar, Desativar

*

Com parâmetro granular Intensidade (%)

Volume (%)

Com parãmetro gradual Temperatura

Canal de TV

Fig. 6 – Comunicação com o Sistema

A aplicação possui um algoritmo que, baseado em um conjunto de regras, interpreta as

informações, que são passadas de baixo-nível para o nível semântico. Esse processo de abstração

permite que a aplicação possa escolher o elemento de interface mais apropriado para cada serviço

provido pelo objeto, voltado especificamente para a interface desenvolvida. Vale ressaltar que

esse procedimento ocorre com um conjunto pré-estabelecido de opções de elementos de

interface e relação de significados, porém permite maior flexibilidade ao sistema do que uma

interface totalmente estática. Na aplicação HandyHome, os elementos de interface exibidos são

específicos do padrão Android, dada a plataforma para o qual o aplicativo foi desenvolvido.

65


5.4 Design

A dificuldade em projetar interfaces para esse domínio consiste na quantidade e complexidade de

informações que devem ser disponibilizadas para o usuário de forma que permita um controle

rápido, simples e eficiente. A apresentação dessas informações não pode ser complexa, deve ser

simples como as atividades diárias na casa, tal como acender uma lâmpada.

A origem do nome da aplicação, denominada HandyHome, vem do significado do termo

“handy”, que pela definição tem-se “à mão, perto, acessível, cômodo, hábil, destro, conveniente”,

juntamente com o termo “home”, visto que a aplicação visa o controle de objetos de uma casa. O

nome escolhido remete à ideia de prover ao usuário o controle de sua casa de forma cômoda e

acessível, ao alcance da sua mão, através da interação com seu smartphone. A partir da estrutura

do sistema e dos requisitos de interface/interação levantados em trabalhos anteriores, uma

proposta de design para a aplicação móvel foi elaborada considerando aspectos de interface e

interação. A proposta de cada um deles será detalhada a seguir.

5.4.1 Interação

Considerando a diversidade do público-alvo presente no ambiente residencial e os recursos

comumente presentes nos dispositivos móveis, foram propostas três formas de interação através

da aplicação: (a) interação visual via touschscreen, (b) interação por voz, (c) interação por gestos

(movimentação do dispositivo).

Com a ascensão da tecnologia touchscreen nos smartphones, essa forma de interação foi

selecionada para interação visual, visto sua predominância em smartphones e acessibilidade para

controle de dispositivos [42]. A interação por voz foi escolhida como outra forma de interação,

de forma a abranger o público com deficiência visual e também, pessoas impossibilitadas

momentaneamente de interagir via interface touchscreen, situação comum no ambiente

doméstico. Dessa forma, essa interação visa facilitar o uso em diversas situações do dia-a-dia de

uma residência. Por fim, a interação por gestos, através da movimentação do dispositivo, foi

selecionada como terceira forma de interação devido a pesquisas recentes que demonstram a

viabilidade da utilização dessa forma de interação para controle do ambiente residencial. Essa

forma de interação já vem sendo aplicada em outros trabalhos, como em [44].

Dessa forma, a proposta de uma interação multi-modal atenderia a diversidade de público

presente no ambiente residencial, e segue a proposta do design universal [78], que visa criar

produtos que sejam utilizados por todos, independente de habilidades físicas ou cognitivas. Vale

ressaltar que nosso foco não é em acessibilidade, mas em propor uma solução que atenda a

diversidade de usuários e situações de uso no ambiente doméstico, facilitando as atividades do

dia-a-dia e a interação com o sistema.


Quanto ao feedback, ou seja, o retorno ou confirmação da execução de uma determinada

ação no sistema, a aplicação provê três diferentes tipos: (a) visual, (b) sonoro e (c) háptico

(vibração). O feedback visual é baseado em mensagens toast [75] mostradas para o usuário; o

feedback sonoro na emissão de um som; e o feedback háptico, na vibração do smartphone. Esses

feedbacks são dados ao usuário sempre que uma ação é executada no sistema, a fim de modificar

o estado de algum aparelho (objeto).

5.4.2 Interface

Para o design da interface da aplicação, propomos uma instância de interface baseada em flat

design. O flat design ou design plano [79] é uma abordagem minimalista, preservando a clareza

das interfaces. Essa abordagem é reconhecida pela não utilização de gradientes e pixels de

sombreamento, substituindo o realismo pelo princípio abstrato, contrário ao skeumorfismo. Ela

utiliza cores sólidas, tipografia nítida e contraste bem definido. Esse estilo foi popularizado pela

Microsoft com a apresentação do Metro UI. O flat design é uma tendência em aplicações móveis

e vem sendo utilizada por diversas aplicações. Um exemplo é a última atualização do ano 2013 do

aplicativo Foursquare9 para a plataforma Android, em que toda a interface foi remodelada e

foram adotados princípios do flat design.

A abordagem do flat design foi escolhida para o projeto de interface do aplicativo

HandyHome visando romper o desafio da complexidade do domínio. O controle de elementos

do ambiente residencial apresenta complexidade no manuseio de diversas funções e dispositivos,

e o contexto móvel e a diversidade de usuários e situações de uso engrandecem ainda mais o

desafio. Características do flat design tais como as cores sólidas e o contraste bem definido visam

facilitar o projeto de uma interface limpa, proporcionando uma diminuição da sobrecarga visual.

A interface da tela principal da aplicação é mostrada na Figura 7. Os princípios de flat

design foram utilizados em todas as interfaces. Cores claras remetendo ao princípio de casas

inteligentes também foram utilizadas, dando uma aparência mais clean, tentando minimizar a

complexidade desse domínio. Na Fig.7(a) é possível visualizar os ambientes da casa, seguindo um

dos requisitos expostos nos capítulos anteriores (capítulos 3 e 4). Na parte superior da tela

encontra-se uma barra superior, denominada Action Bar, conforme será detalhado mais a frente.

Nessa barra, utilizamos o elemento Spinner para permitir ao usuário navegar entre as diferentes

visões da casa. A interface inicia mostrando a opção “Ambientes”, que exibe os locais da casa.

Porém, também é possível selecionar “Aparelhos”, para visualizar os tipos de aparelhos na casa, e

“Meus Grupos”, que são grupos de aparelhos aleatórios organizados pelo usuário. As opções do

Spinner estão retraídas na Fig.7(a), e se o usuário selecionar uma vez o elemento, a lista de opções

é aberta, conforme mostra a Fig.7 (b).

9 https://foursquare.com/

67


Fig. 7 – Interface da Tela Principal

O padrão Navigation Drawer, que se baseia no uso de um menu lateral, também foi

utilizado no design da aplicação. É possível ver o menu retraído na Fig.7(a) e expandido na

Fig.7(c). Ele foi utilizado a fim de simplificar a exibição de opções de navegação. No topo do

menu é exibida a identificação do usuário, visto que na aplicação foram utilizados perfis de

usuário, de forma a permitir a personalização e individualidade dos moradores, conforme

requisito exposto nos capítulos anteriores (capítulo 3). Abaixo da identificação do usuário, o

menu conta com as opções de navegação, sendo sete opções distintas: “Meu Perfil” exibe

informações detalhadas do usuário; “Principal” exibe a tela principal da aplicação, que é a mesma

da Fig.7(a); “Cenários” exibe os cenários, conforme será detalhado adiante; “Buscar” oferece

funcionalidade de busca; “Sobre” fornece informações sobre a aplicação; “Configurações”

permite realizar configurações na aplicação; e “Sair” permite desconectar.

Uma consideração importante sobre a opção “Sair” em aplicações Android é que não se

deve oferecer a opção de sair da aplicação ou fechar a aplicação. Somente ofereça um botão

semelhante com a opção “Sair” se a aplicação necessita realizar uma ação específica relacionada,

por exemplo, com segurança. Neste caso, o botão de “Sair” atua realizando uma atividade de

logout, e este é o caso abordado no projeto de interface da aplicação HandyHome. Caso o usuário

escolha essa opção, ele desconecta de sua conta, e o aplicativo volta para a tela de autenticação. É

importante salientar essa questão para desenvolvedores de aplicações nesse domínio, por seguir

as diretrizes de interface da plataforma Android10.

No design proposto também foi utilizado o padrão Action Bar, que se baseia na barra

superior com opções denominadas Action Itens, a fim de permitir acesso rápido a

funcionalidades do sistema. As funcionalidades providas na Action Bar, da direita para a

10 http://blog.hatemalimam.com/exit-button-in-android-app/


esquerda, são respectivamente: “Interação por Voz”, “Atualizar” (Refresh) e “Cenários Favoritos”.

Vale ressaltar que em nosso design optamos por não exibir o botão overflow a fim de utilizar o

espaço acima à direita para ativar interação por voz, visto que se encontra em um ponto

estratégico do dispositivo. Dessa forma, durante toda a interação com a aplicação, o usuário

poderá ativar essa forma de interação, facilitando o uso pela diversidade de usuários nesse

contexto, incluindo usuários com deficiência visual. A Figura 8 mostra em (a) o posicionamento

do botão para interação por voz no aplicativo HandyHome e em (b) o posicionamento do botão

overflow em seu local padrão, no aplicativo Google Agenda.

Fig. 8 – Decisão de design: Posicionamento do botão de interação por voz

A Figura 9 mostra as funcionalidades referentes aos cenários. Essa funcionalidade se

mostra presente conforme requisito levantado em trabalho anterior (capítulo 4). Um cenário é

um conjunto de ações a serem executadas em conjunto, facilitando o controle de diversos

aparelhos da casa, principalmente para tarefas repetitivas que exigem um mesmo conjunto de

ações. A Fig.9(a) exibe a tela da opção “Cenários” do menu do Navigation Drawer. Já a Fig.9(c)

exibe a tela da funcionalidade “Cenários Favoritos”, acessada através do ícone de estrela na

Action Bar, e fornece apenas um sub-conjunto dos cenários disponíveis para rápido acesso.

Fig. 9 – Interface de (a) Cenários, (b) Cenários, com um cenário sendo ativado e emitindo feedback

visual com mensagem toast, e (c) Cenários favoritos

69


Ao ativar um cenário, um conjunto de ações (comandos) sobre diversos dispositivos é

realizado, de acordo com a relação de ações que estiver previamente cadastrada para aquele

cenário. Ao selecionar a parte com fundo branco que possui o nome e ícone do cenário, é

possível visualizar a lista de ações a serem executadas na ativação daquele cenário; ao selecionar o

botão verde com o símbolo triangular, é possível ativar o cenário correspondente. A Fig.9(b)

mostra um exemplo de feedback visual em “Cenários”, quando um cenário é ativado, com a

exibição de uma mensagem toast.

Outras interfaces da aplicação mostram nitidamente a aplicação do flat design, como

mostra a Figura 10. Após selecionar um dos cômodos da casa exibidos na Fig.7(a), a aplicação

mostra uma tela com os aparelhos que se encontram naquele cômodo, conforme mostra a

Fig.10(a). Os dispositivos presentes naquele cômodo são exibidos com ícones representativos,

indicando o dispositivo da casa e seu estado atual. Na interface, foi utilizado um conjunto de

cores flat11. Vale mencionar que o conjunto de ícones possui fundo transparente, sendo cada um

visualmente preenchido conforme a cor selecionada na geração automática de interface.

Em sequência, é possível visualizar a interface de controle exibida após selecionar uma das

opções de aparelhos, conforme a Fig.10(b). Os serviços, ou seja, as funcionalidades providas pelo

aparelho (objeto) são mostradas abaixo, guiadas por uma linha vertical. No exemplo, o aparelho,

denominado Lamp, é uma lâmpada que só possui um serviço (funcionalidade): ligar/desligar. Na

Fig.10(c) é possível visualizar a interface de “Configurações”, onde é possível, por exemplo,

ativar e desativar os diferentes tipos de feedbacks.

Fig. 10 – Interfaces (a) Dispositivos, (b) Controle do dispositivo e (c) Configurações

Uma decisão de design que merece atenção é quanto à escolha do botão para ações que

permitem mudanças entre dois status, por exemplo, ligar/desligar e abrir/fechar. Foi adotado um

11 http://flatuicolors.com/


único botão, atendendo requisito exposto no capítulo 3. Porém, haviam duas opções no projeto

de design seguindo padrões de interface Android: Botão toggle ou switch. Apesar da opção mais

recente trazida pelo Android 4.0 ser switch, optamos pelo botão toggle, dada à questão do idioma.

Muitos objetos da casa possuem funções de ligar/desligar, porém, em inglês, o estado é indicado

por “On/Off”. Já no idioma português (Brasil) é indicado por “Ligado/Desligado”. Ou seja, as

palavras possuem mais que o dobro do tamanho. Como a pretensão é que a interface seja

propriamente adequada ao idioma, para minimizar a possibilidade de falha, optamos pelo botão

toggle, visto que a área ocupada pelo texto com o indicativo do estado é maior nesse elemento de

interface, como pode ser observado na Figura 11.

Fig. 11 – Decisão de design: (a) Botão Toggle e (b) Switch

5.5 Discussão

Neste capítulo detalhamos o projeto de uma aplicação para controle do ambiente residencial sob

a perspectiva da diversidade. O projeto de interface apresentado mostra uma instância de

interface construída considerando diversos aspectos, tal como princípios do flat design, e a partir

de algumas decisões, considerando diversos requisitos encontrados ao longo desta pesquisa. Vale

mencionar que podem existir outras instâncias de interface que também implementem os

requisitos, tanto para a plataforma Android, como para outros sistemas, neste último caso,

seguindo os requisitos levantados no capítulo 3.

Vale mencionar que algumas funcionalidades não foram implementadas nesta versão do

aplicativo, porém suas representações gráficas já foram inseridas no projeto de interface e

interação, tais como “Interação por Voz” e “Buscar”. Esta versão segue como um protótipo para

validar a proposta do design e de implementação do sistema.

É importante ressaltar que o capítulo foca no design e implementação de uma solução

voltada para smartphones. Isso não impede o uso da solução em dispositivos móveis tais como

tablets, porém é válido enfatizar que o foco do projeto foi smartphone, seguindo os princípios do

aprimoramento progressivo [80], visto que o smartphone é o dispositivo com maiores restrições,

principalmente no que se refere ao tamanho de tela.

Vale destacar que todas as informações referentes à estrutura da casa, tais como

cômodos/ambientes, aparelhos/objetos em cada ambiente, e serviços/funcionalidades oferecidas

por cada aparelho são dinâmicas. Ou seja, a aplicação recebe essas informações do sistema em

formato JSON e gera os elementos de interface gráfica em tempo real, dependendo da

71


informação recebida. Essa dinamicidade, juntamente com a adoção de elementos seguindo

padrões de interface da plataforma Android, somados à preocupação dos aspectos estéticos e a

adoção dos princípios do flat design, se mostram como diferencial no desenvolvimento do

projeto de interface. Além disso, todo o projeto foi guiado por requisitos identificados em

trabalhos anteriores (capítulos 3 e 4), visando transpor os desafios identificados no capítulo 2.

5.6 Conclusão

Este capítulo apresentou design e implementação de uma aplicação para controle de elementos

do ambiente residencial considerando aspectos de IHC, sob a perspectiva da diversidade. O

projeto de interface e interação proposto e desenvolvido no aplicativo propõe a utilização dos

princípios de flat design juntamente com padrões de interface Android. O sistema se mostrou

viável, e através do detalhamento do projeto é possível verificar diversos exemplos e escolhas que

podem ser replicadas em outros projetos ou instâncias de interface, auxiliando designers nesse

domínio específico.

Como trabalhos futuros propomos a observação do uso do aplicativo com usuários a fim

de verificar aspectos da interface e da interação, analisando o projeto de design proposto e

requisitos levantados ao longo desta pesquisa. Outros trabalhos futuros poderiam incluir o

desenvolvimento de um design rationale para auxiliar o processo de design de aplicações para

esse domínio, como também uma proposta de design de interfaces envolvendo funções de

programação de funcionalidades da casa, de forma a se parecer pouco com programação,

utilizando o flat design como abordagem de simplificação, e estudos com usuários para

verificação da efetividade da utilização dessa abordagem também nessa tarefa específica.

5.7 Tomada de Decisão

A partir dos resultados obtidos nesse capítulo, foi possível verificar o impacto dos aspectos

estéticos nas soluções visando o domínio de controle de ambientes residenciais via dispositivos

móveis. Através do conteúdo fornecido neste trabalho, foi possível verificar detalhes de um

projeto de sistema, de interface e de interação de uma aplicação construída sob a perspectiva da

diversidade, atentando para vários pontos no design e no projeto do sistema.

Através da descrição fornecida, projetos com outras instâncias de interface podem ser

construídas. Os princípios de flat design utilizados neste trabalho também mostram uma solução

para problemas recorrentes deste domínio. A instância de interface mostrou exemplo de

aplicação de padrões de interface Android com os princípios adotados para aplicações neste


contexto. Esta solução ainda precisa ser avaliada com usuários, a fim de analisar questões do

projeto e requisitos implementados durante todo o projeto de pesquisa. Portanto, o próximo

passo é realizar uma atividade experimental baseada na observação de usuários em um ambiente

simulado, dentro de uma residência real, que interagem com a aplicação.

Capítulo 6

6 Descobertas e Reflexões de um Estudo de

Caso em um Ambiente Simulado

6.1 Introdução

A interação é o processo de comunicação entre pessoas e sistemas interativos [81]. Através desse

processo, usuários desencadeiam ações e fazem diversas construções cognitivas, caracterizando-o

como um processo meta-comunicativo. Na área de IHC, tradicionalmente procura-se criar

designs que suportem os principais casos e situações de uso, a partir do estudo e da compreensão

do usuário e seu contexto de uso [82]. Para isso, torna-se fundamental observar a interação entre

os usuários e o sistema interativo, a fim de verificar algumas propriedades relativas à qualidade de

uso.

A crescente demanda por dispositivos móveis nos últimos anos têm provocado mudanças

em relação às interfaces e interações realizadas com esses dispositivos. Aplicações móveis,

também denominadas aplicativos ou apps, surgem como um novo nicho de mercado, adotando

interfaces mais atrativas e fazendo uso de várias tecnologias. Apesar disso, diversas aplicações

para determinados domínios ainda carecem de melhorias significativas no que se refere à

interação com os usuários, e não focam em um projeto detalhado de interface e interação que

atenda as necessidades dos diversos usuários e explore os recursos oferecidos por essas

plataformas. Um exemplo de domínio é o controle de ambientes residenciais, também

referenciado por automação residencial ou casas inteligentes.

Aplicações para controle do ambiente residencial concentram uma área em crescimento. As

pessoas passam cada vez mais tempo fora de suas casas, e desejam gerenciar esse ambiente


mesmo a distância, além do conforto e conveniência dentro de casa no dia-a-dia. Nos capítulos

anteriores, levantamos o estado da arte e desafios de IHC para este domínio (capítulo 2) e

requisitos de aplicações utilizando o referencial teórico-metodológico da SO (capítulo 3) e um

método baseado no uso de aplicativos sob a perspectiva da interação (capítulo 4). No capítulo 5,

desenvolvemos uma aplicação considerando questões estéticas, baseado nos requisitos levantados

para atender a diversidade. Porém, faz-se necessário observar o uso dessa aplicação com usuários

a fim de verificar aspectos de interface e interação, analisando o projeto de design proposto.

Um dos desafios referentes ao teste de aplicações móveis com usuários é a realização

desses testes contextualizados ao ambiente de uso desses dispositivos [83]. Se considerarmos o

contexto residencial, essa característica se destaca ainda mais. Segundo Kjeldskov e Graham apud

Kronbauer e Santos [84], é crescente o interesse no desenvolvimento de cenários personalizados

próximos do ambiente de uso real, permitindo obter os benefícios inerentes aos experimentos

controlados como também, do acompanhamento das ações executadas pelos usuários.

Nesse sentido, propomos uma observação da interação de usuários com uma aplicação

para dispositivos móveis que permite controlar objetos de uma casa, realizada em um ambiente

simulado que se encontra dentro de um ambiente doméstico real. A partir dessa observação,

analisamos questões referentes ao design da aplicação e mostramos que os requisitos

implementados são significativos e trazem melhorias na interação dos usuários com esse tipo de

aplicação.

O capítulo está organizado da seguinte forma: a Seção 6.2 introduz a metodologia e o

cenário de pesquisa no qual foi realizado o experimento com os usuários; a Seção 6.3 apresenta

os resultados quantitativos e qualitativos, mostrando a relação dos resultados com os requisitos

identificados; a Seção 6.4 discute os resultados obtidos; a Seção 6.5 apresenta as considerações

finais e, e a Seção 6.6 finaliza o capítulo com uma reflexão acerca do trabalho.

6.2 Metodologia e Cenário de Pesquisa

O experimento foi motivado pela necessidade de melhor compreender a interação entre usuários

e o aplicativo HandyHome, a fim de validar e analisar questões do projeto de interface e interação

da versão inicial desta aplicação. HandyHome é um aplicativo para dispositivos Android que

permite controlar objetos do ambiente residencial. Seu projeto de interface foi baseado nos

princípios do flat design [79] e segue padrões de interface da plataforma Android [75], visando

atender a diversidade de usuários e situações de uso. Detalhes acerca de seu projeto de interface

são encontrados no capítulo 5, e o conjunto de requisitos utilizado como base para sua

implementação, nos capítulos 3 e 4.

O experimento foi conduzido no âmbito de um ambiente residencial real. Parte da

estrutura dessa casa foi apresentada aos usuários e mapeada para a aplicação. O ambiente

75

Capítulo 6. Descobertas e Reflexões de um Estudo de Caso em um Amb. Simulado

simulado contava com seis cômodos: garagem, sala, escritório, cozinha, lavanderia e quarto,

conforme ilustrado na Figura 12. O experimento ocorreu em duas áreas: uma interna, dentro de

um dos cômodos da casa (escritório), e uma externa, que se localizava fora da casa. Na área

interna, foi solicitada a realização de tarefas que envolviam o controle de objetos do próprio

cômodo e de outros cômodos da casa, enquanto que na área externa, as tarefas exigiam controlar

a casa apenas remotamente.

Fig. 12 – Estrutura da casa a ser controlada no experimento

A realização da atividade experimental ocorreu em 6 passos:

Passo I. Uma breve apresentação introduzindo os conceitos de automação residencial,

casas inteligentes, aplicativo e smartphone, mostrando o aparelho a ser utilizado, o ambiente e a

proposta da atividade a ser realizada durante o experimento (controle de uma casa automatizada

com um smartphone, através da interação com um aplicativo instalado no aparelho);

Passo II. Assinatura dos termos de consentimento livre e esclarecido (TCLE) e

autorização de voz, imagem e vídeo, a fim de autorizar a coleta de dados do experimento;

Passo III. Os participantes preenchem um formulário de perfil, a fim de se obter dados

etnográficos, informações sobre experiências anteriores com tecnologias computacionais, móveis

e de controle residencial de cada participante, além de informações sobre sua relação com seu

próprio ambiente residencial e conhecimento acerca do contexto da pesquisa;

Passo IV. Os participantes são solicitados a realizar uma sequência de tarefas no ambiente

experimental;

Passo V. Os participantes preenchem um formulário acerca das atividades realizadas e

opiniões referentes ao contexto da pesquisa;

Passo VI. O condutor do experimento realiza um questionário e apresenta um conjunto de

imagens (ícones), onde são coletados os dados finais.

O passo I foi realizado em grupo, a fim de explicar o contexto do experimento para todos

os participantes. Os demais passos são realizados individualmente com cada participante.

De acordo com a estrutura da casa simulada na aplicação, era possível controlar os

seguintes objetos em cada cômodo da casa, conforme mostra a Tabela 5: na garagem, uma porta;

na sala, uma janela; no escritório, uma lâmpada e uma televisão; na cozinha, um fogão e uma

janela; na lavanderia, uma máquina de lavar roupas e uma janela; no quarto, uma lâmpada, uma


janela, uma televisão, um notebook, um ar-condicionado e um aparelho de som. Vale ressaltar

que em cada cômodo, não havia mais de um objeto do mesmo tipo.

Tabela 5 – Objetos que podem ser controlados em cada cômodo da casa com a aplicação

Cômodo da Casa Quantidade de Objetos Tipos de Objetos

Garagem 1 porta

Sala 1 janela

Escritório 2 lâmpada, televisão

Cozinha 2 fogão, janela

Lavanderia 2 máquina de lavar roupas, janela

Quarto 6 lâmpada, janela, televisão, notebook,

ar-condicionado, aparelho de som

Na apresentação do ambiente, apenas a estrutura da casa foi apresentada, não os objetos

que poderiam ser controlados em cada um deles. Os usuários só teriam conhecimento dos

objetos que poderiam controlar através da interação com a aplicação. No escritório, onde ocorreu

a maior parte da execução das atividades, os objetos existiam em forma real: uma lâmpada e uma

televisão estavam no ambiente. Ao executar ações sobre esses objetos, o usuário poderia ver a

ocorrência da ação presencialmente. O escritório também contava com uma torneira e uma pia,

além de toda a mobília do ambiente, porém esses objetos não foram mapeados para a aplicação.

Os participantes podiam realizar ações sobre os objetos, que poderiam ser acessados

através de três visões distintas: (a) ambientes, em são exibidos cômodo da casa, e ao escolher um

cômodo, são exibidos os objetos que se encontram naquele respectivo cômodo; (b) aparelhos, em

que são exibidos os tipos de aparelhos da casa, e ao escolher um tipo de aparelho são exibidos

todos os objetos daquele tipo existentes na casa; (c) grupos, em que são exibidos diferentes

objetos agrupados aleatoriamente pelo usuário. Na atividade experimental, os usuários são

solicitados a explorar os dois primeiros.

Além de ações individuais sobre objetos, ou seja, visualização de objetos e ativação de cada

serviço oferecido por eles, a aplicação também permite a ativação de cenários. Um cenário é um

conjunto de ações emitidas de uma só vez. Na simulação, foram propostos 12 cenários, acessados

pela opção “Cenários”. Também havia a opção “Cenários Favoritos”, que mostra um

subconjunto dos cenários existentes. Nesta opção, foram simulados apenas 5 cenários favoritos.

Vale ressaltar que os participantes foram introduzidos a esses conceitos na breve apresentação

realizada no início do processo do experimento, porém quantos e quais elementos seriam

simulados não foram ditos, apenas o conceito dessas funcionalidades e como poderiam ser

acessadas. Para acessar todos os recursos da aplicação, é necessário realizar autenticação no

sistema, e no primeiro acesso, é possível visualizar um tutorial antes de visualizar a parte principal

da aplicação.

O experimento contou com a participação de 5 famílias, com 2 membros representando

cada uma delas, em um total de 10 participantes. Esse número foi escolhido com base em

pesquisas [85] que apontam que com 5 usuários obtém-se o melhor custo-benefício, uma vez que

com esse número são encontrados em média 85% dos problemas. Porém, como no âmbito do

77


experimento foi adotado o esquema de duplas de familiares, esse número foi repassado para

duplas, totalizando 10 pessoas. Vale ressaltar que o esquemas de duplas é considerado apenas

para análise dos dados, pois a execução das atividades do experimento ocorreu individualmente.

Os participantes tinham idades entre 24 e 58 anos, e as duplas foram compostas de 3 casais

(sendo um casal sem filhos, um casal com filho único e um casal com vários filhos) e 2 duplas de

pais e filhos (de mesmo gênero e de gêneros diferentes), visando a diversos tipos de usuários e

relações entre eles.

A Tabela 6 apresenta informações sobre a diversidade de usuários que participaram do

experimento. A sequência dos usuários mostra as duplas de familiares participantes, ou seja, U1 e

U2 fazem parte da mesma família, assim como U3 e U4, e assim por diante. Para facilitar a

leitura, foram feitas marcações com cores distintas para cada família, indicando que os

participantes marcados com a mesma cor pertencem a uma mesma família.

Tabela 6 – Dados etnográficos e pessoais dos participantes

Usuário Gênero Idade Pos.Fam. Escolar Mão Dif.Esp. Dif.

U1 F 24 Esposa Superior dir não -

U2 M 28 Marido Superior dir sim U

U3 F 24 Filha Pós dir não -

U4 F 56 Mãe Médio dir sim T,N,U,I

U5 F 25 Filha Pós dir não -

U6 M 52 Pai Médio esq sim outras

U7 F 50 Mãe Superior dir sim T,N,U,I

U8 M 52 Pai Superior dir sim N,U,I

U9 M 57 Pai Pós dir não -

U10 F 58 Mãe Pós dir sim T,N,U,I

Os participantes do experimento são destros, com exceção de U6 que é canhoto (utiliza a

mão esquerda). Em todas as famílias, pelo menos um dos membros informou ter dificuldades

específicas no uso de tecnologias móveis (e.g. U - utilizar dispositivos touchscreen, N - navegar

na internet pelo smartphone/celular/tablet, I - instalar aplicativos, U - utilizar aplicativos, ou

outras). Vale ressaltar que neste ponto, os participantes U4, U7 e U10 afirmaram possuir

dificuldade nas quatro opções específicas.

Na Tabela 7, constam os dados informados pelos usuários referentes às suas experiências

anteriores com diversas tecnologias envolvidas na atividade experimental, de acordo com a

frequência de uso. Um mapa de cor foi utilizado para facilitar a visualização das respostas. De

acordo com os dados, todos os usuários já haviam tido algum contato com alguma das

tecnologias mencionadas (touchscreen; dispositivos móveis, neste caso, considerados celular,

tablet ou smartphone; dispositivos Android; smartphone; aplicativos; e smartphone com tela

touchscreen). Porém, alguns usuários nunca utilizaram algumas dessas tecnologias.

O usuário que afirmou ter menor experiência foi U4, que só utilizou tecnologia

touchscreen alguma vez e nunca utilizou as demais. Vale ressaltar que a tecnologia touchscreen já

se encontra presente em diversos serviços à população na cidade em que foi realizado o

experimento, em terminais de atendimento a clientes como caixas eletrônicos, retirada de senha


em estabelecimentos, entre outros. Possivelmente, por esse motivo, todos os usuários já tiveram

algum contato com essa tecnologia.

Tabela 7 – Dados etnográficos e pessoais dos participantes

Tecnologia U1 U2 U3 U4 U5 U6 U7 U8 U9 U10

touchscreen 4 5 5 2 5 2 4 5 5 5

disp. móveis 4 5 5 1 5 5 5 5 5 5

disp. Android 4 2 5 1 5 1 5 1 3 5

smartphone 4 5 5 1 5 1 5 1 5 5

apps 4 5 5 1 5 1 5 1 5 2

smartphone touchscreen 4 5 5 1 5 1 5 1 5 5

Tabela 8 – Legenda da classificação da tabela 7

N Classificação

1 nunca utilizei

2 já utilizei alguma vez

3 utilizo raramente

4 utilizo ocasionalmente

5 utilizo todos os dias

Após U4, o usuário que indicou menor experiência foi U6, que também utilizou

touchscreen alguma vez e utiliza dispositivos móveis todos os dias, porém nunca utilizou as

demais; seguido pelo usuário U8, que informou utilizar todos os dias tanto touchscreen quanto

dispositivos móveis, porém nunca utilizou as demais opções.

É possível observar uma correlação entre as experiências anteriores dos usuários com as

tecnologias citadas (mostrada na Tabela 7) e as dificuldades específicas no uso das tecnologias

móveis (conforme visto na coluna 7 da Tabela 6). Os usuários que relataram menor experiência

(U4, U6, U8) informaram ter dificuldades específicas. E ainda, U4 informa ter dificuldade em

todas as opções apresentadas. Analogamente, os usuários que indicaram maior experiência (U3 e

U5) afirmaram não ter dificuldades específicas no uso de tecnologias móveis.

A plataforma de realização dos testes foi um smartphone Motorola Razr i XT890, com

Android 4.1.2 – Jelly Bean, configurado no idioma PT-BR, processador Intel Atom Z2460

2GHz, 1GB RAM, tela 4.3” (540x960 pixels).

No passo IV, as atividades solicitadas para os usuários envolviam: autenticar no sistema;

aceitar o termo de uso e navegar pelo tutorial; identificar objetos e ambientes da casa na

aplicação; desligar dispositivos; ativar cenários; desativar feedbacks; repetir operações após

desativar feedbacks; atribuir comandos de voz e gestos para cenários favoritos. Ao todo, foram

20 tarefas. As tarefas deveriam ser realizadas exclusivamente através da interação do usuário com

a aplicação móvel do smartphone, exceto as tarefas que envolviam passar informações para o

condutor do experimento (tarefas 3, 7, 8 e 19). A sequência de tarefas é detalhada a seguir:

Tarefa 1 – Autenticar no sistema, com o usuário “sarah” e a senha “123”.

Tarefa 2 – Passar pelo termo de uso e tutorial, e visualizar a tela principal da aplicação.

Tarefa 3 – Informar quais objetos podem ser controlados em cada ambiente da casa.

Tarefa 4 – Trocar a exibição da casa por ambientes por tipos de aparelhos da casa.

Tarefa 5 – Mostrar todas as janelas da casa.

79


Tarefa 6 – Desligar a televisão do escritório.

Tarefa 7 – Informar quantos cenários estão salvos na aplicação.

Tarefa 8 – Informar quantos cenários favoritos estão salvos na aplicação.

Tarefa 9 – Ativar o cenário “Lavar Roupa”.

Tarefa 10 – Desliguar a lâmpada, a televisão e o ar-condicionado do quarto.

Tarefa 11 – Desativar o feedback de áudio.

Tarefa 12 – Abrir a janela do quarto e ativar o cenário “Cinema em Casa”.

Tarefa 13 – Desativar o feedback háptico (de vibrar).

Tarefa 14 – Repetir a tarefa 12.

Tarefa 15 – Atribuir um gesto com o smartphone para cada “Cenário Favorito”.

Tarefa 16 – Fechar todas as janelas da casa.

Tarefa 17 – Atribuir um comando de voz para cada “Cenário Favorito”.

Tarefa 18 – Fechar todas as janelas da casa.

Tarefa 19 – Informar se o fogão da cozinha está ligado.

Tarefa 20 – Autenticar no sistema, através de interação por voz, informando seu nome.

A realização dessas tarefas ocorreu em quatro momentos distintos, em sequência e em

fluxo contínuo:

Momento (A): No escritório, com o participante sentado. Foi solicitada a realização das

tarefas 1 a 17, uma por vez.

Momento (B): No escritório, com o usuário de pé em frente a pia, lavando as mãos. No

momento em que o participante realizava essa atividade, era solicitada a realização da tarefa 18.

Momento (C): Na área externa, fora da casa. Foi solicitada a realização da tarefa 19.

Momento (D): Na área externa, fora da casa. Foi solicitada a realização da tarefa 20.

No passo VI, o condutor do experimento mostra um conjunto de ícones para o

participante. O participante deve escolher ícones que melhor representem os cômodos da sua

residência real (informados no passo III, no preenchimento do formulário de perfil), ou caso não

haja um ícone desejado para algum ambiente específico de sua moradia, informar como seria o

ícone desejado. Para coleta dos dados, foram utilizados recursos de áudio e vídeo, que foram

analisados após a realização do experimento, juntamente com as informações contidas nos

formulários.

6.3 Resultados

Após a realização da atividade experimental, todos os dados coletados foram analisados. Nesta

seção demonstramos alguns resultados quantitativos e qualitativos obtidos com o experimento


6.3.1 Resultados Quantitativos

De acordo com o gráfico exibido na Figura 13, é possível visualizar a média de tempo levado por

cada participante para realizar a sequência de tarefas 1 a 14. O tempo é mostrado na escala de

segundos. O foco da análise ocorreu nessas tarefas, pois ocorrem no Momento (A), em que o

usuário se encontra sentado e realizando as atividades em fluxo contínuo. As atividades 15,16 e

17, apesar de também ocorrerem no Momento (A), não envolvem sequência de interação com a

interface gráfica da aplicação, e por isso não foram inseridas nessa análise.

Fig. 13 – Tempo que cada usuário utilizou para realizar as tarefas 1 a 14

Com o gráfico, é possível observar que o maior tempo para a realização das tarefas foi de

U4, seguido por U6, passando da faixa dos 1000 segundos (mais de 16 minutos). Esses

participantes são os mesmos que indicaram menor experiência com tecnologias móveis. Em

seguida, quanto ao tempo para conclusão das tarefas, estão U10 e U8, passando da faixa dos 500

segundos (mais de 8 minutos). Apesar de U10 não ter sido o terceiro usuário com menor

experiência, e sim U8, U10 apresentou dificuldades específicas no uso de todas as tecnologias

móveis apresentadas, o que confirma a correlação do tempo com o perfil dos usuários levantado.

Na Figura 14, é possível visualizar as taxas de realização com sucesso das tarefas 1 a 14.

Considera-se que uma tarefa não foi realizada com sucesso em três casos: (a) se a tarefa não foi

concluída, ou seja, o usuário desistiu de realizar a atividade; (b) se o usuário não realizou o que foi

solicitado; (c) se a tarefa envolvia passar informações para o condutor do experimento (tarefas 3,

7, 8 e 19) e a resposta informada não foi correta. Uma observação quanto às tarefas sem sucesso

é que entre as cinco apontadas, constavam as tarefas 3 e 7, esta última com a menor taxa de

sucesso. Essas tarefas visavam avaliar a compreensão dos usuários quanto aos elementos da

aplicação, referentes aos objetos da casa disponíveis e aos cenários, respectivamente. Na tarefa 3,

a resposta incorreta informada pelos participantes foi a mesma, onde inferiram a resposta pelo

81


ícone que representava o respectivo ambiente (e.g. “na garagem há um carro”, “na sala há um

sofá”).

Na tarefa 7, três usuários informaram que haviam seis cenários na aplicação, porém esse é

o número de cômodos (ambientes) que existem na casa. Isso mostra que o conceito de

“cenários” não foi compreendido por alguns participantes do experimento. Quanto a tarefa 9, os

usuários buscaram interagir com o objeto máquina de lavar roupas, que se encontrava na

lavanderia, ao invés de buscar pelo cenário. Vale ressaltar também que U4 não conseguiu realizar

com sucesso nenhuma das 5 tarefas apontadas: T3 e T7 por informar uma resposta incorreta, e as

demais por desistência.

Fig. 14 – Taxas de realização das tarefas 1 a 14 com sucesso

A Figura 15 mostra dois gráficos, referente às respostas dadas pelos participantes no

formulário pós-atividades. De acordo com os dados, 80% dos participantes associaram as cores

da imagem B com o termo “casa inteligente” (gráfico G1). O mesmo percentual foi encontrado

para associação entre as cores da imagem B com as utilizadas na aplicação (gráfico G2). No caso

da resposta com a opção “nenhuma”, a justificativa dada é que nenhuma das duas imagens

mostrava um dispositivo ligado a um computador. Uma observação interessante são algumas

palavras que aparecem nas justificativas da resposta majoritária na pergunta que originou o

primeiro gráfico, tais como “branco”, “novidade” e “clean”.

Fig. 15 – Respostas dos participantes quanto às imagens A e B


6.3.2 Observações Qualitativas

Na tarefa 1, que solicitava a autenticação do usuário por modo textual, diversos problemas de

acessibilidade foram encontrados. Os participantes U4, U6, U8 e U10 solicitaram ajuda do

condutor do experimento para prosseguir com a tarefa, pois apresentavam dificuldades no uso do

teclado e na interação devido ao desconhecimento do padrão de interface de dispositivos móveis

(e.g. padrão em que o teclado fica oculto e só aparece após selecionar um campo de texto). Frases

como “Mas onde eu posso escrever?”, “Onde eu vou digitar?” e “Como é que eu vou escrever?”

foram ditas pelos participantes, tanto os que solicitaram ajuda como também outros que, mesmo

não solicitando auxílio, enfrentaram problemas de acessibilidade, tal como o U7. Vale mencionar

que todos os participantes que apresentaram problemas de acessibilidade tinham 50 anos ou

mais, e alegaram apresentar dificuldades específicas no uso de tecnologias móveis, de acordo com

os dados de perfil obtidos.

Outro problema de acessibilidade encontrado foi referente à leitura de elementos textuais

na interface. Comentários acerca do tamanho do texto, considerado por vezes pequeno, e

solicitações para que o texto fosse ampliado demonstram a situação. A Figura 16 (a) mostra a

expressão de um dos participantes ao tentar ler uma informação textual na interface. Em (b) e (c)

reações no início do experimento. Vale ressaltar que nenhum usuário apresentou dificuldade na

tarefa 20, que consistia na mesma ação, só que por outra forma de interação. Esses resultados

reforçam requisito levantado em trabalho anterior, referente à interação multimodal.

Fig. 16 – Reações aos problemas de acessibilidade no uso de dispositivos móveis

Na tarefa 2, que se refere ao termo de uso e ao tutorial, todos os participantes concluíram a

tarefa com sucesso e não apresentaram problemas ao interagir com a aplicação. Em entrevista,

um participante comentou a importância do termo para aplicações nesse domínio, em que uma

ação pode apresentar impactos sobre a residência, e 100% dos participantes responderam que o

tutorial ajudou a utilizar a aplicação. U9 leu a mensagem de boas vindas enquanto interagia com o

aplicativo, e apresentou expressão de contentamento no momento da leitura da mensagem. Esses

dados confirmam requisitos referentes ao termo de uso, tutorial e mensagem de boas vindas.

83


Durante a tarefa 3, dois usuários confundiram o ícone que representava o objeto janela,

com o objeto porta. O ícone de aparelho de som também apresentou dúvidas para alguns

usuários, que não souberam identificar que aparelho o ícone representava. A tela com

informações detalhadas de cada objeto, que continha um rótulo com o nome do objeto e suas

funções, ajudou na identificação. A necessidade do rótulo também pôde ser observada na tarefa

6. U6, U9 e U10 buscaram o aparelho através do tipo, porém como existiam várias televisões na

casa (e não havia rótulo, somente o ícone), não sabiam identificar qual era a televisão correta, e a

tarefa não foi realizada por esse caminho de navegação.

Os diferentes tipos de feedbacks também foram úteis. Alguns usuários se guiaram pelas

mensagens toast [75], lendo em voz alta a mensagem de confirmação de execução da ação.

Porém, com os feedbacks de áudio e háptico ativados, a confiança de que a ação foi realizada foi

maior entre os participantes, confirmando outro requisito. Quanto ao feedback local, uma

observação é interessante. Apesar da televisão se encontrar no mesmo ambiente dos

participantes, ao desligarem o aparelho pela aplicação (tarefa 6), a maioria dos usuários estava tão

concentrado na tela do smartphone que não percebeu a modificação do estado no próprio

ambiente. Dos 10 participantes, apenas 2 observaram a ação no ambiente e mostraram reação de

surpresa. A Figura 17 mostra diferentes reações ao executar a tarefa 6, imediatamente após emitir

a ação sobre a televisão. Em (a) o usuário não percebe a ação no próprio ambiente, e em (b) o

usuário observa a ação no ambiente.

.

Fig. 17 Diferentes reações após ação no ambiente: (a) usuário não percebe e (b) usuário percebe o

feedback do aparelho no ambiente

Os participantes com pouca experiência com dispositivos móveis apresentaram

dificuldades com o padrão NavigationDrawer [75], responsável pela barra lateral com diversas

funcionalidades da aplicação (entre elas, “Cenários” e “Configurações”, acessadas somente

através desse recurso). Esse foi o maior problema encontrado na interação desses usuários com a

aplicação. Como não conheciam esse padrão de interface do Android, devido sua característica de

barra oculta, os usuários não visualizavam o conteúdo e não sabiam (ou não lembravam) como

encontrá-lo. Dois usuários apresentaram dificuldades com o padrão Spinner [75], outro padrão

que oculta informações visuais. Este padrão foi utilizado para mostrar os três tipos de exibição da

casa (por ambientes, tipos de aparelhos ou grupos). Após várias interações com a aplicação


durante a tarefa 4, os participantes conseguiram interagir utilizando o elemento de interface. Na

tarefa 5, que pede para mostrar todas as janelas da casa, todos os usuários completaram a tarefa

apenas com uma interação, demonstrando a utilidade da implementação do requisito

“Agrupamento de aparelhos da casa”.

Na tarefa 15, diferentes gestos foram definidos pelos participantes. Alguns usuários

solicitaram esclarecimentos acerca do conceito de gesto com o dispositivo móvel, porém todos

concluíram a tarefa com sucesso. Todos os usuários tiveram dificuldade em atribuir gestos

distintos e também, dificuldades de memorização. A figura 18 mostra um conjunto de gestos

definido por um participante. Vários gestos desse conjunto também foram utilizados por outros

participantes.

.

Fig. 18 Conjunto de gestos definido por um participante para os cenários: (a) Acordar, (b) Antes de

dormir, (c) Cinema em casa, (d) Sair de Casa, (e) Chovendo

Na tarefa 16, a maioria dos usuários utilizou interação touchscreen. Desses usuários, sete

utilizaram cenários e um realizou ação sobre os objetos, ou seja, navegou pela aplicação

procurando cada janela da casa e realizou a ação sobre cada uma delas. A Tabela 8 detalha como

a tarefa foi realizada por cada usuário. Dois usuários realizaram interação gestual, realizando o

gesto que ativava o cenário “Chovendo” que haviam escolhido na tarefa anterior. Vale mencionar

que U9 tentou realizar a tarefa procurando por tipos de aparelhos da casa, e em seguida, por

janelas, na tentativa de aplicar uma ação a todos os objetos do mesmo tipo. Isso confirma os

requisitos “Uma ação sobre vários aparelhos” e “Organização de aparelhos da casa por local da

casa e por categoria de dispositivos”.

Tabela 9 – Formas que os usuários realizaram a tarefa 16

Usuário U1 U2 U3 U4 U5 U6 U7 U8 U9 U10

Interação Touch Touch Touch Touch Touch Touch Touch Gesto Touch Gesto

Funcionalidade cena cena cena cena cena cena ac.obj. cena cena cena

A tarefa 18 simulou uma situação da rotina doméstica, onde os participantes estão com as

mãos ocupadas. Esta limitação, mesmo que temporária, é um fator a ser observado no design de

soluções nesse contexto. A forma de interação escolhida por cada usuário é detalhado na Tabela

85


9. Nela, pode-se observar que a maioria dos usuários optou pela interação por voz. A reação dos

usuários pode ser vista na Figura 19.

Tabela 10 – Formas que os usuários realizaram a tarefa 18

Usuário U1 U2 U3 U4 U5 U6 U7 U8 U9 U10

Interação Touch Voz Voz Touch Voz Voz Touch Voz Voz Voz

Fig. 19 – Reação dos usuários no momento de execução da tarefa 18

A tarefa 19, realizada na área externa, simulou outra rotina de moradores e possíveis

usuários dos sistemas de automação residencial. O controle à distância e monitoramento mesmo

fora da residência se mostrou válido, e todos os usuários conseguiram realizar a atividade com

sucesso. Questões de segurança e controle de acesso também são desejadas pelos usuários de

acordo com os dados coletados, justificando requisitos relacionados.

E ainda, com a realização da atividade no passo VI, foi constado que as pessoas, até da

mesma família, possuem concepções diferentes de suas casas. Os membros da mesma família,

mesmo morando em uma mesma residência, dividem e nomeiam os ambientes de formas

distintas, e também atribuíram ícones diferentes para cada cômodo. Esse resultado ocorreu em

todas as duplas, e está de acordo com o requisito “Personalização da interface/interação”,

demonstrando a visão particular de cada indivíduo do mesmo ambiente. Na atividade, também

foram levantados um conjunto de ícones para próximas versões da aplicação.


6.4 Discussão

Através da realização do experimento, alguns resultados interessantes foram obtidos. Todos os

usuários consideram os ícones úteis para a identificação das funcionalidades da aplicação, sendo

que a abordagem do flat design na elaboração do ícone mostrou ter auxiliado na rápida

interpretação do ícone durante o experimento. Porém, somente a informação simbólica não é

suficiente para passar a informação desejada, gerando diferentes interpretações em alguns casos.

Portanto, faz-se necessário a adoção de rótulos na descrição dos aparelhos e dos ambientes. O

design utilizando cores branco e cinza mostrou-se relevante para o contexto do aplicativo para

controle de uma casa, fazendo referência a padrões estéticos de casas inteligentes.

A proposta do design se torna válida, porém algumas alterações se mostram necessárias.

Observando-se a necessidade do uso de rótulos, sugere-se a implementação de animação flipcard.

Neste caso, a animação utilizada permitiria manter o design atual dos ícones dos objetos em um

quadrado preenchido por cor flat, porém ao deslizar o dedo sobre o ícone, o quadrado mostraria

informação adicional sobre o objeto, como nome em um rótulo.

O condutor do experimento interveio sempre que os usuários saíam da aplicação no

momento da interação com o smartphone. Isso ocorreu diversas vezes, principalmente com os

usuários com menor experiência, como U4, U6, U8 e U10. Vale mencionar que durante todo o

momento (A), em que o participante realizava as tarefas sentado, o smartphone estava conectado

a um computador por um fio, a fim de capturar dados de registro da navegação do usuário

durante a atividade experimental. Mesmo conectado, a disposição do aparelho permitia sua

movimentação para execução de gestos e o uso na posição desejada pelo usuário. Porém, a

presença do fio, mesmo que de longo comprimento, é um fator a ser considerado, que pode ter

limitado o conjunto de gestos definido pelos usuários ou influenciado em outros pontos do

experimento.

Na execução da tarefa com as mãos ocupadas, a interação por voz mostrou ser útil,

possibilitando a ativação de recursos da casa mesmo com as mãos ocupadas. Já a interação por

gestos, só fui utilizada uma vez, não demonstrando tanta efetividade. Problemas de memorização

quanto aos gestos e comandos de voz se mostraram presentes, sendo mais graves na interação

gestual, visto que foram atribuídos a cenários e os usuários não assimilavam gestos a cenários

específicos, que eram constituídos de várias ações.

As diferentes formas de visualização da casa se mostraram válidas no contexto da

aplicação, pois os usuários procuravam formas de visualizar a informação por aparelhos ou por

ambientes. Porém, alguns usuários tiveram dificuldades de encontrar a funcionalidade por

desconhecimento do elemento Spinner. A primeira alternativa proposta antes da implementação

do design final foi o uso de Swipe Views, e esta se mostra válida, dado que diversos usuários

durante o experimento aplicaram o movimento swipe buscando alternativas para a realização das

87


tarefas propostas. Porém, a adoção desse padrão economizou espaço considerável de uso no

projeto da interface.

A partir dos resultados, constatou-se que apesar do flat design ser uma abordagem

interessante por abstrair e permitir a clareza na interface, sua utilização juntamente com o uso de

padrões da plataforma Android só se mostram efetivas para usuários que têm conhecimento

prévio dos padrões adotados nessas interfaces. O projeto de interface utilizando o padrão

Navigation Drawer ocasionou problemas na identificação do menu pelos usuários pouco

familiarizados ou que desconheciam o sistema. Por outro lado, a utilização da ActionBar se

mostrou eficiente em todos os casos, auxiliando os usuários a encontrar as funções rapidamente.

6.5 Conclusão

Este capítulo apresentou os resultados de uma atividade experimental baseada na interação de

usuários com uma aplicação para dispositivos móveis desenvolvida considerando aspectos de

IHC sob a perspectiva da diversidade, que permite controlar objetos de uma casa. Essa atividade

foi realizada em um ambiente simulado que se encontra dentro de um ambiente doméstico real.

A partir dessa observação, analisamos questões referentes ao design da aplicação e mostramos

que os requisitos implementados são significativos e trazem melhorias na interação dos usuários

com esse tipo de aplicação.

Como trabalhos futuros propomos a implementação de mais funcionalidades no aplicativo

e uma segunda investigação a fim de obter melhorias e verificar o uso de outros padrões de

interface, bem como o uso de interfaces adaptativas, ou seja, a interface ter as funções adaptadas

a cada usuário, buscando transpor um dos desafios identificados no capítulo 2, referente à lacuna

entre propósitos de uso diferentes.

6.6 Reflexão

Cabe nesse ponto refletirmos sobre os passos realizados nessa pesquisa e as decisões tomadas,

que deram origem a esse trabalho. Na figura 20 podemos visualizar a contribuição dessa pesquisa

na evolução do projeto no qual ele está inserido, destacados em azul. De fato, a proposta da

pesquisa dentro do projeto não foi implementar a infraestrutura com a qual a aplicação se

comunica, e sim se basear nela para o funcionamento da aplicação em um cenário real. O projeto

da infraestrutura se encontra em desenvolvimento, porém, isso não impediu a pesquisa e a

investigação dos aspectos relacionados à interface e interação que a pesquisa se propôs a realizar.


Fig. 20 – Contribuições da pesquisa no projeto desenvolvido

Essa pesquisa fundamentou a construção da infraestrutura para aplicação em um cenário

real de controle de objetos em uma residência, através dos requisitos identificados. Através da

identificação desses requisitos, eles foram traduzidos para especificações de serviços, sendo eles

mais um resultado obtido com essa pesquisa. Os requisitos também demonstraram a necessidade

de utilização dos denominados schemas na infraestrutura do sistema.

Os resultados obtidos neste capítulo permitiram diversas descobertas e reflexões acerca do

projeto de interface e sua aplicação para aplicações móveis no contexto de controle de ambientes

residenciais. O contraponto entre simplicidade e as informações exibidas diretamente na tela é

levantada com o padrão Navigation Drawer, juntamente com questões do flat design. Esse

trabalho demonstra a importância da continuidade da investigação desses aspectos em conjunto

com pesquisas referente à tecnologia, a fim de melhorar a interação e facilitar o desenvolvimento

de aplicações para esse contexto.

Capítulo 7

7 Considerações Finais

Neste capítulo apresentamos um resumo do que foi abordado nesta pesquisa, destacando as

contribuições de cada capítulo, relacionando também os objetivos específicos que foram

cumpridos em cada um deles juntamente com os resultados advindos de cada etapa.

7.1 Trabalho Realizado

Através do levantamento do estado da arte em soluções para controle do ambiente residencial via

dispositivos móveis, identificamos desafios de IHC para esse domínio sob a perspectiva da

diversidade. Essa identificação foi possível devido à análise dos trabalhos considerando seus

aspectos tecnológicos, de interface e interação, e voltando seu foco para o contexto específico

considerando a diversidade de público e riquezas de situações de uso nesse ambiente.

Em seguida, levantamento de requisitos para aplicações nesse domínio. Para isso,

realizamos uma análise do domínio utilizando artefatos da Semiótica Organizacional, a fim de

obter uma visão-sócio técnica, através de diversas perspectivas. O levantamento de requisitos se

deu a partir dessa análise e dos trabalhos do estado da arte apresentados no capítulo 2. A fim de

obter requisitos de interface/interação voltados especificamente para a plataforma-alvo de

desenvolvimento da solução proposta, também foi realizado um levantamento de requisitos

baseado no uso de aplicativos, sendo proposto um processo de levantamento de requisitos e

apresentados os resultados aplicados para a plataforma Android e voltado para smartphones.

Por fim, apresentamos o design e implementação de um aplicativo HandyHome,

HandyHome, bem como os resultados de um experimento realizados com usuários em um

ambiente simulado, a fim de validar alguns requisitos e decisões de design voltadas para esse

contexto, e obter direcionamento para trabalhos futuros.


7.2 Contribuições

Capítulo 2: Este capítulo cumpre os primeiro e segundo objetivos desta pesquisa. A

contribuição desse capítulo se dá em função do abrangente levantamento e sumarização

das soluções da literatura, considerando aspectos de IHC, e identificação de desafios sob

a perspectiva da diversidade. A identificação dos desafios para esse domínio sob essa

perspectiva é fundamental para a compreensão dos aspectos de interação, constituindo o

primeiro passo para prover uma melhor interação para os usuários. Esse capítulo ainda

acrescenta em sua contribuição o conjunto de diretrizes, atuando como um guia de alto-

nível para designers de novas soluções, e visam transpor ou minimizar os desafios

expostos;

Capítulo 3: A contribuição desse capítulo se constitui no conjunto de requisitos e em

mostrar como a Semiótica Organizacional pode ajudar a encontrar os requisitos para esse

domínio específico, antes não aplicado. Este capítulo cumpre o terceiro objetivo, no que

se refere aos requisitos de interface/interação ao contexto abrangente, não considerando

a plataforma exata para qual a solução foi desenvolvida;

Capítulo 4: Este capítulo também cumpre o terceiro objetivo, no que se refere aos

requisitos de interface/interação ao contexto e plataforma específica, nesse caso,

Android. A contribuição é o processo de elicitação de requisitos de interface baseado em

apps, que pode ser utilizado para levantar requisitos no contexto de aplicações móveis,

sendo útil para diferentes públicos, bem como os requisitos encontrados com o emprego

desse processo para esse contexto;

Capítulo 5: Este capítulo cumpre os objetivos quatro e cinco dessa pesquisa. A

contribuição é mostrar os passos desde a fase de concepção/design do aplicativo até sua

implementação, que demonstram a importância de se considerar aspectos de interação no

projeto de soluções para esse domínio bem como aspectos estéticos, considerando a

diversidade.

Capítulo 6: Este capítulo cumpre o sexto objetivo dessa pesquisa. A contribuição

advinda desse capítulo é mostrar os resultados obtidos com o uso do aplicativo pelos

usuários, provendo uma reflexão acerca dos aspectos de design e interação, além de

justificar os passos anteriores realizados nesta pesquisa.

Como resultados parciais desse trabalho, destacamos as seguintes publicações:

Sakamoto, S.G., Miranda, L.C., Hornung, H.H.: Home Control via Mobile Devices: State

of the Art and HCI Challenges under the Perspective of Diversity. In: 8th International

Conference on Universal Access in Human-Computer Interaction (UAHCI) / 16th

91

Capítulo 8. Considerações Finais

International Conference on Human-Computer Interaction (HCII), Lecture Notes in

Computer Science (LNCS), vol. 8515, pp. 501–512, Springer, Heidelberg (2014)

Sakamoto, S.G., Miranda, L.C.: M4REMAIP: Method for Requirements Elicitation Based

on Mobile Applications under an Interaction Perspective. In: 3rd International

Conference on Design, User Experience and Usability (DUXU) / 16th International

Conference on Human-Computer Interaction (HCII), Lecture Notes in Computer

Science (LNCS), vol. 8517, pp. 74–85, Springer, Heidelberg (2014)

Este trabalho reforça a importância de considerar aspectos das três dimensões (os usuários,

a tecnologia e o ambiente) no projeto de novas soluções. E ainda, atentar para o aspecto da

diversidade no desenvolvimento dessas soluções. Através dos resultados da pesquisa também

pudemos identificar a importância dos fatores estéticos na interação e o contraponto com a

simplicidade demasiada com informações implícitas no projeto de interfaces.

7.3 Perspectivas e Trabalhos Futuros

A realização deste trabalho, juntamente com suas contribuições, mostra-nos uma diferente

perspectiva de pesquisa nesse domínio, trazendo o foco do desenvolvimento de soluções para os

três dimensões (usuários, ambiente e tecnologia), demonstrando a relevância de se considerar essa

perspectiva desde as primeiras fases do desenvolvimento de projetos. Os resultados expostos

com esse trabalho despertam novas questões de pesquisa e abrem caminho para outros trabalhos,

além de mostrar o quanto a área é promissora de aplicação de novas abordagens em relação aos

aspectos de Interação Humano-Computador.

Como trabalhos futuros, sugerimos a implementação de mais recursos no aplicativo

HandyHome juntamente com testes com usuários, investigação de mais aspectos desse contexto

através de pesquisas abrangendo um maior número de usuários, projetos de interface utilizando

design participativo e ainda, análises aprofundadas quanto às interações por voz e gestual via

dispositivos móveis. Essas interações trazem desafios e requisitos específicos no contexto do

controle do ambiente residencial que precisam ser investigadas.

Referências bibliográficas

1. Roy Delgado, A., Picking, R., Grout, V.: Remote-Controlled Home Automation Systems with

Different Network Technologies. In: 6th International Network Conference. pp. 365-366.

Plymouth, UK (2007)

2. Friedewald, M., Da Costa, O.: Science and Technology Roadmapping: Ambient Intelligence

in Everyday Life. Working paper, Institute for Prospective Technological Studies (IPTS),

Seville (2003)

3. Grogan, A.: Smart Appliances. Engineering & Technology. 7, 44–45 (2012)

4. Koskela, T., Väänänen-Vainio-Mattila, K.: Evolution Towards Smart Home Environments:

Empirical Evaluation of Three User Interfaces. Personal Ubiquitous Comput. 8, pp. 234–240

(2004)

5. Alam, M.R., Reaz, M.B.I., Ali, M.A.M.: A Review of Smart Homes - Past, Present, and

Future. IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and

Reviews. pp. 1–14 (2012)

6. Mohammadi, M.: Automated Assisted Homes for the Elderly. In: 2nd International

Convention on Rehabilitation Engineering & Assistive Technology, pp.266-270. START

Centre, Singapore (2008)

7. Saizmaa, T., Kim, H-C.: A Holistic Understanding of HCI Perspectives on Smart Home. In:

4th International Conference on Networked Computing and Advanced Information

Management, pp. 59–65, IEEE Computer Society, Washigton (2008)

8. Frolich, D., Kraut, R.: The Social Context of Home Computing. In: Harper, R. (ed.) Inside

the Smart Home, pp. 127–162, Springer, London (2003)

9. Leppanen, S., Jokinen, M.: Daily Routines and Means of Communication in Smart Home. In:

Harper, R. (ed.) Inside the Smart Home, pp.207–225, Springer, London (2003)

10. Strain, J.D.: Households as Morally Ordered Communities: Explorations in the Dynamics Of

Domestic Life. In: Harper, R. (ed.) Inside the Smart Home, pp. 41–62, Springer (2003)

11. Mallett, S.: Understanding Home: A Critical Review of the Literature. The Sociological

Review. 52, pp. 62–89 (2004)

12. Alheraish, A., Alomar, W., Abu-Al-Ela, M.;Programmable Logic Controller System for

Controlling and Monitoring Home Application Using Mobile Network. In: IEEE

Instrumentation and Measurement Technology Conference, pp.24–27. IEEE (2006)

93


13. El-Medany, W.M., El-Sabry, M.R.: GSM-Based Remote Sensing and Control System Using

FPGA. In: Int. Conf. Comp. and Comm. Engineering, pp. 1093–1097. IEEE (2008)

14. Ahmad, A.W., Jan, N., Iqbal, S., Lee, C.: Implementation of ZigBee-GSM based Home

Security Monitoring and Remote Control System. In: 54th International Midwest Symposium

on Circuits and Systems, pp. 1–4. IEEE (2011)

15. Khandare, M.S., Mahajan, A.: Mobile Monitoring System for Smart Home. In: 3rd Int. Conf.

on Emerging Trends in Engineering and Technology, pp. 848–852. IEEE (2010)

16. Zhai, Y., Cheng, X.: Design of Smart Home Remote Monitoring System Based on

Embedded System. In:Int. Conf. on Comp., Control and Ind. Eng., pp. 41–44. IEEE (2011)

17. Li, X., Yuan, Q., Wu, W., Peng, X., Hou, L.: Implementation of GSM SMS Remote Control

System Based on FPGA. In: International Conference on Information Science and

Engineering, pp.4–6. IEEE (2010)

18. Felix, C., Raglend, I.J.: Home Automation Using GSM. In: Int. Conf. Signal Processing,

Communication, Computing and Networking Technologies, pp. 15–19. IEEE (2011)

19. Al-Ali, A.R., El-Hag, A.H., Dhaouadi, R., Zainaldain, A.: Smart Home Gateway for Smart

Grid. In: Int. Conf. on Innovations in Information Technology, pp. 90–93. IEEE (2011)

20. Van Der Werff, M., Gui, X., Xu, W.L.: A Mobile-Based Home Automation System. In: 2nd

Int. Conf. on Mobile Technology, Applications and Systems, pp. 1–5. IEEE (2005)

21. Al Mehairi, S.O., Barada, H., Al Qutayri, M.: Integration of Technologies for Smart Home

Application. In: IEEE/ACS International Conference on Computer Systems and

Applications, pp. 241–246. IEEE, Piscataway (2007)

22. Yuksekkaya, B., Kayalar, A.A, Tosun, M.B, Ozcan, M.K., Alkar, A.Z.: A GSM, Internet and

Speech Controlled Wireless Interactive Home Automation System. In: IEEE Transactions on

Consumer Electronics, 52, pp. 837–843 (2006)

23. Shahriyar, R., Hoque, E., Naim, I., Sohan, S.M., Akbar, M.: Controlling Remote System Using

Mobile Telephony. In: 1st International Conference on Mobile Wireless Middleware,

Operating Systems, and Applications, pp. 1–7. ICST, Brussels (2008)

24. Lien, C-H., Bai, Y-W., Lin, M-B.: Remote-Controllable Power Outlet System for Home

Power Management. In: IEEE Trans. Cons. Electr.. 53, pp. 1634–1641 (2007)

25. Ali, U., Nawaz, S.J., Jawad, N.: A Real-time Control System for Home/Office appliances

automation, from mobile device through GPRS network. In: 13th IEEE International

Conference on Electronics, Circuits and Systems, pp. 854–857. IEEE (2006)

26. Mandurano, J., Haber, N.: House Away: A Home Management System. In: IEEE Long

Island Systems, Applications and Technology Conference, pp.1–4. IEEE (2012)

27. Yoon, D-H., Bae, D-J., Kim, H.S.: Implementation of Home Electric Appliances Control

System based on the Mobile and the Internet. In: International Joint Conference, pp. 3730–

3733. IEEE (2006)


28. Debono, C.J., Abela, K.: Implementation of a Home Automation System through a Central

FPGA Controller. In:IEEE Mediterranean Electrotechnical Conf., pp.641-644.IEEE (2012)

29. Piyare, R., Tazil, M.: Bluetooth Based Home Automation System Using Cell Phone. In: IEEE

15th International Symposium on Consumer Electronics, pp.14–17. IEEE (2011)

30. Yeoh, C-M., Tan, H-Y., Kok, C-K.: Lee, H-J., Lim, H.: e2Home: A Lightweight Smart Home

Management System. In: Third International Conference on Convergence and Hybrid

Information Technology, pp. 11–13. IEEE (2008)

31. Oh, H-K., Kim, I-C.: Hybrid Control Architecture of the Robotic Surveillance System Using

Smartphones. In: International Conference on Ubiquitous Robots and Ambient Intelligence,

pp. 782–785. IEEE (2011)

32. Potts, J., Sukittanon, S.: Exploiting Bluetooth on Android Mobile Devices for Home Security

Application. In: IEEE Southeastcon, pp. 1–4. IEEE (2012)

33. Das, S.R., Chita, S., Peterson, N., Shirazi, B.A., Bhadkamkar, M.: Home Automation and

Security for Mobile Devices. In: IEEE International Conference on Pervasive Computing

and Communications Workshops, pp. 141–146. IEEE, Piscataway (2011)

34. Atukorala, K., Wijekoon, D., Tharugasini, M., Perera, I., Silva, C.: SmartEye Integrated

Solution to Home Automation, Security and Monitoring through Mobile Phones. In: Third

Int. Conf. on Next Generation Mobile App., Serv. and Tech., pp. 64–69. IEEE (2009)

35. Rahman, A.S.M.M., Saddik, A.E.: Remote Rendering based Second Life Mobile Client System

to Control Smart Home Appliances. In: IEEE Int. Conf. on Virtual Environments Human-

Computer Interfaces and Measurement Systems, pp. 1–4. IEEE, Piscataway (2011)

36. Marusic, L., Skocir, P.; Petric, A.; Jezic, G.: Home-in-Palm - A Mobile Service for Remote

Control of Household Energy Consumption. In: 11th International Conference on

Telecommunications, pp. 109–116. IEEE (2011)

37. Kugler, M., Reinhart, F., Schlieper, K., Masoodian, M., Rogers, B., André, E., Rist, T.:

Architecture of a Ubiquitous Smart Energy Management System for Residential Homes. In:

12th Annual Conference of the New Zealand Chapter of the ACM Special Interest Group on

Computer-Human Interaction, pp. 101–104. ACM, New York (2011)

38. Maternaghan, C., Turner, K.J.: A configurable Telecare System. In: 4th Int. Conf. on

Pervasive Technologies Related to Assistive Environments, pp. 1–8. ACM (2011)

39. Dickey, N., Banks, D., Sukittanon, S.: Home Automation using Cloud Network and Mobile

Devices. In: IEEE Southeastcon, pp. 1–4. IEEE (2012)

40. Bittins, B., Sieck, J., Herzog, M.: Supervision and Regulation of Home Automation Systems

with Smartphones. In: Fourth UKSim European Symposium on Computer Modeling and

Simulation, pp.444–448. IEEE (2010)

41. Kartakis, S., Antona, M., Stephanidis, C.: Control Smart Homes Easily with Simple Touch.

In: Int. ACM Workshop on Ubiquitous Meta User Interfaces, pp. 1–6. ACM (2011)

95


42. Suo, Y., Wu, C., Qin, Y., Yu, C., Zhong, Y., Shi, Y.: HouseGenie: Universal Monitor and

Controller of Networked Devices on Touchscreen Phone in Smart Home. In: Symposia

Workshops on Ubiquitous, Autonomic and Trusted Computing, pp. 487–489. IEEE (2010)

43. Costa, L.C.P., Almeida, N.S., Correa, A.G.D., Lopes, R.D., Zuffo, M.K.: Accessible Display

Design to Control Home Area Networks. In: IEEE Transactions on Consumer Electronics.

59, pp.422–427 (2013)

44. Kühnel, C., Westermann, T., Hemmert, F., Kratz, S., Müller, A., Möller, S.: I’m Home:

Defining and Evaluating a Gesture Set for Smart-Home Control. Int. J. Hum.-Comput. Stud.

69, pp. 693–704 (2011)

45. Chueh, T-F., Fanjiang, Y-Y.: Universal Remote Control on Smartphone. In: International

Symposium on Computer, Consumer and Control, pp. 658–661. IEEE (2012)

46. Belimpasakis, P., Walsh, R.: Fusing Mixed Reality and Networked Home Techniques to

Improve User Control of Consumer Electronics. In: IEEE International Conference on

Consumer Electronics, pp. 107–108. IEEE (2011)

47. Chen, L., Pan, G., Li, S.: Touch-Driven Interaction via an NFC-Enabled Smartphone. In:

IEEE Int. Conf. Pervasive Comp. and Comm. Workshops, pp.504-506.IEEE (2012)

48. Huang, K-Y.: Challenges in Human-Computer Interaction Design for Mobile Devices. In:

World Congress on Engineering and Computer Science, pp. 236–241 (2009)

49. Wobbrock, J.O.: The Future of Mobile Device Research in HCI. In: CHI Workshop What is

the Next Generation of Human-Computer Interaction?, pp.131–134 (2006)

50. Sainz de Salces, F.J., England, D., Llewellyn-Jones, D.:Designing for All in the House. In:

Latin American Conference on Human-Computer Interaction, pp.283–288. ACM (2005)

51. Stephanidis, C., Akoumianakis, D., Sfyrakis, M. Paramythis, A.: Universal Accessibility in

HCI: Process-Oriented Design Guidelines and Tool Requirements. In: 4th ERCIM

Workshop on User Interfaces for All, pp.1–15. (1998)

52. Akoumianakis, D. Stephanidis, C.: Propagating Experience-based Accessibility Guidelines to

User-Interface Development. Ergonomics. 42, pp.1283–1310 (1999)

53. Dunlop, M., Brewster, S.: The Challenge of Mobile Devices for Human Computer

Interaction. Personal Ubiquitous Comput. 6, pp.235–236 (2002)

54. Brush, A.J.B., Lee, B., Mahajan, R., Agarwal, S., Saroiu, S., Dixon, C.: Home Automation in

the Wild: Challenges and Opportunities. In: Annual Conference on Human Factors in

Computing Systems. pp. 2115–2124. ACM, New York (2011)

55. Weiser, M.: The Computer for the 21st Century. Scientific American. 265, 94–104 (1991)

56. Hindus, D. The Importance of Homes in Technology Research. In: Second International

Workshop on Cooperative Buildings, pp. 199-207. Springer-Verlag (1999)

57. Rachovides, D., Perry, M.: HCI Research in the Home: Lessons for Empirical Research and

Technology Development Within the Home. In: British Computer Society Human Computer

Interaction Conference, pp. 30-33. Springer Verlag (2006)


58. Liu, K.: Semiotics in Information Systems Engineering. Cambridge University Press(2000)

59. Miranda, L.C., Piccolo, L.S.G., Baranauskas, M.C.C.: Artefatos Físicos de Interação com a

TVDI: Desafios e Diretrizes para o Cenário Brasileiro. In: VIII Simpósio Brasileiro sobre

Fatores Humanos em Sistemas Computacionais, pp. 60-69. SBC, Porto Alegre (2008)

60. Santana, V.F., Solarte, D.S.M., Neris, V.P.A., Miranda, L.C., Baranauskas, M.C.C.: Redes

Sociais Online: Desafios e Possibilidades para o Contexto Brasileiro. In: XXXVI Seminário

Integrado de Software e Hardware / XXIX Congresso da Sociedade Brasileira de

Computação, pp. 339-353. SBC (2009)

61. Peirce, C.S.: Collected Papers of Charles Sanders Peirce. Harvard University Press, (1931-58)

62. Morris, C.W.: Foundations of the theory of signs. International Encyclopedia of Unified

Science, University of Chicago Press (1938)

63. Stamper, R.K.: Information in Business and Administrative Systems. John Wiley and Sons

(1973)

64. Bell, G., Blythe, M., Sengers, P.: Making by Making Strange: Defamiliarization and the Design

of Domestic Technologies. In: ACM Transactions on Computer-Human Interaction. 12, pp.

149-173 (2005)

65. Marcotte, E.: Responsive Web Design. A Book Apart, New York (2011)

66. Kotonya, G., Sommerville, I.: Requirements Engineering: Processes and Techniques. Wiley

(1998)

67. Charland, A., Leroux, B.: Mobile Application Development: Web vs. Native. In: Commun.

ACM, 54, pp. 49–53 (2011)

68. De Angeli, A., Sutcliffe, A., Hartmann, J.: Interaction, Usability and Aesthetics: What

Influences Users' Preferences?. In: 6th Conference on Designing Interactive Systems, pp.

271–280. ACM, New York (2006)

69. Tarrini, L., Bandinelli, R.B., Miori, V., Bertini, G.: Remote Control of Home Automation

Systems with Mobile Devices. In: Human Computer Interaction with Mobile Devices, LNCS,

vol. 2411, pp. 364–368, Springer (2002)

70. Oliveira, D.H.D., Mendes, G.A.V., Miranda, L.C., Miranda, E.E.C., Silva, L.F.: Domotic

based on Arduino Platform: State of the Art and New Hardware Trends (in portuguese). In:

XXXIX Latin America Conference on Informatics, pp. 1–11. IEEE, Los Alamitos (2013)

71. Correia, A.C., Miranda, L.C., Hornung, H.H.: Gesture-Based Interaction in Domotic

Environments: State of the Art and HCI Framework Inspired by the Diversity. In: Kotzé et

al. (eds.) INTERACT 2013, LNCS, vol. 8118, pp. 300–317, Springer, Heidelberg (2013)

72. Correia, A.C.C., Miranda, L.C., Hornung, H.H., Marciano, J.N.: Recommendations for

Gesture-Based Residential Interactive Systems Inspired by Diversity. In: 8th International

Conference on Universal Access in Human-Computer Interaction (UAHCI) / 16th

International Conference on Human-Computer Interaction (HCII), vol. 8513, pp. 337–345,

Springer, Heidelberg (2014)

97


73. Correia, A.C.C., Miranda, L.C., Marciano, J.N.: Syntactic/Semantic Formalizations and

Metrics of Residential Applications Based on Gestural Interface. In: 3rd International

Conference on Design, User Experience and Usability (DUXU) / 16th International

Conference on Human-Computer Interaction (HCII), vol. 8518, pp. 521–532, Springer,

Heidelberg (2014)

74. Marciano, J.N., Miranda, L.C., Miranda, E.E.C., Pereira, R.: Android MALL Apps for

Japanese Language: Identifying and Eliciting Interface/Interaction Requirements through the

Semiotic Framework. In: XXXIX Latin America Conference on Informatics, pp. 1–11.

IEEE, Los Alamitos (2013)

75. Nudelman, G.: Android Design Patterns: Interaction Design Solutions for Developers. Wiley

(2013)

76. Preece, J., Rogers, Y., Sharp, H.: Interaction Design. John Wiley & Sons (2002)

77. Nichols, J., Faulring, A.: Automatic Interface Generation and Future User Interface Tools.

In: ACM CHI 2005 Workshop on The Future of User Interface Design Tools. (2005)

78. Bühler, C.: Empowered Participation of Users with Disabilities in Univesal Design. Univesal

Access in the Information Society, vol. 2, pp. 85–90. Springer (2001)

79. Basu, S.: Modern UI Design. In: Real World Windows 8 Development, pp. 11–24, Apress

(2013)

80. Fling, B.: Mobile Design and Development: Practical Concepts and Techniques for Creating

Mobile Sites and Web Apps. O’Reilly (2009)

81. Preece, J., Rogers, Y., Sharp, E., Benyon, D., Holland, S., Carey, T.: Human-Computer

Interaction. Addison-Wesley (1994)

82. Schmidt A.: Context-Aware Computing: Context-Awareness, Context-Aware User Interfaces,

and Implicit Interaction. In: Soegaard M, Dam RF (eds.) The Encyclopedia of Human-

Computer Interaction, 2nd edn., The Interaction Design Foundation (2013)

83. Betiol, A.H., Cybis, W.A.: Usability Testing of Mobile Devices: A Comparison of Three

Aproaches. In: INTERACT 2005, LNCS, vol. 3585, pp. 470–481, Springer, Heidelberg

(2005)

84. Kronbauer, A.H., Santos, C.A.S.: Um Modelo de Avaliação da Usabilidade Baseado na

Captura Automática de Dados de Interação do Usuário em Ambientes Reais. In: 10th

Brazilian Symposium on Human Factors in Computing Systems and the 5th Latin American

Conference on Human-Computer Interaction, pp. 114–123. SBC (2011)

85. Nielsen, J.: Test with 5 Users, Alertbox (2000). Available online at

http://www.useit.com/alertbox/20000319.html

Apêndice A –

Termo de Consentimento Livre e

Esclarecido

Neste apêndice, consta o termo de consentimento livre e esclarecido (TCLE) utilizado na

atividade experimental mencionada no capítulo 6.

99



Apêndice B –

Termo de Autorização de Gravação de Voz,

Imagem e Vídeo

Neste apêndice, consta o termo de autorização de gravação de voz, imagem e vídeo utilizado

na atividade experimental mencionada no capítulo 6.

101



Apêndice C –

Formulário de Perfil do Participante

Neste apêndice, consta o formulário de perfil, ou categorização do participante utilizado na

atividade experimental mencionada no capítulo 6.

103



105


Apêndice D –

Formulário Pós-Atividades

Neste apêndice, consta o formulário pós-atividades utilizado na atividade experimental

mencionada no capítulo 6.


107



109



Apêndice E –

Autorização 1

Neste apêndice, consta a autorização referente ao uso do conteúdo de artigo publicado, que

consta no capítulo 2.

111



113



Apêndice F –

Autorização 2

Neste apêndice, consta a autorização referente ao uso do conteúdo de artigo publicado, que

consta no capítulo 4.

115

116

117

Documents

Ambientes Residenciais Controlados por Dispositivos Móveis: … · 2017-11-04 · interfaces de controle, tornando essa tarefa, relativamente, complexa. Torna-se necessário, portanto,