Psychopathological research using smartwatch technology

(1)

Psychopathological research using smartwatch technology

Jos´ e Antonio Jim´ enez Hern´ andez

First supervisor: Marco Aiello Second supervisor: Frank Blaauw

Faculty of Mathematics and Natural Sciences University of Groningen

The Netherlands

June 26, 2016

(2)

(3)

List of Figures

4.1 Notification and action button. A notification (left picture) that is binded to an action on a certain questionnaire. Swiping to the right dismisses the notification. 19 4.2 Swiping up and down. . . 20 4.3 Proposals of displays. A list (left pictures) lets the user scrolling up, and down

on the same view, although several pages (right pictures) could be faster, and offer a cleaner design. . . 21 4.4 Example of displaying a question. The white background hightlight the text. 21 4.5 Special buttons for agreement and disagreement. The green button represents

agreement (’yes’, ’I like it’, ’I agree’), the red button disagreement (’no’, ’I do not like it’, ’I do not agree’), and the blue button ambiguity (’maybe’, ’I do not know’). . . 22 4.6 Iterations of the ’agreement’ button. Firstly we make use of basic drawing

tools. Then we move into web tools that codify the buttons on precise values in XML format. The buttons start having a single color (on the figure), then we try with shapes in order to simulate volume (on the questionnaire), and finally we choose again a single color (in the final version). We also try different sizes that are shown above. . . 22 4.7 Feedback of questionnaire completion. An animation guarantees the user that

he has succesfully sent his answers. . . 22 5.1 Architecture of the system. The whole system consists of three elements: the

watch, the phone and the (web) server. The relations among elements are bidirectional, though only possible as shown in the figure. . . 23 5.2 Questionnaires’ logic. We model the layout as a grid (b), where in every row,

there is a question (a). Each question layout is composed of two elements: a CardFragment that stores the text of the question, and a custom CardFragment of three possibilities that defines what alternatives have to be shown. . . 25 6.1 Familiarity with phones. Most of the users affirm they are familiar with smart-

phones. . . 30 6.2 Familiarity with smartwatches. Most of the users affirm they are not familiar

with smartwatches, opposite to the results seen in the previous Figure 6.1. . . 31 6.3 Blue backgrounds. Blue backgrounds are the favourite options by the partici-

pants among blue, green or red variants. . . 31 6.4 Results of intrusivness. The distribution of results comparing the watch (above)

with the phone (below) are similar. . . 32 5

(6)

6 LIST OF FIGURES 6.5 Application icon. The application icon in several different situations: as the

launcher icon, as an identifier on the notification, and as an action button. . . 32 6.6 Results about the cohesion experience. We find a trend to more likely feel the

application as cohesive. . . 33 6.7 Results of intrusivness. The distribution of results comparing the watch (left)

with the phone (right) are similar. . . 34 7.1 Question and answers. Different questions are binded to different types of

answers. If it implies several alternatives, the user can swipe few times to the left to reveal them. . . 37 A.1 Cards. There are three types: simple cards, cards with actions, and a stack of

cards [29]. . . 49 A.2 Card with a potential action. It lets the user to stop/play a music service [29]. 49 A.3 Current web questionnaire. Most of the questions are answered either with a

slider or picking up an option from multiple choices [14, 15]. . . 50 D.1 Android Studio environment. The main Sections in Android Studio are the

project files (a), the coding window (b) and the debugging tools (c). . . 57

(7)

List of Tables

6.1 Summary of descriptive statistics. Questions answered on a Likert scale ranging 1-5 are statistically described (i.e. mean, mode, median, sd). . . 33 6.2 Summary of descriptive statistics. Questions answered on a Likert scale ranging

1-5 are statistically described (i.e. mean, mode, median, sd). . . 35

7

(8)

(9)

Abstract

A novel direction in psychopathology research is the use of repeated measurements over a period of time. A well-known method for performing these repeated measurements are Ecological Momentary Assesments (EMA). EMA are filled in in natural settings for user [16], and several times a day. Currently a research initiative by the University of Groningen, HoeGekIsNL, uses this approach by asking users to fill in questionnaires on the phone, a method which has a few disadvantages. Wearable technology (e.g. smartwatches) seems the least intrusive manner of administering these questionnaires to users. In the present work we focus on the development of an application prototype that runs on a smartwatch, and can be used to administer small questionnaires (2-5 questions) according to a predefined schedule.

User experience matters as long as it avoids participants faking their answers or avoid- ing completing the questionnaires. In order to determine which user interface elements work best in a smartwatch EMA application, we conduct both an online survey (n = 65) and a more intensive test in person (n = 10). Ultimately based on the results from this study, we polish the application’s prototype. The resulting prototype is an Android Wear application paired with its corresponding phone application, the phone application pushes user data to a backend server that could potentially store the results or forward them to other research platforms.

9

(10)

(11)

Chapter 1

Introduction

Wrist analog watches have been around since 1907 [1], and have been helpful for telling the time. Few decades ago technology made it possible to extend this functionality (e.g. setting alarms, lighting up the screen), turning them into what we call digital watches. The last step has just arrived few years ago with the advent of smartwatches, as capable as minicomputers [2, 1]. A smartwatch is a general purpose device, wore on the wrist, whose functionality goes beyond digital, and analog functionalities. Whereas early models can perform basic tasks, such as calculations, translations, and game-playing, modern smartwatches are effectively wearable computers (i.e. wearable general purpose devices). Many run mobile apps, using a mobile operating system. Furthermore, Generator Research predicts this market will grow to 214 million units by 2018 [3, 4, 5, 17]. Smartwatches are to stay, and most likely will play an important role in our lives [6, 1].

Nonetheless, smartwatches are not the panacea of technology. Smartwatches suffer from two major constraints which are well documented by Reza, Blaine, and Marian’s study (2015) [3]:

... their small screen size results in restricted I/O and their small hardware results in weaker computing capability, and especially limited battery capacity in comparison with larger devices. (p.48)

The screen restriction requires new ways of thinking about user experience (UX), and user interface (UI) designs [6].

We can highlight two advantages of smartwatches over other devices: (1) smartwatches are accesible at a glance (i.e. they are located on the wrist), and (2) they are constantly con- nected to the skin [1, 3]. Smartwatches can easily sense and record information such as physiological information, activity data, and knowledge of the owner’s fundamental weaknesses (e.g. excessive high heart rate after climbing stairs) [3]. The type of recollected information is not restringed to physical data, but smartwatches can be used to gather psychological data as well. We can distinguish two means of collecting such information [1, 7]: (1) actively, requir- ing the user to input the data, or (2) passively, using algorithms to analyze the low-level data (localization, hours, application usage, physical data), and extract higher-level information (e.g. mood fluctuations over days [9, 10]).

Psychology and psychiatry employ several methods to evaluate people: interviews (structured, free, half-structured), tests based on psychometrics, questionnaires, and reports [11]. A particular method of administering questionnaires are Ecological Momentary As- sesments (EMA) [12]. EMA possess certain advantages: (1) real-time assesments reduce

