PRE2020 3 Group8

Group description

Members

Name	Student number	Department
Edwin Steenkamer	1006712	Computer Science
Emi Kuijpers	1227154	Psychology & Technology
Fanni Egresits	1316400	Psychology & Technology
Morris Boers	1253107	Computer Science and Psychology & Technology
Lulof Pirée	1363638	Computer Science

Main Task division

Task	Members
Backend software (database, question scheduling, output)	Lulof & Edwin
Graphical User Interface	Morris
USE-part	Fanni & Emi

Prototype

Video of demonstation and final presentation

GitHub Page:

GitHub

Logbook

See the page logbook_group_8

Main Concept: Motis

Abstract

A pure software end-user application that supports people in their need to socialize while motivating self-improvement. Anthropomorphism is intentionally used to increase user commitment and experience. Machine learning techniques are used to process user's data and provide feedback, and to facilitate the anthropomorphized interface.

Conceptualized Idea

Hypothetical idea: an application designed to motivate its users into a more (mentally) healthy way of living life. The user can put in any preferences to be motivated on and set its own goals. Numeric data of the user will be tracked in a communicative way rather than filling in forms, is stored and compared to older data, and reflection of this comparison will be given in a personalized way back to the user. The application can be configured by domain specialists, such as dietists, trainers and clinical psychologists, making it a widely employable tool for aiding users in positive behavior change.

On this page, the concept of this motivating coaching system will be presented. This system combines specialized monitored and self-measured data from its user with individual and reference knowledge to give its users an overview (and recommendations). The system will keep track of one’s daily life structure, translate and summarize the numerical input into recommendations in a continuous personalized motivating coaching dialogue taking into account the needs and preferences of each user individually.

Problem statement and objectives

Problem Statement

Often loneliness is associated with elderly people living unintentionally in social isolation due to unfortunate circumstances. However, the reality is that loneliness is experienced by all ages and almost all humans. Humans are social animals , and we humans influence each other by merely existing together. Loneliness is seen as a severe public health issue due to its association to increased risk of morbidity and mortality . A study by Luhmann & Hawkley suggests that the prevalence rates of loneliness are highest for young adults (<30 years).

Loneliness can best be stated as the perceived discrepancy between the desired amount and the actual perceived amount and quality of social communication and relationships. Both physical, as well as mental health and overall well-being, can suffer from this. With less social relationships, less comparison and facilitation from others will influence a person's behaviour and motivation, leading to a decrease in intrinsic motivation.

Due to the COVID-19 pandemic restrictions, many people are forced to stay at home . These restrictions also cause personal trainers, dieticians, and other employees that help people engage in a more healthy lifestyle to be unable to work with the normal citizen. However, at this very moment, people must maintain a healthy lifestyle. Exercising and healthy lifestyles increase at the beginning of covid. After the restrictions aimed at minimizing the risk of local transmission of SARS-CoV-2 got stricter, it is more likely that this leads to reductions in physical activity. Therefore, it is necessary to find other ways to externally motivate people to maintain a healthy lifestyle independent of other people's motivation.

Besides the external motivation that humans get from other people, we also can motivate ourselves. People have a very complex decision-making process, and not always the rationally right decision is chosen for a particular event or action. Heuristics are used as a mental shortcut to make decisions and are simplifications. These can occasionally lead to systematic flaws and errors, which are deviations from the normative decision-making model, known as biases.

One of these biases is overconfidence, a bias during interpreting and assessing information, the second step in the decision-making process. People are often biased in their confidence concerning the hypothesis they have brought in their working memory, believing that they are more correct more often than they actually are. For example, if people would have to report how much they ran during a jog, they will most likely unconsciously overestimate themselves. There is also the psychological phenomenon called planning fallacy, where people underestimate the time it will take to complete a future task. Combining this will optimism bias, which explains our tendency to overestimate the likelihood of experiencing positive events and underestimate the occurrence of negative events. The human mind can sometimes be a dangerous decision-making toolbox to rely on. Using this system, the data gathered from the user will serve as a toolbox. They can be seen as an extended memory that provides the user with statistically true information so decisions will be made taking into account actual statistics, rather than only the estimations and thoughts humans have left of past events. In this way, users will be calibrated towards the truth and rely less on decisions made while possibly be biased.

Survey and research

Before any actions, some realistical science based proof was needed. Therefore, instead of interviewen or collecting our own participants for a survey, we looked up public databases from already conducted surveys. Below, the results of different analysis can be seen. The main reason why we analysed this data because we wanted to see how much the responses reflected the negatively influenced mental health after long working hours and lonely spent time. We wanted to compare genders to see whether there is any difference and to see how many people actually seeked help who said their mental health decreased due to the circumstances. We highly assume with a dataset from 2020, where the COVID-19 situation appeared, these numbers would be more critical. As the results show, the need of any kind of help is needed for these people which is the main reason why we believe MOTIS is a useful and high demand technology.

The table below displays the overall response results from the 1258 participants from the public survey of Rupa Lahiri and Diego Calvo in the topic of “Mental Health in Tech Survey in the Tech Workplace in 2014” . We ran few tests with our team and we compared the answers of the interviewees on mental and physical health deterioration based on gender differences. In the survey we had 1000 male and 259 female respondents. The possible responses were yes, no or maybe. In the first results we inspected whether there were mental health consequences of the long-term quarantine. Most of the answers arrived in the category of No or Maybe. The answers reached almost the same level which could mean uncertainty about it or shame in the topic.

Between genders we had 415 No (41.5%), 221 (22.1%), and 364 (36.4%) Maybe answers out of the 1000 male responses. Additionally, 75 (29%) No 71 (27.4%) Yes, finally 113 (43.6%) Maybe responses from the female participants. It clearly indicates that women admitted the negative influence of home office work and the 36.4% “Maybe” responses from males, although shows some unclarity, still gives a strong feeling of problems.

As an additional analysis, we inspected the number of people who seek help after admitting visible negative mental health problems. 646 of the overall responders said he or she does not seek help. The highest number of answers fell in this category. Based on this research we could give another strong point to believe our product needs a quick and effective implementation.

Needs

Two needs arise from the problem statement above. Firstly, to reduce biases in the decision-making process due to falsely remembered memories, people need to be provided with an objective summary of their past events. Secondly, the net amount (both intensity and frequency) of negative emotions and lack of motivation experienced due to a lack of social interaction must be decreased to fill the lack of external motivation. A system is needed that enhances intrinsic motivation and also provides personalized social interaction to the user to enhance engagement while using the system.

Goals

To reach the needs stated above, the software application has two main requirements:

