Prototypes of User Interfaces for Mobile Applications for Patients with Diabetes

: We live in a heavily technologized global society. It is therefore not surprising that efforts are being made to integrate current information technology into the treatment of diabetes mellitus. This paper is dedicated to improving the treatment of this disease through the use of well-designed mobile applications. Our analysis of relevant literature sources and existing solutions has revealed that the current state of mobile applications for diabetics is unsatisfactory. These limitations relate both to the content and the Graphical User Interface (GUI) of existing applications. Following the analysis of relevant studies, there are four key elements that a diabetes mobile application should contain. These elements are: (1) blood glucose levels monitoring; (2) effective treatment; (3) proper eating habits; and (4) physical activity. As the next step in this study, three prototypes of new mobile applications were designed. Each of the prototypes represents one group of applications according to a set of given rules. The most optimal solution based on the users’ preferences was determined by using a questionnaire survey conducted with a sample of 30 respondents participating in a questionnaire after providing their informed consent. The age of participants was from 15 until 30 years old, where gender was split to 13 males and 17 females. As a result of this study, the speciﬁcations of the proposed application were identiﬁed, which aims to respond to the ﬁndings discovered in the analytical part of the study, and to eliminate the limitations of the current solutions. All of the respondents expressed preference for an application that includes not only the key functions, but a number of additional functions, namely synchronization with one of the external devices for measuring blood glucose levels, while ﬁve-sixths of them found suggested additional functions as being sufﬁcient.


Introduction
Information and Communication Technologies (ICT), medical and sociological research form the base for Ambient Assisted Living (AAL) which is being developed further by many international projects.One of them under the EU (European Union) COST (European Cooperation in Science and Technology) Action IC1303 AAPELE (Architectures, Algorithms and Platforms for Enhanced Living Environments) also dealt with the concept of Enhanced Living Environments (ELE) and Activities of Daily Living (ADL), which can be identified automatically by sensors available in smartphones [1,2].
The recognition of ADL can also be beneficial for people with diabetes mellitus where the using of mobile software solutions can result in reaching a better health condition of the users [3].Modern technologies, including smartphones, have become irreplaceable in healthcare [4], hence the new term coined to describe mobile technologies in healthcare: mHealth [2,3].Smartphones have already proven their usefulness in healthcare, and they have been found to be helpful in areas such as smoking cessation, proper diet, healthy living, sexual and reproductive health, etc. [5].The success of mobile technologies is thanks to their global availability and accessibility [6,7].
This study investigates the use of mobile phones and their application in a specific area of healthcare, namely, the treatment of diabetes mellitus.Diabetes mellitus is a disease caused by the deficiency of the insulin hormone.This deficiency has one of two causes, according to which we can distinguish two basic types of the disease: type I and type II diabetes [8].Globally, there is a rising number of diabetes patients [9,10].The main causes of this increasing trend include not only the ageing population and unhealthy lifestyles, but also the improving quality of healthcare, improvements in the diagnostics of the disease, and a growing number of autoimmune diseases [11].It follows that the issue of diabetes is a topical one, and mobile applications may play an important role in treating this disease.Relevant literature sources [12,13], which reveals that though mobile applications are generally beneficial in the treatment of diabetes mellitus [3], their functionality is insufficient, and applications do not make use of their full potential [14].Some studies clearly indicate that the results of diabetes patients improve when they use mobile applications and other technologies.The most commonly tracked value was the HbA1c level (blood glucose), which always decreased with the use of the applications [15].Other studies are primarily concerned with the contents of the applications.One study defines four key elements which, according to the authors of the studies, should be included in mobile applications for diabetes.These elements are: blood glucose levels monitoring, effective treatment, proper eating habits, and physical activity.In general, these functions can be regarded as the basic tools that a diabetes patient requires for effective self-management [16].However, the results show that most applications do not include all four elements, and the general conclusion drawn in all the studies is that there are major limitations in the contents of the applications [13,17].Other limitations mentioned in the studies [15,18] are the lack of personalized feedback [19,20], and insufficient support regarding the patient's behavior, with the aim of encouraging them to learn new skills and to build new habits [21][22][23][24].
Therefore, the aim of the paper is a proposed mobile application for people with diabetes mellitus, which removes the main identified shortcomings.