11

(12)

Chapter 1. Introduction 12

retrospective biases, and improve accuracy, (2) the information can be integrated with other of physiological, physical or psychological mode, (3) information can be filtered by context (specific or general), (4) interactive feedback can be given on real-time, and (5) repeated assesment can reveal dynamic processes (e.g. subtle and hard to detect interactions among users’ variables) [12].

Based on the previous features, we can wield several reasons in favor of using smartwatches as a tool to perform EMA studies [13, 7]: (1) they can deliver a questionnaire in real-time, (2) they can be used to measure other variables as well as integrate collected information with other wearables, (3) we can add filters inside the smartwatch to process the data depending on context, and (4) they are less intrusive than smartphones.

1.1 Research questions

In the present work we explore two research questions regarding the plausibility of using smartwatch applications to administer EMA questionnaires. These questions are the following:

1. Is a smartwatch capable of recording EMA questionnaires? Can a smartwatch be wired to a larger system (i.e. a research center) in an applicable manner?

2. Which user interface elements can best be used for conducting questions on a smartwatch? After trying a prototype application, what is the opinion of users towards these elements?

Aiming to answer the above questions, we build a prototype¹ of a smartwatch application, and endeavour to integrate it to a research platform known as HoeGekIsNL² [14, 15]. For approaching the second question (i.e. user experience) we explore people’s prototype’s opinion running a custom on-line survey, as well as after trying the prototype application by a few people.

1.2 Organization of the present work

Firstly, we present in the Background Chapter basic concepts that aim to facilitate the understanding of the present work. We continue stating our research questions, and the means we utilize to approach them (i.e. the Chapter of Problem analysis). Then, in the Design Chapter we describe the process of materializing a visual design for the application. Following this, we describe in the Software implementation Chapter the archiecture of the system, and its pieces (e.g. the smartwatch, and phone applications), and the most interesting snipets of code are shown, as well as briefly explained in order to clarify architectural decisions. After this, in the User experience Chapter we describe the goals, tools, and statistical analysis methods used to collect the opinion from users about the application prototype, as well as the results, and conclusions. Finally, in the Conclusions Chapter we present the final state of our prototype, critically reflect on our own work, and summarize our findings (e.g. Android Wear as preferent environment of development). In the last Chapter (i.e. Future work), we propose both improvements, and different lines of research.

1Source code: https://github.com/compsy/smartwatch-questionnaire-research

2https://www.hoegekis.nl/

(13)

Chapter 2

Background

In order to grasp the goal of the project we briefly present a few importnat concepts illustrating the background of our project. We describe related work as well as programming concepts that might be not clear for every type of reader.

2.1 A Dutch research initiative: HoeGekIsNL

HoeGekIsNL is a research initiative by the University of Groningen (RUG) in the Netherlands [14, 15]. The platform aims to conduct psychological studies on every type of person, and map what is the psychological status of the Dutch people. On the website, in Dutch, everybody is free to register, and subscribe to a study (e.g. diary study, or EMA study). As an insigthful example for the present work: a person subscribes to a diary study to evaluate its emotional status, then this person will be notified on his mobile phone by an SMS with a link to a questionnaire on the web. This is not the best way for the participants to be inquired.

2.2 Ecological Momentary Assesments (EMA)

Ecological Momentary Assesments has different names, being also called diary study, or Ex- perience Sampling Method (ESM). In words of J. Jim´enez (2014) [16], ESM/EMA:

... has the ability to capture user experiences in-situ, i.e. in time and situ- ation, and for extended period of times to elicit people’s feelings and emotional state. ESM takes advantage of the popularity of mobile devices to ask people for feedback at random times during the day. Via ESM participants can make a quick record close to the moment of interest, providing instant reports on momentary experiences instead of having to recall what they did in the past. The involvement of context-aware technologies in ESM opens the opportunity to au- tomatize the capturing of context around participants’ self-reports. Furthermore, contextual information could help to adapt the timing and content of the prompts minimizing interruptions as well as tailoring the research questions according to what has been observed. These characteristics allow the researcher to map the users’ experiences providing a closer view of people daily life over time... (p. 38) Accepting the previous quotation, one more time we can see advantages of one of the present work’s purposes, prototyping an application to conduct EMA studies.

13

(14)

Chapter 2. Background 14

2.3 Related work

This work is not the first that approaches smartwatches for administering (health) studies, be it EMA or of other type. ESTHER, STARK, and Diabetes Diary explore this opportunity [13, 7, 17]. ESTHER is a “context and emotional aware system for patients and clinicians in the home recovery of pathophysiology and psychopathology conditions” (Jim´enez, J., 2014, p.46). Paraphrasing J. Jim´enez’s work (2014, p. 46) [16], ESTHER is minded to be:

1. Reflective, enabling meaningful information to active patients’ awareness about the course of their recovery and to help them to cope with the dynamic changes of the recovery;

2. Supportive, personalizing and optimizing the quality of communication between the patient and the physiotherapist;

3. Predictive, helping clinicians to get new insights.

STARK is a system composed by a smartphone, and a smartwatch that meets particular needs for Parkinson disease study. Among these needs we find collecting clinically relevant data, and personalize the treatment through intelligent sensing elements [7]. They use two means of monitoring the users, passively or actively. A custom Parkinson disease rating scale is answered actively by users, in a similar manner to the questionnaires that HoeGekIsNL requires users to answer.

A final, and equally important example is the Diabetes Diary application. The system is composed of a smartwatch application, and smartphone application. The smartphone application is the core component, whose functionality is extended by the smartwatch application [17]. The purpose of the smartwatch component is to serve as a diary where you can introduce the status of the diabetes. The smartphone application has several functionalities, like notifying parents about the status of their children, allowing different types of diaries (e.g. Diabetes I and Diabetes II). The communication between the smartwatch, and the smartphone is constant with the purpose of exchanging crucial information. An example of the application running can be seen in a video [18] http://youtu.be/UKZMLdlZ9i8).

The previous applications reveal solid preliminary paths on which we get inspiration for the present work.

2.4 A platform for developing smartwatch applications: An- droid Wear

We have few alternatives to utilize as a platform for the application development, principally Pebble, Android Wear, Apple Watch¹, and cross-platform tools. As stated in Section 1, we choose Android Wear, this platform is characterized for few concepts which the readers of the present work are advised to know in advance. Android Wear is the operating system for smartwatches, a branch of the more general purpose operating system Android. Android Wear provides with (1) Services [30], and (2) Activities to manage the applications’ functionalities.

Both do the same, execute a modular piece of program with a specific goal (e.g. receive data from the phone), the difference is that Services can run on background (i.e. being not ‘visible’

1Also iWatch. iWatch runs WatchOS as its operating system.

(15)

15 2.4. A platform for developing smartwatch applications: Android Wear

to the user) and Activities cannot. A Fragment is a piece of an Activity [32], which can have its own visual layout.