• Firstly, the system's main aim is to provide users with insight in parts of their behavioural patterns that are unknown to them. Humans tend to rely heavily on their intuitions, which can often strongly deviate from its true value. The system will serve as a non-biased evaluation tool, which will result in the user discovering behavioural patterns after a fixed period based on their objective data, rather than intuitions and memory.

• Secondly, to increase the motivation of the user to put in data, and to enhance positive changes in behavioural patterns, anthropomorphic features and serious gaming will be used while designing the system. Using a human-like question generator to let the user put in data rather than a non-interactive (for example, a questionnaire), the user will perceive a need to answer the system rather than merely filling in the data. The aim here is to increase motivation and overall well-being by presenting the data's reflection in a personalized way.

Beyond the scope

The following features are probably valuable additions to the product, but they are beyond the scope of what can be achieved in one quartile:

• Voice recognition, natural language text inputs (natural language processing is too much to add within the given timespan)
• Animated anthropomorphized interface (e.g. simulated face)

Current State-of-the-art

Exercise

Bickmore and Picard developed a computer-based virtual relational agent that served as a daily exercise advisor by engaging the user in conversation and providing educational information about walking for exercise, asking about the user's daily activity levels, tracking user progress over time while giving feedback, and engaging the user in relational dialog. These kind of social agents are also used often as a weight-loss advisor coach.

Work

Ted Grover et al. describe an experiment with two chatbots used to help office employees focus on their work. The chatbots require the user to plan periods of focus-time, and remind the user to start and stop those periods. The chatbots also notified users when they appeared to be distracted, and they propose breaks when the user appears focused for a long time.

Two different chatbots were used: one that appeared to have emotional intelligence, that used emoji, and used a recorded face with audio for messages. The other was a simpler chatbot with only a textual interface.

The main result was that the 'presence' of a chatbot made users focused (less distracted, more time present behind computer) better during their focus-times than without a chatbot. Outside of the focus-times no significant results were found in this study.

This topic is further explained in the #Literature Review.

User description

Primary Target Audience

The application will be designed to be used by technology-oriented adults (mainly focusing on younger than 30 years), who interact with computers and smartphones on a daily basis. The main target for this system are students who spend most of their time alone in their student accommodation. This can both be due to contemporary COVID-19 pandemic stay-at-home regulations, but also for users who live abroad for a short time, for example.

The focus will also be on people who want to improve their daily structure and overall well-being in any way but have no idea what would be best for them. Therefore, the system will provide its user with objective data to discover clear behavioural patterns that might have lead to certain events. Users are more extensively described at the user analysis-section.

As stated before, the focus will be put on the younger generation. Because of their affiliation with technology, it is most certainly easier for them to adapt to systems and be nudged into a healthy behaviour compared to people who first have to accept the device before being able to use the application. Research also states that mental illnesses cause a huge burden on the younger generation's illnesses.

The application will likely not be suitable for children due to its design constraints, or for elderly people who are not technology-oriented and adapted to new technologies.

User requirements

To engage positive behaviour in people using an AI application, an accessible and practical user-interface is critical. An irresponsible, unintuitive or unfinished interface may discourage users from using the application, let alone be positively nudged by the application. Users need to perceive social engagement and be positively motivated by the system to change its behaviour.

User-Centered Design

When looking at the user, four motivations should be fulfilled in order to let the system successfully be adapted by its user. Human factors should be considered during the design of applications of this kind. With the information stated above, it has been decided to consider the following four characteristics as important during the user analysis.

(1) Technology-oriented

(2) Curious to learn

(3) Trust in technology

(4) Adaptive skills

To take universal design into account, it is also important to know what variables are feasible and relevant to track for the broadest range of end-users possible. After that, one must consider how to track the data in an engaging enough way so that the user will keep using the system. It must take little effort for the user to put in the data, and possible ethical threats regarding privacy, efficiency, and effectiveness must first be evaluated when defining the way of tracking and monitoring the user. These can be found below in #Ethical regulations Motis must meet.

Notifications and reminders should also be provided to the user in a way that is not perceived as negative in any way.

Persona Storyboards

In this section, one can see some examples of the target audience to get a clear overview of the main users of the system and with what kind of characteristics one must take into account while designing the system.

Design and Approach

While designing the system that will enhance healthy behaviour in a pro-active way, we followed the design methodology, which asserts that the SAR agent must possess :

(1) The system must have the ability to influence the user's intrinsic motivation to perform the task.

(2) The system must have the ability to personalize social interaction to maintain user engagement in the task and build trust in the task-based human-robot relationship.

Only with these characteristics can the system be implemented successfully and be effective in one's life. The two characteristics will be explained below.

Influence the user's intrinsic motivation

First, the system must have the ability to influence the user's intrinsic motivation. Intrinsic motivation comes from a person itself, and it has been shown that intrinsic motivation is more effective for long-term task compliance and actual behaviour change. . Intrinsic motivation does not have to be triggered by the person itself, but can also be affected by external factors, for instance, by a (digital) instructor or coach. Through positive and negative (verbal) feedback, the intrinsic motivation of the user can be affected.

Below, three characteristics of a system that influence intrinsic motivation according to previous studies have been explained briefly, which will later be implemented in our system.

Competition

Humans like to compete against each other and improve themselves, and be challenged to compete against an ideal outcome. Studies show that humans perform better in a competitive environment compared to a non-competitive environment.

Therefore, it is important to consider designing and providing weekly summaries, high scores and comparisons to the user. These concepts tend to increase the intrinsic motivation for the task . The user must be exposed continuously to their performances for motivational purposes.

Reward and Criticism

Both reward and criticism are two forms of feedback a digital coach can give. According to a study conducted by Vallerand and Reid (1984), forms of negative feedback – criticism and punishment – is considered to have a negative impact on the intrinsic motivation of the user . On the other hand, Vallerand also stated in another study (1983) that positive feedback – praise and reward – tend to positively impact the user's intrinsic motivation .

However, it is essential to note that the effect of positive feedback is closely tied to the user's own perceived competence at the task. Once a user believes he is doing an excellent job while performing a task, praise and reward are no longer affecting intrinsic motivation.

It is decided that the system will not provide any negative feedback and only praise and reward the user upon correct completion of tasks and when following up the right advice. With this, the user can be helped with getting a healthier lifestyle without a decrease in intrinsic motivation.

Autonomy and Self-determination

To achieve long-term behaviour change, the system should support user autonomy and self-determination Users do not want unnecessary information and do not want to put in data that they think is unnecessary.

Therefore, the user will have the freedom to choose the preferences he/she wants to be advised for. The users can also set the amount and timing of notifications and can also put in questions themselves. User choice and the level of autonomy a user wants differs per system and innovation. This makes self-determination a fascinating concept that must be studied specifically for this system with a user-study.

Personalized Social Interaction to maintain User Engagement