Current Mobile Application for Diabetes Mellitus
Based on the latest review literature of available and the most suitable software solutions (e.g., [18]) Diabetes: M were taken as a reference software solution.Due to that fact, that respondents of our questionnaire were from the Czech national diabetes community, we asked them for the most commonly used applications, from which another four most used was selected: Mobiab [25]; Diamonitor [26]; Diabetes-Glucose Journal [27]; and Diabetes Kit Blood Glucose Logbook [28].Out of these five selected applications, three were mobile-based, one was web-based, and one was a mobile application communicating with its web counterpart.By making a comparison of these applications (Table 1) in relation to the four key functions, which each diabetes management application should contain, it was found that they all included the function of blood glucose monitoring.However, with respect to the other key functions, the results were less encouraging.Medication management, diet monitoring, and physical activity tracking were missing in some of the applications.This confirms the findings of the theoretical studies regarding the insufficient content of the applications, despite their availability in several versions and their inclusion of many additional functions [28][29][30].

No detailed statistics
Table 1 provides a summary of existing mobile and web applications.It compares the implementation of the applications, the platforms for which they are created and, above all, their content on the functional side.A summary of the individual features and the applications that they include is provided below.None of the previous approaches have addressed the defined problem adequately.Many applications do not generate reports, do not communicate across smart devices, do not solve other physical activity of the individual, nor do they "rejoice" to adhere to the regime in the area, although it is crucial for patients.Even among the applications mentioned above, there are deficiencies, such as not communicating with a doctor, not providing reprograms.

Study Design
Firstly, there was an evaluation of scientific studies dealing with the topic of diabetes and mobile applications and the content of such applications, their functions, and the ways in which they assist their users.
Following the definition of these factors, application prototypes were designed.The design and implementation of the application UI (User Interface) prototypes were divided into three versions.These three versions were achieved by combining the functions included, using different graphic designs and taking into account various operating systems [31].Each of the prototypes represents a particular group of applications, its advantages and disadvantages, and a comparison of the prototypes should determine the optimal solution.

Data Analysis
A questionnaire survey was carried out on a sample of 30 respondents (aged 15-30) to verify the functionality and user-friendliness of the proposed solution.The proposed solutions were tested on a sample of users to determine which combination of functions and which graphic designs are preferred, which services are the most important for users, and whether findings derived from the analysis of the studies and applications will be confirmed.
The data collection period was at October and November 2017, addressing respondents and collecting data via social networks, where there are groups of individuals with diabetes.The distribution of respondents by gender is 17/13, in favor of women.The upper age group (23-30 years) accounted for 60% of all respondents, and most of the respondents were university educated people

Data Calculation
Descriptive analysis was performed to provide information about the sample frame.MS Excel was used for data analysis.
A new solution was presented by the means of prototypes of new mobile applications, designed for diabetes mellitus patients.To implement the new solution, visual designs [32] of the diabetes application prototypes were used [2,31,33,34].The designs were divided into three categories.These three application design versions were achieved by combining the features contained by the applications, different graphical solutions, and a variety of operating systems.Each of the prototypes represented a certain group of applications, with its advantages and disadvantages, and a comparison of them should provide the best solution.
Testing the implemented solutions on selected human samples made it possible to examine the combination of features and the graphical environment that users prefer, according to the features that are most important to them, and whether the knowledge that is gained from research and application research is confirmed.
All of these three versions contain one functionality in the form of monitoring blood glucose levels.This function is key, and diabetic applications would be meaningless without it.This functionality is offered by all applications, regardless of their quality, even when compared to applications that have been selected for analysis.Another interesting phenomenon that we observed when comparing the applications was the inclusion of features that are not perceived as being primary.These features are sometimes included in the applications with the same frequency as key features.For example, the possibility of sharing data with another person (a doctor), or of generating reports.These functions are not considered to be the most important, as they are compared with the same frequency as effective treatment or eating management.
The rules for designing individual prototypes are set out in the following sections.