Android Wear provides users with a Data layer whose goal is to synchronize data (e.g. questionnaires) among devices [31]. Abstractly you can exemplify it: the phone loads a questionnaire into a box (i.e. the Data layer), the watch takes the questionnaire from the box, and vice versa.

It is worth highlighting a difference in the nomenclature along the present work. When we use capital letters (e.g. Questionnaire), we always refer to the object representation in code (i.e. the software version of a real concept). A reference to a questionnaire (lowercase) means a tool used to measure, for example, a psychological construct. The use of the words

’questionnaire’, ’study’, and ’survey’ will be indistinctly used when referring to the research tool.

(16)

(17)

Chapter 3

Problem analysis

Smartwatches are a recent technology. To give an impression, Pebble, the first smartwatch, was released on January 2013 [19], while the first Apple Watch was released on 24 April 2015 [21]; finally the first Android Wear smartwatch was released on 18 March 2014 [20]. Thus, a complete knowledge of these devices as well as their capabilities remain unknown. In this Section we explore the alternatives when it concerns building the application prototype.

3.1 Research question 1

3.1.1 Is a smartwatch capable of recording EMA questionnaires?

Wearable applications have already successfully been used in research [13]. We aim to devleop an application that is available to the largest range of users, modular, and thus easibly extensible. Under these premises, we explore the idea, inspired on the smartphone field, of using web technologies (e.g. using Cordova¹) to build a cross-platform (essentially for watchOS, and Android Wear) smartwatch application. Although there are plugins being developed, and that provide basic functionality for Cordova, the state of the art up to 2015 does not guarantee a working smartwatch application on both platforms with the minimum functionality [22, 23]. Considering the openness of the Android platform, its potential growth [5], and inspired on the current dominance of Android on the smartphone market [24], we choose Android Wear as our development platform.

The Android environment makes use of the Java language for all its platforms (i.e.

Android for phones, Android Wear for wearables). Due to our familiarity with the Java language, we are able to rapid prototyping, and develop extensions (e.g. applications for other devices).

3.1.2 Can it be wired to a larger system (i.e. research center) in an applicable manner?

The HoeGekIsNL is prone to be extended, and modified. Research requirements can rapidly change, therefore it is always convenient to have a modular, and extendable smartwatch application. Besides, we aim to go further than our initial, and main goal in the present

1Cross-platform mobile application development framework.

17

(18)

Chapter 3. Problem analysis 18

work, and we try to develop a prototype of a basic REST API² for gathering the answers from the phone. We also analyse the process of doing it, e.g. how easy or complex is developing the REST API.

3.2 Research question 2: Which user interface elements can best be used for conducting questions on a smartwatch?

What is the opinion of users towards the prototype?

As stated in Lyons’ (2015, p. 3) work [25], there are open questions regarding the final use of smartwatches, i.e. what exactly the users want out of them. We quote from this paper an interesting fact:

When we turn to the research literature, there is little published work to draw upon to inform possible smartwatch design. In contrast to other domains, there is not a well established user base of smartwatch wearers to study using user-centered practices in HCI³.

With this knowledge on mind, we still have to find an appropiate user interface design for our application prototype that looks appealing to users. Otherwise, we have to assume the risk that users might eventually avoid or fake data when using the application prototype.

When it comes to facing the lack of research regarding the present research question, we can take into account a few factors that might happen to be crutial:

1. Smartwatches’ screens are smaller than usual. Smaller screens constraint the user input.

Worse still, users with mobility problems or in certain circumstances (e.g. while walking) might have problems using using the screen.

2. Smartwatches aim to be less intrusive than other devices (e.g. phones); thus the notified information must be essential for the user (e.g. upcoming meetings, taking pills). We want to send to the users crucial information in order to not have them ignoring the application.

3. The interface space to explore is novel [7]. We have no strong evidence of using a predefined design. Thus, there is no solid guidance to base the design on, and the way to get an optimal design is likely harder, even though it is crucial [8].

4. The given feedback matters. A user might be using the watch, and straight away apart the eyes away from it. Feedback have to take it into account. An appropriate feedback is crutial for a correct communication between the user, and the device.

By conducting a literature search, and creating our own user experience questionnaire, tailor-made for our application prototype, we aim to solve this problem.

2A webservice that receives requests, and returns data. A REST API works as interface among components in a system.

3Human-Computer Interaction.

(19)

Chapter 4

Visual design

The appearance of the application has a notable impact on the user experience. As previously stated, user experience forms a significant, and large part of the present work. The suitability of performing EMA in a smartwatch possesses several (visual) challenges that we aim to solve within the present Chapter. In other words, we discuss the visual design, explain our design alternatives, and justify our choices regarding the prototype design.

During the entire design process of the prototype, Google Design Principles [26, 27], similar researches [6, 7, 13, 25], and our own experience as users are our referenced sources.

We apply an iterative approach to derive a few different designs for the watch application (e.g. layouts, colors, buttons’ styles, elements’ size; see Appendix A for examples). Once we are satisfied with the resulting elements, we terminate the design of the prototype that is to be examined in the user experience survey. The application display is adapted both to squared and rounded screen watches.

4.1 Basic interaction elements

Figure 4.1: Notification and action button. A notification (left picture) that is binded to an action on a certain questionnaire. Swiping to the right dismisses the notification.

With the widespread use of smartphones and tablets, a smooth, expressive, and intuitive user-interface is required to be compared to the classical interfaces widely known in computers [8, 28]. In Android Wear the most frequently used interaction elements are (1) swiping, (2) action buttons, and (3) two button cards. Swiping is a simple movement of the screen to one side (up, down, right or left) done typically by the index finger. Action buttons are icons that when pressed, lead to a change (i.e. playing music, sending a message, showing a notification). Finally, a card with two action buttons is typically a tiny white temporal screen, with two realizable actions (e.g. playing/stopping music but also recording music).

Android Developers documentation provides UI patterns that follow its philosophy of design [29]. These patterns can be understood as stand-alone (e.g. cards) or extended elements (e.g. actions on cards). See the Appendix A for a visual example. In EMA research it is essential that a participant fills in the diary study as soon as possible after being notified

19

(20)

Chapter 4. Visual design 20

(e.g. in our case, by means of a custom vibration pattern), thus we use the idea of extended elements: a notification that when swiped to the left, displays an action button which once pressed, initiates the application, and lets the user answer directly (see Figure 4.1). This design also implies fewer finger moves for the user, recommended by Google Design Principles [26], as it shortens the actions to take in order to complete the questionnaire.

4.2 Displaying the questionnaire on the watch

Swiping vertically replaces the shown card, while swiping horizontally displays further information about the current topic [35, 26]. We adopt this idea to display the different questions, so the user can navigate along them vertically. When the user decides to answer a question, he swipes horizontally to left. Swiping up, and down always moves along different questions (see Figure 4.2 as an illustration). At any moment, swiping up takes the user to the previous question, swiping down to the next question or, at the end of the questionnaire, to a ’Send’