Anthropormorphism

The tendency to attribute human features or behaviour to non-human agents is called Anthropomorphism . Emotions and affects have an important role in human cognition, which cannot be disabled. Therefore, to truly motivate the end-user to long-term behaviour change, emotional responses must be evoked by the user.

Anthropomorphic design principles are often employed to facilitate interaction and acceptance. In social robotics, this is often done by designing a physical embodiment with human-like features . To make the system easily accessible and feasible for most people of the target group, it has been chosen to design a system for commonly used devices (phone, tablet, computer).

The communication interface design of Motis contains some anthropomorphic features. Motis has two eyes that follow the cursor of the user, and blink regularly. Motis also has a mouth, which it uses to adapt its expression to the evaluation of the given answer or latest feedback. For negative evaluation, Motis will show a 'sad' expression, for neutral a 'neutral' expression and for positive evaluation a 'happy' face as can be seen below. This evaluation is based on a numeric value ranging from -1 to 1, which is determined in the evaluation part of the Rule that caused the output. Motis also mentions the name of the user when talking to them, to gain a more personal connection.

These features will be elaborated upon in the software section.

Serious Gaming

Motis is designed to proactively motivate people to engage in a healthy lifestyle, by providing the end-user with objective statistical information in a personalized way. To gain the data from the end-user, the user can 'chat' with Motis by answering the questions. By answering these questions, the user will gain points that will eventually bring him/her to a new level. A new level will unlock new features of the application, ranging from backgrounds to preferences of the appearance of Motis itself. In this way, serious gaming techniques will be used to motivate the user to answer questions (required for data collection) and to read the feedback.

Possible Impact on End-user

In the last twenty years, many Internet-delivered and movile mental health interventions are being brought to both the market as well as in the field of research .

A lack of support, guidelines, and regulations in the ethical field could cause possible ethical threats using a monitoring system like Motis, which will be discussed in this section.

Conversational Embodied Agents and Chatbots

Motis is, at its core, an advanced chatbot. A chatbot can be defined as machine agent that serves as natural language user interfaces for data and service providers . Chatbot can serve a large variety of different roles, but they share common goals: engaging in a conversation to track, educate, encourage or prevent some behavior from the user . These systems especially influence the behaviour of the younger generation, due to their technology-oriented view of life. Chatbots provide the perfect blend between immediacy and asynchronicity, because of its combination of prompt answers/feedback and notifications/reminders . The user will receive the summarized data in a way that will be perceived as more personal.

An experiment has been conducted (2014) in order to determine the percentage of people that seek professional help when they have troubles with their mental health, exercising, diet, and sleep. Studies show that this percentage is extremely low, which can be caused by many different reasons. People might not feel like their problem is worth seeking help, or think they can fix it on their own, they cannot financially afford it, do not have enough time for it or simply do not think about it. Especially the younger generation first tries using the internet and mobile phone applications before reaching out for professional help. Therefore, the applications offered need to be professional and serve as a digital coach for people who do not want to seek professional help for any reason they provide. Chatbots are also the perfect system to be perceived as non-judgmental and objective.

Chatbot versus Social Robot