A Prototype according to the Current State of the Applications
The first prototype represents the current state of the applications, as determined in the research part of this project.The current state is illustrated by a prototype that includes only two key functions (blood glucose level monitoring and medication management) and additional non-essential functions (Figure 1).This prototype was included in testing, to find out whether users are satisfied with the current state, or whether they would prefer the new applications that are designed in keeping with the findings of the relevant studies, and which contain improved and more complex functions.
Computers 2018, xx, x FOR PEER REVIEW 5 of 14 Testing the implemented solutions on selected human samples made it possible to examine the combination of features and the graphical environment that users prefer, according to the features that are most important to them, and whether the knowledge that is gained from research and application research is confirmed.
All of these three versions contain one functionality in the form of monitoring blood glucose levels.This function is key, and diabetic applications would be meaningless without it.This functionality is offered by all applications, regardless of their quality, even when compared to applications that have been selected for analysis.Another interesting phenomenon that we observed when comparing the applications was the inclusion of features that are not perceived as being primary.These features are sometimes included in the applications with the same frequency as key features.For example, the possibility of sharing data with another person (a doctor), or of generating reports.These functions are not considered to be the most important, as they are compared with the same frequency as effective treatment or eating management.
The rules for designing individual prototypes are set out in the following sections.

A Prototype according to the Current State of the Applications
The first prototype represents the current state of the applications, as determined in the research part of this project.The current state is illustrated by a prototype that includes only two key functions (blood glucose level monitoring and medication management) and additional non-essential functions (Figure 1).This prototype was included in testing, to find out whether users are satisfied with the current state, or whether they would prefer the new applications that are designed in keeping with the findings of the relevant studies, and which contain improved and more complex functions.

A Prototype with Key Functions
The second prototype was designed to integrate all of the four key functions, which should be included in all diabetes applications.These are, however, the only functions offered in the prototype.User testing will show whether users will demand other functions, such as statistics and charts, which were included in all the other tested prototypes, or whether the inclusion of the four key functions, which are in theory deemed to be the most important ones, will compensate for the absence of these informative functions (Figure 2).

A Prototype with Key Functions
The second prototype was designed to integrate all of the four key functions, which should be included in all diabetes applications.These are, however, the only functions offered in the prototype.User testing will show whether users will demand other functions, such as statistics and charts, which were included in all the other tested prototypes, or whether the inclusion of the four key functions, which are in theory deemed to be the most important ones, will compensate for the absence of these informative functions (Figure 2).

A Prototype with Extra Functions
The previous two prototypes are assumed to be imperfect, as they do not make full use of the potential of mobile applications.The third prototype is intended to be the best solution, and to eliminate the limitations of the previous two prototypes.This was achieved by including all of the four key functions as well as some extra functions.These extra functions include the option to generate statistics and charts, share data with friends, and create detailed reports to share with the patient's physician.Furthermore, there is an educational module, and the option to influence the content of the application.In this case, there are two prototypes, one for each operating system.One prototype was designed for Android, and the other for iOS (Figure 3).Both prototypes have the exact same functionality; the only difference is the operating system, hence they also have a different user interface.Dividing one prototype into two designs with the same functions is a deliberate decision that is made, in order to test whether the operating system, or the user interface, plays any role for the users.

A Prototype with Extra Functions
The previous two prototypes are assumed to be imperfect, as they do not make full use of the potential of mobile applications.The third prototype is intended to be the best solution, and to eliminate the limitations of the previous two prototypes.This was achieved by including all of the four key functions as well as some extra functions.These extra functions include the option to generate statistics and charts, share data with friends, and create detailed reports to share with the patient's physician.Furthermore, there is an educational module, and the option to influence the content of the application.In this case, there are two prototypes, one for each operating system.One prototype was designed for Android, and the other for iOS (Figure 3).Both prototypes have the exact same functionality; the only difference is the operating system, hence they also have a different user interface.Dividing one prototype into two designs with the same functions is a deliberate decision that is made, in order to test whether the operating system, or the user interface, plays any role for the users.