button that validates the answers, and finishes the entire process. Google recommends the vertical swiping to be restricted to a maximum of 5, and that the user’s activity has to be swiping up-down for changing a topic, and horizontally to expand the information of a topic [27]. In our case, showing the alternatives of a question.

Figure 4.2: Swiping up and down.

HoeGekIsNL utilizes three types of questions for its diary studies (see Figure A.3 in Appendix A): questions of 2-3 options, questions with several alternatives (e.g. 1-7 options, or a Likert scale), and numerical questions that are answered with a slider (e.g. from 0 to 100).

In consequence, we adhered to the same idea for the smartwatch application. In questions with few choices or a slider, the user has one possible horizontal swipe, i.e. to change from the question view to the answer view. When it is the case of a question with a wider number of options, displaying them on the screen can be challenging, as typically smartwatch screens are relatively small. The user has to spend longer time on the watch to decide an alternative, and all alternatives cannot be displayed at once on the screen. For dealing with this we considered two alternatives (which are exemplified in Figure 4.3):

1. A list that shows three alternatives at once. The user can navigate along the list by

(21)

21 4.3. Displaying the questions and answers on the watch screen

scrolling up and down, and tapping on his choice to confirm.

2. Several pages, each one with up to 3 alternatives. Every page illustrates three options at most. The user can swipe to the left to reveal alternatives. This is more in accordance with the ecosystem than the former alternative, since lists are to be avoided if possible in watches [26].

Figure 4.3: Proposals of displays. A list (left pictures) lets the user scrolling up, and down on the same view, although several pages (right pictures) could be faster, and offer a cleaner design.

4.3 Displaying the questions and answers on the watch screen

The questions’ text is shown in small white cards with a light blue background in the prototype version (see Figure 4.4), as a result the text stands out. The alternatives to answer are displayed in a different view that utilizes the entire screen; the background color remains the same, in order to create an atmosphere of cohesion within the application. The text for the options is rendered in boldface, and with a darker blue color. The buttons of questions that can be answered with 2-3 alternatives (e.g. yes, maybe, and no) have distinguished design and colors that are meant to represent agreement or disagreement (see below in Figure 4.5).

This layout reduces the time the user needs to answer [6].

Figure 4.4: Example of displaying a question. The white background hightlight the text.

(22)

Chapter 4. Visual design 22

Figure 4.5: Special buttons for agreement and disagreement. The green button represents agreement (’yes’, ’I like it’, ’I agree’), the red button disagreement (’no’, ’I do not like it’, ’I do not agree’), and the blue button ambiguity (’maybe’, ’I do not know’).

An example of the iterative process for creating a button is illustrated below (Figure 4.6). Eventually we decided to use a web tool known as Angry Buttons¹; using it results in a precise manner of creating buttons by means of graduating bars. The result is stored in two XML files (see Appendix C for an example) instead of a picture file (e.g. JPG, PNG).

Figure 4.6: Iterations of the ’agreement’ button. Firstly we make use of basic drawing tools.

Then we move into web tools that codify the buttons on precise values in XML format. The buttons start having a single color (on the figure), then we try with shapes in order to simulate volume (on the questionnaire), and finally we choose again a single color (in the final version).

We also try different sizes that are shown above.

4.4 Providing (visual) feedback to the user

Figure 4.7: Feedback of questionnaire completion. An animation guarantees the user that he has succesfully sent his answers.

Providing feedback once an action has been taken is also another recommendation by [26].

Feedback can have several modalities (e.g. tactil, visual, auditive), and modify user behavior [36]. We briefly show a short message (50 ms.) that notifies the user with its choice (e.g.

’OK! selected’). When finishing the questionnaire a short animation of approx. 1 second is executed (see above Figure 4.7). If all the questions are not answered, a short message warns the user. We employ visual feedback because it is the least intrusive within the given application’s context.

1http://angrytools.com/android/button/

(23)

Chapter 5

Software implementation

The details of the software implementation follows below, where we discuss the software design (e.g. the system architecture), as well as snipets of code that show interesting Android features or helps revealing the structure of the system. The tools used for developing, and testing the system are explained in Appendix D.

5.1 Software design

Software design comprises the design of both the system in overall, and each of its parts (e.g. watch, phone, and backend server). To facilitate the understanding, we provide a few conceptual diagrams.

5.1.1 System architecture

The application adheres to a service-oriented architecture (SOA) [33, 34]. SOA is a widely used paradigm to develop distributed systems [34]. This architecture allows fast developing (e.g. adding new components in different environments). As an example, a layered architecture is used in SPARK [7].

Figure 5.1: Architecture of the system. The whole system consists of three elements: the watch, the phone and the (web) server. The relations among elements are bidirectional, though only possible as shown in the figure.

Above in Figure 5.1 a schema of the system architecture is pictured. The watch is the core element of the present work. The smartphone executes a background service application that serves as an entrypoint for the communication with the backend server. The server is currently a REST service, which we create in order to prototype the system and test particular phone/watch functionalities (e.g. receiving and sending data, marshalling and unmarshalling¹

1Serializing and deserializing. To convert complex data objects into bytes and viceversa

23

(24)

Chapter 5. Software implementation 24

data).

In order to synchronize data between the watch and the phone, we make use of Google Data Layer. A requirement of the Data Layer is that we have to have a third module (i.e. a common module) that stores the custom, and shared data structures, so the use of serializa- tion² can be done among the devices when sending the data. The synchronization of data is done, in our case, straight-away, so notifications arrive to the watch as soon as possible.

5.1.2 Common files to smartwatch and smartphone applications

We created a few classes that represented the data of our system, and are common to both applications. A Questionnaire object is composed of a serie of Question objects. A Ques- tionnaire object has a unique key that is used to identify a unique questionnaire’s answer. A Question object stores few attributes, a boolean value³ that specifies if a question is mandatory or not, the type of question (i.e. it is answered with few alternatives, many alternatives, or a slider), and the possible alternatives to choose as an answer. There are three types of questions, and each of them is represented in the code as a class: FewAnswers, ManyAnswers and SliderAnswer. It improves code readability, maintainability, and makes easier to create new types of questions.

5.1.3 Smartwatch application

The application can be split on two activities. A MainActivity that in the prototype stage works for generating a fake questionnaire, as well as initializing the answering process (i.e.

show the notification, be able to dismiss it, and adds the action button). The second activity is QuestionnaireActivity, which takes care of the main purpose of the application: collecting the answers and sending them. QuestionnaireActivity utilizes a GridLayer object (see Figure 5.2 (a)), where every question is a regular CardFragment, and the alternatives to answer are stored in customized Fragments (see Figure 5.2 (b)). These fragments are of three types: Slid- erFragment, ManyAnswersFragment, or FewAnswersFragment. Each fragment implements a different layout stored in an XML file that is named in a reference manner to its corresponding fragment (e.g. FewAnswersFragment loads the layout from the XML file “few answers.xml”).

2An alternative is Parceability - https://developer.android.com/reference/android/os/Parcelable.html