A paper by Andrea Deublein and Birgit Lugrin shows the result of an experiment where social robots are compared to tablets. The results of the study indicate that none of the experimental conditions (social robot // tablet // emotional social robot) was generally perceived superior to the others. Each interface has its own advantages. The tablet performed best for usability and workload, but social perception and overall evaluation were higher rated when there was a more social interface used.

This provided the motivation to design Motis as an application that has both a social interface while being accessible. The software runs on all everyday devices (phones, tablets, desktops), which will increase the overall usability and amount of work expected from the user. To add a social interface, users give the answers Motis via a chat-like environment rather than a simple form. By doing this, Motis will be perceived as more socially engaging, and perform better as a digital coach to promote healthy behavior change in users.

Effectiveness

Research in the fields of effectiveness show different results, but state that it is important to take possible ethical threats into account during the design process.

Fixed responses (e.g. Likert scales) might help users label their subjective experiences, but it could also leave users feeling limited and unable to express themselves properly. Therefore, it has been chosen to also add a free text box where the user can type their thoughts out for themselves and reread it later. It is also possible to connect this textbox to a certain mental state (by using a Likert scale). Since all users will perceive a likert scale in a different way, it has been decided to only compare the user's data with his previous monitored data instead of also comparing it to other people's data. In this way, the system will not face any problems in effectivity due to perceptual differences of the users.

As of yet, chatbots are not able to communicate with humans in a completely natural way. A rising problem in artificial intelligence is often that the more human a system is perceived, the more is also expected from the system. As the Woebot warns its users saying "I may seem smart, but I am not capable of really understanding what you need", or as general chatbots (e.g. chatbots at websites serving to answer basic questions) often state that they are "not understanding what you mean" when you use different phrasings or typos. To avoid the possible frustrations a user could possibly face, it has been decided that the chatbot will have fixed way of answering the questions, in combination with the free-text where a person can state its thoughts and reread it later. In this way, possible inappropriate or disappointing answers are avoided, to not give the user the feeling the system is unable to help the end-user.

Ethical Recommendations Motus must meet

A study done by Kretzschmar et al. (2019) gave a clear outline of the ethical recommendations for chatbot creators that are developed during a group discussion about mental health chatbots amongst the younger generation. These recommendations are therefore based on young users (age 14 till 18), and can also be applied for this system. The recommendations are categorized in three sections: Privacy & Confidentiality, efficiacy, and safety. Below, it is briefly discussed if Motus will meet these recommendations, and if so, in which way. Since Motis will be developed as a flexible system so more features that are currently not feasible with the available resources, time, and money, it is also discussed how possible new features have to be developed to meet the recommendations below.

Privacy and Confidentiality

In particular, young people consider the availability of trusted relationships to be a key motivational factor for seeking professional support . It is therefore important to keep the data private as far as possible. If anything is shared, it is essential that it does not contain any personal identifiable information.

It has been showed that people felt more comfortable with sharing personal and honest information when it was possible to chat anonymously. Therefore, our system only asks for a user name rather than connecting the account to an existing profile on a social media platform.

The four suggested recommendations are:

(1) Personal information, if collected, should be kept confidential

The original Motis collects four kinds of data from its user: Its username and password, the input data on the provided (daily) questions, the output data (chat), and the input text in the free text-box. The current system will only use the input data to perform a statistical analysis and only store it on the device of the user and will not be further distributed. Therefore, the current Motis meets this recommendation.

To be monitored better using other features (for example connecting a smartwatch, step-counter, sleep-tracker), it also means the user has to give away more personal information. The user must agree upon the fact that the information will be monitored, but only be stored on his or her own device. In this way, the personal information will be kept confidential.

(2) Content of conversations, if shared, should be de-identified

The current implementation does not share any of the gathered data. All extracted information is stored locally on the user's device only.

It may be necessary to introduce centralized information collection for certain future extensions of Motis (see #Future work). These would require careful anonymization of the information.

(3) Privacy arrangements and limitations should be made transparent to users

For the current Motis, as well as when new features would be added, all privacy arrangements and limitations will be transparent to users by letting them accept the privacy conditions for the application before using the device. Without accepting the privacy conditions, it is not possible to use the system. The device will not distribute or extract personal data in any way. However, it is possible to adjust the amount of data that is stored on your device.

It is suggested that the best way to inform users about privacy arrangements is to outline these within the chat in an easy language and format. Therefore, in the beginning, when one starts the chat with Motis, a brief summary of the privacy arrangements will be stated in bullet points in order to let the user go through the most important arrangements fast.

(4) Users should have the option of being reminded of privacy arrangements and limitations at any stage

In the settings, it is possible to reread and adjust the privacy conditions for the device. With any new update and possible new arrangements, the user will have to accept the new conditions again before making use of Motus. If any further update contains intruding options, it is always possible not to accept and stay at the current version of the system.

However, it has also been suggested that the most user-friendly way to remind the user about the confidentiality arrangements is to program the chatbots in a way that by typing the words 'privacy' or 'confidentiality', the privacy conditions will be shown to the user. Therefore, this option has also been implemented in the system.

Efficacy

The four regulations for this section are:

(1) The support provided should be evidence-based

As a general rule, it is important that the support offered by chatbots is based on clinical approaches that have been empirically supported. Therefore, instead of coming up with the input questions ourselves, it has been chosen to have an intermediate interface. This concerns a configuration file to specify which variables to track, which questions to ask and which feedback to give. In this way, the domain specialists (such as dietists, personal trainers, and psychologists) can configure and ensure the feedback provided is based on proven practices of their field, without needed to edit the source-code.

In future versions of Motis, it is also possible to let the interface be a GUI with a formula-editor, that automatically checks every value entered and allows the user to construct the rules and questions using buttons for connectives, and drop-down-menus for variables. The GUI interface could produce a text file with the simplified syntax. By letting the specialist make the rules, the provided support will be more objective.

(2) The platforms should be tested empirically

Before the system gets available for the end-user, multiple empirical tests should be performed in order to be sure that there are no unforeseen hidden threats. A usability test is necessary to test the system for its flaws. Before proceeding with the actual prototype, a small survey has been distributed amongst young people (age 18 - 24) to ask which preferences they consider important in 'maintaining a healthy lifestyle'. The results were mainly in the direction of diet, exercising, sleep, and mental health. The same survey also showed participants were most afraid that their data would be misused, which is a common occurring fearful thought. Therefore, the user must accept the terms and conditions before using the app, and the most important privacy guidelines of the system will also be shown to the user through the chatbot when the user uses Motis for the first time (see Privacy section, point (4)).

(3 + 4) Users should be informed about the extent to which the service is backed up by evidence and what the chatbot targets.

The study used for this section implies that more information about the target user of the chatbot is wanted, so that people can assess better if the platform will meet their goals. Therefore, it must be made clear to the target audience why the system is designed and in what circumstances it is meant most to use it. EVen though this is important to implement, (young) people may not look for themselves per application that they use whether it is empirically validated. Therefore, it is crucial to provide only evidence-based, trustworthy, objective, safe information to the end-user.

Safety

The four regulations for this section are:

(1) Users should be informed that they are talking to a robot

Motis will call himself a chatbot, and since it does not contain more anthropomorphist features than the digital interface, there is no need for fear for cognitive deception/depletion of the user. However, users often like to be informed about how a system works, so they get a better grasp of the innovation they are using. Therefore, Motis will call himself a chatbot and will also be able to explain himself if needed (see guideline 3+4, section 'Efficacy')

(2) Automated chatbots should encourage people to seek human support

An automated chatbot must serve as a helper rather than a problem-solving machine. It is therefore important that Motis encourages the user to seek human support if the capabilities of Motis are insufficient enough to pro-actively change bad behavioural patterns.

(3+4) Automated chatbots should have systems in place to prevent over-reliance, and must be able to deal with emergency situations

These guidelines are not crucial for an innovation like Motis, since Motis will only serve as a helper for good behavioural change in the main categories diet, exercise, and sleep. Besides this, mental health is taken into account, but if the user consistently gives low ratings to the mental-health questions, Motis will propose to see an actual therapist.

Lack of transparency can change the balance of risk and benefits for the user. Therefore, being conscious about the possible ethical threats while designing the system is crucial for acceptance by the users.

Software Design

This section describes the architecture of the prototype implementation. The prototype is an offline desktop application that runs on multiple operation systems (it has been tested on Linux and Windows). All user information is stored locally only, effectively avoiding the overhead of server hosting and privacy issues. Note that for a fully developed product a more complex design will be needed, and a central sever would be essential.

Overview

The prototype software is divided over four modules:

1. The Graphical User Interface (GUI). This is the module only the user will directly interact with. It provides a modern interface reminiscent of a modern chat services, together with an abstract anthropomorphized face. The GUI runs in a separate process.
2. A database. A local SQL database used to store the gathered user information. The SQLite implementation is used, as this provides a lightweight, server-less SQL server.
3. The data gathering process. In order to provide useful feedback to the user, information must be gathered regularly. This module manages a calendar of reoccurring sets of questions. As soon as their scheduled moment is reached, the question sends the questions to the GUI process, and stores answers in the database. The data gathering also runs as a separate process.
4. The output generation process. This third process monitors the database and triggers feedback production as soon as criteria are met. Furthermore, it formats the output and attaches an evaluation.

It is of conceptual importance that the data gathered about the user belongs to a certain Variable. Variables can for example be hours of sleep, a mood evaluation, an energy evaluation, number of friends spoken, minutes of exercise, etc. The system is designed such that the set of tracked Variables can easily be changed, even at runtime.

Overview of the software organization. Three processes are running in parallel: only one of which is directly visible to the user (the GUI, Graphical User Interface). The second process is the Question-Answer process, that invokes the GUI to ask the user to insert data, and which also stores the answers in the database. Questions occur according to a configurable weekly schedule. The third process is the Feedback process, which uses a configured set of 'Rules' to determine what summary statistics of the database should be provided to the user, and under which conditions. The Rules, the set of Variables that the database records, and the questions are configured in a text-file that is read when the application starts up. Not shown is the persistent database, also stored on disk, that will be loaded if the application is restarted.

The software is designed for two kinds of users: end-users and domain specialists. The end-users will interact with the system via the graphical user interface, and represent the target group in need of feedback and support. The domain specialists are, for example, psychologists, dietiststs and organizations who wish to tailor the application to their own needs, in order to help their clients. The latter group of users will use a less salient configuration file to setup the tracked information and questions asked.

Overview how the two types of users can interact with the system. End users will exclusively interact through the GUI. They will need to register their name once in the system, and after this they can use the main functions of the program: answering questions and receiving feedback on their data. This data is stored in a local database, and also feedback is drawn from the database. As an extra motivational feature, users can also customize the appearance of Motis' avatar, and unlock more customization options the more they use the application. Domain specialists do not interact with the GUI, but only configure the questions and feedback the end-users will receive (in advance of employment).

Graphical User Interface (GUI)

For the creation of the Graphical User Interface a free open source library is chosen called Kivy. Kivy offers a framework for developing multi touch application in Python that uses a Natural User Interface design (NUI). A NUI puts the idea of an inexperienced user being able to quickly learn how to interact with the interface central. The Kivy framwork includes a graphics library using standard OpenGL methods and a wide range of customizable widgets that support multitouch projects. While the developer could write a full GUI using only python, Kivy also offers a flexible markup language called the KV language. The Kv Language is a CSS-esque intermediate language which makes it easier to design the GUI and add interactions to Widgets. It was designed to give an easy to use alternative for dividing independent front-end and back-end development. Now a full overview will be given of all pages and elements of the GUI and where and to which degree the user can interact with them.

Login page

To start off when the user starts up the application, they will be brought to the login page of Motis as seen below. Here the user will be presented with the Logo and is asked to fill in their login information. Here the user can type in their username, password, and real name (e.g. what the system should call them) in the provided textbox fields. This information is asked to make a distinction between different user and personal information in the database. This will also provide Motis with the ability to call the suer by its name which will enhance personal connection. When the user provides the correct combination of username and password they will be forwarded to the main page of the application.

The login screen of the application

The main screen of the application

Main page

On the main page Motis will be presented as seen above. Motis is designed in a simple way with customizability an expendability in mind. Add this point Motis consists of a mouth and two eyes but is given some anthropomorphic features to look more alive.

First of all, Motis has the ability to blink ever so often. This is decided by a random number generator which generates blinking intervals from 1 to 10 seconds. Another anthropomorphic feature is that Motis follows the mouse pointer of the user with its eyes. It does this by moving its pupils over a imaginary circle to the position that is at the same angle of the mouse pointer to the center of the circle. This simulates as if Motis is looking at a certain direction. Lastly, Motis is given the ability to express basic emotions using its mouth. The mouth can be given a numeric value from -1 to 1. With 1 meaning that Motis is happy and -1 meaning that Motis should be sad. This is achieved by lowering the corners of the mouth up to signal happiness and lowering the corners of the mouth down to signal sadness as discussed in the anthropomorphism section.

Below Motis the chatbot-function can be found. Here the user can go into a conversation with Motis. This text-based communication is designed such that it looks like a messaging platform familiarized by apps on a user’s phone (e.g. WhatsApp, Facebook Messenger, Instagram DM’s etc.). This is done to evoke the feeling that the user is talking to someone at the other end of the platform, as this is what normally would happen with the mentioned above apps. When Motis asks a question to the user and the user wants to send a message back to answer the question there are three possible message types. Depending on the question asked the user can answer using a textbox, in which the user is free to type anything, a numeric slider in which the user can answer with a number specified in a pre-defined range or the user can click one of the given multiple choice options presented by a set of radio buttons. These three types can be seen below. The additional possibility to communicate via png images was also implemented but this has been left out in the final prototype for the sake of simplicity.

Every time the user answers a question the level bar on the top of the home screen increases a bit. When the full level bar has been filled up the user has reached a new level which will be communicated with them using a pop-up. Also, the level bar drains again and the new level will be shown as a number besides the level bar. Every time a new level has been reached the user will unlock new customizability options. These options allow the user to personalize Motis to their liking. This feature will be further explained in the settings section. Doing this will transform our application into a serious game to keep the user engaged and motivated as discussed in the ‘serious game’ section.

Settings page

When the user clicks in the top navigation bar on the ‘cog’ icon they will be directed to the settings page as seen below. Here the user has the possibility to change numerous things like the color or theme used throughout the app, various customizability options and configurations settings for the backend.

When the user clicks a different theme color all things presented in the app which currently have a yellow color, for example the body of Motis, color of messages or the outline color, will change to the selected color. Doing this it will give the user the feeling to make the app their own. This can also enhance the viewing experience and could be expanded upon to include a dark or light mode.

Below this the various customizability options for Motis can be found which will gradually be unlocked when the user moves trough the levels. When a option has not yet been unlocked it has been given a gray shading as can be seen on the last background option. The user can click on the desired option in every category which changes the appearance of Motis on the main screen. The first big change that can be made to Motis is giving it a body, giving the choice between a circular, rectangular, or triangular body. When chosen the selected body is added to the main screen and enables Motis to breath. Motis body will expand and shrink over time repeatedly is to simulate breathing. This again adds a anthropomorphic element to Motis gaining more liveliness. Besides this a few purely customizability options are added like choosing a type of hat or moustache. Enough flexibility in the system has been built to easily expand this in the future and provide more content to be explored throughout the levels. A few examples of how Motis could look can be seen above.

Lastly variables that connect with the backend can be changed to the users liking on this screen. For example the maximum daily amount of questions the user can receive from the system can be changed here using a slider.

The settings screen of the application

The profile screen of the application

Profile page

When the user clicks on the ‘profile’ icon in the top navigation bar they will be directed to the profile page as can be seen above. This page has been built in the show raw statistics of the various trackable variables. This has not been implemented in the final prototype due to time constraints. Here also the logout button can be found to safely logout. When this button has been clicked the user will be brought back to the login screen. This ensures that no one else but the user with the correct username and password has access to the user data.

Database

The prototype implementation of the database uses a local SQLite3 database. The organization of the database is straightforward: there is a table variables containing all registered Variables, and for each Variable a new table is created that stores the recorded values of the Variable.

The primary key of variables is a string var_name. Also stores as a string the type of the variable and as an integer the timestamp when it was added.

For each Variable, the corresponding table has the name of the Variable. Each entry contains a value of the datatype corresponding to the Variable, a timestamp and a unique ID-number as primary key.

Data Gathering Process

The responsibility of the data-gathering process is to periodically prompt the user with questions, and to store the responses in the database. Questions are simply send to the GUI, and answers send back from the GUI.

Most logic lies in scheduling the questions. The questions are organized as a calendar: for each question, a specific day of the week and a timestamp are specified. The question will be generated and send to the GUI every week at this timestamp.

Output Generation Process

Rules

The output generation works on the basis of a set of so-called rules. A rule is a mathematical function that compares the values of one or more Variables, and possibly their history, and maps this to a Boolean output (True / False) plus presentable information. The Boolean part of the output indicates whether the observation is worth notifying the user about. The other output is the actual output given to the user, which can be a summary statistic of their data, a notification about a positive or negative trend, a major change in pattern, etc... This output will not be presented directly to a user, but will first be formatted by the Formatter.

The third output of some rules is an evaluation. In its simplest form, this is a decimal number in [-1, 1], where -1 indicates 'bad', 0 'neutral' and 1 'good'. This evaluation is used to tune the formatting of the output, and also the expression of the anthropomorphized face of the GUI will adapt to the 'mood' of this evaluation.

Similarly to Variables, also rules are not hard-coded and can be added or removed at runtime. Note that the set of employed rules must be designed carefully, in consideration of psychological/behavioural research, for a successful application of the software.

The use of rules is a tradeoff between feasibility and performance. Ideally, one would not have to create rules manually (which introduces risks of errors, forgetting to add important rules, etc.) but use an automatic system to decide when and what feedback to provide. Such a system would be able to maximize the impact on the user, and hence the utility of the software. Furthermore, it could add a reliable and detailed evaluation. However, this approach would require an advanced model of human health and cognition, which is far beyond the current state of the art.

Another solution would be to use large amounts of prior data. Either through statistical means or through machine learning, it is possible to accurately map data to an evaluation, and possibly also to appropriate feedback. This would require less domain knowledge of the engineer than designing the rules, but the set of chosen Variables must be fixed and reflect the datasets well. This approach is not used, as it hinders the flexibility of the software, and the required data is not easily gathered within the scope of the project.

Intermediate interface

Individual rules can relatively easily be implemented in the source code, and in a similar way, it is simple to add variables. However, the stakeholders who need to specify the rules are not the programmers. Instead, this will be the domain specialists, such as dietists, personal trainers, and psychologists (see #Stakeholder analysis). It cannot be expected that these people have the time, motivation or experience to read the source code. Hence it was decided to provide a simplified interface for defining rules. This interface is still hidden from the end-users, but simpler for the domain specialists to use without prior programming knowledge. This helps to empower domain specialists to use the software as a tool to support their clients, who are the true end-users.

Accessibility

The domain specialist can specify variables and rules via a text file. For this purpose, a simplified syntax is used. In particular, to reduce ambiguities the following properties have been added:

• The syntax is case insensitive
• No manual indexing is needed. This avoids the ambiguity of the first index: this is often 0 in programming languages, whereas the value 1 is often used in mathematics and everyday language.

An even simpler interface would be a GUI with a form or formula-editor, that automatically checks every value entered and allows the user to construct rules by means of buttons for connectives, and drop-down-menus for variables. This remains a possible extension point of the software. Note that it is not in conflict with the syntax specified below: this GUI interface could produce a text file with the simplified syntax.

Defining Variables

Specifying variables is simple, as only a name and a type are needed. Take for example:

var hours_sleep decimal

This line specifies that a variable 'hours_sleep' needs to be created and that it will have decimal numbers as values.

In general, the variable-defining syntax is:

var [name] [type]

where:

1. var specifies that the rest of the line describes a Variable.
2. [name] specifies the name of the variable. The name may not contain whitespaces.
3. [type] specifies the type of the variable. The following types are recognized:
   1. Decimal numbers: any of decimal, float, num, number
   2. Integer numbers: any of int, integer, wholeNumber
   3. Strings: any of str, string, text

Defining Questions

The questions follow a very similar syntax as the variables. They only require a Variable's name, and a string. For example:

question hours_sleep (Monday Tuesday) 12:33 How many hours did you sleep today?

Will result in the user being asked "How many hours did you sleep today?", and the answer of the user will be stored as a value of the Variable hours_sleep. This question will be asked every Monday and Tuesday, always at 12:33.

In general, the syntax is as follows:

question [var_name] ([days]) [hour]:[minute] [question-body]

where:

1. question specifies that the rest of the line describes a Question.
2. [var_name] specifies the name of the variable asked after. The answering options presented will adhere to the type of the Variable, and the value users answer will be stored in the table of the respective Variable.
3. [days] specifies the days of a week at which the question is asked. This are one-word names separated by a whitespace. Accepted keywords are Monday, Mon, Tuesday,Tue, Wednesday, wed, Thursday, Thu, Friday, Fri, Saturday, Sat, Sunday and Sun (all case-insensitive).
4. [hour] is an integer in [0, 23] specifying the full hour of the timestamp at which the question is to be asked.
5. [minutes] is an integer in [0, 59] specifying the minutes past the hour of the timestamp at which the question is to be asked.
6. [question-body] specifies the string shown to the user when the question is asked. For best usability, this provides a clear, concise and motivating description of what information the user needs to fill in.

If a question must occur multiple times during the same day of the week, one can simply construct multiple question lines in the configuration file (one for each desired timestamp).

Defining Rules

A rule is defined on a single line of the file. They consist of three parts: a trigger, a message and an evaluation. This is best explained with an example:

rule mean(hours_sleep(last 3))>=mean(hours_sleep(allButLast 3)) | mean(hours_sleep(last 3)) | 1 -0.5 * ((hours_sleep(last 3) - 8)**2)**0.5

In this example, hours_sleep is a Variable. Here the mean of the last 3 entries of 'hours_sleep' is compared to the mean of all entries before, which acts as the trigger. That is, the rule will be activated when mean(hours_sleep(last 3))>=mean(hours_sleep(allButLast 3)) evaluates to true. In this case a message will be given to the user once.

The part between the | indicates the value that will be communicated to the user, the message. In this case, this is the mean value of the last three entries of 'hours_sleep'.

The last past, after the second |, is an optional evaluation of the expression. It should be a function with range [-1, 1], but it will always automatically be trimmed to this region (using a hyperbolic tangent function). A value of '1' means that the message is very positive, and a value of '-1' means that the message is very negative. In this example, the absolute between the average hours slept and 8 hours is used as an evaluation. The larger this distance, the lower the evaluation is. When the user slept 8 hours, it will produce a value of +1. However, if the user slept only 4 hours on average, the evaluation will result in -1. Note that, if the user slept less than 4 hours or more than 12 hours, the value would be out of the [-1, 1] range. This is not a problem as the output will be forced in the correct range. If no evaluation is provided, a value of 0 will be used.

In general, the rule-defining syntax is:

rule [trigger_comparison] | [message_expression] | [evaluation_expression]

Where:

1. [trigger_comparison] is of the form [expression 1] [comparison] [expression 2]
2. [expression 1], [expression 2], [message_expression] and [evaluation_expression] are any valid expression, described further below.
3. [comparison] is one of ==, >=, <=, > or <, and indicates whether [expression 1] must be equal, equal or greater, equal or smaller, greater or smaller than [expression 2], respectively, for the rule to be fired.

Expressions contain either Variables, constant numbers or both, and evaluate to a single number. Variables must always be indexed, as they generally speaking have multiple entries. Given a Variable named x, it can be indexed as x([specifier] [num]), where

1. [specifier] is one of allButLast, last, first, allButFirst
2. [num] is an integer.

Supported binary operations are +, -, /, *, ** and % (which correspond to the usual arithmetic operations, where x**y means 'raise x to the power y' and x % y means 'x modulo y'). The unary operation mean(x(...)) is also supported, with returns the sample mean of a subsequence x(...).

Approach, milestones and deliverables

Milestones

The project milestones are divided into three main parts: Implementing a human-centered design approach, the system's economical value and the software milestones.

User-centered Design

Target User-perspective: Human-Centered design

• Perform user analysis
• Describe the potential main users and their needs
• Provide several persona scenario's.
• Define boundaries for user requirements
• Research needs to be conducted on how different system features will motivate its users and trigger them to change their behaviour in a non-intrusive, engaging way.
• Secondary end-users and stakeholders (developers, the scientific community) need to be defined and described.

Potential Ethical Threats

• Negative anthropomorphism: By adding human-like features to non-human agents, it is essential to consider possible threats of cognitive deception. The user must be (and stay) aware that the responses are computationally generated.
• Paternalism: The system is designed to provide its user's insight into their behaviour and motivate them objectively to make positive changes. Hence, the system is deliberately nudging the user. A sufficient amount of care must be taken not to exploit this capability to act against the user's interest.
• Intruding one's privacy: Research has to be investigated to find an optimum amount of tradeoff between the user trusting the system enough to give a sufficient amount of data without negatively intruding the user.

Comparative advantage, product innovation and improving quality of life of its users

• Essence and uniqueness of the project need to be defined.
• Describe current state-of-the-art, combining it with essence and uniqueness to state comparative advantages.
• Define the actual perceived gain of the end-user.

Economical perspective

Economical value

In this section, the preferences of the given users are described that determine the economical value of our product. This can be defined by a survey/questionnaire or by market-research.The economical value of the product is the benefit that the costumers receive from the usage of the AI software. In the case of the specific device we develop, this could be the motivation, joy, health,fun..etc. This value is not an objective characteristic, but rather subjective, since it differs by its user's needs and expectations. Because of this diversity, our proposal is a survey conduction before the start of the program to collect enough information for a fully personalized service. On this way, the economical value to the customers (EVC) can be determined and the market price of the software can be quantified. \\ After the market-research, we plan to create a competitor-analysis which helps us to see which additional tools we need to implement and what the essence and uniqueness our product could be compare to our competitors. This step will also help us to narrow or extend the list of stakeholders we want to approach. This information will enable us to create a value network,a cash-flow for the upcoming semester and to develop a business plan.

Stakeholder analysis

A stakeholder analysis of an issue consists of finding the equilibrium of different demands from different perspectives. The stakeholder map shows which stakeholders will be considered, moreover, it will help to identify the interests and mechanisms of the stakeholders to influence other stakeholders, key people, competitors and to reduce potential risk. The center is the online platform in the center which connects every stakeholder and provides access to the AI assistant. The main target group is the users, described above. With the marketing, the first targeting would reach the bigger associations, companies or universities, furthermore individuals who personally are interested. The idea is to include specialists, such as dietitians, psychologists and personal trainers. The data analysts are mainly members in our current team who could work in collaboration with the specialist as an exchange in knowledge and expertise. Our team would provide referencing to the specialists by our customers in case the users wish to use the help of physical specialists, e.g. receive a proper diet plan from a dietitian, set a bigger goal for weight loss with a personal trainer or get better help from a psychologist. The help of the specialists could be included in the watch.

The collaboration with bigger companies e.g. IT companies where the employees are required to work long with a busy schedule or to do night-shifts would give an opportunity to help to maintain health goals for the employees. Universities could also profit from the services and help the well-being of their students and employees.

Competitor analysis

In conclusion, most AI assistants are used for marketing strategies or for analytical tasks. The complexity of the health and well-being related software is very low. The AI Assistants are mainly used for asking repetitive questions in the form of daily reports and to do generic measurements with Smart bracelets or watches. Compared to these devices, we concluded that our AI would bring new functionalities to the market. In reflection to other AI assistants, Motis uses its personalized questionnaire during the set-up of the software and based on that analysis the performance of the user, gives feedback and guidance with subjective questions during the day. Our team targeted four perspectives and decided to focus on well-being, healthy eating, sports activity and sleeping.

The main functionality that made our product outstanding is the use of the self-reflection technique on the users. After doing market research and conducting questionnaires, we realized the main goal is the increase of motivation. In order to accomplish this, the users reflect on their own performance and answer their own questions such as why they make specific decisions, how their decisions influence them and how they can use their knowledge for their own benefit. During the market research, one of the obvious realizations was that people lose interest just by seeing notifications or comparisons to other users.

Therefore, our product would rely on incorporating strategies from cognitive-behavioural therapy, accepting and committing therapy, mindfulness, and other science-based approaches. This could be the key element to increase intrinsic motivation. The Youper named software stands the closest to our idea, but it focuses on the stress and mindfulness perspectives.

Compared to Youper we would add sport performance measurements and diet helps. As seen in the stakeholder analysis, we would involve additional specialists in the project which would give more opportunities and better reliability. Additionally, Wysa, the interactive penguin assistant provides similar services . The penguin assistant has a highly developed AI system for any kind of mental therapy, although the software deals only with mental well-being. With Motis we tried to combine all the options together and create something that deals with not only mental well-being but also with the physical state.

Essecially, Motis is the combination of existing softwares in the market and is a needed technology based on the research we conducted above. Motis is not an analytical assistant or a simple reminder, but a technology that helps humans to achieve their goals with building up their own motivation. In many aspects, we trieed to build a unique assistant that differs from the others and adds to the existing ones.

Business plan, development & strategy

Considering business model, a small market research was made to see how much it would cost to set up a website, advertise and involve specialists until the moment some profit could be earned. The calculation was based on simple online browsing of specific companies who provide help with website development, privacy policy, accountancy or online advertisement.. etc. We aimed to pick the most affordable options and minimize the costs. The picture below can be seen zoomed in as well.

Financial overview of 9 months

The idea was to start with the website development and implementation of the security footage once team members finished the interface of Motis. This is the first part which would involve a third party. This would involve the expenses of the hostage, domain, themes and additional application. From the second month the advertisement and marketing would start. Hopefully, a successful advertisement will draw the attention of curious specialists who would like to try the trial month of Motis. If a user requests professional help, the person will be redirected to the required specialists. As a small prediction we expected psychologists and physioterapists to be interested at the beginning. The interest rate would rise not only because of the e-commercial, but also because of the reference from among specialists. The main income source is expected to come from the specialists, as once they succeed and continue, Motis gains a profit of 25% of the patients' price per specialists they make in the website. From July,we expect to have the first income from speicialists, which is the already calculated price in the column. The 25(100) 20(80) 12.5(50) (this part is in progress)

Zoomed in image of the financial overview between March and July

Zoomed in image of the financial overview between August and December

As the table shows above, the first positive income number would appeare after almost 9 months while paying for the subscriptions for legal issues, website development and advertisement. As mentiones, this is a fictive overview of a possible business plan that of course could be further developed or adjusted based on unexpected situations which are expected.

Visualized Free cashflow per month in Euros

Software milestones

1 Startup

• Research what technologies are feasible to implement, and potentially applicable to reach the requirements
• Division in modules with (relatively) independent functions that can be developed and tested independently
• Create specific requirements for different modules
• Create designs for various modules
• Define interfaces between modules

2 Rough Scattered Prototype

• A functional yet limited user interface is present, without taking into account human factors design.
• Working content-generating networks have been implemented, but the output does not yet need to be fine-tuned or adaptive to input

3 Connected Prototype

• A basic database is operational
• The interface can accept inputs, pass the input information to the database. Human factor design will be implemented into the interface.
• The decoder can read the database and generate output in the UI. The output does not yet need to be perfectly adjusted to the database’s content.
• The Question-generator can generate output to be displayed in the UI

4 Rough Complete Prototype

• Users are able to select which variables will be logged.
• Users are able to delete data
• Users can request transparency of the data gathered (whether this is just a textual description, direct access to the database, or otherwise)
• The Question-generator produces human-like questions that align with the input fields
• The decoder produces outputs that correctly reflect nontrivial information in the database.

Presenting the Idea

For a quick and clear overview of the system's main requirements and an example of the prototype, visit the following link:

https://www.youtube.com/watch?v=CaCJMHHMIRE

Literature Review

Due to bugs in the installation of the LaTeX engine of the wiki, mathematical expressions cannot be shown here. See the following Overleaf file for the literature review, and references: Literature review Overleaf file.

Results

The prototype has almost in its entire been implemented and tested, according to the specification in #Software Design. Because the development team currently prioritizes the wiki, the question-parsing from the configuration file and the question scheduling are still unfinished.

Future work

More accessible intermediate user-interface

While the configuration-file interface may already be a great deal less daunting to domain specialists with no programming experience, it is speculated that it may still introduce a learning threshold and/or feel outdated. A simple graphical interface, in which domain specialists can define new Variables, Rules and Questions with buttons, drop-down menus and typed input-fields may be even more inviting and modern. It could also restrict user input, avoiding any possible syntax errors. Time constraints are the reason this approach has not yet been used.

Liberal Paternalism

The book Nudge: Improving Decisions about Health, Wealth, and Happiness by Richard H. Thaler and Cass R. Sunstein explains how subtle ways of presenting choices can make a large impact on human behavior. Motis is a suitable application to implement those 'nudges': the feedback and the questions can change user's behavior for the better or the worse.

Social pressure

Human behaviour can be strongly influences by information about what other people do. For example, a classical study of the effect of group pressure on human judgement is Asch's line-length judging experiment . More recently, Salganik, Dodds and Watts (2016) show how certain songs in a music webstore can become more popular than others, simply by showing how many downloads they received. Note that these are examples of external motivation, unlike the effects in #Influence the user's intrinsic motivation.

These findings can be used to make Motis more persuasive. It can be implemented in various ways to promote desirable behavior in users. It is, for example, possible to have Motis simply report large numbers of people engaging in the desirable behaviour. However, when not based on actual data this may become lying, which would raise serious ethical issues.

A friendlier way would be to centrally collect statistics about various Motis-users, and present the number of users engaging in an activity to the to-be-persuaded user. Note that this would require data acquisition from users, which violates the privacy requirements of the system unless explicit consent is given by the user.

Public data could also be used. If, for example, it has been published what percentage of the population engages in a particular activity, then this finding could also be reported by Motis. A centralized server may be needed to provide up-to-date data, but the one-way flow of information (from server to end-user devices) would create no privacy issues. To increase the strength of the nudge, it may be helpful to find a strict subset of the population where the user identifies with, and report the desired statistic explicitly for this subset.

Replacement of the domain specialist

Motis is configured by domain specialists that determine the variables being tracked, questions being asked, rules when the output should be given and the output itself. This makes it a widely employable tool which can be adjusted to each individual user. Although this allows for an anthropomorphized way of communicating to the user there are a few limitations to it, because a domain specialist cannot come up with an unlimited amount of questions and feedback output. Since everything is hardcoded it is unavoidable that there will repetition in questions and the feedback that is given to the user. This gives a limitation to how anthropomorphized the communication with the user can be.

To overcome these limitations the domain specialist could be replaced by emerging machine-learning technologies. This would allow for unique questions and feedback to be generated automatically which would increase the anthropomorphism of the application. A few machine-learning technologies applicable on our application are elaborated below.

Natural Language Processing

The input a user can give to Motis is heavily restricted to mostly numerical or multiple choice answers. This is done to make sure the input data can easily be stored and used to produce feedback, but the downside is that the communication with Motis feels less human for the user since only numerical or multiple choice answers can be given. Being able to give full sentences as answers would increase the anthropomorphic feeling a user has with Motis. This could be done by using Natural Language Processing.

NLP is the field of processing and analyzing natural language data. In the last decennium machine learning has revolutionized the field of NLP. The two main types of Deep Neural Networks (DNNs), Convolutional Neural Networks (CNNs) and Recurrent Neural Networks(RNNs) are widely explored to handle various NLP tasks. In our system RNNs could be used since these perform well in key phrase recognition which is necessary in a question-answer setting.

Natural Language Generation

Creating automatic, personalized questions and feedback could be done using Natural Language Generation (NLG), which is a process that produces natural language as output. RNNs have proven to be very effective in NLG. .

Context is pretty important in the communication, namely which variable is used, what sentiment does the answer of the user have (in case of NLP), so the gated contexts to sequences (gC2S) that is proposed by Tang, Yang, Carton, Zhang and Mei (2016) . could be a good approach for the system. A drawback of this approach could be that there is not enough training data available, since the training data needed would have to be quite specific, but this would be a drawback in every approach neural networks are used since every neural network depends on training data.

References