Formulated Assumptions
Following the design of the prototypes, assumptions about the results of the prototype testing with a sample of users were formulated.First, it was assumed that the first prototype, that is, the one that reflects the current state of the applications, would be judged to be the worst.The reason for this assumption was the lack of key functions, which reflects the current state of most diabetes mobile

Formulated Assumptions
Following the design of the prototypes, assumptions about the results of the prototype testing with a sample of users were formulated.First, it was assumed that the first prototype, that is, the one that reflects the current state of the applications, would be judged to be the worst.The reason for this assumption was the lack of key functions, which reflects the current state of most diabetes mobile applications, and the simplicity of the application in other functions.As for the second prototype, it would be tested with a special focus on its evaluation by users in relation to its functionality.This means that attention is paid to whether the respondents unconsciously appreciate the presence of all the key functions, and are satisfied with the application, or whether they judge the application to be inadequate because of the lack of additional functions.
Finally, it was assumed that the prototype with extra functions would be evaluated most favorably, because it was based on findings derived from relevant studies and research.This prototype included all the key functions that should be offered by a mobile application for diabetes, as well as additional functions that exploit the full potential of the mobile application and aim to increase its usefulness.

Respondent Sample Description
The prototype testing was conducted with a sample of users by the means of a questionnaire survey after providing their informed consents.The size of the sample was 30 respondents, as this sample size was determined as minimum for this type of questionnaire, according to literature [35].
The questionnaire was therefore targeted at what is known as Generation Y (age 15-30) [36].The reason for the choice of this age range was the fact that Generation Y is familiar with technologies such as smartphones and mobile applications [37].It is the demographic group that investigates these technologies most often.
Thirty respondents took part in the testing, while the gender and education, as well as the age distribution of the respondents is shown in Table 2.The distribution of the respondents according to their highest education attained is shown.The largest group comprised respondents with university education (36%), while the second-largest group was composed of respondents with a secondary education, having completed a school-leaving examination (30%).

Health and Technical Information Overview
In response to the question of whether they suffered from diabetes, 27 respondents answered in the affirmative and only three respondents answered "no".
As for which type of diabetes the respondents had, most respondents stated type I diabetes (17 respondents).Six respondents stated that they had type II diabetes, and four respondents stated that they had gestational diabetes.
All of the respondents stated that they own a smartphone.The operating systems of their smartphones were either Android (22) or iOS (8).There was no other operating system.
The technical information also included the question of whether smartphone owners used mobile applications for diabetes treatment.Out of 30 respondents, only 11 reported that they use diabetes mobile applications, while the remaining 19 respondents stated that they do not use such applications.
Those respondents who used mobile applications for diabetes most often mentioned the following ones: Diabetes:M, SiDiary, MiniMed Connect, and Contour.