3A boolean value can be either true or false.

(25)

25 5.1. Software design

Figure 5.2: Questionnaires’ logic. We model the layout as a grid (b), where in every row, there is a question (a). Each question layout is composed of two elements: a CardFragment that stores the text of the question, and a custom CardFragment of three possibilities that defines what alternatives have to be shown.

Fragments are advised by Google to create dynamic application layouts [32]. Thus, even though the activity remains the same, QuestionnaireActivity, the questionnaires, built upon different Fragments, are created dynamically. This allows easily expandable capabilities for questionnaires, as it is one of the requisits of the current research. Adding a new type of answer is as easy as creating a new customized Fragment, and adding it on the Activity when building the Questionnaire object.

5.1.4 Smartphone application

A task can demand a constant use of the processing power from the device (e.g. checking constantly for new WIFI networks), which drains battery energy. Such tasks are left to the handheld since both it is recommended in the design guidelines by Android Developers guide [26], and widely seen in research [35]. Therefore, we develop a secondary application for smartphones that is intended to:

1. Run a Service in the background that listens to the answers to a questionnaire from the watch.

2. Wrap the questionnaires in a Notification, and deliver them to the watch.

3. Once the answers to a questionnaire are received from the watch, push them to a REST API web service.

This application consists of an Activity and a Service. A MainActivity that, for testing purposes, has a button to generate a Notification object which has attachted a predefined questionnaire. A Service that runs on the background, and works for communicating with the phone by means of the Data Layer. There is also a REST client class that is used by the Service to push data (i.e. the answers of a questionnaire) to the web server.

(26)

5.1.5 REST API as webserver

The current implementation⁴ only serves the purpose of receiving the questionnaire’s answers from the smartphone as it was developed purely for demonstration purposes and to test the prototype.

5.2 Implementation

Few snipets of code are shown below. These snipets reveal the details of implementation in order to meet many of our goals (e.g. an extendable application, taking the user to fill in questionnaires as soon as possible). Because of their importance, we consider to illustrate, and explain them.

5.2.1 Dynamically building the questionnaire layout in the application Dynamically building the questionnaire layout, as stated in Section 5.1.2, improves maintainability and readability. If we want to add a new type of question, we only need to create a class object defining it, and use it. This is important as well as it is an open source code.

The code that can be seen in Appendix B.1 consist of a loop that loads the questionnaire’s information from the Questionnaire object (e.g. received within the notification), and fills in the grid with the questions’ texts, and their alternatives. The technical name of this pattern is 2DPicker [27] (more information in the Appendix B.1).

5.2.2 WatchViewStub and dynamic layouts

An important aspect of creating an optimal user experience is the visual look. The perfor- mance of this visual look can be negatively affected by the fact that watches have different screens, and a squared layout might not work correctly on a rounded screen. The WatchView- Stub is used to adapt the MainActivity’s XML layout (i.e. the file that defines the visual layout used by MainActivity) to both squared, and circle screen watches. The rounded or squared layout is rendered during runtime depending on the type of screen. The procedure follows:

1. Android loads the visual layout for MainActivity (i.e. the XML file R.layout.main activity).

2. A particular object defined in the MainActivity’s XML layout is a Stub. Android loads it from the Layout into the memory of the program.

3. This object detects the type of the screen (i.e. squared or rounded) and, depending on it, finally loads a subtype of MainActivity’s XML layout.

This elegant solution is provided by Google Design Principles [26]. We did not have time for implementing it on every application’s context. The code can be found in Appendix B.1.

4https://github.com/compsy/qapp-webapp

(27)

27 5.2. Implementation

5.2.3 Notification (builder) properties

Notifications are key to our implementation idea. Notification objects are the representation, in code, and in program, of a notification. A Notification Builder allows the programmer to customize Notification objects (i.e. a notification ‘represented’ in the software program) in a easy manner. By using a Notification Builder we can establish all the characteristics of our Notification (e.g. lines 6-15). Besides the basic features of a Notification (e.g. the title, small icon; lines 8 and 9, respectively), we have few features more of our interest for the project.

First, making use of setPriority (line 6) we deliver the notification as soon as possible to the patient from the handheld. If we did not make use of PRIORITY MAX (still line 6), the user could be notified up to one hour later, which is pointless for our goals, as EMA studies require the user to answer as soon as possible. In line 7 we create our custom vibration pattern in order to make it differentiable from other notification’s vibrations, so users who are prone to ignore vibrations (e.g. because they receive too many) can filter the application’s notification, and not to ignore them.

When a notification is received, a white card appears on the screen. This card, as commented in Section 4.1, can be associated to an action. At lines 8-12 this action is attachted to the Notification object, and specifically at line 11 we define that this action has to take the user to answer the questionnaire.

At line 14 the Notification object is sent using a unique ID. This ID is the same as the ID in the Questionnaire object created. A dismissed Notification dismisses the possibility to answer a Questionnaire.

1 p u b l i c v o i d s h o w N o t i f i c a t i o n ( V i e w v i e w ) {

2 N o t i f i c a t i o n n o t i f i c a t i o n = new N o t i f i c a t i o n C o m p a t .←- B u i l d e r ( t h i s )

3 . s e t P r i o r i t y ( N o t i f i c a t i o n C o m p a t . P R I O R I T Y _ M A X )

4 . s e t V i b r a t e ( new l o n g [ ] { 1 0 0 0 , 1000 , 1000 , 1000 ,←- 1 0 0 0 } )

5 . s e t C o n t e n t T i t l e ( g e t S t r i n g ( R . s t r i n g .←- n o t i f i c a t i o n _ t i t l e ) )

6 . s e t C o n t e n t T e x t ( g e t S t r i n g ( R . s t r i n g .←- n o t i f i c a t i o n _ c o n t e n t ) )

7 . s e t S m a l l I c o n ( R . d r a w a b l e . i c _ l o g o _ q a p p )

8 . a d d A c t i o n ( R . d r a w a b l e . i c _ l o g o _ q a p p ,

9 g e t T e x t ( R . s t r i n g .←-

a c t i o n _ l a u n c h _ a c t i v i t y ) ,

10 P e n d i n g I n t e n t . g e t A c t i v i t y ( this , ←- N O T I F I C A T I O N _ R E Q U E S T _ C O D E ,

11 new I n t e n t ( this , ←-

Q u e s t i o n n a i r e A c t i v i t y . c l a s s ←- ) ,

12 P e n d i n g I n t e n t .←-

F L A G _ U P D A T E _ C U R R E N T ) )

13 . b u i l d () ;

14 N o t i f i c a t i o n M a n a g e r C o m p a t . f r o m ( t h i s ) . n o t i f y (←- N O T I F I C A T I O N _ I D , n o t i f i c a t i o n ) ;

15 f i n i s h () ;

(28)

16 }

5.2.4 Questionnaire builder