Overview of Responses Concerning the Application Prototypes
Next, there was a block of questions regarding the individual application prototypes.Considering the difficulty of interpreting the respondents' answers, some of their responses were interpreted through the use of figures, which is the most straightforward way of presenting the results.
The answers to the question of whether the application prototypes included all the basic functions expected by the respondents were as shown in Table 3.If a respondent selected "no" for any of the applications, meaning that the application did not contain the basic functions, the following question offered the respondent the opportunity to specify which functions were missing in the application.
With prototype number one, that is, the prototype following the current state of the applications, the most common feedback was the lack of diet management.This was the most frequently reported limitation, which means that the respondents did miss this feature.Further comments on this application prototype related to its generally limited functionality and lack of complexity, such as missing options to monitor body weight, calculate how much energy must be expended in physical exercise with respect to the food consumed, set limits and goals, view statistics in charts, etc.
Other additional functions mentioned were those contained in the other prototypes (generating reports, communicating with the physician and sharing data) and further functions not included in any of the prototypes (connection with the insulin pump and Global Positioning System (GPS) location) [38,39].
With prototype number two, that is, the one covering the key functions, there was less criticism, although the respondents naturally still missed some functions.The missing functions were similar to those for the previous prototype, except for those already eliminated by including the key elements in this second prototype.Apart from comments along the lines of "generally not enough functions", the most frequently reported limitations were again the missing option to create reports, share data, and connect to GPS and to the insulin pump.New comments on this prototype mentioned the missing option to show general overviews and statistical graphs, and to calculate bolus insulin doses.
With prototypes numbers three and four, that is, the prototypes with extra functions, 85% of the respondents were satisfied with the functionality of the application.Those respondents who were not satisfied with this prototype repeated the same limitations in their comments that had already been mentioned for the previous two prototypes, and that were not eliminated in this prototype either.These limitations included the missing GPS location and connection to the insulin pump.
Another question related to the user interface of the application, and the respondents were asked whether they found it intuitive and easy to use.The respondents could express their opinion by selecting one of the following statements: "Yes"; "Mostly yes"; "Mostly no"; and "No".The respondents' answers were consistent.None of the respondents chose "No" or "Mostly no".With prototype number one, the option "Yes" was selected by 26 respondents (four respondents selected "Mostly yes"), while with the remaining three prototypes, the option "Yes" was chosen by 24 respondents (six respondents chose "Mostly yes").
The following question concerned the graphic design of the prototypes, and its purpose was to collect feedback from the respondents regarding the visuals of the application.The results following the respondents' answers are expressed in Table 3.The figure illustrates that the feedback was positive overall, and that none of the respondents selected the option "Very bad" for any of the prototypes.
In this study, the respondents had already been asked about their opinion regarding basic functions.The follow-up question inquired into the respondents' impressions regarding the functions overall, and not only basic functions (Table 3).
In another follow-up question, respondents were asked to name additional functions, elements, or features that they knew from other applications that they would welcome in the prototypes presented.However, since only 37% of the respondents used mobile applications for diabetes, the answers were few, and similar to those already stated at the beginning of the questionnaire.That is, the required functions included a connection with the insulin pump, diet management (with the prototype representing the current state of the applications), and GPS location (regular routes, such as from home to work) [40].
Those respondents who already used diabetes mobile applications were offered the option to state how likely they would be to switch to the given prototype from their current application (Table 3).
The respondents who answered that they would not switch to the particular prototype were asked to state the reasons for their preference.In prototype number one, the reason was the lack of key functions, particularly diet management.The second prototype already included all the key functions, but it was found that respondents regarded overviews, statistics, and graphs as essential.The most common reason regarding the prototype with extra functions for the iOS operating system was that few respondents owned a smartphone running iOS.As for the Android version of the prototype, the reasons stated by the respondents were the limitations of the prototype regarding its functions, and the fact that they were satisfied with their current application.
The last question aimed to determine the order of the individual applications according to the respondents' preferences.The respondents were asked to order the application prototypes from the best to the worst, according to their opinions.The rankings are shown in Figure 4.The figure illustrates that the prototypes with extra functions were ranked as the best, and that there were no differences in the rankings of the two prototypes.The prototype with key functions was ranked second, and the prototype according to the current state was evaluated as being the worst.
respondents owned a smartphone running iOS.As for the Android version of the prototype, the reasons stated by the respondents were the limitations of the prototype regarding its functions, and the fact that they were satisfied with their current application.
The last question aimed to determine the order of the individual applications according to the respondents' preferences.The respondents were asked to order the application prototypes from the best to the worst, according to their opinions.The rankings are shown in Figure 4.The figure illustrates that the prototypes with extra functions were ranked as the best, and that there were no differences in the rankings of the two prototypes.The prototype with key functions was ranked second, and the prototype according to the current state was evaluated as being the worst.The best ranking prototype was clearly the one with the extra functions, that is, the prototype that aimed to respond to the theoretical findings and took into account the limitations of the current applications, attempting to eliminate them.With this prototype, however, it was not confirmed whether the operating system or the user interface played any role in the respondents' evaluations.As expected, the second place was taken by the prototype with key functions.Although the key functions were Respondent preferences (the higher the number, the higher the preferences) The best ranking prototype was clearly the one with the extra functions, that is, the prototype that aimed to respond to the theoretical findings and took into account the limitations of the current applications, attempting to eliminate them.With this prototype, however, it was not confirmed whether the operating system or the user interface played any role in the respondents' evaluations.As expected, the second place was taken by the prototype with key functions.Although the key functions were included in the prototype, the respondents expressed some degree of dissatisfaction with the functions of this application.The respondents commented on the lack of features that are not regarded as key functions in relevant studies, but which proved to be important to the respondents.The application prototype representing the current state was unsurprisingly ranked in last place, and the respondents expressed their dissatisfaction with the current state in other questions as well.However, not even the best ranking prototype could eliminate all the limitations, at least, according to the respondents' opinions.This prototype lacked certain functions which the respondents required.These functions included a connection to the insulin pump and GPS location.

Discussion
The prototypes aimed to eliminate the limitations revealed in the analysis of the state of current mobile applications.Limitations in the content of the applications was dealt with by including all the key functions which are:

•
functions that support personalized feedback, • informative functions intended to modify the user's behavior in keeping with the limitations imposed by the disease, • and functions that exploit the communication potential of smartphones.
Current limitations in applications were eliminated by creating the content with GUI best practices [34,41], which involved dividing the content into zones containing primary, secondary, and tertiary content.Furthermore, functions that support personalized feedback were included, such as charts, statistics, and measurement reports.The results of the testing are in accordance with the established assumptions, and the analysis of the relevant literature [11][12][13]15,16,18].It unambiguously confirms the results of other studies that also highlight the shortcomings that the current proposal eliminates, comprehensive diabetes management [42], individualizing the content [43,44], and synchronization with one of the external devices for measuring blood glucose levels [45,46].At the same time, the proposed solution, and especially the research to verify the solution has certain limits.Namely, assumptions about that the prototype with extra functions would be evaluated most favorably, as described in Section 3.4.and the related study design.Furthermore, a small sample of respondents did not correspond to the standard population structure.Respondents were especially young people with a higher level of education.The challenge, therefore, is for older generations of diabetes who may have a problem with technology, and because, as demonstrated by the statistical test, there is a positive correlation between the use of technology in general and the positive approach of applications.It is also likely that if the target group were to be even older, it would have a significant impact on the design.In the framework of future research, the focus will be on the further development of the application and its verification in a representative sample.
At least 90% of all people with diabetes are patients with type 2 diabetes mellitus (DM2), which may occur at any age.However, the risk group is over 40 year old with overweight, hypertension, and high blood lipids.

Conclusions
Diabetes mellitus is one of the chronic illnesses that is growing in the populations of developed countries.Self-monitoring [47] is a prerequisite for the proper education of people with diabetes.Better education increases adherence, i.e., the extent to which patient behavior (drug use, compliance with regimens) coincides with medical advice or medical standards.However, adherence also has an impact on financial costs, as drug consumption decreases and delays possible complications [48][49][50].With the current rapid development and increased use of modern technologies, mobile applications for diabetes shows that existing solutions do not provide a comprehensive service about maximum adherence [51].A newly designed solution that focuses primarily on ensuring features like: the option to generate statistics and charts, share data with friends, create detailed reports to share with the patient's physician, an educational module, and the option to influence the content of the application, gives the potential to increase the formation of the right habits of patients with diabetes [52].

Funding:
The work and the contribution were supported by the SPEV projects "Smart Solutions in Ubiquitous Computing Environments", and "Investments under the Industry 4.0 concept", the Faculty of Informatics and Management, University of Hradec Kralove, Czech Republic.

Figure 1 .
Figure 1.A prototype according to the current state of the applications.

Figure 1 .
Figure 1.A prototype according to the current state of the applications.

Figure 2 .
Figure 2. A prototype with key functions.

Figure 2 .
Figure 2. A prototype with key functions.

Figure 3 .
Figure 3.A prototype with extra functions (iOS and Android).

Table 1 .
Comparison of the selected solutions.

Table 2 .
Structure of respondents.

Table 3 .
Summary of responses concerning the application prototypes.