We implement the Builder design pattern to create our Questionnaire builder. Firstly, we created three classes that represent the different archetypes of answers’ type. Using them it is clearer which class of answers we want, and internally the question establishes its TypeOfQues- tion value. As a consequence, we have a QuestionnaireBuilder that improves readability, and facilitates the process of adding questions. The logic of building a questionnaire, and its questions lies completely on this new class. It also suffices the need for an easily extensible application; now we can add new types of questions by means of adding new classes.

Building a questionnaire looks like in the following snipet of code. In the lines 1,2 and 8 we create three different types of questions. From lines 2 to 7 we add several alternatives to the second question, which is of the type that holds several alternatives. In lines 11-15 we add those questions to a new questionnaire, and finally we ‘build’ it.

1 F e w A n s w e r s f a n s w e r s = new F e w A n s w e r s (" yes ", " no ") ;

2 M a n y A n s w e r s m a n s w e r s = new M a n y A n s w e r s () ;

3 m a n s w e r s . g e t A n s w e r s () . add (" V e e l te d r u k ") ;

4 m a n s w e r s . g e t A n s w e r s () . add (" L e k k e r d r u k ") ;

5 m a n s w e r s . g e t A n s w e r s () . add (" N e u t r a a l ") ;

6 m a n s w e r s . g e t A n s w e r s () . add (" L e k k e r r u s t i g ") ;

7 m a n s w e r s . g e t A n s w e r s () . add (" V e e l te r u s t i g ") ;

8 S l i d e r A n s w e r s a n s w e r = new S l i d e r A n s w e r (" 0 ", " 100 ") ;

9

10 Q u e s t i o n n a i r e B u i l d e r q B u i l d e r = new ←- Q u e s t i o n n a i r e B u i l d e r () ;

11 Q u e s t i o n n a i r e q u e s t i o n n a i r e = q B u i l d e r .←- s e t U p Q u e s t i o n n a i r e (3) // T h r e e q u e s t i o n s

12 . a d d Q u e s t i o n (" H e e f t u s i n d s het v o r i g e ←- m e e t m o m e n t g e s l a p e n ? ", true , f a n s w e r s )

13 . a d d Q u e s t i o n (" Hoe d r u k heb ik het ? ", true , ←- m a n s w e r s )

14 . a d d Q u e s t i o n (" Hoe g a a t het op dit m o m e n t met u←-

? ", true , s a n s w e r )

15 . b u i l d Q u e s t i o n n a i r e () ;

(29)

Chapter 6

User experience research

User experience does not have a universal definition [37]. Few commonly accepted ideas are that user experience has to do with affect and feelings; the experience is seen as subjective and individual-centered more than social-centered [37]. There are several conceptions of user experience, namely: business-oriented, or stand-alone applications. The former focus on how users experience their relation with a company as a whole (e.g. Google, Facebook, Amazon), the latter focus on how a single user experiences an application (e.g. Gmail, Hangouts, Google Search). We are interested in the latter one since we aim to develop a particular application that potential users (e.g. research participants) do not dislike, or even more, refuse to use.

6.1 Research methods

Interviews, and observation while testing a product (e.g. a prototype like our smartwatch application) are two frequent means of measuring user experience [38]. Using a questionnaire (e.g. for asking for particular feedback) after trying the prototype is found to be used in research [36] as well. We designed a custom questionnaire (see Apprendix E) that explored few aspects from potential users: (1) general information for analysis purposes (e.g. experience with smarwatches), (2) the attitude towards particular UI elements (e.g. “What is your opinion about the application icon?”) in the survey Section “Interface Elements”, (3) the attitude towards several components of a general user experience when using an application (“General App Experience”), (4) the opinion regarding the feedback in-app (survey Section

“Feedback”), and (5) the attitude towards the current status of the application (“Evaluating QuestApp”). At the end the survey provides an open question for optional extra comments.

We have two modalities to pass the questionnaire. An on-line modality, where the application is not tested but explained and shown in pictures; and an in person modality where the application is tried and, following it, the questionnaire is filled in. Under the first condition, we make use of ‘snowball sampling’ to reach as many people as possible to fill in the questionnaire (e.g. friends, and also friends of friends), as well as Internet forums. Under the second modality (i.e. in person), we explain the user what is the purpose of the project and teach basic usage of a smartwatch (e.g. swiping to the left usually shows more options on a card, but swiping to the right tends to dismiss). This usually takes approx. 5 minutes, then we ask the user if he feels confident enough to try the prototype. Before handing the watch to the user, we create a notification by means of a special button on the prototype. The user then uses the watch application to fill in a fake-questionnaire of 3 questions, one of each kind

29

(30)

Chapter 6. User experience research 30

(i.e. few options, many options, and using a slider), and to send it once it is finished. After being finished with the application, the user is passed the questionnaire. The only difference with the on-line modality’s questionnaire is question 9, that instead of being answered using a Likert-scale, two opposing alternatives are given.

The on-line questionnaire is stored and passed by Google Forms¹ and analysed by Google Sheets². We also make use of Google Sheets to put in the data from the in person modality and to analyse the data.

6.2 Results regarding the user experience research

We show, both textually and graphically, the results from the user experience research questionnaire, in the on-line modality as well as in the in-person modality. Finally, this feedback leads to changes in the prototype, which we explain in the Section 7.1.

There are qualitatively two different groups to analyze, depending on the modality that was used to pass the questionnaire. We consider the possibility of different results and answers, specially regarding the free comments at the bottom of the questionnaire (i.e. more comments when passed in-person). We show graphs whenever possible and interesting. A partial summary of on-line results can be seen in Table 6.1, and a partial summary of in-person results can be seen in Table 6.2.

6.2.1 On-line results

The sample size is of n = 65. The average age is 24.6 years old (SD = 5.4, mode and median are 23 yrs. old), 66.2% of participants are male, and 33.8% are female. Most of the participants consider themselves familiar with smartphones (”I use one everyday”, alternative 5) with 85.7% of answers. Nevertheless, the pattern of answers is reversed when it comes to how familiar are participants with smartwatches, with most of the people finding themselves with no experience at all (68.3% - ”I have no experience with them”, alternative 1). See Figures 6.1, and 6.2.

Figure 6.1: Familiarity with phones. Most of the users affirm they are familiar with smartphones.

1Website to create custom forms for surveys and questionnaires at no extra cost. You can gather ev- erything in a spreadsheet and analyze data right in Google Sheets. Link: https://www.google.com/intl/en- GB/forms/about/

2Website to create spreadsheets and edit with others at the same time. Link:

https://www.google.com/intl/en-GB/sheets/about/

(31)

31 6.2. Results regarding the user experience research

Figure 6.2: Familiarity with smartwatches. Most of the users affirm they are not familiar with smartwatches, opposite to the results seen in the previous Figure 6.1.

Interface Elements

The most appealing background colours are of blue tonality (options C and D, with 36.5%

and 28.6% of answers). Two examples used during the study are shown below in Figure 6.3.

Figure 6.3: Blue backgrounds. Blue backgrounds are the favourite options by the participants among blue, green or red variants.

81% of inquired people chooses option A for the questions regarding two unique alternatives to answer. A more even result is found when people are asked about multiple choice questions (58.7% for option B). For questions that are answered with a slider, almost half of participants choose option A (47.6%), among 4 options.

General App Experience

57.2% of the users answer that the questions, once answered, should remain available before delivering the questionnaire (e.g. for letting them change an answer). Nearly half the participants feel neutral towards how intrusive is the procedure of delivering the questionnaire (42%

of answers) in smartwatches (see Figure 6.4). For the smartphone version of the question, the distribution of answers remains the same. More than half of the users like double-tapping (i.e. clicking fast two times on the screen (e.g. to choose an answer)) when asked (52.4%).

(32)

Figure 6.4: Results of intrusivness. The distribution of results comparing the watch (above) with the phone (below) are similar.

Regarding the application icon (see Figure 6.5), the participants provide a neutral answer (28.6%) or do not like it (42.9%).

Figure 6.5: Application icon. The application icon in several different situations: as the launcher icon, as an identifier on the notification, and as an action button.

Feedback

Most of the users think that it is convenient to provide feedback to the users when selecting an option in the application (76.2% of answers). Most of the users think that the feedback should be either temporary (33.3%) or both temporary and permanent (36.5%).

Evaluating QuestApp

Slightly more than half of the participants think that the whole application is cohesive (52.4%

of answers; see Figure 6.6), with 28.6% participants choosing a neutral position. A large subset of participants (90.5%) think that users should be provided with in-app instructions (e.g. basic functionality). Finally, when participants are asked if a short and temporary message is convenient as feedback, most of them think so (between 75% and 95%, depending on the type of question).

(33)

33 6.2. Results regarding the user experience research

Ten participants filled out an optional comment at the end of the survey, four of them are partially or totally useful. An insightful comment states, “If older people are using the smartwatch, the letters have to be darker to clearly see the text. I would make a white background and black letters everywhere.”

Figure 6.6: Results about the cohesion experience. We find a trend to more likely feel the application as cohesive.

Question 3 4 9 10 11 12 13 14 16 18 19 20

Mean 4.72 1.72 3.41 3.33 3.22 3.49 2.78 3.92 3.43 3.64 3.62 3.78

Mode 5 1 4 3 3 4 3 4 4 4 4 4

Median 5 1 4 3 3 4 3 4 4 4 4 4

S.D. 0.76 1.28 1.42 0.95 1.11 1.15 1.22 0.97 1.01 1.2 1.21 1.14 Table 6.1: Summary of descriptive statistics. Questions answered on a Likert scale ranging 1-5 are statistically described (i.e. mean, mode, median, sd).

6.2.2 In person results

The sample size is of n = 10. The average age is 27.3 years old (SD = 11.33, mode is 22, and median is 23.5 yrs. old³), 50% of participants are male. Most of the participants consider themselves familiar with smartphones (”I use one everyday”, alternative 5) with 90%

of answers. Nevertheless, the pattern of answers is reversed when it comes to how familiar are participants with smartwatches, with most of the people finding themselves with no experience at all (60% - ”I have no experience with them”, alternative 1).

Interface Elements

The most appealing background colours are of blue tonality (options C and D, with 50% and 40% of answers).

Every participant chooses option A for the questions regarding two unique alternatives to answer (100%). A more even result is found when people are asked about multiple choice questions (50% for option B). For questions that are answered with a slider, one more time every participant chooses option A (100%), among 4 options.

3Two participants did not reveal their ages.

(34)

General App Experience

Half of participants answer that the questions, once answered, should remain available before delivering the questionnaire (e.g. for letting them change an answer). Half the participants feel it most intrusive towards how intrusive is the procedure of delivering the questionnaire (50% of answers) in smartwatches (see Figure 6.7). For the smartphone version of the question, this tendency grows (75% of answers). Also three quarters of the users like double-tapping (i.e. clicking fast two times on the screen (e.g. to choose an answer)) when asked (70%).

Due to the small sample size, an histogram like in the on-line modality does not suit when illustrating the results of intrusiveness; a chart is chosen instead (see Figure 6.7).

Figure 6.7: Results of intrusivness. The distribution of results comparing the watch (left) with the phone (right) are similar.

Regarding the application icon, most of the users feel neutral or affirm to like it (80% of answers).

Feedback

Every user thinks that it is convenient to provide feedback to the users when selecting an option in the application. Most of the users think that the feedback should be either temporary (20%) or both temporary and permanent (80%). It replicates the pattern of answers showed in the on-line results.

Evaluating QuestApp

Slightly more than half of the participants think that the whole application is cohesive (60%

of answers). A large subset of participants (70%) think that users should be provided with in-app instructions (e.g. basic functionality). Finally, when participants are asked if a short, and temporary message is convenient as feedback, most of them think so (between 75% and 95%, depending on the type of question).

Received comments

In the in-person modality there are more comments than in the on-line modality, nearly every participant gives verbal or written feedback. Few of these comments are remarkable, as few examples:

(35)

35 6.3. Conclusions from the user experience research

Question 3 4 10 11 12 13 14 16 18 19 20

Mean 4.4 1.6 3.4 3.9 3.6 3.1 4.4 3.3 4.8 4.7 4.8

Mode 5 1 4 4 4 3 4 4 5 5 5

Median 5 1 3.5 4 4 3 4 4 5 5 5

S.D. 1.26 0.84 0.7 0.57 0.7 1 0.52 1.25 0.632 0.67 0.42 Table 6.2: Summary of descriptive statistics. Questions answered on a Likert scale ranging 1-5 are statistically described (i.e. mean, mode, median, sd).

• “QApp icon is pixeled”. Even though more people like the application’s app, we receive this remark. It can be a consequence of printing the questionnaire, or changes in resolution.

• “You could use the entire screen”. This, on the same path as Google Design Principles [26], tells us, in particular for displaying the alternatives of agreement-disagreement, that we can split the whole screen in halves, thus using the entire screen.

• “X is not an intuitive button for me. I would have put W”. We wonder if the icons of the buttons (i.e. ’X’ for disagreement) are as universal as we aim to.

6.3 Conclusions from the user experience research

From the usability research we conducted we can conclude the users who answer the custom questionnaire, in overall, affirm they do like the application structure, they find it cohesive, they do not like the icon, and when faced to alternatives, although they find few of them the most attractive, users agree that the design can be improved.

In person results show divergent results in few questions. For example, in this group, most of the participants like the application’s icon. They also provided with many more comments than in the on-line modality. Few users did not feel confortable with the use of smartwatches.

Few remarks have to be said when it comes to the qualitative differences among groups. The size in the in person group is more reduced comparing with the on-line modality;

therefore it is likely that the sample is not representative. Moreover, the people who filled in the user experience questionnaire are related to the author of the work (e.g. friend, classmate, relative), thus the answers are likely to be biased.

To sum up, the user experience research is a success. The research provides a precious insight that is partially used to improve the application (Section 7.1), or explored as part of future work (Chapter 8).

(36)

(37)

Chapter 7

Conclusions

Partially based on the conclusions from the user experience research, we show the resulting changes in the prototype. Following this, we discuss the present work, and determine general conclusions.

7.1 Resulting changes in the prototype

We can see below (Figure 7.1) the final look of the smartwatch application. The background color is lighter, close to white. It is grey enough to be distinguished from the cards and improve readability, helping to hightlight the content that matters (i.e. the question’s text).

This modification is inspired on the already insightful comment (see again Section 6.2.1) by the survey from the online modality. It is also in line with the previous “blue color” approach, as it was the least disrupting color from the given to choose on the survey (i.e. red, green, and blue).

Figure 7.1: Question and answers. Different questions are binded to different types of answers.

If it implies several alternatives, the user can swipe few times to the left to reveal them.

The slider and counter are moved upwards, based on the results of the survey. The buttons with the text ’OK!’, ’ ?’ and ’X’ are modified, returning to a plain-color style. The shapes are different, being finally squares with rounded edges. The name of the ’agreement’

button (i.e. ’OK!’) changed, being before a ’|’ symbol which could lead to confussion; in other words, an ’OK’ text has more likely the same meaning on people’s mind than a ’|’ symbol.

7.2 General conclusions

In the present work we faced two challenges: (1) exploring the feasability of developing a smartwatch application for conducting EMA studies, and (2) exploring UI elements that best

37

(38)

Chapter 7. Conclusions 38

fit our application’s purposes. After choosing Android Wear as our developing platform, we created an application prototype, and a custom questionnaire to collect written feedback about the users’ experience. Using the results of this questionnaire, we developed the final prototype. Finally, this prototype is wired to a system composed of a smartphone and a backend server. The final state of the system is a prototype that allows basic interaction with questionnaires, and has basic functionality for exchanging data.

The smartwatch applications’ space is nowadays rather unexplored, and basic, thus limiting the ways of approaching our goals, both when it concerns software design, and visual design. Still, Android Wear seemed the best platform for several reasons: (1) growing market share, (2) opening of the platform, and (3) rich, diverse, and good documentation, both from direct and indirect sources.

Regarding the Research question 1 (i.e. Is a smartwatch capable of recording EMA questionnaires? Can a smartwatch be wired to a larger system (i.e. research center) in an applicable manner?), we can conclude that (1) there is no tool that already lets researchers create a cross-platform EMA application for smartwatches (e.g. Cordova) [22]. (2) Android Wear, together with iWatch, are the platform that support, and will support in the long-term, most of the users.

When developing the current prototype for Android Wear, soon we realized how essential it was to create a paired smartphone application, being in our case crucial. Developing the phone application was not an issued, as its functionality was basic, and its purpose was to behave as a point to communicate the watch, and the backend server.

Concerning wiring the whole system, and particularly the phone and watch applica- tiosn to the backend server, we did not wired it to HoeGekIsNL, as firstly expected, but to the REST API with basic functionality. We lowered the goals as wiring the phone, and watch modules to HoeGekIsNL will be a complex task beyond the scope of the present work.

Conceivably, as a secondary or parallel option, working on iWatch might have been a good option. If we finally went for Android Wear was because of our preliminar background with the same programming language (i.e. Java). Still, it is worth remarking than Android Wear is used in multiples devices, despite WatchOS.

Finally, as we developed an EMA application, and wired it to a smartphone, and partially to a backend server, we can answer affirmatively to both halves of the question.

Research question 2 (i.e. Which user interface elements can best be used for conducting questions on a smartwatch? After trying a prototype application, what is the opinion of users towards these elements?) was an intriguing, and more unexplored path. Previous work helped us [13, 7, 17] initiating the present work, which together with Google Design Principles [26], motivated us to create a custom user experience questionnaire in order to capture the users’

opinion. This research was conducted in two modalities, with the goal of gathering as much feedback as possible, and that was an issue well resolved by the on-line modality. The nature of these modalities was qualitatively different, thus the analysis were conducted separately, even though the conclusions did not notably differ.

The conclusions revealed by the user experience research are advised to be taken as temporary. The research was rather exploratory due to time constraint (i.e. 3 months), and how hard was to conduct a proper research of this kind. Still, the results stretched the exploration space, facilitating for future work the research of user experience in smartwatch diary study applications.

In general we can conclude that the research was a success, the main research questions were both satisfactorily answered. Besides, the user experience research revealed insightful

(39)

39 7.2. General conclusions

information to lead future research.

(40)

(41)

Chapter 8

Future work

Although the present work has proved itself successful to answer the main research questions, several questions remain unanswered at present. We advise to run a larger number of user experience studies, mostly in person after trying the application. We think that a higher control of variables can be convenient (i.e. the same question layout when asking for background colors, biases by Internet users). These two changes will improve current validity, and fiability results. Besides, future surveys are advised to be of shorter length, and inquire about more particular topics; this corresponds rather with a confirmatory study than an exploratory study [39]. For unexplored paths (i.e. application’s functionalities that are beyond the current scope), we recommend inquiring users by open questions [40, 41], and make use of closed questions as the space of test becomes smaller (similarly to what the researchers have done in other reserach project [13]). Ideally, the user experience studies can be run in parallel with upcoming iterations of the visual design, so there is a richer exchange of information (i.e. feedback) among processes.

Metrics can be used to evaluate the modularity, and extensibility of the smartwatch application, a modular and extensible application guarantees easier maintenance. An example of metrics to be used are in the reference [43]. Regarding the smartphone application, we recommend to develop further the platform, incrementing the functionality of the software (e.g. subscription to questionnaires, scheduling questionnaires, answering questionnaires, sav- ing a record of answered/missed questionnaires). A specific (and useful) proposal is managing mandatory and non mandatory questions inside a questionnaire. Moreover, providing longer feedback (i.e. a copy of analyzed results) as suggested by J. Jim´enez (2014, p. 46) [16], in order to motivate users to keep engaged with the application, is a path worth being explored.

The use of WatchConnect is worth exploring [23]. WatchConnect is a recent toolkit for prototyping smartwatch-centric cross-device applications. WatchConnect aims to implement fast, intuitive, and easy transfer of data among different devices, which can be ideal for prototyping different whole structures for the current system (i.e. watch, phone, and backend server).

The platform is potentially extendable, e.g. the backend server can be fully integrated in the product platform HoeGekIsNL, going further than the current prototype stage, as the platform so far uniquely supports basic functionality. This requires a complex study of (1) what is the best way to fully wire the system components, and (2) what are the means to use to wire them (e.g. by direct transfer of data, use of an API, database).

41

(42)

(43)

Acknowledgments

I am very thankful to both supervisors, Frank and Marco, as well as to all the study participants who filled in the questionnaire either on-line or in-person. Special thanks to Paulina, whose Android smartphone was intensively used for testing purposes.

43

(44)

Psychopathological research using smartwatch technology